cc-codeconductor 0.4.3 → 1.0.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-codeconductor",
-  "version": "0.4.3",
+  "version": "1.0.0",
   "description": "A multi-agent orchestration framework for AI-assisted software engineering workflows.",
   "keywords": [
     "ai",
@@ -16,6 +16,8 @@
   "license": "MIT",
   "files": [
     "dist/index.js",
+    "dist/library.js",
+    "dist/**/*.d.ts",
     "policy.yml",
     "presets/",
     "src/presets/"
@@ -28,13 +30,24 @@
     "node": ">=20.11"
   },
   "type": "module",
+  "main": "./dist/library.js",
+  "types": "./dist/index.d.ts",
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "import": "./dist/library.js"
+    }
+  },
   "bin": {
     "cc-codeconductor": "./dist/index.js",
     "codeconductor": "./dist/index.js"
   },
   "scripts": {
     "dev": "bun run src/cli/main.ts",
-    "build": "bun build src/cli/main.ts --target=node --outfile=dist/index.js",
+    "build": "bun run scripts/build.ts",
+    "build:cli": "bun build src/cli/main.ts --target=node --outfile=dist/index.js",
+    "build:lib": "bun build src/index.ts --target=node --outfile=dist/library.js --packages=external",
+    "build:types": "tsc -p tsconfig.lib.json --emitDeclarationOnly",
     "test": "bun test",
     "typecheck": "tsc --noEmit",
     "check:prompt-changelog": "bun run scripts/check-prompt-changelog.ts",

package/policy.yml

@@ -42,23 +42,24 @@ denyWrite:
   - ".git/**"
   - ".claude/**"
   - ".opencode/**"
+  # Session handoffs belong in .codeconductor/sessions/ (gitignored). The
+  # compiler does not exist yet; gitignore + workflow redaction are the
+  # compensating controls for /cc:handoff.
   - ".codeconductor/**"
   - ".code-conductor/policy.yml"
   - "/etc/**"
   - "/var/**"
   - "~/**"
 
-# Credential patterns for secret detection.
-# These are merged with CodeConductorConfig.safety.secretPatterns at runtime.
-secretPatterns:
-  - password
-  - secret
-  - api_key
-  - token
-  - api[_-]?key
-  - access[_-]?token
-  - auth[_-]?token
-  - private[_-]?key
+# Optional keyword patterns for secret detection, merged with
+# CodeConductorConfig.safety.secretPatterns at runtime.
+#
+# Built-in detection does NOT rely on this list: high-confidence signatures
+# (AWS access key ids, AWS_SECRET_ACCESS_KEY values, GitHub PATs, PEM/OpenSSH
+# private key headers) are enforced in code and always active. Entries here add
+# legacy keyword matching (`<keyword> = <value of 8+ chars>`), which is prone to
+# false positives — add them only when a project needs them.
+secretPatterns: []
 
 targets:
   opencode:

package/presets/agy/AGENTS.md

@@ -74,6 +74,12 @@ Antigravity CLI loads custom slash commands from `.agents/workflows/*.md`. The f
 | `/cc-tdd-cycle`  | Runs a Test-Driven Development (TDD) cycle                         |
 | `/cc-api-contract`| Handles API contract modification and validation                  |
 | `/cc-db-migration`| Coordinates database schema migrations safely                      |
+| `/cc-iterative`  | Advanced iterative workflow — wayfinding, grilling, TDD, council |
+| `/cc-explore`    | Map the repo and recommend the next `/cc:` command               |
+| `/cc-triage`     | Classify type, risk, and destination workflow                    |
+| `/cc-prototype`  | Disposable spike in an isolated worktree                         |
+| `/cc-handoff`    | Compact the session to `.codeconductor/` Markdown                |
+| `/cc-clarify`    | Re-explain the last deliverable in Task Card vocabulary          |
 | `/cc-pagespeed`  | Performs a web performance and Core Web Vitals audit               |
 
 ---
@@ -99,13 +105,13 @@ When multiple signals apply, take the highest risk level. Do not average.
 
 | Task Type            | Risk        | Route                                               |
 | -------------------- | ----------- | --------------------------------------------------- |
-| New feature design   | any         | `architect` → `implementer`                         |
-| Bug fix              | low         | `implementer`                                       |
-| Bug fix              | medium–high | `task-coach` → `implementer` → `tester`             |
+| New feature design   | any         | `architect` → `tester` → `implementer`              |
+| Bug fix              | low         | `tester` → `implementer`                            |
+| Bug fix              | medium–high | `task-coach` → `tester` → `implementer`             |
 | Refactor             | low         | `implementer`                                       |
 | Refactor             | medium–high | `architect` → `implementer` → `reviewer`            |
 | API change           | any         | `architect` → `implementer` → `reviewer`            |
-| Database migration   | any         | `architect` → `implementer` → `tester` → `reviewer` |
+| Database migration   | any         | `architect` → `tester` → `implementer` → `reviewer` |
 | Test coverage        | any         | `tester`                                            |
 | Documentation update | any         | `docs`                                              |
 | Codebase exploration | any         | `repo-explorer`                                     |
@@ -265,7 +271,7 @@ High-risk checkpoint: [yes | no — if yes, describe what triggers a stop]
 **Does not:** Write files. Execute commands. Make routing decisions.
 
 **Template matching:**
-The planner matches objective keywords against built-in templates (auth, crud, search, notification, migration) and falls back to a generic 4-task chain: task-coach → architect → implementer → tester.
+The planner matches objective keywords against built-in templates (auth, crud, search, notification, migration) and falls back to a generic 4-task chain: task-coach → architect → tester → implementer.
 
 **Dependency order delegation (orchestrator):**
 When the orchestrator receives a GoalGraph, it delegates tasks in dependency order. A task is only routed after all its `depends_on` targets complete with status `done`. If a dependency is `blocked`, the dependent task remains `pending`. The orchestrator tracks the graph state in `.codeconductor/current-goal.yml`.

package/presets/agy/gates/pre-commit/GATE.md

@@ -0,0 +1,136 @@
+# Pre-commit Gate: Typecheck and Test
+
+Este gate instala un hook `pre-commit` que ejecuta `bun run typecheck` y `bun run test` antes de permitir commits en el repositorio. Si cualquiera de estos comandos falla, el commit es bloqueado.
+
+## Cuándo usar
+
+**Para agentes**: Integra este gate en flujos de desarrollo local cuando quieras garantizar que los cambios typecheck correctamente y pasan los tests antes de ser cometidos.
+
+**Para equipos**: Utiliza este gate como barrera de calidad local (sin dependencias externas) para prevenir commits con errores de tipado o tests fallidos.
+
+## Instalación
+
+### Paso 1: Descarga el script
+
+El script está embebido abajo (sección "Script Installer").
+
+### Paso 2: Ejecuta en la raíz de tu proyecto
+
+Desde la raíz del repositorio (o cualquier subdirectorio), extrae el bloque ```bash de este archivo y ejecuta:
+
+    bash << 'SCRIPT_EOF'
+    #!/bin/bash
+    set -e
+    # [contenido del bloque bash de abajo]
+    SCRIPT_EOF
+
+O, más simplemente, guarda el script en un archivo temporal y ejecútalo:
+
+    curl -s https://raw.githubusercontent.com/.../ | bash
+
+### Paso 3: Verifica
+
+Después de la instalación, debería verse:
+
+    Pre-commit hook installed successfully.
+
+## Script Installer
+
+```bash
+#!/bin/bash
+set -e
+
+# Resolver git directory dinámicamente (worktree-safe)
+GIT_DIR=$(git rev-parse --git-dir)
+HOOK_PATH="$GIT_DIR/hooks/pre-commit"
+
+# Detectar Husky o lint-staged en package.json
+if grep -q '"husky"' package.json 2>/dev/null || grep -q '"lint-staged"' package.json 2>/dev/null; then
+  echo "Warning: Husky or lint-staged detected in package.json. Installation skipped."
+  exit 0
+fi
+
+# Verificar si un pre-commit hook ya existe
+if [ -f "$HOOK_PATH" ]; then
+  echo "Warning: Pre-commit hook already exists at $HOOK_PATH. Not overwriting."
+  exit 0
+fi
+
+# Crear directorio hooks si no existe
+mkdir -p "$GIT_DIR/hooks"
+
+# Escribir el hook pre-commit
+cat > "$HOOK_PATH" << 'HOOK_EOF'
+#!/bin/bash
+bun run typecheck || exit 1
+bun run test || exit 1
+HOOK_EOF
+
+# Hacer el hook ejecutable
+chmod +x "$HOOK_PATH"
+
+echo "Pre-commit hook installed successfully."
+```
+
+## Notas de implementación
+
+- **Sin dependencias externas**: El script no instala Husky, lint-staged, ni ninguna otra herramienta. Solo escribe un archivo shell y configura permisos.
+- **Resolución dinámica de git dir**: Usa `git rev-parse --git-dir` para localizar el directorio correcto, incluso en worktrees.
+- **Detección de conflictos**: Si Husky o lint-staged ya está en `package.json`, el script avisa y no instala para evitar conflictos.
+- **Protección de hooks existentes**: Si ya existe un `.git/hooks/pre-commit`, el script no lo sobrescribe.
+- **Solo Bun**: El hook ejecuta `bun run typecheck` y `bun run test`. Asegúrate de que estos scripts están definidos en `package.json`.
+
+## Verificación
+
+Después de instalar, verifica que el hook está en su lugar.
+
+Para verificar, ejecuta:
+
+    ls -la .git/hooks/pre-commit
+
+Debe mostrar algo como:
+
+    -rwxr-xr-x  user  group  ... .git/hooks/pre-commit
+
+Luego, intenta hacer un commit. Si hay errores de tipo o tests fallidos, el commit será bloqueado:
+
+    git add .
+    git commit -m "test"
+    # Si typecheck o test falla, verás el error y el commit será abortado.
+
+## Troubleshooting
+
+### "Warning: Pre-commit hook already exists"
+
+Ya hay un hook pre-commit. Revisa su contenido:
+
+    cat .git/hooks/pre-commit
+
+Si quieres reemplazarlo, bórralo y ejecuta el script nuevamente:
+
+    rm .git/hooks/pre-commit
+    bash /path/to/installer
+
+### "Warning: Husky or lint-staged detected"
+
+Tu proyecto usa Husky o lint-staged. Este gate no se instala para evitar conflictos. Si quieres usar este gate, remove Husky/lint-staged de `package.json` y ejecuta de nuevo.
+
+### Hook no se ejecuta al hacer commit
+
+Verifica que el hook es ejecutable:
+
+    chmod +x .git/hooks/pre-commit
+
+Verifica que `bun run typecheck` y `bun run test` existen en `package.json`:
+
+    cat package.json | grep -A 5 '"scripts"'
+
+### "command not found: bun"
+
+Bun no está instalado o no está en PATH. Instala Bun desde https://bun.sh o configura PATH adecuadamente.
+
+## Adicional: Desinstalación
+
+Para remover el hook, simplemente bórralo:
+
+    rm .git/hooks/pre-commit

package/presets/agy/skills/cc-fix/SKILL.md

@@ -47,7 +47,7 @@ Read the risk field from the Task Card and follow the corresponding route.
 Applies when: the bug is isolated to a single component, existing tests cover
 the affected code, and no public API or shared state is involved.
 
-Route: `task-coach` → `implementer` → `tester`
+Route: `task-coach` → `tester` → `implementer`
 
 Proceed directly to Step 3a.
 
@@ -56,7 +56,7 @@ Proceed directly to Step 3a.
 Applies when: the bug touches shared state, a public API, auth or payment paths,
 database writes, or the root cause is not yet understood.
 
-Route: `task-coach` → `architect` → `implementer` → `tester` → `reviewer`
+Route: `task-coach` → `architect` → `tester` → `implementer` → `reviewer`
 
 Invoke `architect` before implementation. architect must:
 

package/presets/agy/skills/cc-tdd-cycle/SKILL.md

@@ -30,6 +30,17 @@ non-negotiable:
 Do not write implementation code during RED. Do not refactor during GREEN.
 Mixing phases invalidates the cycle.
 
+## Verifiable phase gates
+
+RED → GREEN and GREEN → REFACTOR are enforced by `tddCycleStateMachine` in
+`domain/loop`. Evidence must be captured with `captureTddSuiteEvidence` (verification
+runner) — do not hand-edit JSON under `.codeconductor/evidence/`.
+
+- RED→GREEN requires runner evidence that the suite **failed**.
+- GREEN→REFACTOR requires runner evidence that the suite **passed**.
+
+Do not advance phases until that evidence exists.
+
 ---
 
 ## Phase 1 — RED (Tester role)

package/presets/agy/skills/evaluation/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: evaluation
+description: Scorecard and outcome tracking for CodeConductor workflows.
+---
+
+Record outcomes via `scorecard record`. Use `scorecard models` before OpenSpec phases.

package/presets/agy/skills/openspec/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: openspec
+description:
+  OpenSpec backlog format, state machine, and delivery workflow for CodeConductor.
+  Use when running /cc-openspec or editing BACKLOG.md.
+---
+
+# OpenSpec / BACKLOG Skill
+
+## BACKLOG.md contract
+
+`BACKLOG.md` at repo root is the operational queue. Required sections:
+
+- `## Global` — Product, Strategy, Policy, Review required, TDD required
+- `## Items` — active backlog entries
+- `## Archive` — completed entries (do not re-execute)
+
+Each item: `### BC-001 | Short title` with Priority (P0–P3), Status, Type, Depends on, Description, Scope, Out of scope, Acceptance (measurable checklist).
+
+## Status machine
+
+`TODO` → `READY` → `PLANNED` → `IN_PROGRESS` → `REVIEW` → `DONE` → Archive
+
+## CLI
+
+`openspec validate | scan | plan | status | next`
+
+## Agent phases
+
+discover → repo-explorer, design → architect, test → tester, implement → implementer, review → reviewer.
+
+TDD required: test before implement.

package/presets/agy/workflows/cc-api-contract.md

@@ -9,6 +9,18 @@ description:
 
 API contract request: $ARGUMENTS
 
+## Step 0 — CCEP Bootstrap
+
+Command: `api-contract` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command api-contract "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command api-contract "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile api-contract --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command api-contract --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
 ## Step 1 — Task Card validation (task-coach)
 
 Invoke `task-coach` with the request above.

package/presets/agy/workflows/cc-ask.md

@@ -0,0 +1,55 @@
+---
+description: >-
+  [cc: alias] Recommend one CodeConductor slash command from a natural-language
+  problem. Does not start that workflow.
+---
+
+# Ask — recommend a slash command
+
+Problem: $ARGUMENTS
+
+This is a **router**, not a delivery workflow. Recommend exactly one command.
+Do **not** run the recommended `/cc:` command unless the human confirms.
+
+---
+
+## Step 1 — Recommend (deterministic)
+
+Run (local repo: `bun run dev`; published package: `npx cc-codeconductor`):
+
+```bash
+bun run dev ask "$ARGUMENTS" --output json
+```
+
+or:
+
+```bash
+npx cc-codeconductor ask "$ARGUMENTS" --output json
+```
+
+The catalog is only:
+
+| Slash | When |
+| ----- | ---- |
+| `/cc:feature` | new behavior |
+| `/cc:fix` | bug / regression |
+| `/cc:refactor` | structure, no behavior change |
+| `/cc:review` | inspect a diff/PR |
+| `/cc:tdd-cycle` | red → green → refactor |
+| `/cc:openspec` | BACKLOG / BC-xxx delivery |
+
+If the CLI is unavailable, apply the same catalog and the same priority:
+openspec → tdd-cycle → review → refactor → fix → feature (default).
+
+---
+
+## Step 2 — Show and stop
+
+Print:
+
+- **Recommended:** the slash command
+- **Why:** one or two sentences from the CLI `reason` (or your matching)
+
+**STOP.** Wait for the human. Do not invoke the recommended workflow.
+
+For a full preset inventory (skills, commands on disk), use `/cc:help` / `cc-help`.

package/presets/agy/workflows/cc-clarify.md

@@ -0,0 +1,33 @@
+---
+name: cc-clarify
+description:
+  Re-explain the last deliverable in Task Card vocabulary when it did not land.
+---
+
+# Clarify Workflow
+
+Clarify request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `clarify` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command clarify "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command clarify "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile clarify --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command clarify --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+## Step 1 — Re-explain (task-coach)
+
+Invoke `task-coach` / `orchestrator`. Restate the last Task Card, plan, or review in the project's vocabulary. Do not add new scope. If questions remain, one question per branch.
+
+**STOP if ConfirmationGate reports questions.**
+
+---
+
+## Completion
+
+A plain-language restatement plus any remaining questions. Then resume the previous workflow.

package/presets/agy/workflows/cc-council.md

@@ -7,20 +7,44 @@ description: Run the full Council-Driven Development workflow — SDD spec creat
 
 Task request: $ARGUMENTS
 
-## Step 1 — Deliberation & Specification (SDD)
+## Step 0 — CCEP Bootstrap
+
+Command: `council` (fixed for this workflow — do not infer from user text)
+command: council
+
+1. Run: `npx cc-codeconductor ccep parse --command council "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command council "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile council --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command council --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
+`graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
+to map impact radius before deliberation. Do not write code in this step.
+
+---
+
+## Step 2 — Deliberation & Specification (SDD)
 
 Invoke the `council` skill to analyze the request before writing any code. The council must act as a steering committee involving `task-coach` (Product), `architect`, and `devil`.
 
 The council must:
 1. Clarify the prompt and define the absolute minimum scope (Simplicity Gate).
-2. Explicitly document all assumptions and resolve ambiguities (Think Before Coding).
+2. Explicitly document all assumptions and run the Grilling protocol on each one (Think Before Coding).
 3. Draft a Task Card & Technical Plan (The Specification).
 
-**STOP here. Show the agreed Task Card & Technical Plan and wait for human confirmation before continuing.**
+**STOP here.** Unresolved grilling questions populate `questionsForUser` in the
+CCEP-1 `planner-output`; `ccep evaluate` (ConfirmationGate) halts until a human
+answers. Show the agreed Task Card & Technical Plan and wait for confirmation
+before continuing.
 
 ---
 
-## Step 2 — Test Definition (TDD)
+## Step 3 — Test Definition (TDD)
 
 Invoke `tester` with the approved Task Card & Technical Plan.
 
@@ -32,7 +56,7 @@ tester must:
 
 ---
 
-## Step 3 — Surgical Implementation
+## Step 4 — Surgical Implementation
 
 Invoke `implementer` with the failing tests and the Technical Plan.
 
@@ -44,7 +68,7 @@ implementer must:
 
 ---
 
-## Step 4 — Multi-Perspective Council Review
+## Step 5 — Multi-Perspective Council Review
 
 Invoke the `council` skill on the generated diff to perform the final review phase.
 
@@ -52,7 +76,7 @@ The council will evaluate the diff against the 6 axes (Architecture, Security, P
 
 If ANY agent votes CRITICAL (especially due to over-engineering, scope creep, or missing the verifiable goals):
 - The Review Report status is **BLOCKED**.
-- Return to Step 3 with the feedback.
+- Return to Step 4 with the feedback.
 
 If APPROVED (no CRITICAL findings):
 - Deliver the final Council Verdict and the diff summary.

package/presets/agy/workflows/cc-db-migration.md

@@ -9,6 +9,19 @@ description:
 
 Migration request: $ARGUMENTS
 
+## Step 0 — CCEP Bootstrap
+
+Command: `db-migration` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command db-migration "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command db-migration "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile db-migration --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command db-migration --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
 ## Step 1 — Task Card validation (task-coach)
 
 Invoke `task-coach` with the request above.
@@ -36,22 +49,22 @@ compatibility strategy, rollback/forward-fix notes, and test approach.
 
 ---
 
-## Step 3 — Implementation (implementer)
+## Step 3 — Migration tests (tester)
 
-Invoke `implementer` with the approved plan.
+Invoke `tester`.
 
-implementer must keep model and migration changes together, avoid unrelated
-refactors, and preserve the deployment order specified by architect.
+tester must cover migration-sensitive behavior where the stack supports it,
+including happy path, existing-data edge cases, and rollback/forward-fix notes
+when automated rollback tests are not practical.
 
 ---
 
-## Step 4 — Migration tests (tester)
+## Step 4 — Implementation (implementer)
 
-Invoke `tester`.
+Invoke `implementer` with the approved plan.
 
-tester must cover migration-sensitive behavior where the stack supports it,
-including happy path, existing-data edge cases, and rollback/forward-fix notes
-when automated rollback tests are not practical.
+implementer must keep model and migration changes together, avoid unrelated
+refactors, and preserve the deployment order specified by architect.
 
 ---
 

package/presets/agy/workflows/cc-explore.md

@@ -0,0 +1,37 @@
+---
+name: cc-explore
+description:
+  Map the repository and recommend the next CodeConductor slash command. Read-only.
+---
+
+# Explore Workflow
+
+Explore request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `explore` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command explore "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command explore "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile explore --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command explore --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+## Step 1 — Map (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"`. Invoke `repo-explorer`. Produce a Repo Map. Do not write code.
+
+---
+
+## Step 2 — Suggest next command (orchestrator)
+
+Recommend exactly one next slash command (`/cc:feature`, `/cc:fix`, `/cc:refactor`, `/cc:review`, `/cc:triage`, …) with a one-sentence rationale. Do not start that workflow.
+
+---
+
+## Completion
+
+Report the Repo Map and the recommended next `/cc:` command.