@leeovery/claude-technical-workflows 2.1.24 → 2.1.25

package/skills/status/SKILL.md

@@ -27,32 +27,37 @@ docs/workflow/research/
 docs/workflow/discussion/
 docs/workflow/specification/
 docs/workflow/planning/
+docs/workflow/implementation/
 ```
 
+For implementation, check `docs/workflow/implementation/{topic}/tracking.md` files and extract frontmatter fields: `status`, `current_phase`, `current_task`, `completed_tasks`, `completed_phases`.
+
 ## Step 2: Present Status
 
 Research is project-wide exploration. From discussion onwards, work is organised by **topic** - different topics may be at different stages.
 
-Show a summary like this:
+> *Output the next fenced block as markdown (not a code block):*
 
 ```
-## Workflow Status
-
-**Research:** 2 files (exploration.md, market-analysis.md)
+**Workflow Overview**
 
-**Topics:**
+**Research:** {count} files ({filenames})
 
-| Topic        | Discussion | Spec | Plan | Implemented |
-|--------------|------------|------|------|-------------|
-| auth-system  | ✓          | ✓    | ✓    | in progress |
-| payment-flow | ✓          | ✓    | -    | -           |
-| notifications| ✓          | -    | -    | -           |
+| Topic | Discussion | Spec | Plan | Implemented |
+|-------|------------|------|------|-------------|
+| {topic} | {discussion_status} | {spec_status} | {plan_status} | {impl_status} |
+| ... | | | | |
 ```
 
 Adapt based on what exists:
-- If a directory is empty or missing, show "Not started"
+- If a directory is empty or missing, show `-`
 - For planning, note the output format if specified in frontmatter
 - Match topics across phases by filename
+- For implementation, derive the Implemented column from tracking file data:
+  - No tracking file → `-`
+  - `status: not-started` → `not started`
+  - `status: in-progress` → `phase {current_phase} ({n}/{total} tasks done)` — count `completed_tasks` for n; use total task count from `completed_tasks` + remaining if available, otherwise just show completed count
+  - `status: completed` → `completed`
 
 ## Step 3: Suggest Next Steps
 
@@ -75,6 +80,8 @@ Keep suggestions brief - the user knows their project's dependencies better than
 
 If planning files exist, let the user know they can view plan details:
 
+> *Output the next fenced block as a code block:*
+
 ```
 To view a plan's tasks and progress, use /view-plan
 ```

package/skills/technical-implementation/SKILL.md

@@ -166,6 +166,9 @@ Commit: `impl({topic}): start implementation`
 
 Present the existing configuration for confirmation:
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 Previous session used these project skills:
 - `{skill-name}` — {path}
 - ...
@@ -174,8 +177,7 @@ Previous session used these project skills:
 - **`y`/`yes`** — Keep these, proceed
 - **`c`/`change`** — Re-discover and choose skills
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for user choice.
 
@@ -184,6 +186,8 @@ Previous session used these project skills:
 
 #### If `.claude/skills/` does not exist or is empty
 
+> *Output the next fenced block as a code block:*
+
 ```
 No project skills found. Proceeding without project-specific conventions.
 ```
@@ -194,6 +198,9 @@ No project skills found. Proceeding without project-specific conventions.
 
 Scan `.claude/skills/` for project-specific skill directories. Present findings:
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 Found these project skills that may be relevant to implementation:
 - `{skill-name}` — {brief description}
 - `{skill-name}` — {brief description}
@@ -204,8 +211,7 @@ Found these project skills that may be relevant to implementation:
 - **`n`/`none`** — Skip project skills
 - **Or list the ones you want** — e.g. "golang-pro, react-patterns"
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for user to confirm which skills are relevant.
 
@@ -223,6 +229,9 @@ If `linters` is already populated in the tracking file, present the existing con
 
 Otherwise, present discovery findings to the user:
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 **Linter discovery:**
 - {tool} — `{command}` (installed / not installed)
 - ...
@@ -234,8 +243,7 @@ Recommendations: {any suggested tools with install commands}
 - **`c`/`change`** — Modify the linter list
 - **`s`/`skip`** — Skip linter setup (no linting during TDD)
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for user choice.
 

package/skills/technical-implementation/references/steps/analysis-loop.md

@@ -32,12 +32,14 @@ If `analysis_cycle > 3`:
 
 Analysis has run {N-1} times so far. You can continue (recommended if issues were still found last cycle) or skip to completion.
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 - **`p`/`proceed`** — Continue analysis *(default)*
 - **`s`/`skip`** — Skip analysis, proceed to completion
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for user choice. You MUST NOT choose on the user's behalf.
 
@@ -61,13 +63,15 @@ If there are unstaged changes or untracked files, categorize them:
 - `{file}` ({status: modified/untracked})
 - ...
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 - **`y`/`yes`** — Include all in the checkpoint commit
 - **`s`/`skip`** — Exclude unexpected files, commit only implementation files
 - **Comment** — Specify which to include
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for user choice.
 
@@ -145,13 +149,15 @@ Sources: {sources}
 **Tests**:
 {tests}
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 - **`a`/`approve`** — Approve this task
 - **`s`/`skip`** — Skip this task
 - **Comment** — Revise based on feedback
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for user input.
 

package/skills/technical-implementation/references/steps/task-loop.md

@@ -44,13 +44,15 @@ Present the executor's ISSUES to the user:
 
 {executor's ISSUES content}
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 - **`r`/`retry`** — Re-invoke the executor with your comments (provide below)
 - **`s`/`skip`** — Skip this task and move to the next
 - **`t`/`stop`** — Stop implementation entirely
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for user choice.
 
@@ -103,14 +105,16 @@ Present the reviewer's findings and fix analysis to the user:
 Notes (non-blocking):
 {NOTES from reviewer}
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 - **`y`/`yes`** — Accept the review and fix analysis, pass to executor
 - **`a`/`auto`** — Accept and auto-approve future fix analyses
 - **`s`/`skip`** — Override the reviewer and proceed as-is
 - **Comment** — Any commentary, adjustments, alternative approaches, or questions before passing to executor
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for user choice.
 
@@ -134,14 +138,16 @@ Present a summary and wait for user input:
 Phase: {phase number} — {phase name}
 {executor's SUMMARY — brief commentary, decisions, implementation notes}
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 **Options:**
 - **`y`/`yes`** — Approve, commit, continue to next task
 - **`a`/`auto`** — Approve this and all future reviewer-approved tasks automatically
 - **Comment** — Feedback the reviewer missed (triggers a fix round)
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for user input.
 

package/skills/technical-planning/SKILL.md

@@ -84,12 +84,14 @@ Found existing plan for **{topic}** (previously reached phase {N}, task {M}).
 
 {spec change summary from spec-change-detection.md}
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 - **`c`/`continue`** — Walk through the plan from the start. You can review, amend, or navigate at any point — including straight to the leading edge.
 - **`r`/`restart`** — Erase all planning work for this topic and start fresh. This deletes the Plan Index File and any Authored Tasks. Other topics are unaffected.
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for user response.
 
@@ -128,12 +130,14 @@ Present the recommendation:
 
 Existing plans use **{format}**. Use the same format for consistency?
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 - **`y`/`yes`** — Use {format}
 - **`n`/`no`** — See all available formats
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for user choice. If declined, fall through to the full list below.
 

package/skills/technical-planning/references/steps/analyze-task-graph.md

@@ -38,13 +38,15 @@ The natural task order is already correct. Present as rendered markdown (not in
 
 {notes from agent output}"
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 **To proceed:**
 - **`y`/`yes`** — Confirmed.
 - **Or tell me what to change.**
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for the user's response.
 
@@ -74,13 +76,15 @@ Dependencies and priorities have already been written to the task files. Present
 
 {any notes from agent output}"
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 **To proceed:**
 - **`y`/`yes`** — Approved.
 - **Or tell me what to change.**
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for the user's response.
 

package/skills/technical-planning/references/steps/author-tasks.md

@@ -31,14 +31,16 @@ After presenting, ask:
 
 **Task {M} of {total}: {Task Name}**
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 **To proceed:**
 - **`y`/`yes`** — Approved. I'll log it to the plan.
 - **Or tell me what to change.**
 - **Or navigate** — a different phase or task, or the leading edge.
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for the user's response.
 

package/skills/technical-planning/references/steps/define-phases.md

@@ -59,14 +59,16 @@ Present the phase structure to the user as rendered markdown (not in a code bloc
 
 **Phase Structure**
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 **To proceed:**
 - **`y`/`yes`** — Approved. I'll proceed to task breakdown.
 - **Or tell me what to change** — reorder, split, merge, add, edit, or remove phases.
 - **Or navigate** — a different phase or task, or the leading edge.
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 #### If the user provides feedback
 

package/skills/technical-planning/references/steps/define-tasks.md

@@ -42,14 +42,16 @@ Present the task overview to the user as rendered markdown (not in a code block)
 
 **STOP.** Ask:
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 **To proceed:**
 - **`y`/`yes`** — Approved.
 - **Or tell me what to change** — reorder, split, merge, add, edit, or remove tasks.
 - **Or navigate** — a different phase or task, or the leading edge.
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 #### If the user provides feedback
 

package/skills/technical-planning/references/steps/plan-construction.md

@@ -71,14 +71,16 @@ Present the task list to the user as rendered markdown (not in a code block).
 
 **Phase {N}: {Phase Name}** — {M} tasks.
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 **To proceed:**
 - **`y`/`yes`** — Confirmed.
 - **Or tell me what to change.**
 - **Or navigate** — a different phase or task, or the leading edge.
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for the user's response.
 

package/skills/technical-planning/references/steps/resolve-dependencies.md

@@ -43,13 +43,15 @@ Skip the resolution and reverse check — there is nothing to resolve against. D
 
 **STOP.** Present a summary of the dependency state: what was documented, what was resolved, what remains unresolved, and any reverse resolutions made.
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 **To proceed:**
 - **`y`/`yes`** — Approved. I'll proceed to plan review.
 - **Or tell me what to change.**
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 #### If the user provides feedback
 

package/skills/technical-planning/references/steps/review-integrity.md

@@ -171,14 +171,16 @@ After presenting the finding and proposed fix, ask:
 
 **Finding {N} of {total}: {Brief Title}**
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 **To proceed:**
 - **`y`/`yes`** — Approved. I'll apply it to the plan verbatim.
 - **`s`/`skip`** — Leave this as-is and move to the next finding.
 - **Or tell me what to change.**
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for the user's response.
 

package/skills/technical-planning/references/steps/review-traceability.md

@@ -149,14 +149,16 @@ After presenting the finding and proposed fix, ask:
 
 **Finding {N} of {total}: {Brief Title}**
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 **To proceed:**
 - **`y`/`yes`** — Approved. I'll apply it to the plan verbatim.
 - **`s`/`skip`** — Leave this as-is and move to the next finding.
 - **Or tell me what to change.**
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **STOP.** Wait for the user's response.
 

package/skills/technical-research/SKILL.md

@@ -87,13 +87,15 @@ When you notice convergence, **flag it and give the user options**:
 
 This thread seems to be converging — we've explored {topic} enough that the tradeoffs are clear and it's approaching decision territory.
 
+> *Output the next fenced block as markdown (not a code block):*
+
+```
 · · · · · · · · · · · ·
 - **`p`/`park`** — Mark as discussion-ready and move to another topic
 - **`k`/`keep`** — Keep digging, there's more to understand
 - Comment — your call
 · · · · · · · · · · · ·
-
-**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+```
 
 **Never decide for the user.** Even if the answer seems obvious, flag it and ask.
 

package/skills/technical-review/references/invoke-task-verifiers.md

@@ -4,7 +4,7 @@
 
 ---
 
-This step dispatches `review-task-verifier` agents in parallel to verify ALL tasks across the selected plan(s). Each verifier independently checks one task for implementation, tests, and code quality.
+This step dispatches `review-task-verifier` agents in batches to verify ALL tasks across the selected plan(s). Each verifier independently checks one task for implementation, tests, and code quality, writing its full findings to a file and returning a brief status.
 
 ---
 
@@ -26,15 +26,33 @@ From each plan in scope, list every task across all phases:
 - Note each task's description
 - Note each task's acceptance criteria
 - Note expected micro acceptance (test name)
+- Assign each task a sequential **index** (1, 2, 3...) for file naming
 
 ---
 
-## Dispatch Verifiers
+## Create Output Directory
 
-Dispatch **one verifier per task, all in parallel** via the Task tool.
+For each topic in scope, ensure the review output directory exists:
+
+```bash
+mkdir -p docs/workflow/review/{topic}
+```
+
+---
+
+## Batch Dispatch
+
+Dispatch verifiers in **batches of 5** via the Task tool.
 
 - **Agent path**: `../../../agents/review-task-verifier.md`
 
+1. Group tasks into batches of 5
+2. For each batch:
+   - Dispatch all agents in the batch in parallel
+   - Wait for all agents in the batch to return
+   - Record statuses
+3. After all batches complete, proceed to aggregation
+
 Each verifier receives:
 
 1. **Plan task** — the specific task with acceptance criteria
@@ -42,63 +60,35 @@ Each verifier receives:
 3. **Plan path** — the full plan for phase context
 4. **Project skill paths** — from Step 2 discovery
 5. **Review checklist path** — `skills/technical-review/references/review-checklist.md`
+6. **Topic name** — for output file path
+7. **Task index** — sequential number for file naming (1, 2, 3...)
 
----
-
-## Wait for Completion
-
-**STOP.** Do not proceed until all verifiers have returned.
-
-Each verifier returns a structured finding. If any verifier fails (error, timeout), record the failure and continue — aggregate what's available.
+If any verifier fails (error, timeout), record the failure and continue — aggregate what's available.
 
 ---
 
 ## Expected Result
 
-Each verifier returns:
+Each verifier returns a brief status:
 
 ```
-TASK: [Task name/description]
-
-ACCEPTANCE CRITERIA: [List from plan]
-
 STATUS: Complete | Incomplete | Issues Found
-
-SPEC CONTEXT: [Brief summary of relevant spec context]
-
-IMPLEMENTATION:
-- Status: [Implemented/Missing/Partial/Drifted]
-- Location: [file:line references]
-- Notes: [Any concerns]
-
-TESTS:
-- Status: [Adequate/Under-tested/Over-tested/Missing]
-- Coverage: [What is/isn't tested]
-- Notes: [Specific issues]
-
-CODE QUALITY:
-- Project conventions: [Followed/Violations/N/A]
-- SOLID principles: [Good/Concerns]
-- Complexity: [Low/Acceptable/High]
-- Modern idioms: [Yes/Opportunities]
-- Readability: [Good/Concerns]
-- Issues: [Specific problems if any]
-
-BLOCKING ISSUES:
-- [List any issues that must be fixed]
-
-NON-BLOCKING NOTES:
-- [Suggestions for improvement]
+FINDINGS_COUNT: {N blocking issues}
+SUMMARY: {1 sentence}
 ```
 
+Full findings are written to `docs/workflow/review/{topic}/qa-task-{index}.md`.
+
 ---
 
 ## Aggregate Findings
 
-Once all verifiers have returned, synthesize their reports:
+Once all batches have completed:
 
-- Collect all tasks with `STATUS: Incomplete` or `STATUS: Issues Found` as blocking issues
-- Collect all test issues (under/over-tested)
-- Collect all code quality concerns
-- Include specific file:line references
-- Check overall plan completion (see [review-checklist.md](review-checklist.md) — Plan Completion Check)
+1. Read all `docs/workflow/review/{topic}/qa-task-*.md` files
+2. Synthesize findings from file contents:
+   - Collect all tasks with `STATUS: Incomplete` or `STATUS: Issues Found` as blocking issues
+   - Collect all test issues (under/over-tested)
+   - Collect all code quality concerns
+   - Include specific file:line references
+   - Check overall plan completion (see [review-checklist.md](review-checklist.md) — Plan Completion Check)

package/skills/technical-specification/references/specification-guide.md

@@ -84,7 +84,7 @@ Then, **separately from the content above** (clear visual break), present the ch
 - **Or tell me what to change.**
 · · · · · · · · · · · ·
 
-**Do not wrap content or choices in a code block** — both must render as styled markdown. The content and choices must be visually distinct (not run together).
+Content and choices must be visually distinct (not run together).
 
 > **CHECKPOINT**: After presenting, you MUST STOP and wait for the user's response. Do NOT proceed to logging. Do NOT present the next topic. WAIT.
 
@@ -518,13 +518,17 @@ For each item, follow the **same workflow as the main specification process**:
 
    [content as rendered markdown]
 
+   > *Output the next fenced block as markdown (not a code block):*
+
+   ```
    · · · · · · · · · · · ·
    **To proceed:**
    - **`y`/`yes`** — Approved. I'll add the above to the specification **verbatim**.
    - **Or tell me what to change.**
    · · · · · · · · · · · ·
+   ```
 
-   **Do not wrap content or choices in a code block.** Content and choices must be visually distinct.
+   Content and choices must be visually distinct.
 
 4. **Wait for explicit approval** - same rules as always: `y`/`yes` or equivalent before writing
 5. **Log verbatim** when approved
@@ -652,13 +656,17 @@ For each item:
 
    [content as rendered markdown]
 
+   > *Output the next fenced block as markdown (not a code block):*
+
+   ```
    · · · · · · · · · · · ·
    **To proceed:**
    - **`y`/`yes`** — Approved. I'll add the above to the specification **verbatim**.
    - **Or tell me what to change.**
    · · · · · · · · · · · ·
+   ```
 
-   **Do not wrap content or choices in a code block.** Content and choices must be visually distinct.
+   Content and choices must be visually distinct.
 
 4. **Wait for explicit approval**
 5. **Log verbatim** when approved

package/skills/view-plan/SKILL.md

@@ -38,8 +38,10 @@ Follow the reading reference to locate and read the actual plan content.
 
 Display a readable summary:
 
+> *Output the next fenced block as a code block:*
+
 ```
-## Plan: {topic}
+Plan: {topic}
 
 **Format:** {format}