@leeovery/claude-technical-workflows 2.1.24 → 2.1.26

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}