Summary
The design-analysis co-design stop renders the full Rule-46 six-section human-verdict packet (the gate-stop format), when it should be workshop-class — a lighter, picker-style collaborative interaction — like the initial design workshop. This is inconsistent with the established rule: the full six-section packet is mandatory at verdict boundary stops; the workshop is excluded, and workshop/clarify questions keep the AskUserQuestion picker.
Evidence
A feature crew at the design-analysis stage (reopening the design-workshop for the architecture decision) rendered the full packet:
## What I Just Did … ## Why I Stopped … ## What Needs Your Review … ## What Happens Next …
## What I Need From You — Confirm the decomposition, request changes, or ask to review … one at a time.
Design-analysis literally reopens the design-workshop process ("reopen the design-workshop process for the design-analysis architecture decision"), so it is collaborative co-design, not a binary approve/reject boundary verdict.
Root cause
.claude/skills/specrew-gate-stop/SKILL.md enumerates the verdict boundaries it fires at — specify, clarify, plan, tasks, before-implement, implement, review, retro, feature-closeout, lifecycle-end — and design-analysis is (correctly) absent. The skill body even states "the design workshop is unaffected: its per-lens questions keep the picker."- But there is no positive classification telling the crew that design-analysis is workshop-class and should use the workshop (picker) interaction. Design-analysis is recognized only as an artifact gate (
scripts/internal/design-analysis-gate.ps1, which checks design-analysis.md), not as a stop-format class.
- With no workshop-class signal, the crew defaults to the full verdict packet for a stop that needs human input.
Expected
Design-analysis (and any design-workshop reopen) is workshop-class: lighter interaction, keep the AskUserQuestion picker, no six-section verdict packet — identical to the initial design workshop. The packet/gate-stop path is reserved for the canonical verdict boundaries.
Fix direction
Positively classify the design-analysis stop as workshop-class in the stop-format governance (the workshop skill / coordinator instructions / conformance provider), so it routes through the workshop interaction rather than the gate-stop packet. The gate-stop skill already excludes it by omission; make the exclusion positive and ensure the workshop path claims it.
Minor adjacent inconsistency
The gate-stop skill's description says "Invoke at EVERY human-judgment boundary stop" and lists clarify, while its body says "Clarify questions are not boundary stops and keep the picker." The verdict-stop vs workshop/clarify-stop taxonomy isn't crisply enforced — design-analysis falls through that gap. Worth tightening the taxonomy in the same change.
Related
Feature 165 (gate-stop skill / picker-collapse fix), Features 171/185 (Stop-hook packet enforcement), Proposal 137 (design-analysis gate).
🤖 Generated with Claude Code
Summary
The design-analysis co-design stop renders the full Rule-46 six-section human-verdict packet (the gate-stop format), when it should be workshop-class — a lighter, picker-style collaborative interaction — like the initial design workshop. This is inconsistent with the established rule: the full six-section packet is mandatory at verdict boundary stops; the workshop is excluded, and workshop/clarify questions keep the
AskUserQuestionpicker.Evidence
A feature crew at the design-analysis stage (reopening the design-workshop for the architecture decision) rendered the full packet:
Design-analysis literally reopens the design-workshop process ("reopen the design-workshop process for the design-analysis architecture decision"), so it is collaborative co-design, not a binary approve/reject boundary verdict.
Root cause
.claude/skills/specrew-gate-stop/SKILL.mdenumerates the verdict boundaries it fires at —specify, clarify, plan, tasks, before-implement, implement, review, retro, feature-closeout, lifecycle-end— and design-analysis is (correctly) absent. The skill body even states "the design workshop is unaffected: its per-lens questions keep the picker."scripts/internal/design-analysis-gate.ps1, which checksdesign-analysis.md), not as a stop-format class.Expected
Design-analysis (and any design-workshop reopen) is workshop-class: lighter interaction, keep the
AskUserQuestionpicker, no six-section verdict packet — identical to the initial design workshop. The packet/gate-stop path is reserved for the canonical verdict boundaries.Fix direction
Positively classify the design-analysis stop as workshop-class in the stop-format governance (the workshop skill / coordinator instructions / conformance provider), so it routes through the workshop interaction rather than the gate-stop packet. The gate-stop skill already excludes it by omission; make the exclusion positive and ensure the workshop path claims it.
Minor adjacent inconsistency
The gate-stop skill's description says "Invoke at EVERY human-judgment boundary stop" and lists
clarify, while its body says "Clarify questions are not boundary stops and keep the picker." The verdict-stop vs workshop/clarify-stop taxonomy isn't crisply enforced — design-analysis falls through that gap. Worth tightening the taxonomy in the same change.Related
Feature 165 (gate-stop skill / picker-collapse fix), Features 171/185 (Stop-hook packet enforcement), Proposal 137 (design-analysis gate).
🤖 Generated with Claude Code