@leeovery/claude-technical-workflows 2.1.16 → 2.1.18

package/agents/implementation-analysis-architecture.md

@@ -27,6 +27,8 @@ You receive via the orchestrator's prompt:
 - Integration test gaps — are cross-task workflows tested end-to-end?
 - Seam quality between task boundaries — do the pieces fit together cleanly?
 - Over/under-engineering — are abstractions justified by usage? Is raw code crying out for structure?
+- Missed composition opportunities — are new abstractions independently implemented when they could be derived from existing ones? If two queries are logical inverses, one should be defined in terms of the other.
+- Type safety at boundaries — are interfaces or function signatures using untyped parameters when the concrete types are known? Runtime type checks inside implementations signal the signature should be more specific.
 
 ## Your Process
 

package/agents/implementation-task-reviewer.md

@@ -42,10 +42,12 @@ Are all criteria genuinely met — not just self-reported?
 - Check for criteria that are technically met but miss the intent
 
 ### 3. Test Adequacy
-Do tests actually verify the criteria? Are edge cases covered?
+Do tests actually verify the criteria? Are assertions precise? Are edge cases covered?
 - Is there a test for each acceptance criterion?
 - Would the tests fail if the feature broke?
 - Are edge cases from the task's test cases covered?
+- **Assertion depth**: For mutation operations, do tests verify observable side effects — not just that the operation returned success? State changes should be asserted independently.
+- **Assertion precision**: When expected output is deterministic, do tests use exact comparison? Substring or partial matching masks formatting regressions and missing/extra content.
 - Flag both under-testing AND over-testing
 
 ### 4. Convention Adherence
@@ -61,6 +63,7 @@ Is this a sound design decision? Will it compose well with future tasks?
 - Are there coupling or abstraction concerns?
 - Will this cause problems for subsequent tasks in the phase?
 - Are there structural concerns that should be raised now rather than compounding?
+- Are concrete types used where data structures are known? Flag untyped escape hatches used where concrete types would be clearer and safer.
 
 ## Fix Recommendations (needs-changes only)
 

package/package.json

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

package/skills/link-dependencies/SKILL.md

@@ -161,11 +161,11 @@ UPDATED FILES:
 If any files were updated:
 
 ```
-· · ·
-
+· · · · · · · · · · · ·
 Shall I commit these dependency updates?
 - **`y`/`yes`** — Commit the changes
 - **`n`/`no`** — Skip
+· · · · · · · · · · · ·
 ```
 
 If yes, commit with message:

package/skills/start-discussion/SKILL.md

@@ -228,35 +228,35 @@ Discussions:
 
 **If research AND discussions exist:**
 ```
-· · ·
-
+· · · · · · · · · · · ·
 How would you like to proceed?
 
 - **`r`/`refresh`** — Force fresh research analysis
 - From research — pick a topic number above (e.g., "1" or "research 1")
 - 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?
 
 - **`r`/`refresh`** — Force fresh research analysis
 - 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-implementation/SKILL.md

@@ -210,8 +210,7 @@ Then re-run /start-implementation.
 
 **Otherwise (multiple selectable plans, or implemented plans exist):**
 ```
-· · ·
-
+· · · · · · · · · · · ·
 Select a plan (enter number):
 ```
 
@@ -260,11 +259,11 @@ INCOMPLETE (planned but not implemented):
 - {topic}: task {task_id} not yet completed
   -> This task must be completed first.
 
-· · ·
-
+· · · · · · · · · · · ·
 - **`i`/`implement`** — Implement the blocking dependencies first
 - **`l`/`link`** — Run /link-dependencies to wire up recently completed plans
 - Mark as "satisfied externally" — tell me which dependency was implemented outside this workflow
+· · · · · · · · · · · ·
 ```
 
 **STOP.** Wait for user response.

package/skills/start-planning/SKILL.md

@@ -155,8 +155,7 @@ Omit either section entirely if it has no entries.
 
 **If multiple actionable items:**
 ```
-· · ·
-
+· · · · · · · · · · · ·
 Select a specification (enter number):
 ```
 
@@ -232,10 +231,10 @@ Note: The following cross-cutting specifications are still in-progress:
 
 These may contain architectural decisions relevant to this plan.
 
-· · ·
-
+· · · · · · · · · · · ·
 - **`c`/`continue`** — Plan without them
 - **`s`/`stop`** — Complete them first (/start-specification)
+· · · · · · · · · · · ·
 ```
 
 **STOP.** Wait for user response.

package/skills/start-research/SKILL.md

@@ -10,14 +10,14 @@ Invoke the **technical-research** skill for this conversation.
 
 This is **Phase 1** of the six-phase workflow:
 
-| Phase | Focus | You |
-|-------|-------|-----|
-| **1. Research** | EXPLORE - ideas, feasibility, market, business | ◀ HERE |
-| 2. Discussion | WHAT and WHY - decisions, architecture, edge cases | |
-| 3. Specification | REFINE - validate into standalone spec | |
-| 4. Planning | HOW - phases, tasks, acceptance criteria | |
-| 5. Implementation | DOING - tests first, then code | |
-| 6. Review | VALIDATING - check work against artifacts | |
+| Phase             | Focus                                              | You    |
+|-------------------|----------------------------------------------------|--------|
+| **1. Research**   | EXPLORE - ideas, feasibility, market, business     | ◀ HERE |
+| 2. Discussion     | WHAT and WHY - decisions, architecture, edge cases |        |
+| 3. Specification  | REFINE - validate into standalone spec             |        |
+| 4. Planning       | HOW - phases, tasks, acceptance criteria           |        |
+| 5. Implementation | DOING - tests first, then code                     |        |
+| 6. Review         | VALIDATING - check work against artifacts          |        |
 
 **Stay in your lane**: Explore freely. This is the time for broad thinking, feasibility checks, and learning. Surface options and tradeoffs — don't make decisions. When a topic converges toward a conclusion, that's a signal it's ready for discussion phase, not a cue to start deciding. Park it and move on.
 
@@ -43,95 +43,20 @@ Follow these steps EXACTLY as written. Do not skip steps or combine them. Presen
 
 Invoke the `/migrate` skill and assess its output.
 
-**If files were updated**: STOP and wait for the user to review the changes (e.g., via `git diff`) and confirm before proceeding to Step 1. Do not continue automatically.
+**If files were updated**: STOP and wait for the user to review the changes (e.g., via `git diff`) and confirm before proceeding to Step 1.
 
 **If no updates needed**: Proceed to Step 1.
 
 ---
 
-## Step 1: Get the Seed Idea
+## Step 1: Gather Context
 
-Ask:
-
-```
-What's on your mind?
-
-- What idea or topic do you want to explore?
-- What prompted this - a problem, opportunity, curiosity?
-```
-
-**STOP.** Wait for user response before proceeding.
+Load **[gather-context.md](references/gather-context.md)** and follow its instructions as written.
 
 → Proceed to **Step 2**.
 
 ---
 
-## Step 2: Understand Current Knowledge
-
-Ask:
-
-```
-What do you already know?
-
-- Any initial thoughts or research you've done?
-- Constraints or context I should be aware of?
-```
-
-**STOP.** Wait for user response before proceeding.
-
-→ Proceed to **Step 3**.
-
----
-
-## Step 3: Determine Starting Point
-
-Ask:
-
-```
-Where should we start?
-
-- Technical feasibility? Market landscape? Business model?
-- Or just talk it through and see where it goes?
-```
-
-**STOP.** Wait for user response before proceeding.
-
-→ Proceed to **Step 4**.
-
----
-
-## Step 4: Gather Final Context
-
-Ask:
-
-```
-Any constraints or context I should know about upfront?
-
-(Or "none" if we're starting fresh)
-```
-
-**STOP.** Wait for user response before proceeding.
-
-→ Proceed to **Step 5**.
-
----
-
-## Step 5: Invoke the Skill
-
-After completing the steps above, this skill's purpose is fulfilled.
-
-Invoke the [technical-research](../technical-research/SKILL.md) skill for your next instructions. Do not act on the gathered information until the skill is loaded - it contains the instructions for how to proceed.
-
-**Example handoff:**
-```
-Research session for: {topic}
-Output: docs/workflow/research/exploration.md
-
-Context:
-- Prompted by: {problem, opportunity, or curiosity}
-- Already knows: {any initial thoughts or research, or "starting fresh"}
-- Starting point: {technical feasibility, market, business model, or "open exploration"}
-- Constraints: {any constraints mentioned, or "none"}
+## Step 2: Invoke the Skill
 
-Invoke the technical-research skill.
-```
+Load **[invoke-skill.md](references/invoke-skill.md)** and follow its instructions as written.

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

@@ -0,0 +1,68 @@
+# Gather Context
+
+*Reference for **[start-research](../SKILL.md)***
+
+---
+
+Ask each question below **one at a time**. After each, **STOP** and wait for the user's response before proceeding.
+
+---
+
+## Seed Idea
+
+Ask:
+
+```
+What's on your mind?
+
+- What idea or topic do you want to explore?
+- What prompted this - a problem, opportunity, curiosity?
+```
+
+**STOP.** Wait for user response before proceeding.
+
+---
+
+## Current Knowledge
+
+Ask:
+
+```
+What do you already know?
+
+- Any initial thoughts or research you've done?
+- Constraints or context I should be aware of?
+```
+
+**STOP.** Wait for user response before proceeding.
+
+---
+
+## Starting Point
+
+Ask:
+
+```
+Where should we start?
+
+- Technical feasibility? Market landscape? Business model?
+- Or just talk it through and see where it goes?
+```
+
+**STOP.** Wait for user response before proceeding.
+
+---
+
+## Final Context
+
+Ask:
+
+```
+Any constraints or context I should know about upfront?
+
+(Or "none" if we're starting fresh)
+```
+
+**STOP.** Wait for user response before proceeding.
+
+---

package/skills/start-research/references/invoke-skill.md

@@ -0,0 +1,23 @@
+# Invoke the Skill
+
+*Reference for **[start-research](../SKILL.md)***
+
+---
+
+This skill's purpose is now fulfilled.
+
+Invoke the [technical-research](../../technical-research/SKILL.md) skill for your next instructions. Do not act on the gathered information until the skill is loaded - it contains the instructions for how to proceed.
+
+**Example handoff:**
+```
+Research session for: {topic}
+Output: docs/workflow/research/exploration.md
+
+Context:
+- Prompted by: {problem, opportunity, or curiosity}
+- Already knows: {any initial thoughts or research, or "starting fresh"}
+- Starting point: {technical feasibility, market, business model, or "open exploration"}
+- Constraints: {any constraints mentioned, or "none"}
+
+Invoke the technical-research skill.
+```

package/skills/start-review/SKILL.md

@@ -114,8 +114,7 @@ Available Plans:
   1. {topic-1} ({status}) - format: {format}, spec: {exists|missing}
   2. {topic-2} ({status}) - format: {format}, spec: {exists|missing}
 
-· · ·
-
+· · · · · · · · · · · ·
 Which plan would you like to review the implementation for? (Enter a number or name)
 ```
 
@@ -138,13 +137,13 @@ Auto-selecting: {topic} (only available plan)
 Ask the user what code to review:
 
 ```
-· · ·
-
+· · · · · · · · · · · ·
 What code should I review?
 
 - **`a`/`all`** — All changes since the plan was created
 - **`g`/`git`** — Identify from git status
 - Specific directories or files — tell me which
+· · · · · · · · · · · ·
 ```
 
 **STOP.** Wait for user response.

package/skills/start-specification/SKILL.md

@@ -210,13 +210,13 @@ Check `cache.status` from discovery to determine which options to present.
 ##### If `cache.status: "valid"`
 
 ```
-· · ·
-
+· · · · · · · · · · · ·
 What would you like to do?
 
 - **`c`/`continue`** — Resume work on a spec in progress
 - **`s`/`select`** — Choose from previously analyzed groupings ({cache.generated})
 - **`r`/`refresh`** — Fresh analysis of discussion relationships
+· · · · · · · · · · · ·
 ```
 
 **STOP.** Wait for user response.
@@ -224,14 +224,14 @@ What would you like to do?
 ##### If `cache.status: "stale"`
 
 ```
-· · ·
-
+· · · · · · · · · · · ·
 What would you like to do?
 
 Note: A previous grouping analysis exists but is now outdated - discussion documents have changed since it was created. Re-analysis is required, but existing specification names will be preserved where groupings overlap.
 
 - **`c`/`continue`** — Resume work on a spec in progress
 - **`a`/`assess`** — Re-analyze discussions for combinations
+· · · · · · · · · · · ·
 ```
 
 **STOP.** Wait for user response.
@@ -239,12 +239,12 @@ Note: A previous grouping analysis exists but is now outdated - discussion docum
 ##### If `cache.status: "none"`
 
 ```
-· · ·
-
+· · · · · · · · · · · ·
 What would you like to do?
 
 - **`c`/`continue`** — Resume work on a spec in progress
 - **`a`/`assess`** — Analyze discussions for combinations
+· · · · · · · · · · · ·
 ```
 
 **STOP.** Wait for user response.
@@ -474,8 +474,7 @@ Coupling: {explanation}
 
 ---
 
-· · ·
-
+· · · · · · · · · · · ·
 How would you like to proceed?
 
 - **`p`/`proceed`** — As recommended (I'll ask which to start with)
@@ -483,6 +482,7 @@ How would you like to proceed?
 - **`i`/`individual`** — Create 1:1 specs (I'll ask which to start)
 - **`r`/`refresh`** — Re-analyze discussions
 - Combine differently — tell me your preferred groupings
+· · · · · · · · · · · ·
 ```
 
 **Status Legend:**
@@ -564,10 +564,10 @@ This reorganization affects multiple existing specifications:
 
 Moving discussions between established specifications requires deleting the affected specs and re-processing. The source material in your discussions is preserved.
 
-· · ·
-
+· · · · · · · · · · · ·
 - **`d`/`delete`** — Remove affected specs and create fresh ones for your new groupings
 - **`r`/`reconsider`** — Adjust your groupings to affect fewer specs
+· · · · · · · · · · · ·
 ```
 
 **STOP.** Wait for user choice.
@@ -608,11 +608,11 @@ Check if `docs/workflow/specification/unified.md` already exists.
 
 This will consolidate ALL {N} concluded discussions into a single specification.
 
-· · ·
-
+· · · · · · · · · · · ·
 Proceed with unified specification?
 - **`y`/`yes`** — Proceed
 - **`n`/`no`** — Cancel
+· · · · · · · · · · · ·
 ```
 
 **STOP.** Wait for user to confirm, then proceed to **Step 9** with all discussions as sources.
@@ -665,11 +665,11 @@ Output: docs/workflow/specification/{grouping-name}.md
 After completion:
 - specification/{topic-c}.md will be marked as superseded
 
-· · ·
-
+· · · · · · · · · · · ·
 Proceed?
 - **`y`/`yes`** — Proceed
 - **`n`/`no`** — Go back
+· · · · · · · · · · · ·
 ```
 
 #### If creating a NEW grouped specification (no existing specs)
@@ -684,11 +684,11 @@ Sources:
 
 Output: docs/workflow/specification/{grouping-name}.md
 
-· · ·
-
+· · · · · · · · · · · ·
 Proceed?
 - **`y`/`yes`** — Proceed
 - **`n`/`no`** — Go back
+· · · · · · · · · · · ·
 ```
 
 #### If CONTINUING an existing grouped specification
@@ -702,11 +702,11 @@ Sources:
 - docs/workflow/discussion/{topic-a}.md
 - docs/workflow/discussion/{topic-b}.md
 
-· · ·
-
+· · · · · · · · · · · ·
 Proceed?
 - **`y`/`yes`** — Proceed
 - **`n`/`no`** — Go back
+· · · · · · · · · · · ·
 ```
 
 #### If creating/continuing an INDIVIDUAL specification
@@ -719,11 +719,11 @@ Sources:
 
 Output: docs/workflow/specification/{topic}.md
 
-· · ·
-
+· · · · · · · · · · · ·
 Proceed?
 - **`y`/`yes`** — Proceed
 - **`n`/`no`** — Go back
+· · · · · · · · · · · ·
 ```
 
 **STOP.** Wait for user confirmation.

package/skills/technical-implementation/SKILL.md

@@ -62,6 +62,10 @@ Do not guess at progress or continue from memory. The files on disk and git hist
 1. **No autonomous decisions on spec deviations** — when the executor reports a blocker or spec deviation, present to user and STOP. Never resolve on the user's behalf.
 2. **All git operations are the orchestrator's responsibility** — agents never commit, stage, or interact with git.
 
+## Output Formatting
+
+When announcing a new step, output `── ── ── ── ──` on its own line before the step heading.
+
 ---
 
 ## Step 1: Environment Setup
@@ -162,14 +166,14 @@ Commit: `impl({topic}): start implementation`
 
 Present the existing configuration for confirmation:
 
-> "Previous session used these project skills:
+> Previous session used these project skills:
 > - `{skill-name}` — {path}
 > - ...
 >
-> · · ·
->
+> · · · · · · · · · · · ·
 > - **`y`/`yes`** — Keep these, proceed
-> - **`c`/`change`** — Re-discover and choose skills"
+> - **`c`/`change`** — Re-discover and choose skills
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for user choice.
 
@@ -193,7 +197,11 @@ Scan `.claude/skills/` for project-specific skill directories. Present findings:
 > - `{skill-name}` — {brief description}
 > - ...
 >
-> Which of these should I pass to the implementation agents? (all / list / none)
+> · · · · · · · · · · · ·
+> - **`a`/`all`** — Use all listed skills
+> - **`n`/`none`** — Skip project skills
+> - **Or list the ones you want** — e.g. "golang-pro, react-patterns"
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for user to confirm which skills are relevant.
 
@@ -217,11 +225,11 @@ Otherwise, present discovery findings to the user:
 >
 > 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)
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for user choice.
 

package/skills/technical-implementation/references/code-quality.md

@@ -12,8 +12,11 @@ Apply standard quality principles. Defer to project-specific skills for framewor
 - Extract repeated logic after three instances (Rule of Three)
 - Avoid premature abstraction for code used once or twice
 
+### Compose, Don't Duplicate
+When new behavior is the logical inverse or subset of existing behavior, derive it from the existing abstraction rather than implementing independently. If you have a query for "ready items," the query for "blocked items" should be "open AND NOT ready" — not an independently authored query that could drift. Prefer mathematical relationships (derived = total - computed) over parallel computations that must be kept in sync.
+
 ### SOLID
-- **Single Responsibility**: Each class/function does one thing
+- **Single Responsibility**: Each class/function does one thing. Multi-step logic should decompose into named helper functions — each step a function, each name documents intent.
 - **Open/Closed**: Extend behavior without modifying existing code
 - **Liskov Substitution**: Subtypes must be substitutable for base types
 - **Interface Segregation**: Don't force classes to implement unused methods
@@ -25,6 +28,9 @@ Keep low. Fix with early returns and method extraction.
 ### YAGNI
 Only implement what's in the plan. Ask: "Is this in the plan?"
 
+### Concrete Over Abstract
+Prefer concrete types over language-level escape hatches that bypass the type system. Use specific types for data passing between layers, not untyped containers. If you need polymorphism, define a named interface/protocol with specific methods — don't pass untyped values. If you find yourself writing runtime type checks or casts inside a function, the signature is too abstract.
+
 ## Testability
 - Inject dependencies
 - Prefer pure functions
@@ -36,6 +42,8 @@ Only implement what's in the plan. Ask: "Is this in the plan?"
 - Deep nesting (3+)
 - Long parameter lists (4+)
 - Boolean parameters
+- Untyped parameters when concrete types are known at design time
+- Substring assertions in tests when exact output is deterministic
 
 ## Project Standards
 Check `.claude/skills/` for project-specific patterns.

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

@@ -26,10 +26,10 @@ If `analysis_cycle > 3`:
 
 > **Analysis cycle {N} — this is beyond the standard 3 cycles.**
 >
-> · · ·
->
+> · · · · · · · · · · · ·
 > - **`s`/`skip`** — Skip analysis, proceed to completion
 > - **`p`/`proceed`** — Run analysis anyway
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for user choice.
 
@@ -55,11 +55,11 @@ If there are unstaged changes or untracked files, categorize them:
 > - `{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
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for user choice.
 
@@ -137,11 +137,11 @@ Then present each task with `status: pending` individually:
 > **Tests**:
 > {tests}
 >
-> · · ·
->
+> · · · · · · · · · · · ·
 > - **`a`/`approve`** — Approve this task
 > - **`s`/`skip`** — Skip this task
 > - **Comment** — Revise based on feedback
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for user input.
 

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

@@ -44,11 +44,11 @@ Present the executor's ISSUES to the user:
 >
 > {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
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for user choice.
 
@@ -101,12 +101,12 @@ Present the reviewer's findings and fix analysis to the user:
 > 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
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for user choice.
 
@@ -130,12 +130,12 @@ Present a summary and wait for user input:
 > 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)
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for user input.
 

package/skills/technical-implementation/references/tdd-workflow.md

@@ -42,7 +42,9 @@ But write **complete, functional implementations** - don't artificially minimize
 
 **Derive tests from plan**: Task's micro acceptance becomes your first test. Edge cases become additional tests.
 
-**Write test names first**: List all test names before writing bodies. Confirm coverage matches acceptance criteria.
+**Assert precisely**: For mutation operations (create, update, delete, state transitions), don't just assert the return value — verify observable side effects independently. A test that checks "operation succeeded" but ignores whether timestamps updated, related records changed, or output structure is correct will miss regressions that only affect side effects. Assert structured output by parsing and checking fields/values, not by string matching the serialized form.
+
+**Write test names first**: List all test names before writing bodies. Confirm coverage matches acceptance criteria. Then consider: invalid input types, boundary values, zero/nil/empty inputs, single vs multiple items, and success alongside failure paths — add tests for any that are relevant and non-trivial.
 
 **No implementation code exists yet.** If you're tempted to "just sketch out the class first" - don't. The test comes first. Always.
 

package/skills/technical-planning/SKILL.md

@@ -58,6 +58,10 @@ This process constructs a plan from a specification. A plan consists of:
 
 Follow every step in sequence. No steps are optional.
 
+## Output Formatting
+
+When announcing a new step, output `── ── ── ── ──` on its own line before the step heading.
+
 ---
 
 ## Step 0: Resume Detection
@@ -76,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}).
+> 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."
+> - **`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.
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for user response.
 
@@ -120,12 +124,12 @@ First, choose the Output Format.
 
 Present the recommendation:
 
-> "Existing plans use **{format}**. Use the same format for consistency?
->
-> · · ·
+> Existing plans use **{format}**. Use the same format for consistency?
 >
+> · · · · · · · · · · · ·
 > - **`y`/`yes`** — Use {format}
-> - **`n`/`no`** — See all available formats"
+> - **`n`/`no`** — See all available formats
+> · · · · · · · · · · · ·
 
 **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,11 +38,11 @@ The natural task order is already correct. Present this to the user:
 >
 > {notes from agent output}"
 
-> · · ·
->
+> · · · · · · · · · · · ·
 > **To proceed:**
 > - **`y`/`yes`** — Confirmed.
 > - **Or tell me what to change.**
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for the user's response.
 
@@ -72,11 +72,11 @@ Dependencies and priorities have already been written to the task files. Present
 >
 > {any notes from agent output}"
 
-> · · ·
->
+> · · · · · · · · · · · ·
 > **To proceed:**
 > - **`y`/`yes`** — Approved.
 > - **Or tell me what to change.**
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for the user's response.
 

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

@@ -31,12 +31,12 @@ 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.
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for the user's response.
 

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

@@ -59,12 +59,12 @@ Present the phase structure to the user.
 
 > **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.
+> · · · · · · · · · · · ·
 
 #### If the user provides feedback
 

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

@@ -42,12 +42,12 @@ Present the task overview to the user.
 
 **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.
+> · · · · · · · · · · · ·
 
 #### If the user provides feedback
 

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

@@ -71,12 +71,12 @@ Present the task list to the user for review.
 
 > **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.
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for the user's response.
 

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

@@ -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.**
+> · · · · · · · · · · · ·
 
 #### If the user provides feedback
 

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

@@ -171,12 +171,12 @@ 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.**
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for the user's response.
 

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

@@ -149,12 +149,12 @@ 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.**
+> · · · · · · · · · · · ·
 
 **STOP.** Wait for the user's response.
 

package/skills/technical-research/SKILL.md

@@ -87,11 +87,11 @@ 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
+> · · · · · · · · · · · ·
 
 **Never decide for the user.** Even if the answer seems obvious, flag it and ask.
 

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

@@ -78,11 +78,11 @@ Present your understanding to the user **in the format it would appear in the sp
 
 Then present two explicit choices:
 
-> · · ·
->
+> · · · · · · · · · · · ·
 > **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 paraphrase these choices.** Present them exactly as written so users always know what to expect.
 
@@ -518,11 +518,11 @@ For each item, follow the **same workflow as the main specification process**:
    >
    > [content exactly as it would appear]
    >
-   > · · ·
-   >
+   > · · · · · · · · · · · ·
    > **To proceed:**
    > - **`y`/`yes`** — Approved. I'll add the above to the specification **verbatim**.
    > - **Or tell me what to change.**
+   > · · · · · · · · · · · ·
 
 4. **Wait for explicit approval** - same rules as always: `y`/`yes` or equivalent before writing
 5. **Log verbatim** when approved
@@ -650,11 +650,11 @@ For each item:
    >
    > [content exactly as it would appear]
    >
-   > · · ·
-   >
+   > · · · · · · · · · · · ·
    > **To proceed:**
    > - **`y`/`yes`** — Approved. I'll add the above to the specification **verbatim**.
    > - **Or tell me what to change.**
+   > · · · · · · · · · · · ·
 
 4. **Wait for explicit approval**
 5. **Log verbatim** when approved