admin/.cursor/skills/document/workflows/task.md

Document Skill — Task Mode Workflow

Lightweight, incremental documentation update triggered by task spec files. Updates only the docs affected by implemented tasks — does NOT redo full discovery, verification, or problem extraction.

Trigger

• User provides one or more task spec files (e.g., @_docs/02_tasks/done/AZ-173_*.md)
• AND _docs/02_document/ already contains module/component docs

Accepts

One or more task spec files from _docs/02_tasks/todo/ or _docs/02_tasks/done/.

Steps

Task Step 0: Scope Analysis

1. Read each task spec — extract the "Files Modified" or "Scope / Included" section to identify which source files were changed
2. Map changed source files to existing module docs in DOCUMENT_DIR/modules/
3. Map affected modules to their parent components in DOCUMENT_DIR/components/
4. Identify which higher-level docs might be affected (system-flows, data_model, data_parameters)

Output: a list of docs to update, organized by level:

• Module docs (direct matches)
• Component docs (parents of affected modules)
• System-level docs (only if the task changed API endpoints, data models, or external integrations)
• Problem-level docs (only if the task changed input parameters, acceptance criteria, or restrictions)

Task Step 1: Module Doc Updates

For each affected module:

1. Read the current source file
2. Read the existing module doc
3. Diff the module doc against current code — identify:
   • New functions/methods/classes not in the doc
   • Removed functions/methods/classes still in the doc
   • Changed signatures or behavior
   • New/removed dependencies
   • New/removed external integrations
4. Update the module doc in-place, preserving the existing structure and style
5. If a module is entirely new (no existing doc), create a new module doc following the standard template from workflows/full.md Step 1

Task Step 2: Component Doc Updates

For each affected component:

1. Read all module docs belonging to this component (including freshly updated ones)
2. Read the existing component doc
3. Update internal interfaces, dependency graphs, implementation details, and caveats sections
4. Do NOT change the component's purpose, pattern, or high-level overview unless the task fundamentally changed it

Task Step 3: System-Level Doc Updates (conditional)

Only if the task changed API endpoints, system flows, data models, or external integrations:

1. Update system-flows.md — modify affected flow diagrams and data flow tables
2. Update data_model.md — if entities changed
3. Update architecture.md — only if new external integrations or architectural patterns were added

Task Step 4: Problem-Level Doc Updates (conditional)

Only if the task changed API input parameters, configuration, or acceptance criteria:

1. Update _docs/00_problem/input_data/data_parameters.md
2. Update _docs/00_problem/acceptance_criteria.md — if new testable criteria emerged

Task Step 5: Summary

Present a summary of all docs updated:

══════════════════════════════════════
 DOCUMENTATION UPDATE COMPLETE
══════════════════════════════════════
 Task(s): [task IDs]
 Module docs updated: [count]
 Component docs updated: [count]
 System-level docs updated: [list or "none"]
 Problem-level docs updated: [list or "none"]
══════════════════════════════════════

Principles

• Minimal changes: only update what the task actually changed. Do not rewrite unaffected sections.
• Preserve style: match the existing doc's structure, tone, and level of detail.
• Verify against code: for every entity added or changed in a doc, confirm it exists in the current source.
• New modules: if the task introduced an entirely new source file, create a new module doc from the standard template.
• Dead references: if the task removed code, remove the corresponding doc entries. Do not keep stale references.