@leeovery/claude-technical-workflows 2.1.17 → 2.1.19

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/steps/analysis-loop.md

@@ -22,21 +22,25 @@ F. Create tasks in plan → invoke-task-writer.md
 
 Increment `analysis_cycle` in the implementation tracking file.
 
+→ If `analysis_cycle <= 3`, proceed directly to **B. Git Checkpoint**.
+
 If `analysis_cycle > 3`:
 
-> **Analysis cycle {N} — this is beyond the standard 3 cycles.**
+**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
-> - **`p`/`proceed`** — Run analysis anyway
+> · · · · · · · · · · · ·
 
-**STOP.** Wait for user choice.
+**STOP.** Wait for user choice. You MUST NOT choose on the user's behalf.
 
-- **`skip`**: → Return to the skill for **Step 8**.
 - **`proceed`**: → Continue to **B. Git Checkpoint**.
-
-→ If `analysis_cycle <= 3`, proceed to **B. Git Checkpoint**.
+- **`skip`**: → Return to the skill for **Step 8**.
 
 ---
 
@@ -55,11 +59,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 +141,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-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