azclaude-copilot 0.4.12 → 0.4.13

package/templates/commands/refactor.md

@@ -18,6 +18,18 @@ Load: shared/completion-rule.md
 
 ---
 
+## Pre-Flight: Constitution Check
+
+```bash
+[ -f .claude/constitution.md ] && echo "constitution=found" || echo "no constitution"
+```
+
+If found: read `## Architectural Commitments` and `## Required Patterns`.
+Refactoring often changes structure — ensure the refactor moves TOWARD required patterns, not away from them.
+If the refactor would conflict with an architectural commitment → flag before starting Phase 1. Do not proceed silently.
+
+---
+
 ## Pre-Flight Analysis (intelligent-dispatch)
 
 Load `shared/intelligent-dispatch.md`.

package/templates/commands/setup.md

@@ -159,6 +159,47 @@ All ✓ required before printing "Setup complete."
 
 ---
 
+## Step 8: Governance + Spec Readiness
+
+After quality gate passes, check governance state:
+
+```bash
+# Constitution check
+[ -f .claude/constitution.md ] && echo "constitution=found" || echo "constitution=missing"
+
+# Spec directory check
+ls .claude/specs/*.md 2>/dev/null | head -3
+```
+
+Output a next-steps block:
+
+```
+─── Recommended Next Steps ──────────────────────────────
+```
+
+If constitution missing:
+```
+  ⚠ No project constitution found.
+    Run: /constitute
+    Why: defines non-negotiables, required patterns, definition of done.
+    Copilot checks this before every milestone implementation.
+```
+
+If no specs found:
+```
+  · No feature specs found.
+    Run: /spec [feature name]
+    Why: structured spec → /blueprint derives a better plan → /copilot builds the right thing.
+    Spec-first workflow: /spec → /clarify → /blueprint → /copilot
+```
+
+If both exist:
+```
+  ✓ Constitution and specs found. Ready for /copilot.
+```
+
+---
+
 ## If Running Again on an Existing Project
 
 Do not overwrite CLAUDE.md — read it first and update only the placeholders that are still unfilled.

package/templates/commands/ship.md

@@ -37,7 +37,25 @@ If problem-architect not installed OR git diff is only docs/config: skip and pro
 
 ## Pre-Ship Gate (runs before any commit)
 
-**0. Security scan** — check if `security-auditor` agent is installed:
+**0a. Ghost Milestone Check** — catch plan drift before it ships:
+
+```bash
+[ -f .claude/plan.md ] && echo "plan=found" || echo "plan=missing"
+```
+
+If `plan=found`: run `/analyze plan` inline:
+- Scan for milestones marked `done` where the committed files no longer exist
+- If ANY ghost milestones found → STOP:
+  ```
+  ✗ Pre-ship blocked: ghost milestones detected (marked done, files missing).
+    Run /analyze to see full list. Fix plan.md before shipping.
+  ```
+- If constitution.md exists: also verify no `pending` milestones violate a non-negotiable
+  (a quick grep is sufficient — full constitution-guard runs per-milestone during /copilot)
+
+If `plan=missing`: skip ghost check.
+
+**0b. Security scan** — check if `security-auditor` agent is installed:
 ```bash
 ls .claude/agents/security-auditor.md 2>/dev/null && echo "agent=found" || echo "agent=missing"
 ```

package/templates/commands/spec.md

@@ -0,0 +1,196 @@
+---
+name: spec
+description: >
+  Write a structured, versioned spec for a feature BEFORE planning or coding.
+  Triggers on: "write a spec", "spec this out", "create a spec", "spec for", "I need a spec",
+  "document the requirements", "write requirements for", "define what to build",
+  "spec-driven", "requirements document", "feature spec", "write the spec first",
+  "spec before we plan", "what should we build", "define the feature",
+  "product spec", "technical spec for", "write spec then plan",
+  "spec before blueprint", "let's spec this".
+  Use after /dream (intent exists) and before /blueprint (plan).
+  NOT triggered by "add X" or "build X" alone.
+argument-hint: "[feature or product description]"
+disable-model-invocation: true
+allowed-tools: Read, Write, Bash, Glob, Grep
+---
+
+# /spec — Write a Structured Spec
+
+$ARGUMENTS
+
+---
+
+## Purpose
+
+The spec is the primary artifact. Code is derived from it, not the reverse.
+A spec produced here becomes the canonical input for /blueprint → /add → /audit.
+Without a spec, /blueprint is guessing. With a spec, every milestone traces to a requirement.
+
+**Workflow position:**
+```
+/dream → /spec → /clarify (if needed) → /blueprint → /add
+```
+
+---
+
+## Copilot Mode Detection
+
+```bash
+[ -f .claude/copilot-intent.md ] && echo "COPILOT_MODE" || echo "INTERACTIVE_MODE"
+```
+
+If `COPILOT_MODE`: read `.claude/copilot-intent.md` as the source — skip Phase 1 questions.
+If `INTERACTIVE_MODE`: run Phase 1 as normal.
+
+---
+
+## Phase 1: Intake
+
+If $ARGUMENTS is blank or vague, use **AskUserQuestion**:
+- What are you building? (specific — "user login with JWT" not "auth")
+- Who uses it? (role/persona)
+- What's the single most important outcome for the first version?
+
+If a spec file already exists for this feature:
+```bash
+ls .claude/specs/ 2>/dev/null
+```
+Show existing spec and ask: "Use this as a base, or start fresh?"
+
+---
+
+## Phase 2: Context Scan
+
+```bash
+# Understand what already exists
+grep -i "domain:\|stack:\|scale:" CLAUDE.md 2>/dev/null | head -5
+
+# Find related existing code
+grep -ri "$(echo "$ARGUMENTS" | cut -d' ' -f1-3)" --include="*.ts" --include="*.py" --include="*.js" -l 2>/dev/null | head -8
+
+# Read constitution if it exists
+cat .claude/constitution.md 2>/dev/null | head -30
+```
+
+---
+
+## Phase 3: Write the Spec
+
+Generate slug and create spec file:
+
+```bash
+SLUG=$(echo "$ARGUMENTS" | tr '[:upper:]' '[:lower:]' | tr ' ' '-' | tr -cd 'a-z0-9-' | cut -c1-40)
+NEXT_N=$(ls .claude/specs/ 2>/dev/null | grep -c '^' || echo 0)
+N=$(printf '%02d' $((NEXT_N + 1)))
+mkdir -p .claude/specs
+SPEC_FILE=".claude/specs/${N}-${SLUG}.md"
+```
+
+Write `$SPEC_FILE`:
+
+```markdown
+# Spec: {feature title}
+id: {N}-{slug}
+created: {today's date}
+status: draft
+version: 1
+
+---
+
+## Goal
+{1-2 sentences — the problem this solves, for whom, and why now}
+
+## User Stories
+- As a {user type}, I want to {action} so that {outcome}
+- As a {user type}, I want to {action} so that {outcome}
+- As a {user type}, I want to {action} so that {outcome}
+
+## Acceptance Criteria
+All criteria must be independently verifiable — "given X, when Y, then Z" format.
+
+1. Given {precondition}, when {action}, then {expected outcome}
+2. Given {precondition}, when {action}, then {expected outcome}
+3. Given {precondition}, when {action}, then {expected outcome}
+
+## Data Model Changes
+{Describe any new or modified data structures, fields, tables, or schemas.}
+{If none: "No data model changes."}
+
+## API / Interface Changes
+{Describe new or modified endpoints, function signatures, events, or contracts.}
+{If none: "No API changes."}
+
+## Out of Scope (this version)
+- {explicitly excluded}
+- {explicitly excluded}
+- {explicitly excluded}
+
+## Failure Modes
+| Scenario | Expected behavior |
+|----------|-------------------|
+| {X fails} | {what should happen} |
+| {Y is missing} | {what should happen} |
+
+## Constraints
+- Performance: {requirement or "none"}
+- Security: {requirement or "none"}
+- Backwards compatibility: {requirement or "none"}
+- Dependencies: {blocked by or requires}
+
+## Open Questions
+{List any unresolved decisions. Run /clarify to resolve before /blueprint.}
+- [ ] {question}
+```
+
+---
+
+## Phase 4: Validate
+
+Before saving, check:
+- At least 3 acceptance criteria present
+- Out of scope section is not empty (forces explicit scoping)
+- No open questions remain (or mark spec as `draft` if they do)
+
+If any open questions remain → set `status: draft` and recommend `/clarify {spec-file}`.
+If all criteria met → set `status: ready-for-blueprint`.
+
+**Spec Reviewer Gate** (if `spec-reviewer` agent is installed):
+
+```bash
+ls .claude/agents/spec-reviewer.md 2>/dev/null && echo "agent=found" || echo "agent=missing"
+```
+
+If `agent=found` AND status is `ready-for-blueprint`: spawn spec-reviewer:
+```
+Review spec file: {SPEC_FILE}
+```
+
+- Verdict `APPROVED` → proceed to Completion Rule
+- Verdict `NEEDS_CLARIFY` → downgrade status to `draft`, output spec-reviewer feedback,
+  recommend `/clarify {spec-file}`
+- Verdict `INCOMPLETE` → do NOT write the file yet, list missing sections and re-run Phase 3
+
+If `agent=missing`: skip gate, trust manual validation above.
+
+---
+
+## Completion Rule
+
+Show:
+1. Spec file path: `.claude/specs/{N}-{slug}.md`
+2. Acceptance criteria count
+3. Status: `draft` or `ready-for-blueprint`
+4. Open questions count
+
+If `ready-for-blueprint`:
+```
+Next: /blueprint .claude/specs/{N}-{slug}.md
+```
+
+If `draft`:
+```
+Next: /clarify .claude/specs/{N}-{slug}.md  (resolve open questions first)
+```
+
+Do not write any implementation code during /spec.

package/templates/commands/tasks.md

@@ -0,0 +1,151 @@
+---
+name: tasks
+description: >
+  Generate a dependency-ordered, parallelizable task list from a plan or spec.
+  Shows what can run in parallel vs. what must be sequential.
+  Triggers on: "show me the tasks", "task breakdown", "what are the tasks", "task list",
+  "dependency order", "what can run in parallel", "task graph", "ordered tasks",
+  "show task dependencies", "what should I work on next", "task queue",
+  "breakdown the milestones", "sequential vs parallel", "work order",
+  "what's next to build", "task planning", "task dependency graph",
+  "what order should we build", "parallelizable tasks", "task ordering",
+  "task schedule", "which tasks block which".
+  Use BEFORE /copilot to understand the work order, or AFTER /blueprint to validate the plan.
+argument-hint: "[blank to read plan.md, or path to spec/plan file]"
+disable-model-invocation: true
+allowed-tools: Read, Bash, Glob, Grep
+---
+
+# /tasks — Dependency-Ordered Task List
+
+$ARGUMENTS
+
+**EnterPlanMode** — read-only. No file modifications.
+
+---
+
+## Step 1: Find the Source
+
+```bash
+# Check for plan.md
+ls .claude/plan.md 2>/dev/null && echo "plan found" || echo "no plan"
+
+# Check for specs
+ls .claude/specs/*.md 2>/dev/null | head -5
+
+# If $ARGUMENTS points to a file, use that
+[ -n "$ARGUMENTS" ] && [ -f "$ARGUMENTS" ] && echo "using: $ARGUMENTS"
+```
+
+Priority:
+1. If $ARGUMENTS is a file path → use that
+2. If `.claude/plan.md` exists → use plan.md
+3. If specs exist but no plan → suggest running `/blueprint` first
+4. If nothing found → use **AskUserQuestion**: "Paste the list of tasks or milestones to order"
+
+---
+
+## Step 2: Parse Tasks
+
+Read the source file. Extract each task/milestone with:
+- ID (M1, M2, … or T1, T2, …)
+- Title
+- `Depends:` field (what must be done first)
+- `Files:` field (for parallel collision detection)
+- Current status (`pending`, `in-progress`, `done`, `blocked`)
+
+---
+
+## Step 3: Build Dependency Graph
+
+For each task, determine:
+- **Blocked by**: all tasks that must complete before this one starts
+- **Blocks**: all tasks that cannot start until this one is done
+- **File collision**: tasks that write to the same files (cannot run in parallel)
+
+Check file collisions:
+```bash
+# Group tasks by shared files — tasks sharing files cannot run in parallel
+```
+
+---
+
+## Step 4: Identify Parallel Groups
+
+Tasks with no dependencies between them AND no file collisions can run in parallel.
+Group them into "waves":
+
+**Wave = a set of tasks that can all run simultaneously**
+
+Algorithm:
+1. Wave 1 = tasks with no `Depends:` and status `pending`
+2. Wave 2 = tasks that only depend on Wave 1 tasks
+3. Wave N = tasks that only depend on tasks in waves 1 through N-1
+4. A wave cannot contain tasks that share files
+
+---
+
+## Step 5: Output the Task Graph
+
+```
+Task Dependency Graph
+═════════════════════
+Source: {file}
+Total tasks: {N}  |  Done: {N}  |  Pending: {N}  |  Blocked: {N}
+
+── Wave 1 (can start now) ──────────────────────────────────────
+  ▶ M1  {title}                     [Files: src/auth/login.ts]
+  ▶ M2  {title}                     [Files: src/models/user.ts]
+  ▶ M3  {title}                     [Files: tests/auth/]
+
+── Wave 2 (after Wave 1) ───────────────────────────────────────
+  ▶ M4  {title}   ←depends M1       [Files: src/api/routes.ts]
+  ▶ M5  {title}   ←depends M2       [Files: src/services/]
+
+── Wave 3 (after Wave 2) ───────────────────────────────────────
+  ▶ M6  {title}   ←depends M4,M5    [Files: src/app.ts]
+
+── Blocked ─────────────────────────────────────────────────────
+  ✗ M7  {title}   reason: {from blockers.md}
+
+── Already Done ────────────────────────────────────────────────
+  ✓ M0  {title}
+```
+
+---
+
+## Step 6: Parallelism Analysis
+
+```
+Parallelism Analysis
+════════════════════
+Max parallel at once: {N tasks in largest wave}
+Critical path length: {N waves minimum to complete}
+File collision pairs: {N pairs that cannot run simultaneously}
+
+Suggested dispatch order for /copilot:
+  1. Start Wave 1 tasks simultaneously (or sequentially if no orchestrator)
+  2. On Wave 1 complete → start Wave 2
+  3. ...
+```
+
+---
+
+## Copilot Mode Integration
+
+If `.claude/agents/orchestrator.md` exists:
+→ Note: "The orchestrator will use this graph to dispatch milestone-builder agents in parallel"
+
+If no orchestrator:
+→ Note: "Copilot will process waves sequentially — Wave 1 first, then Wave 2, etc."
+
+---
+
+## Completion Rule
+
+**ExitPlanMode**
+
+Show: the full task graph with waves.
+Show: parallelism analysis.
+Show: critical path.
+Do not modify plan.md or any other file during /tasks.

package/templates/hooks/post-tool-use.js

@@ -219,7 +219,7 @@ let editCount = 1;
 try { editCount = parseInt(fs.readFileSync(counterPath, 'utf8'), 10) + 1; } catch (_) {}
 try { fs.writeFileSync(counterPath, String(editCount)); } catch (_) {}
 if (editCount > 0 && editCount % 15 === 0) {
-  process.stdout.write(`\n⚠ ${editCount} edits this session — run /snapshot before context compaction loses your reasoning\n`);
+  process.stderr.write(`\n⚠ ${editCount} edits this session — run /snapshot before context compaction loses your reasoning\n`);
 }
 
 // ── Rapid-edit detection — same file edited 5+ times in <5 min ───────────────

package/templates/skills/architecture-advisor/SKILL.md

@@ -25,6 +25,21 @@ HOW to code — it guides WHEN to use WHICH approach based on project context an
 Any decision where the right answer depends on project scale, team size, domain, or
 deployment target — not just technical preference.
 
+## Step 0: Constitution Check
+
+```bash
+[ -f .claude/constitution.md ] && echo "constitution=found" || echo "no constitution"
+```
+
+If found: read `## Architectural Commitments` before advising.
+Recommendations must not contradict an existing architectural commitment.
+If the user's question asks to deviate from a committed decision:
+1. State the conflict explicitly: "constitution.md commits to {X}, this recommendation would change that"
+2. Offer two paths: (a) recommendation within the constraint, (b) what amending the constitution would require
+3. Do NOT silently recommend the deviation without flagging the conflict.
+
+---
+
 ## Step 1: Detect Project Context
 
 Read these signals (skip what doesn't exist):