@leeovery/claude-technical-workflows 2.1.20 → 2.1.22

package/package.json

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

package/skills/link-dependencies/SKILL.md

@@ -168,6 +168,8 @@ Shall I commit these dependency updates?
 · · · · · · · · · · · ·
 ```
 
+**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+
 If yes, commit with message:
 ```
 Link cross-topic dependencies

package/skills/start-discussion/SKILL.md

@@ -7,6 +7,8 @@ allowed-tools: Bash(.claude/skills/start-discussion/scripts/discovery.sh), Bash(
 
 Invoke the **technical-discussion** skill for this conversation.
 
+> **⚠️ ZERO OUTPUT RULE**: Do not narrate your processing. Produce no output until a step or reference file explicitly specifies display content. No "proceeding with...", no discovery summaries, no routing decisions, no transition text. Your first output must be content explicitly called for by the instructions.
+
 ## Workflow Context
 
 This is **Phase 2** of the six-phase workflow:
@@ -88,8 +90,6 @@ Parse the discovery output to understand:
 
 **IMPORTANT**: Use ONLY this script for discovery. Do NOT run additional bash commands (ls, head, cat, etc.) to gather state - the script provides everything needed.
 
-**Silent processing**: Do NOT output your assessment of the discovery state. Parse it internally and proceed to the next step without narrating field values, routing decisions, or prerequisites. The first user-visible output should be the display content itself.
-
 → Proceed to **Step 2**.
 
 ---

package/skills/start-discussion/references/display-options.md

@@ -30,11 +30,12 @@ Key:
   ✓ = already has a corresponding discussion
 ```
 
+**Output in a fenced code block exactly as shown above.**
+
 **Then present the options based on what exists:**
 
 #### If research and discussions exist
 
-```
 · · · · · · · · · · · ·
 How would you like to proceed?
 
@@ -43,11 +44,9 @@ How would you like to proceed?
 - Continue discussion — name one above (e.g., "continue {topic}")
 - Fresh topic — describe what you want to discuss
 · · · · · · · · · · · ·
-```
 
 #### If only research exists
 
-```
 · · · · · · · · · · · ·
 How would you like to proceed?
 
@@ -55,17 +54,14 @@ How would you like to proceed?
 - From research — pick a topic number above (e.g., "1" or "research 1")
 - Fresh topic — describe what you want to discuss
 · · · · · · · · · · · ·
-```
 
 #### If only discussions exist
 
-```
 · · · · · · · · · · · ·
 How would you like to proceed?
 
 - Continue discussion — name one above (e.g., "continue {topic}")
 - Fresh topic — describe what you want to discuss
 · · · · · · · · · · · ·
-```
 
 **STOP.** Wait for user response before proceeding.

package/skills/start-discussion/references/gather-context-research.md

@@ -22,4 +22,6 @@ research you'd like to include — drop them in now.
 · · · · · · · · · · · ·
 ```
 
+**Do not wrap the above in a code block** — output as raw markdown so bold styling renders.
+
 **STOP.** Wait for user response before proceeding.

package/skills/start-implementation/SKILL.md

@@ -7,6 +7,8 @@ allowed-tools: Bash(.claude/skills/start-implementation/scripts/discovery.sh)
 
 Invoke the **technical-implementation** skill for this conversation.
 
+> **⚠️ ZERO OUTPUT RULE**: Do not narrate your processing. Produce no output until a step or reference file explicitly specifies display content. No "proceeding with...", no discovery summaries, no routing decisions, no transition text. Your first output must be content explicitly called for by the instructions.
+
 ## Workflow Context
 
 This is **Phase 5** of the six-phase workflow:
@@ -94,8 +96,6 @@ Parse the discovery output to understand:
 
 **IMPORTANT**: Use ONLY this script for discovery. Do NOT run additional bash commands (ls, head, cat, etc.) to gather state - the script provides everything needed.
 
-**Silent processing**: Do NOT output your assessment of the discovery state. Parse it internally and proceed to the next step without narrating field values, routing decisions, or prerequisites. The first user-visible output should be the display content itself.
-
 → Proceed to **Step 2**.
 
 ---
@@ -159,6 +159,8 @@ Not implementable:
   · reporting [planning]
 ```
 
+**Output in a fenced code block exactly as shown above.**
+
 **Formatting rules:**
 
 Implementable (numbered, selectable):

package/skills/start-planning/SKILL.md

@@ -7,6 +7,8 @@ allowed-tools: Bash(.claude/skills/start-planning/scripts/discovery.sh)
 
 Invoke the **technical-planning** skill for this conversation.
 
+> **⚠️ ZERO OUTPUT RULE**: Do not narrate your processing. Produce no output until a step or reference file explicitly specifies display content. No "proceeding with...", no discovery summaries, no routing decisions, no transition text. Your first output must be content explicitly called for by the instructions.
+
 ## Workflow Context
 
 This is **Phase 4** of the six-phase workflow:
@@ -83,8 +85,6 @@ Parse the discovery output to understand:
 
 **IMPORTANT**: Use ONLY this script for discovery. Do NOT run additional bash commands (ls, head, cat, etc.) to gather state - the script provides everything needed.
 
-**Silent processing**: Do NOT output your assessment of the discovery state. Parse it internally and proceed to the next step without narrating field values, routing decisions, or prerequisites. The first user-visible output should be the display content itself.
-
 → Proceed to **Step 2**.
 
 ---
@@ -139,6 +139,8 @@ Not plannable specifications:
   · {rate-limiting} [cross-cutting, in-progress]
 ```
 
+**Output in a fenced code block exactly as shown above.**
+
 **Formatting rules:**
 
 Available (numbered, selectable):

package/skills/start-review/SKILL.md

@@ -7,6 +7,8 @@ allowed-tools: Bash(.claude/skills/start-review/scripts/discovery.sh)
 
 Invoke the **technical-review** skill for this conversation.
 
+> **⚠️ ZERO OUTPUT RULE**: Do not narrate your processing. Produce no output until a step or reference file explicitly specifies display content. No "proceeding with...", no discovery summaries, no routing decisions, no transition text. Your first output must be content explicitly called for by the instructions.
+
 ## Workflow Context
 
 This is **Phase 6** of the six-phase workflow:
@@ -76,8 +78,6 @@ Parse the discovery output to understand:
 
 **IMPORTANT**: Use ONLY this script for discovery. Do NOT run additional bash commands (ls, head, cat, etc.) to gather state - the script provides everything needed.
 
-**Silent processing**: Do NOT output your assessment of the discovery state. Parse it internally and proceed to the next step without narrating field values, routing decisions, or prerequisites. The first user-visible output should be the display content itself.
-
 → Proceed to **Step 2**.
 
 ---
@@ -123,6 +123,8 @@ Not reviewable:
   · {topic-3} [no implementation]
 ```
 
+**Output in a fenced code block exactly as shown above.**
+
 **Formatting rules:**
 
 Reviewable (numbered, selectable):

package/skills/start-specification/SKILL.md

@@ -7,6 +7,8 @@ allowed-tools: Bash(.claude/skills/start-specification/scripts/discovery.sh), Ba
 
 Invoke the **technical-specification** skill for this conversation.
 
+> **⚠️ ZERO OUTPUT RULE**: Do not narrate your processing. Produce no output until a step or reference file explicitly specifies display content. No "proceeding with...", no discovery summaries, no routing decisions, no transition text. Your first output must be content explicitly called for by the instructions.
+
 ## Workflow Context
 
 This is **Phase 3** of the six-phase workflow:
@@ -74,8 +76,6 @@ Parse the discovery output to understand:
 
 **IMPORTANT**: Use ONLY this script for discovery. Do NOT run additional bash commands (ls, head, cat, etc.) to gather state - the script provides everything needed.
 
-**Silent processing**: Do NOT output your assessment of the discovery state. Parse it internally and proceed to the next step without narrating field values, routing decisions, or prerequisites. The first user-visible output should be the display content itself.
-
 → Proceed to **Step 2**.
 
 ---

package/skills/start-specification/references/confirm-continue.md

@@ -16,13 +16,13 @@ Sources to extract:
 
 Previously extracted (for reference):
   • {discussion-name}
+```
 
 · · · · · · · · · · · ·
 Proceed?
 - **`y`/`yes`**
 - **`n`/`no`**
 · · · · · · · · · · · ·
-```
 
 #### If spec is in-progress with all sources extracted
 
@@ -34,13 +34,13 @@ Existing: docs/workflow/specification/{kebab-case-name}.md (in-progress)
 All sources extracted:
   • {discussion-name}
   • {discussion-name}
+```
 
 · · · · · · · · · · · ·
 Proceed?
 - **`y`/`yes`**
 - **`n`/`no`**
 · · · · · · · · · · · ·
-```
 
 #### If spec is concluded with pending sources
 
@@ -54,13 +54,13 @@ New sources to extract:
 
 Previously extracted (for reference):
   • {discussion-name}
+```
 
 · · · · · · · · · · · ·
 Proceed?
 - **`y`/`yes`**
 - **`n`/`no`**
 · · · · · · · · · · · ·
-```
 
 **STOP.** Wait for user response.
 

package/skills/start-specification/references/confirm-create.md

@@ -14,13 +14,13 @@ Sources:
   • {discussion-name}
 
 Output: docs/workflow/specification/{kebab-case-name}.md
+```
 
 · · · · · · · · · · · ·
 Proceed?
 - **`y`/`yes`**
 - **`n`/`no`**
 · · · · · · · · · · · ·
-```
 
 #### If any source discussion has an individual spec
 
@@ -37,13 +37,13 @@ Output: docs/workflow/specification/{kebab-case-name}.md
 
 After completion:
   specification/{discussion-name}.md → marked as superseded
+```
 
 · · · · · · · · · · · ·
 Proceed?
 - **`y`/`yes`**
 - **`n`/`no`**
 · · · · · · · · · · · ·
-```
 
 **STOP.** Wait for user response.
 

package/skills/start-specification/references/confirm-refine.md

@@ -11,13 +11,13 @@ Existing: docs/workflow/specification/{kebab-case-name}.md (concluded)
 
 All sources extracted:
   • {discussion-name}
+```
 
 · · · · · · · · · · · ·
 Proceed?
 - **`y`/`yes`**
 - **`n`/`no`**
 · · · · · · · · · · · ·
-```
 
 **STOP.** Wait for user response.
 

package/skills/start-specification/references/confirm-unify.md

@@ -19,13 +19,13 @@ Existing specifications to incorporate:
   • {spec-name}.md → will be superseded
 
 Output: docs/workflow/specification/unified.md
+```
 
 · · · · · · · · · · · ·
 Proceed?
 - **`y`/`yes`**
 - **`n`/`no`**
 · · · · · · · · · · · ·
-```
 
 #### If no existing specifications
 
@@ -38,13 +38,13 @@ Sources:
   ...
 
 Output: docs/workflow/specification/unified.md
+```
 
 · · · · · · · · · · · ·
 Proceed?
 - **`y`/`yes`**
 - **`n`/`no`**
 · · · · · · · · · · · ·
-```
 
 **STOP.** Wait for user response.
 

package/skills/start-specification/references/display-analyze.md

@@ -40,13 +40,13 @@ No `---` separator before these messages.
 These discussions will be analyzed for natural groupings to determine
 how they should be organized into specifications. Results are cached
 and reused until discussions change.
+```
 
 · · · · · · · · · · · ·
 Proceed with analysis?
 - **`y`/`yes`**
 - **`n`/`no`**
 · · · · · · · · · · · ·
-```
 
 #### If cache status is "stale"
 
@@ -56,13 +56,13 @@ have changed since it was created.
 
 These discussions will be re-analyzed for natural groupings. Results
 are cached and reused until discussions change.
+```
 
 · · · · · · · · · · · ·
 Proceed with analysis?
 - **`y`/`yes`**
 - **`n`/`no`**
 · · · · · · · · · · · ·
-```
 
 **STOP.** Wait for user response.
 

package/skills/start-specification/references/display-groupings.md

@@ -56,20 +56,18 @@ Specification Overview
 Recommended breakdown for specifications with their source discussions.
 
 1. {Grouping Name}
-    └─ Spec: {status} {(X of Y sources extracted) if applicable}
-    └─ Discussions:
-       ├─ {discussion-name} ({status})
-       └─ {discussion-name} ({status})
+   └─ Spec: {status} {(X of Y sources extracted) if applicable}
+   └─ Discussions:
+      ├─ {discussion-name} ({status})
+      └─ {discussion-name} ({status})
 
 2. {Grouping Name}
-    └─ Spec: none
-    └─ Discussions:
-       └─ {discussion-name} (ready)
+   └─ Spec: none
+   └─ Discussions:
+      └─ {discussion-name} (ready)
 ```
 
-Indentation: `└─` starts at column 4 (under the grouping name text, not the number). Discussion entries start at column 7.
-
-Use `├─` for all but the last discussion, `└─` for the last.
+**Output in a fenced code block exactly as shown above.**
 
 ### If in-progress discussions exist
 
@@ -145,7 +143,7 @@ Select an option (enter number):
 · · · · · · · · · · · ·
 ```
 
-Menu descriptions are wrapped in backticks to visually distinguish them from the choice labels.
+**Output in a fenced code block exactly as shown above.** Every meta option (Unify, Re-analyze) MUST include its description lines.
 
 **STOP.** Wait for user response.
 

package/skills/start-specification/references/display-single-grouped.md

@@ -21,13 +21,13 @@ Specification Overview
 Single concluded discussion found with existing multi-source specification.
 
 1. {Spec Title Case Name}
-    └─ Spec: {spec_status} ({X} of {Y} sources extracted)
-    └─ Discussions:
-       ├─ {source-name} (extracted)
-       └─ {source-name} (extracted, reopened)
+   └─ Spec: {spec_status} ({X} of {Y} sources extracted)
+   └─ Discussions:
+      ├─ {source-name} (extracted)
+      └─ {source-name} (extracted, reopened)
 ```
 
-Indentation: `└─` starts at column 4 (under the name text, not the number). Discussion entries start at column 7.
+**Output in a fenced code block exactly as shown above.**
 
 ### If in-progress discussions exist
 

package/skills/start-specification/references/display-single-has-spec.md

@@ -16,12 +16,12 @@ Specification Overview
 Single concluded discussion found with existing specification.
 
 1. {Title Case Name}
-    └─ Spec: {spec_status} ({X} of {Y} sources extracted)
-    └─ Discussions:
-       └─ {discussion-name} (extracted)
+   └─ Spec: {spec_status} ({X} of {Y} sources extracted)
+   └─ Discussions:
+      └─ {discussion-name} (extracted)
 ```
 
-Indentation: `└─` starts at column 4 (under the name text, not the number). Discussion entries start at column 7.
+**Output in a fenced code block exactly as shown above.**
 
 ### If in-progress discussions exist
 

package/skills/start-specification/references/display-single-no-spec.md

@@ -14,12 +14,12 @@ Specification Overview
 Single concluded discussion found.
 
 1. {Title Case Name}
-    └─ Spec: none
-    └─ Discussions:
-       └─ {discussion-name} (ready)
+   └─ Spec: none
+   └─ Discussions:
+      └─ {discussion-name} (ready)
 ```
 
-Indentation: `└─` starts at column 4 (under the name text, not the number). Discussion entries start at column 7.
+**Output in a fenced code block exactly as shown above.**
 
 ### If in-progress discussions exist
 

package/skills/start-specification/references/display-specs-menu.md

@@ -20,13 +20,13 @@ For each non-superseded specification from discovery output, display as nested t
 
 ```
 1. {Spec Title Case Name}
-    └─ Spec: {status} ({X} of {Y} sources extracted)
-    └─ Discussions:
-       ├─ {source-name} (extracted)
-       └─ {source-name} (extracted)
+   └─ Spec: {status} ({X} of {Y} sources extracted)
+   └─ Discussions:
+      ├─ {source-name} (extracted)
+      └─ {source-name} (extracted)
 ```
 
-Indentation: `└─` starts at column 4 (under the name text, not the number). Discussion entries start at column 7.
+**Output in a fenced code block exactly as shown above.**
 
 Determine discussion status from the spec's `sources` array:
 - `incorporated` + `discussion_status: concluded` or `not-found` → `extracted`
@@ -114,6 +114,8 @@ Select an option (enter number):
 · · · · · · · · · · · ·
 ```
 
+**Output in a fenced code block exactly as shown above.**
+
 Menu descriptions are wrapped in backticks to visually distinguish them from the choice labels.
 
 **STOP.** Wait for user response.

package/skills/technical-implementation/SKILL.md

@@ -175,6 +175,8 @@ Present the existing configuration for confirmation:
 > - **`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.
 
 - **`yes`**: → Proceed to **Step 5**.
@@ -203,6 +205,8 @@ Scan `.claude/skills/` for project-specific skill directories. Present findings:
 > - **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.
 
 Store the selected skill paths in the tracking file.
@@ -231,6 +235,8 @@ Otherwise, present discovery findings to the user:
 > - **`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.
 
 - **`yes`**: Store the approved linter commands in the tracking file.

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

@@ -37,6 +37,8 @@ If `analysis_cycle > 3`:
 > - **`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.
 
 - **`proceed`**: → Continue to **B. Git Checkpoint**.
@@ -65,6 +67,8 @@ If there are unstaged changes or untracked files, categorize them:
 > - **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.
 
 Commit included files:
@@ -147,6 +151,8 @@ Then present each task with `status: pending` individually:
 > - **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.
 
 #### If `approve`

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

@@ -50,6 +50,8 @@ Present the executor's ISSUES to the user:
 > - **`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.
 
 #### If `retry`
@@ -108,6 +110,8 @@ Present the reviewer's findings and fix analysis to the user:
 > - **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.
 
 - **`y`/`yes`**: → 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).
@@ -137,6 +141,8 @@ Present a summary and wait for user input:
 > - **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.
 
 - **`y`/`yes`**: → Proceed to **E. Update Progress and Commit**.

package/skills/technical-planning/SKILL.md

@@ -89,6 +89,8 @@ Load **[spec-change-detection.md](references/spec-change-detection.md)** to chec
 > - **`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.
 
 #### If `continue`
@@ -131,6 +133,8 @@ Present the recommendation:
 > - **`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.
 
 **If no recommendation, or user declined:**

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

@@ -32,7 +32,7 @@ The agent clears any existing dependencies/priorities, analyzes all tasks, and
 
 #### If the agent reports no changes needed (`STATUS: no-changes`)
 
-The natural task order is already correct. Present this to the user:
+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.
 >
@@ -44,6 +44,8 @@ The natural task order is already correct. Present this to the user:
 > - **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.
 
 #### If the agent reports a cycle (`STATUS: blocked`)
@@ -60,7 +62,7 @@ No changes were applied. Present the cycle to the user:
 
 #### If the agent applied changes successfully (`STATUS: complete`)
 
-Dependencies and priorities have already been written to the task files. Present the summary:
+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:
 >
@@ -78,6 +80,8 @@ Dependencies and priorities have already been written to the task files. Present
 > - **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.
 
 #### If the user provides feedback

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

@@ -25,7 +25,7 @@ Invoke `planning-task-author` with these file paths:
 
 ### Present the Output
 
-The agent returns complete task detail following the task template from task-design.md. Present it to the user **exactly as it will be written** — what the user sees is what gets logged.
+The agent returns complete task detail following the task template from task-design.md. Present it to the user as rendered markdown (not in a code block) **exactly as it will be written** — what the user sees is what gets logged.
 
 After presenting, ask:
 
@@ -38,6 +38,8 @@ After presenting, ask:
 > - **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.
 
 #### If the user provides feedback

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

@@ -53,7 +53,7 @@ Continue to **Review and Approve** below.
 
 ## Review and Approve
 
-Present the phase structure to the user.
+Present the phase structure to the user as rendered markdown (not in a code block). Then, separately, present the choices:
 
 **STOP.** Ask:
 
@@ -66,6 +66,8 @@ Present the phase structure to the user.
 > - **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
 
 Re-invoke `planning-phase-designer` with all original inputs PLUS:

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

@@ -38,7 +38,7 @@ planning:
 
 Commit: `planning({topic}): draft Phase {N} task list`
 
-Present the task overview to the user.
+Present the task overview to the user as rendered markdown (not in a code block). Then, separately, present the choices:
 
 **STOP.** Ask:
 
@@ -49,6 +49,8 @@ Present the task overview to the user.
 > - **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
 
 Re-invoke `planning-task-designer` with all original inputs PLUS:

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

@@ -67,7 +67,7 @@ After Step A returns with an approved task table, continue to **Author Tasks for
 
 #### If the phase has a task table
 
-Present the task list to the user for review.
+Present the task list to the user as rendered markdown (not in a code block).
 
 > **Phase {N}: {Phase Name}** — {M} tasks.
 >
@@ -78,6 +78,8 @@ Present the task list to the user for review.
 > - **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.
 
 **If the user wants changes:** → Go to **Step A** with this phase for revision.

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

@@ -49,6 +49,8 @@ Skip the resolution and reverse check — there is nothing to resolve against. D
 > - **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
 
 Incorporate feedback, re-present the updated dependency state, and ask again. Repeat until approved.

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

@@ -117,7 +117,7 @@ Show the finding with full detail:
 
 ### Propose the Fix
 
-Present the proposed fix **in the format it will be written to the plan**. What the user sees is what gets applied — no changes between approval and writing.
+Present the proposed fix **in the format it will be written to the plan**, rendered as markdown (not in a code block). What the user sees is what gets applied — no changes between approval and writing.
 
 State the action type explicitly so the user knows what's changing structurally:
 
@@ -178,6 +178,8 @@ After presenting the finding and proposed fix, ask:
 > - **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.
 
 ### If the user provides feedback

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

@@ -95,7 +95,7 @@ Show the finding with full detail:
 
 ### Propose the Fix
 
-Present the proposed fix **in the format it will be written to the plan**. What the user sees is what gets applied — no changes between approval and writing.
+Present the proposed fix **in the format it will be written to the plan**, rendered as markdown (not in a code block). What the user sees is what gets applied — no changes between approval and writing.
 
 State the action type explicitly so the user knows what's changing structurally:
 
@@ -156,6 +156,8 @@ After presenting the finding and proposed fix, ask:
 > - **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.
 
 ### If the user provides feedback

package/skills/technical-research/SKILL.md

@@ -93,6 +93,8 @@ When you notice convergence, **flag it and give the user options**:
 > - 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.
 
 ### If the user parks it

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

@@ -70,13 +70,13 @@ For each topic or subtopic, perform exhaustive extraction:
 **Why this matters:** The specification is the single source of truth for planning. Planning will not reference prior source material - only this document. Missing a detail here means that detail doesn't get implemented.
 
 ### 2. Synthesize and Present
-Present your understanding to the user **in the format it would appear in the specification**:
+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 it would appear]
+> [content as rendered markdown]
 
-Then present two explicit choices:
+Then, **separately from the content above** (clear visual break), present the choices as raw markdown:
 
 > · · · · · · · · · · · ·
 > **To proceed:**
@@ -84,7 +84,7 @@ Then present two explicit choices:
 > - **Or tell me what to change.**
 > · · · · · · · · · · · ·
 
-**Do not paraphrase these choices.** Present them exactly as written so users always know what to expect.
+**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).
 
 > **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.
 
@@ -512,11 +512,11 @@ For each item, follow the **same workflow as the main specification process**:
 
 1. **Present** the item in detail - what you found, where it came from (source reference), and what you propose to add
 2. **Discuss** if needed - clarify ambiguities, answer questions, refine the content
-3. **Present for approval** - show exactly what will be written to the specification:
+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 exactly as it would appear]
+   > [content as rendered markdown]
    >
    > · · · · · · · · · · · ·
    > **To proceed:**
@@ -524,6 +524,8 @@ For each item, follow the **same workflow as the main specification process**:
    > - **Or tell me what to change.**
    > · · · · · · · · · · · ·
 
+   **Do not wrap content or choices in a code block.** 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
 6. **Update tracking file** - Mark the item's resolution (Approved/Adjusted/Skipped) and add any notes
@@ -644,11 +646,11 @@ For each item:
 
 1. **Present** the gap in detail - what's missing or unclear, what questions an implementer would have
 2. **Discuss** - work with the user to determine the correct specification content
-3. **Present for approval** - show exactly what will be written:
+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 exactly as it would appear]
+   > [content as rendered markdown]
    >
    > · · · · · · · · · · · ·
    > **To proceed:**
@@ -656,6 +658,8 @@ For each item:
    > - **Or tell me what to change.**
    > · · · · · · · · · · · ·
 
+   **Do not wrap content or choices in a code block.** Content and choices must be visually distinct.
+
 4. **Wait for explicit approval**
 5. **Log verbatim** when approved
 6. **Update tracking file** - Mark resolution and add notes