diff --git a/Writing/coding-age-ai.md b/Writing/coding-age-ai.md index 4420d4d..48103a6 100644 --- a/Writing/coding-age-ai.md +++ b/Writing/coding-age-ai.md @@ -26,7 +26,9 @@ authors: - Validation - "Writing – original draft" - "Writing – review & editing" -citation: true +citation: + doi: 10.5281/zenodo.16633122 + url: https://drezil.de/Writing/coding-age-ai.html google-scholar: true fileClass: authored bibliography: @@ -264,6 +266,7 @@ one‑sentence feature description plus any additional Q&A with the stakeholder. it in _Open Questions_. 4. After questions are answered reply exactly: Ready to generate the PRD. 5. On a user message that contains only the word "go" (case‑insensitive): + - Generate /tasks//PRD.md following _Output_ spec. - Reply: /PRD.md created – review it. @@ -324,16 +327,19 @@ Every specification should include: ``` 2. **Scope and Boundaries** + - What is included/excluded - Dependencies on other specifications - Relationship to other components 3. **Detailed Requirements** + - Structured by logical sections - Clear, unambiguous language - Examples where helpful 4. **Error Handling** + - How errors should be handled - Fallback behaviors - Edge cases diff --git a/dist/About/Experience.html b/dist/About/Experience.html index e7981cf..360d241 100644 --- a/dist/About/Experience.html +++ b/dist/About/Experience.html @@ -2,7 +2,7 @@ - + @@ -32,17 +32,19 @@ ul.task-list li input[type="checkbox"] { + - - + + + - - - + + + + - - + + + - - - + + + + - - + + + - - - + + + + - - + + + - - - + + + + - - + + + - - - + + + + - - + + + - - - + + + + - - + + + - - - + + + + - - + + + - - - + + + + - - + + + - - - + + + + - - + + + - - - + + + + - - + + + - - - + + + + - - + + + - - - + + + + - - + + + - - - + + + + - - + + + - - - + + + + - - + - - - - - - - - - -
-
+
Draft
@@ -316,26 +313,30 @@ ul.task-list li input[type="checkbox"] {
-

This compliance-report also need a deep-thinking model, like the specification beforehand.

Tasks

-
---
+
---
 description:
 globs:
 alwaysApply: false
@@ -1263,7 +1273,7 @@ This is most often the most trivial step. Everything is known and formulated for
 - Never touch production data.
 - Assume all work happens in a feature branch, never commit directly to main.
 - Check the generated Document with `markdownlint` (if available), apply
-  auto-fixes and fix the remaining issues manually.

+  auto-fixes and fix the remaining issues manually.

This also works better with one of those deep-thinking models.

@@ -1286,7 +1296,7 @@ This is most often the most trivial step. Everything is known and formulated for
-User +Tipp User
@@ -1306,7 +1316,7 @@ User
-Cursor +Hinweis Cursor
@@ -1322,9 +1332,9 @@ Cursor
  • Projects in the detailed part “appear in the same order they had inside their group’s summary table” (Spec §4, bullet 3).

    • Implementation:

    -
    # ... excerpt ...
+
    # ... excerpt ...
 for od in sorted(group_projects, key=lambda p: p.project.name.lower()):
-    # renders project sections alphabetically
    
+    # renders project sections alphabetically
    • Projects are sorted alphabetically, not in the original summary-table order.
    • ✅ Groups themselves are ordered by descending project count (matches spec).
      • @@ -1419,7 +1429,7 @@ Cursor
      -Commenting the result +Warnung Commenting the result
      @@ -1454,7 +1464,7 @@ Commenting the result
      -User +Tipp User
      @@ -1474,7 +1484,7 @@ User
      -Cursor +Hinweis Cursor
      @@ -1551,7 +1561,7 @@ Cursor
      -User +Tipp User
      @@ -1565,7 +1575,7 @@ User
      -Cursor +Hinweis Cursor
      @@ -1658,7 +1668,7 @@ Cursor
      -User +TippUser
      @@ -1672,14 +1682,14 @@ User
      -Cursor +Hinweis Cursor

      I’ll help you implement the tasks from Task1*.md in the markdown rendering feature. Let me first check what these tasks entail.

      Let me first check the current state of the spec file we need to modify.

      I’ll now implement both tasks. Let’s start with Task 1.1 - amending the alphabetical ordering rule.

      -
      // ... existing code ...
+
      // ... existing code ...
 
 ## 4. Ordering Guarantees
 
@@ -1689,9 +1699,9 @@ Cursor
   [Table Sorting](./spec_table_sorting.md)).
 - In the detailed part, projects appear alphabetically by their name.
 
-// ... existing code ...
      
+// ... existing code ...

      Now let’s implement Task 1.2 - documenting the 10-line truncation rule for the Description call-out.

      -
      // ... existing code ...
+
      // ... existing code ...
 
 Missing entries from the Project-Info are omitted.
 
@@ -1719,7 +1729,7 @@ Cursor
 ```
 
 2. **Release badge** – image linking to `<web_url>/-/releases`. // ...
-   existing code ...
      
+   existing code ...

      Let me run markdownlint as suggested in the task hints to ensure our changes meet the markdown style guidelines.

      I’ve completed both tasks:

        @@ -1776,6 +1786,7 @@ Cursor title = {Field Report: Coding in the Age of AI with Cursor}, date = {2025-06-26}, url = {https://drezil.de/Writing/coding-age-ai.html}, + doi = {10.5281/zenodo.16633122}, langid = {de}, abstract = {This report presents practical methodologies and best practices for developing software using Cursor, an AI-assisted IDE. @@ -1795,7 +1806,7 @@ Cursor }
        Bitte zitieren Sie diese Arbeit als:
        Dresselhaus, Nicole. 2025. “Field Report: Coding in the Age of AI -with Cursor.” June 26, 2025. https://drezil.de/Writing/coding-age-ai.html. +with Cursor.” June 26, 2025. https://doi.org/10.5281/zenodo.16633122.
        + - - + + + - - - + + + + - - + + + - - - + + + + - - + + + - - - + + +