@leeovery/claude-technical-workflows 2.1.22 → 2.1.24

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@leeovery/claude-technical-workflows",
-  "version": "2.1.22",
+  "version": "2.1.24",
   "description": "Technical workflow skills & commands for Claude Code",
   "license": "MIT",
   "author": "Lee Overy <me@leeovery.com>",

package/skills/start-implementation/scripts/discovery.sh

@@ -262,10 +262,10 @@ if [ -d "$IMPL_DIR" ] && [ -n "$(ls -A "$IMPL_DIR" 2>/dev/null)" ]; then
     echo "  exists: true"
     echo "  files:"
 
-    for file in "$IMPL_DIR"/*.md; do
+    for file in "$IMPL_DIR"/*/tracking.md; do
         [ -f "$file" ] || continue
 
-        impl_name=$(basename "$file" .md)
+        impl_name=$(basename "$(dirname "$file")")
         impl_status=$(extract_field "$file" "status")
         impl_status=${impl_status:-"unknown"}
         current_phase=$(extract_field "$file" "current_phase")
@@ -343,7 +343,7 @@ if [ "$plan_count" -gt 0 ] && [ -d "$PLAN_DIR" ]; then
             if [ "$dep_state" = "resolved" ] && [ -n "$dep_task_id" ]; then
                 has_resolved_deps=true
                 # Check if the dependency topic has a tracking file
-                tracking_file="$IMPL_DIR/${dep_topic}.md"
+                tracking_file="$IMPL_DIR/${dep_topic}/tracking.md"
                 task_completed=false
 
                 if [ -f "$tracking_file" ]; then
@@ -441,7 +441,7 @@ if [ "$plan_count" -gt 0 ] && [ -d "$PLAN_DIR" ]; then
                         is_ready=false
                         break
                     elif [ "$dep_state" = "resolved" ] && [ -n "$dep_task_id" ]; then
-                        tracking_file="$IMPL_DIR/${dep_topic}.md"
+                        tracking_file="$IMPL_DIR/${dep_topic}/tracking.md"
                         if [ -f "$tracking_file" ]; then
                             completed=$(extract_completed_tasks "$tracking_file")
                             if ! echo "$completed" | grep -qx "$dep_task_id" 2>/dev/null; then

package/skills/technical-implementation/SKILL.md

@@ -31,13 +31,13 @@ Either way: dispatch agents per task — executor implements via TDD, reviewer v
 **Before proceeding**, verify all required inputs are available and unambiguous. If anything is missing or unclear, **STOP** — do not proceed until resolved.
 
 - **No plan provided?**
-  > "I need an implementation plan to execute. Could you point me to the plan file (e.g., `docs/workflow/planning/{topic}.md`)?"
+  "I need an implementation plan to execute. Could you point me to the plan file (e.g., `docs/workflow/planning/{topic}.md`)?"
 
 - **Plan has no `format` field in frontmatter?**
-  > "The plan at {path} doesn't specify an output format in its frontmatter. Which format does this plan use?"
+  "The plan at {path} doesn't specify an output format in its frontmatter. Which format does this plan use?"
 
 - **Plan status is not `concluded`?**
-  > "The plan at {path} has status '{status}' — it hasn't completed the review process. Should I proceed anyway, or should the plan be reviewed first?"
+  "The plan at {path} has status '{status}' — it hasn't completed the review process. Should I proceed anyway, or should the plan be reviewed first?"
 
 If no specification is available, the plan becomes the sole authority for design decisions.
 
@@ -91,7 +91,7 @@ Follow them. Complete ALL steps before proceeding.
 
 Ask:
 
-> "No environment setup document found. Are there any setup instructions I should follow before implementing?"
+"No environment setup document found. Are there any setup instructions I should follow before implementing?"
 
 **STOP.** Wait for user response.
 
@@ -166,14 +166,14 @@ Commit: `impl({topic}): start implementation`
 
 Present the existing configuration for confirmation:
 
-> Previous session used these project skills:
-> - `{skill-name}` — {path}
-> - ...
->
-> · · · · · · · · · · · ·
-> - **`y`/`yes`** — Keep these, proceed
-> - **`c`/`change`** — Re-discover and choose skills
-> · · · · · · · · · · · ·
+Previous session used these project skills:
+- `{skill-name}` — {path}
+- ...
+
+· · · · · · · · · · · ·
+- **`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.
 
@@ -194,16 +194,16 @@ No project skills found. Proceeding without project-specific conventions.
 
 Scan `.claude/skills/` for project-specific skill directories. Present findings:
 
-> Found these project skills that may be relevant to implementation:
-> - `{skill-name}` — {brief description}
-> - `{skill-name}` — {brief description}
-> - ...
->
-> · · · · · · · · · · · ·
-> - **`a`/`all`** — Use all listed skills
-> - **`n`/`none`** — Skip project skills
-> - **Or list the ones you want** — e.g. "golang-pro, react-patterns"
-> · · · · · · · · · · · ·
+Found these project skills that may be relevant to implementation:
+- `{skill-name}` — {brief description}
+- `{skill-name}` — {brief description}
+- ...
+
+· · · · · · · · · · · ·
+- **`a`/`all`** — Use all listed skills
+- **`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.
 
@@ -223,17 +223,17 @@ If `linters` is already populated in the tracking file, present the existing con
 
 Otherwise, present discovery findings to the user:
 
-> **Linter discovery:**
-> - {tool} — `{command}` (installed / not installed)
-> - ...
->
-> Recommendations: {any suggested tools with install commands}
->
-> · · · · · · · · · · · ·
-> - **`y`/`yes`** — Approve these linter commands
-> - **`c`/`change`** — Modify the linter list
-> - **`s`/`skip`** — Skip linter setup (no linting during TDD)
-> · · · · · · · · · · · ·
+**Linter discovery:**
+- {tool} — `{command}` (installed / not installed)
+- ...
+
+Recommendations: {any suggested tools with install commands}
+
+· · · · · · · · · · · ·
+- **`y`/`yes`** — Approve these linter 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.
 

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

@@ -28,14 +28,14 @@ If `analysis_cycle > 3`:
 
 **Do NOT skip analysis autonomously.** This gate is an escape hatch for the user — not a signal to stop. The expected default is to continue running analysis until no issues are found. Present the choice and let the user decide.
 
-> **Analysis cycle {N}**
->
-> Analysis has run {N-1} times so far. You can continue (recommended if issues were still found last cycle) or skip to completion.
->
-> · · · · · · · · · · · ·
-> - **`p`/`proceed`** — Continue analysis *(default)*
-> - **`s`/`skip`** — Skip analysis, proceed to completion
-> · · · · · · · · · · · ·
+**Analysis cycle {N}**
+
+Analysis has run {N-1} times so far. You can continue (recommended if issues were still found last cycle) or skip to completion.
+
+· · · · · · · · · · · ·
+- **`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.
 
@@ -57,15 +57,15 @@ If there are unstaged changes or untracked files, categorize them:
 - **Implementation files** (files touched by `impl({topic}):` commits) — stage these automatically.
 - **Unexpected files** (files not touched during implementation) — present to the user:
 
-> **Pre-analysis checkpoint — unexpected files detected:**
-> - `{file}` ({status: modified/untracked})
-> - ...
->
-> · · · · · · · · · · · ·
-> - **`y`/`yes`** — Include all in the checkpoint commit
-> - **`s`/`skip`** — Exclude unexpected files, commit only implementation files
-> - **Comment** — Specify which to include
-> · · · · · · · · · · · ·
+**Pre-analysis checkpoint — unexpected files detected:**
+- `{file}` ({status: modified/untracked})
+- ...
+
+· · · · · · · · · · · ·
+- **`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.
 
@@ -121,35 +121,35 @@ Read the staging file from `docs/workflow/implementation/{topic}/analysis-tasks-
 
 Present an overview:
 
-> **Analysis cycle {N}: {K} proposed tasks**
->
-> 1. {title} ({severity})
-> 2. {title} ({severity})
-> ...
+**Analysis cycle {N}: {K} proposed tasks**
+
+1. {title} ({severity})
+2. {title} ({severity})
+...
 
 Then present each task with `status: pending` individually:
 
-> **Task {current}/{total}: {title}** ({severity})
-> Sources: {sources}
->
-> **Problem**: {problem}
-> **Solution**: {solution}
-> **Outcome**: {outcome}
->
-> **Do**:
-> {steps}
->
-> **Acceptance Criteria**:
-> {criteria}
->
-> **Tests**:
-> {tests}
->
-> · · · · · · · · · · · ·
-> - **`a`/`approve`** — Approve this task
-> - **`s`/`skip`** — Skip this task
-> - **Comment** — Revise based on feedback
-> · · · · · · · · · · · ·
+**Task {current}/{total}: {title}** ({severity})
+Sources: {sources}
+
+**Problem**: {problem}
+**Solution**: {solution}
+**Outcome**: {outcome}
+
+**Do**:
+{steps}
+
+**Acceptance Criteria**:
+{criteria}
+
+**Tests**:
+{tests}
+
+· · · · · · · · · · · ·
+- **`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.
 

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

@@ -40,15 +40,15 @@ E. Update progress + commit
 
 Present the executor's ISSUES to the user:
 
-> **Task {id}: {Task Name} — {blocked/failed}**
->
-> {executor's ISSUES content}
->
-> · · · · · · · · · · · ·
-> - **`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
-> · · · · · · · · · · · ·
+**Task {id}: {Task Name} — {blocked/failed}**
+
+{executor's ISSUES content}
+
+· · · · · · · · · · · ·
+- **`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.
 
@@ -84,7 +84,7 @@ Increment `fix_attempts` in the implementation tracking file.
 
 Announce the fix round (one line, no stop):
 
-> **Review for Task {id}: {Task Name} — needs changes** (attempt {N}/{max 3}, fix analysis included). Re-invoking executor.
+**Review for Task {id}: {Task Name} — needs changes** (attempt {N}/{max 3}, fix analysis included). Re-invoking executor.
 
 → Return to the top of **B. Execute Task** and re-invoke the executor with the full task content and the reviewer's notes (including fix analysis).
 
@@ -92,23 +92,23 @@ Announce the fix round (one line, no stop):
 
 If `fix_attempts >= 3`, the executor and reviewer have failed to converge. Prepend:
 
-> The executor and reviewer have not converged after {N} attempts. Escalating for human review.
+The executor and reviewer have not converged after {N} attempts. Escalating for human review.
 
 Present the reviewer's findings and fix analysis to the user:
 
-> **Review for Task {id}: {Task Name} — needs changes** (attempt {N})
->
-> {ISSUES from reviewer, including FIX, ALTERNATIVE, and CONFIDENCE for each}
->
-> Notes (non-blocking):
-> {NOTES from reviewer}
->
-> · · · · · · · · · · · ·
-> - **`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
-> · · · · · · · · · · · ·
+**Review for Task {id}: {Task Name} — needs changes** (attempt {N})
+
+{ISSUES from reviewer, including FIX, ALTERNATIVE, and CONFIDENCE for each}
+
+Notes (non-blocking):
+{NOTES from reviewer}
+
+· · · · · · · · · · · ·
+- **`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.
 
@@ -129,17 +129,17 @@ After the reviewer approves a task, check the `task_gate_mode` field in the impl
 
 Present a summary and wait for user input:
 
-> **Task {id}: {Task Name} — approved**
->
-> Phase: {phase number} — {phase name}
-> {executor's SUMMARY — brief commentary, decisions, implementation notes}
->
-> · · · · · · · · · · · ·
-> **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)
-> · · · · · · · · · · · ·
+**Task {id}: {Task Name} — approved**
+
+Phase: {phase number} — {phase name}
+{executor's SUMMARY — brief commentary, decisions, implementation notes}
+
+· · · · · · · · · · · ·
+**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.
 
@@ -153,7 +153,7 @@ Present a summary and wait for user input:
 
 Announce the result (one line, no stop):
 
-> **Task {id}: {Task Name} — approved** (phase {N}: {phase name}, {brief summary}). Committing.
+**Task {id}: {Task Name} — approved** (phase {N}: {phase name}, {brief summary}). Committing.
 
 → Proceed to **E. Update Progress and Commit**.
 
@@ -189,6 +189,6 @@ This is the end of this iteration.
 
 ## When All Tasks Are Complete
 
-> "All tasks complete. {M} tasks implemented."
+"All tasks complete. {M} tasks implemented."
 
 → Return to the skill for **Step 7**.

package/skills/technical-planning/SKILL.md

@@ -80,14 +80,14 @@ Note the current phase and task position from the `planning:` block.
 
 Load **[spec-change-detection.md](references/spec-change-detection.md)** to check whether the specification has changed since planning started. Then present the user with an informed choice:
 
-> Found existing plan for **{topic}** (previously reached phase {N}, task {M}).
->
-> {spec change summary from spec-change-detection.md}
->
-> · · · · · · · · · · · ·
-> - **`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.
-> · · · · · · · · · · · ·
+Found existing plan for **{topic}** (previously reached phase {N}, task {M}).
+
+{spec change summary from spec-change-detection.md}
+
+· · · · · · · · · · · ·
+- **`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.
 
@@ -126,12 +126,12 @@ First, choose the Output Format.
 
 Present the recommendation:
 
-> Existing plans use **{format}**. Use the same format for consistency?
->
-> · · · · · · · · · · · ·
-> - **`y`/`yes`** — Use {format}
-> - **`n`/`no`** — See all available formats
-> · · · · · · · · · · · ·
+Existing plans use **{format}**. Use the same format for consistency?
+
+· · · · · · · · · · · ·
+- **`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.
 
@@ -231,10 +231,10 @@ After the review is complete:
 3. **Final commit** — Commit the concluded plan
 4. **Present completion summary**:
 
-> "Planning is complete for **{topic}**.
->
-> The plan contains **{N} phases** with **{M} tasks** total, reviewed for traceability against the specification and structural integrity.
->
-> Status has been marked as `concluded`. The plan is ready for implementation."
+"Planning is complete for **{topic}**.
+
+The plan contains **{N} phases** with **{M} tasks** total, reviewed for traceability against the specification and structural integrity.
+
+Status has been marked as `concluded`. The plan is ready for implementation."
 
 > **CHECKPOINT**: Do not conclude if any tasks in the Plan Index File show `status: pending`. All tasks must be `authored` before concluding.

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

@@ -12,7 +12,7 @@ This step uses the `planning-dependency-grapher` agent (`../../../../agents/plan
 
 Orient the user:
 
-> "All tasks are authored. Now I'll analyze internal dependencies and priorities across the full plan."
+"All tasks are authored. Now I'll analyze internal dependencies and priorities across the full plan."
 
 Read **[output-formats.md](../output-formats.md)**, find the entry matching the `format:` field in the Plan Index File, and load the format's **[reading.md](../output-formats/{format}/reading.md)** and **[graph.md](../output-formats/{format}/graph.md)**.
 
@@ -34,15 +34,15 @@ The agent clears any existing dependencies/priorities, analyzes all tasks, and
 
 The natural task order is already correct. Present as rendered markdown (not in a code block):
 
-> "I've analyzed all {M} tasks and the natural execution order is already correct — no explicit dependencies or priorities are needed.
->
-> {notes from agent output}"
+"I've analyzed all {M} tasks and the natural execution order is already correct — no explicit dependencies or priorities are needed.
 
-> · · · · · · · · · · · ·
-> **To proceed:**
-> - **`y`/`yes`** — Confirmed.
-> - **Or tell me what to change.**
-> · · · · · · · · · · · ·
+{notes from agent output}"
+
+· · · · · · · · · · · ·
+**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.
 
@@ -52,11 +52,11 @@ The natural task order is already correct. Present as rendered markdown (not in
 
 No changes were applied. Present the cycle to the user:
 
-> "The dependency analysis found a circular dependency:
->
-> {cycle chain from agent output}
->
-> This must be resolved before continuing. The cycle usually means two tasks each assume the other is done first — one needs to be restructured or the dependency removed."
+"The dependency analysis found a circular dependency:
+
+{cycle chain from agent output}
+
+This must be resolved before continuing. The cycle usually means two tasks each assume the other is done first — one needs to be restructured or the dependency removed."
 
 **STOP.** Wait for the user to decide how to resolve. Options include adjusting task scope, merging tasks, or removing a dependency. Re-invoke the agent after changes.
 
@@ -64,21 +64,21 @@ No changes were applied. Present the cycle to the user:
 
 Dependencies and priorities have already been written to the task files. Present as rendered markdown (not in a code block):
 
-> "I've analyzed and applied dependencies and priorities across all {M} tasks:
->
-> **Dependencies** ({count} relationships):
-> {dependency list from agent output}
->
-> **Priorities**:
-> {priority list from agent output}
->
-> {any notes from agent output}"
-
-> · · · · · · · · · · · ·
-> **To proceed:**
-> - **`y`/`yes`** — Approved.
-> - **Or tell me what to change.**
-> · · · · · · · · · · · ·
+"I've analyzed and applied dependencies and priorities across all {M} tasks:
+
+**Dependencies** ({count} relationships):
+{dependency list from agent output}
+
+**Priorities**:
+{priority list from agent output}
+
+{any notes from agent output}"
+
+· · · · · · · · · · · ·
+**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.
 

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

@@ -29,14 +29,14 @@ The agent returns complete task detail following the task template from task-des
 
 After presenting, ask:
 
-> **Task {M} of {total}: {Task Name}**
->
-> · · · · · · · · · · · ·
-> **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.
-> · · · · · · · · · · · ·
+**Task {M} of {total}: {Task Name}**
+
+· · · · · · · · · · · ·
+**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.
 
@@ -65,6 +65,6 @@ Present the revised task in full. Ask the same choice again. Repeat until approv
 
 Confirm:
 
-> "Task {M} of {total}: {Task Name} — authored."
+"Task {M} of {total}: {Task Name} — authored."
 
 → Return to **Plan Construction**.

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

@@ -16,7 +16,7 @@ Read the Plan Index File. Check if phases already exist in the body.
 
 Orient the user:
 
-> "Phase structure already exists. I'll present it for your review."
+"Phase structure already exists. I'll present it for your review."
 
 Continue to **Review and Approve** below.
 
@@ -24,7 +24,7 @@ Continue to **Review and Approve** below.
 
 Orient the user:
 
-> "I'll delegate phase design to a specialist agent. It will read the full specification and propose a phase structure — how we break this into independently testable stages."
+"I'll delegate phase design to a specialist agent. It will read the full specification and propose a phase structure — how we break this into independently testable stages."
 
 ### Invoke the Agent
 
@@ -57,14 +57,14 @@ Present the phase structure to the user as rendered markdown (not in a code bloc
 
 **STOP.** Ask:
 
-> **Phase Structure**
->
-> · · · · · · · · · · · ·
-> **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.
-> · · · · · · · · · · · ·
+**Phase Structure**
+
+· · · · · · · · · · · ·
+**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.
 

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

@@ -12,7 +12,7 @@ This step uses the `planning-task-designer` agent (`../../../../agents/planning-
 
 Orient the user:
 
-> "Taking Phase {N}: {Phase Name} and breaking it into tasks. I'll delegate this to a specialist agent that will read the full specification and propose a task list."
+"Taking Phase {N}: {Phase Name} and breaking it into tasks. I'll delegate this to a specialist agent that will read the full specification and propose a task list."
 
 ### Invoke the Agent
 
@@ -42,12 +42,12 @@ Present the task overview to the user as rendered markdown (not in a code block)
 
 **STOP.** Ask:
 
-> · · · · · · · · · · · ·
-> **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.
-> · · · · · · · · · · · ·
+· · · · · · · · · · · ·
+**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.
 

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

@@ -53,7 +53,7 @@ Work through each phase in order.
 
 Orient the user:
 
-> "I'll now work through each phase — presenting existing work for review and designing or authoring anything still pending. You'll approve at every stage."
+"I'll now work through each phase — presenting existing work for review and designing or authoring anything still pending. You'll approve at every stage."
 
 ### For each phase, check its state:
 
@@ -69,14 +69,14 @@ After Step A returns with an approved task table, continue to **Author Tasks for
 
 Present the task list to the user as rendered markdown (not in a code block).
 
-> **Phase {N}: {Phase Name}** — {M} tasks.
->
-> · · · · · · · · · · · ·
-> **To proceed:**
-> - **`y`/`yes`** — Confirmed.
-> - **Or tell me what to change.**
-> - **Or navigate** — a different phase or task, or the leading edge.
-> · · · · · · · · · · · ·
+**Phase {N}: {Phase Name}** — {M} tasks.
+
+· · · · · · · · · · · ·
+**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.
 
@@ -107,7 +107,7 @@ Never parallelize the first `pending` task in a phase. Never parallelize across
 
 Already written. Present a brief summary:
 
-> "Task {M} of {total}: {Task Name} — already authored."
+"Task {M} of {total}: {Task Name} — already authored."
 
 Continue to the next task.
 
@@ -121,7 +121,7 @@ After Step B returns, the task is authored. Continue to the next task.
 
 Advance the `planning:` block in frontmatter to the next phase. Commit: `planning({topic}): complete Phase {N} tasks`
 
-> Phase {N}: {Phase Name} — complete ({M} tasks authored).
+Phase {N}: {Phase Name} — complete ({M} tasks authored).
 
 Continue to the next phase.
 
@@ -131,7 +131,7 @@ Continue to the next phase.
 
 When all phases have all tasks authored:
 
-> "All phases are complete. The plan has **{N} phases** with **{M} tasks** total."
+"All phases are complete. The plan has **{N} phases** with **{M} tasks** total."
 
 ---
 

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

@@ -85,10 +85,10 @@ After both reviews:
 
 3. **Confirm with the user**:
 
-> "The plan has passed both reviews:
-> - **Traceability**: All specification content is covered; no hallucinated content
-> - **Integrity**: Plan structure, tasks, and dependencies are implementation-ready
->
-> Review is complete."
+"The plan has passed both reviews:
+- **Traceability**: All specification content is covered; no hallucinated content
+- **Integrity**: Plan structure, tasks, and dependencies are implementation-ready
+
+Review is complete."
 
 > **CHECKPOINT**: Do not confirm completion if tracking files still exist. They indicate incomplete review work.

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

@@ -6,7 +6,7 @@
 
 Orient the user:
 
-> "All phases and tasks are written. Now I'll check for external dependencies — things this plan needs from other topics or systems."
+"All phases and tasks are written. Now I'll check for external dependencies — things this plan needs from other topics or systems."
 
 After all phases are detailed and written, handle external dependencies — things this plan needs from other topics or systems.
 
@@ -43,11 +43,11 @@ 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.
 
-> · · · · · · · · · · · ·
-> **To proceed:**
-> - **`y`/`yes`** — Approved. I'll proceed to plan review.
-> - **Or tell me what to change.**
-> · · · · · · · · · · · ·
+· · · · · · · · · · · ·
+**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.
 

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

@@ -87,15 +87,15 @@ Then:
 
 **Stage 1: Summary**
 
-> "I've completed the plan integrity review. I found [N] items:
->
-> 1. **[Brief title]** (Critical/Important/Minor)
->    [2-4 line explanation: what the issue is, why it matters for implementation]
->
-> 2. **[Brief title]** (Critical/Important/Minor)
->    [2-4 line explanation]
->
-> Let's work through these one at a time, starting with #1."
+"I've completed the plan integrity review. I found [N] items:
+
+1. **[Brief title]** (Critical/Important/Minor)
+   [2-4 line explanation: what the issue is, why it matters for implementation]
+
+2. **[Brief title]** (Critical/Important/Minor)
+   [2-4 line explanation]
+
+Let's work through these one at a time, starting with #1."
 
 **Stage 2: Process One Item at a Time**
 
@@ -105,15 +105,15 @@ Work through each finding **one at a time**. For each finding: present it, propo
 
 Show the finding with full detail:
 
-> **Finding {N} of {total}: {Brief Title}**
->
-> **Severity**: Critical | Important | Minor
->
-> **Plan Reference**: [Phase/task in the plan]
->
-> **Category**: [Which review criterion — e.g., "Task Template Compliance", "Vertical Slicing"]
->
-> **Details**: [What the issue is and why it matters for implementation]
+**Finding {N} of {total}: {Brief Title}**
+
+**Severity**: Critical | Important | Minor
+
+**Plan Reference**: [Phase/task in the plan]
+
+**Category**: [Which review criterion — e.g., "Task Template Compliance", "Vertical Slicing"]
+
+**Details**: [What the issue is and why it matters for implementation]
 
 ### Propose the Fix
 
@@ -123,60 +123,60 @@ State the action type explicitly so the user knows what's changing structurally:
 
 **Update a task** — change content within an existing task:
 
-> **Proposed fix — update Phase {N}, Task {M}:**
->
-> **Current:**
-> [The existing content as it appears in the plan]
->
-> **Proposed:**
-> [The replacement content]
+**Proposed fix — update Phase {N}, Task {M}:**
+
+**Current:**
+[The existing content as it appears in the plan]
+
+**Proposed:**
+[The replacement content]
 
 **Add content to a task** — insert into an existing task (e.g., missing acceptance criteria, edge case):
 
-> **Proposed fix — add to Phase {N}, Task {M}, {section}:**
->
-> [The exact content to be added, in plan format]
+**Proposed fix — add to Phase {N}, Task {M}, {section}:**
+
+[The exact content to be added, in plan format]
 
 **Remove content from a task** — strip content that shouldn't be there:
 
-> **Proposed fix — remove from Phase {N}, Task {M}, {section}:**
->
-> [The exact content to be removed]
+**Proposed fix — remove from Phase {N}, Task {M}, {section}:**
+
+[The exact content to be removed]
 
 **Add a new task** — a spec section has no plan coverage and needs its own task:
 
-> **Proposed fix — add new task to Phase {N}:**
->
-> [The complete task in plan format, using the task template]
+**Proposed fix — add new task to Phase {N}:**
+
+[The complete task in plan format, using the task template]
 
 **Remove a task** — an entire task is hallucinated with no spec backing:
 
-> **Proposed fix — remove Phase {N}, Task {M}: {Task Name}**
->
-> **Reason**: [Why this task has no specification basis]
+**Proposed fix — remove Phase {N}, Task {M}: {Task Name}**
+
+**Reason**: [Why this task has no specification basis]
 
 **Add a new phase** — a significant area of the specification has no plan coverage:
 
-> **Proposed fix — add new Phase {N}: {Phase Name}**
->
-> [Phase goal, acceptance criteria, and task overview]
+**Proposed fix — add new Phase {N}: {Phase Name}**
+
+[Phase goal, acceptance criteria, and task overview]
 
 **Remove a phase** — an entire phase is not backed by the specification:
 
-> **Proposed fix — remove Phase {N}: {Phase Name}**
->
-> **Reason**: [Why this phase has no specification basis]
+**Proposed fix — remove Phase {N}: {Phase Name}**
+
+**Reason**: [Why this phase has no specification basis]
 
 After presenting the finding and proposed fix, ask:
 
-> **Finding {N} of {total}: {Brief Title}**
->
-> · · · · · · · · · · · ·
-> **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.**
-> · · · · · · · · · · · ·
+**Finding {N} of {total}: {Brief Title}**
+
+· · · · · · · · · · · ·
+**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.
 
@@ -197,13 +197,13 @@ Apply the fix to the plan — as presented, using the output format adapter to d
 
 Confirm:
 
-> "Finding {N} of {total}: {Brief Title} — fixed."
+"Finding {N} of {total}: {Brief Title} — fixed."
 
 ### If Skipped
 
 Update the tracking file: mark resolution as "Skipped", note the reason.
 
-> "Finding {N} of {total}: {Brief Title} — skipped."
+"Finding {N} of {total}: {Brief Title} — skipped."
 
 ### Next Finding
 

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

@@ -65,15 +65,15 @@ After completing your review:
 
 **Stage 1: Summary**
 
-> "I've completed the traceability review comparing the plan against the specification. I found [N] items:
->
-> 1. **[Brief title]** (Missing from plan | Hallucinated | Incomplete)
->    [2-4 line explanation: what's wrong, where in the spec/plan, why it matters]
->
-> 2. **[Brief title]** (Missing from plan | Hallucinated | Incomplete)
->    [2-4 line explanation]
->
-> Let's work through these one at a time, starting with #1."
+"I've completed the traceability review comparing the plan against the specification. I found [N] items:
+
+1. **[Brief title]** (Missing from plan | Hallucinated | Incomplete)
+   [2-4 line explanation: what's wrong, where in the spec/plan, why it matters]
+
+2. **[Brief title]** (Missing from plan | Hallucinated | Incomplete)
+   [2-4 line explanation]
+
+Let's work through these one at a time, starting with #1."
 
 **Stage 2: Process One Item at a Time**
 
@@ -83,15 +83,15 @@ Work through each finding **one at a time**. For each finding: present it, propo
 
 Show the finding with full detail:
 
-> **Finding {N} of {total}: {Brief Title}**
->
-> **Type**: Missing from plan | Hallucinated content | Incomplete coverage
->
-> **Spec Reference**: [Section/decision in the specification]
->
-> **Plan Reference**: [Phase/task in the plan, or "N/A" for missing content]
->
-> **Details**: [What's wrong and why it matters]
+**Finding {N} of {total}: {Brief Title}**
+
+**Type**: Missing from plan | Hallucinated content | Incomplete coverage
+
+**Spec Reference**: [Section/decision in the specification]
+
+**Plan Reference**: [Phase/task in the plan, or "N/A" for missing content]
+
+**Details**: [What's wrong and why it matters]
 
 ### Propose the Fix
 
@@ -101,60 +101,60 @@ State the action type explicitly so the user knows what's changing structurally:
 
 **Update a task** — change content within an existing task:
 
-> **Proposed fix — update Phase {N}, Task {M}:**
->
-> **Current:**
-> [The existing content as it appears in the plan]
->
-> **Proposed:**
-> [The replacement content]
+**Proposed fix — update Phase {N}, Task {M}:**
+
+**Current:**
+[The existing content as it appears in the plan]
+
+**Proposed:**
+[The replacement content]
 
 **Add content to a task** — insert into an existing task (e.g., missing acceptance criteria, edge case):
 
-> **Proposed fix — add to Phase {N}, Task {M}, {section}:**
->
-> [The exact content to be added, in plan format]
+**Proposed fix — add to Phase {N}, Task {M}, {section}:**
+
+[The exact content to be added, in plan format]
 
 **Remove content from a task** — strip content that shouldn't be there:
 
-> **Proposed fix — remove from Phase {N}, Task {M}, {section}:**
->
-> [The exact content to be removed]
+**Proposed fix — remove from Phase {N}, Task {M}, {section}:**
+
+[The exact content to be removed]
 
 **Add a new task** — a spec section has no plan coverage and needs its own task:
 
-> **Proposed fix — add new task to Phase {N}:**
->
-> [The complete task in plan format, using the task template]
+**Proposed fix — add new task to Phase {N}:**
+
+[The complete task in plan format, using the task template]
 
 **Remove a task** — an entire task is hallucinated with no spec backing:
 
-> **Proposed fix — remove Phase {N}, Task {M}: {Task Name}**
->
-> **Reason**: [Why this task has no specification basis]
+**Proposed fix — remove Phase {N}, Task {M}: {Task Name}**
+
+**Reason**: [Why this task has no specification basis]
 
 **Add a new phase** — a significant area of the specification has no plan coverage:
 
-> **Proposed fix — add new Phase {N}: {Phase Name}**
->
-> [Phase goal, acceptance criteria, and task overview]
+**Proposed fix — add new Phase {N}: {Phase Name}**
+
+[Phase goal, acceptance criteria, and task overview]
 
 **Remove a phase** — an entire phase is not backed by the specification:
 
-> **Proposed fix — remove Phase {N}: {Phase Name}**
->
-> **Reason**: [Why this phase has no specification basis]
+**Proposed fix — remove Phase {N}: {Phase Name}**
+
+**Reason**: [Why this phase has no specification basis]
 
 After presenting the finding and proposed fix, ask:
 
-> **Finding {N} of {total}: {Brief Title}**
->
-> · · · · · · · · · · · ·
-> **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.**
-> · · · · · · · · · · · ·
+**Finding {N} of {total}: {Brief Title}**
+
+· · · · · · · · · · · ·
+**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.
 
@@ -175,13 +175,13 @@ Apply the fix to the plan — as presented, using the output format adapter to d
 
 Confirm:
 
-> "Finding {N} of {total}: {Brief Title} — fixed."
+"Finding {N} of {total}: {Brief Title} — fixed."
 
 ### If Skipped
 
 Update the tracking file: mark resolution as "Skipped", note the reason.
 
-> "Finding {N} of {total}: {Brief Title} — skipped."
+"Finding {N} of {total}: {Brief Title} — skipped."
 
 ### Next Finding
 

package/skills/technical-research/SKILL.md

@@ -24,10 +24,10 @@ Either way: Explore feasibility (technical, business, market), validate assumpti
 **Before proceeding**, confirm the required input is clear. If anything is missing or unclear, **STOP** and resolve with the user.
 
 - **No topic provided?**
-  > "What would you like to research or explore? This could be a new idea, a technical concept, a market opportunity — anything you want to investigate."
+  "What would you like to research or explore? This could be a new idea, a technical concept, a market opportunity — anything you want to investigate."
 
 - **Topic is vague or could go many directions?**
-  > "You mentioned {topic}. That could cover a lot of ground — is there a specific angle you'd like to start with, or should I explore broadly?"
+  "You mentioned {topic}. That could cover a lot of ground — is there a specific angle you'd like to start with, or should I explore broadly?"
 
 ---
 
@@ -85,13 +85,13 @@ Watch for these signs that a thread is moving from exploration toward decision-m
 
 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.
->
-> · · · · · · · · · · · ·
-> - **`p`/`park`** — Mark as discussion-ready and move to another topic
-> - **`k`/`keep`** — Keep digging, there's more to understand
-> - Comment — your call
-> · · · · · · · · · · · ·
+This thread seems to be converging — we've explored {topic} enough that the tradeoffs are clear and it's approaching decision territory.
+
+· · · · · · · · · · · ·
+- **`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.
 

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

@@ -72,17 +72,17 @@ For each topic or subtopic, perform exhaustive extraction:
 ### 2. Synthesize and Present
 Present your understanding to the user **in the format it would appear in the specification**. Output the content as rendered markdown (not in a code block) — the user needs to read it naturally, not inspect raw formatting:
 
-> "Here's what I understand about [topic] based on the reference material. This is exactly what I'll write into the specification:
->
-> [content as rendered markdown]
+"Here's what I understand about [topic] based on the reference material. This is exactly what I'll write into the specification:
+
+[content as rendered markdown]
 
 Then, **separately from the content above** (clear visual break), present the choices as raw markdown:
 
-> · · · · · · · · · · · ·
-> **To proceed:**
-> - **`y`/`yes`** — Approved. I'll add the above to the specification **verbatim** (exactly as shown, no modifications).
-> - **Or tell me what to change.**
-> · · · · · · · · · · · ·
+· · · · · · · · · · · ·
+**To proceed:**
+- **`y`/`yes`** — Approved. I'll add the above to the specification **verbatim** (exactly as shown, no modifications).
+- **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).
 
@@ -491,18 +491,18 @@ After completing your review (steps 1-7):
 
 Present a numbered summary of everything you found (from your tracking file):
 
-> "I've completed my final review against all source material. I found [N] items:
->
-> 1. **[Brief title]**
->    [2-4 line explanation: what was missed, where it came from, what it affects]
->
-> 2. **[Brief title]**
->    [2-4 line explanation]
->
-> 3. **[Brief title]**
->    [2-4 line explanation]
->
-> Let's work through these one at a time, starting with #1."
+"I've completed my final review against all source material. I found [N] items:
+
+1. **[Brief title]**
+   [2-4 line explanation: what was missed, where it came from, what it affects]
+
+2. **[Brief title]**
+   [2-4 line explanation]
+
+3. **[Brief title]**
+   [2-4 line explanation]
+
+Let's work through these one at a time, starting with #1."
 
 Each item should have enough context that the user understands what they're about to discuss - not just a label, but clarity on what was missed and why it matters.
 
@@ -514,15 +514,15 @@ For each item, follow the **same workflow as the main specification process**:
 2. **Discuss** if needed - clarify ambiguities, answer questions, refine the content
 3. **Present for approval** - show as rendered markdown (not a code block) exactly what will be written to the specification. Then, separately, show the choices:
 
-   > "Here's what I'll add to the specification:
-   >
-   > [content as rendered markdown]
-   >
-   > · · · · · · · · · · · ·
-   > **To proceed:**
-   > - **`y`/`yes`** — Approved. I'll add the above to the specification **verbatim**.
-   > - **Or tell me what to change.**
-   > · · · · · · · · · · · ·
+   "Here's what I'll add to the specification:
+
+   [content as rendered markdown]
+
+   · · · · · · · · · · · ·
+   **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.
 
@@ -630,15 +630,15 @@ Follow the same two-stage presentation as Phase 1:
 
 **Stage 1: Summary**
 
-> "I've completed the gap analysis of the specification. I found [N] items:
->
-> 1. **[Brief title]** (Critical/Important/Minor)
->    [2-4 line explanation: what the gap is, why it matters for implementation]
->
-> 2. **[Brief title]** (Critical/Important/Minor)
->    [2-4 line explanation]
->
-> Let's work through these one at a time, starting with #1."
+"I've completed the gap analysis of the specification. I found [N] items:
+
+1. **[Brief title]** (Critical/Important/Minor)
+   [2-4 line explanation: what the gap is, why it matters for implementation]
+
+2. **[Brief title]** (Critical/Important/Minor)
+   [2-4 line explanation]
+
+Let's work through these one at a time, starting with #1."
 
 **Stage 2: Process One Item at a Time**
 
@@ -648,15 +648,15 @@ For each item:
 2. **Discuss** - work with the user to determine the correct specification content
 3. **Present for approval** - show as rendered markdown (not a code block) exactly what will be written. Then, separately, show the choices:
 
-   > "Here's what I'll add to the specification:
-   >
-   > [content as rendered markdown]
-   >
-   > · · · · · · · · · · · ·
-   > **To proceed:**
-   > - **`y`/`yes`** — Approved. I'll add the above to the specification **verbatim**.
-   > - **Or tell me what to change.**
-   > · · · · · · · · · · · ·
+   "Here's what I'll add to the specification:
+
+   [content as rendered markdown]
+
+   · · · · · · · · · · · ·
+   **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.
 
@@ -703,14 +703,14 @@ Before asking for sign-off, assess whether this is a **feature** or **cross-cutt
 
 Present your assessment to the user:
 
-> "This specification appears to be a **[feature/cross-cutting]** specification.
->
-> [Brief rationale - e.g., "It defines a caching strategy that will inform how multiple features handle data retrieval, rather than being a standalone piece of functionality to build."]
->
-> - **Feature specs** proceed to planning and implementation
-> - **Cross-cutting specs** are referenced by feature plans but don't have their own implementation plan
->
-> Does this assessment seem correct?"
+"This specification appears to be a **[feature/cross-cutting]** specification.
+
+[Brief rationale - e.g., "It defines a caching strategy that will inform how multiple features handle data retrieval, rather than being a standalone piece of functionality to build."]
+
+- **Feature specs** proceed to planning and implementation
+- **Cross-cutting specs** are referenced by feature plans but don't have their own implementation plan
+
+Does this assessment seem correct?"
 
 Wait for user confirmation before proceeding.
 
@@ -729,14 +729,14 @@ If either file still exists, delete it now. These are temporary working files th
 
 Once the type is confirmed and tracking files are removed, ask for final sign-off:
 
-> "The specification is ready for sign-off:
-> - **Type**: [feature/cross-cutting]
-> - **Status**: Complete
->
-> [If feature]: This specification can proceed to planning
-> [If cross-cutting]: This specification will be surfaced as reference context when planning features
->
-> Ready to mark as complete?"
+"The specification is ready for sign-off:
+- **Type**: [feature/cross-cutting]
+- **Status**: Complete
+
+[If feature]: This specification can proceed to planning
+[If cross-cutting]: This specification will be surfaced as reference context when planning features
+
+Ready to mark as complete?"
 
 ### Step 4: Update Frontmatter