cc-codeconductor 0.4.3 → 1.0.0

package/presets/cursor/commands/cc/feature.md

@@ -0,0 +1,137 @@
+---
+description: >-
+  [cc: alias] Run the full feature workflow — task validation, technical design,
+  implementation, testing, review, and documentation.
+---
+
+# Feature Workflow
+
+Feature request: $ARGUMENTS
+
+---
+
+## Step 0 — CCEP Bootstrap
+
+Command: `feature` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command feature "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command feature "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile feature --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command feature --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 — 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 modules, conventions, and impact radius. Do not write code in this step.
+Record a Repo Map artifact before intake.
+
+---
+
+## Step 2 — Task Card validation (Task Coach role)
+
+Invoke the `task-coach` subagent via the Task tool.
+
+Produce a complete Task Card. The Task Card is ready when it contains: title,
+type, risk classification, scope, context, acceptance criteria, and constraints.
+
+If any field is missing or ambiguous, ask one clarifying question at a time and
+wait for the answer. Do not proceed with an incomplete Task Card.
+
+**STOP here. Show the completed Task Card and wait for human confirmation before
+continuing.**
+
+---
+
+## Step 3 — Technical Plan (Architect role)
+
+Invoke the `architect` subagent via the Task tool.
+
+Produce a Technical Plan that covers:
+
+- Chosen approach and rationale
+- Affected files and modules
+- Data model changes (if any)
+- API contract changes (if any)
+- Identified risks and mitigations
+- Open questions that require a human decision
+
+**STOP here. Show the Technical Plan and wait for explicit human approval. Do
+not proceed to implementation until the plan is approved.**
+
+---
+
+## Step 4 — Test coverage (Tester role)
+
+Invoke the `tester` subagent via the Task tool.
+
+Use the Implementation Summary and the Task Card.
+
+1. Write or extend failing tests for the new behavior before implementation (RED).
+2. Ensure all acceptance criteria from the Task Card have at least one test.
+3. Run the full test suite and confirm it passes.
+4. Produce a Test Report: test files added or modified, cases covered.
+
+---
+
+## Step 5 — Implementation (Implementer role)
+
+Invoke the `implementer` subagent via the Task tool.
+
+Use the approved Technical Plan and the Task Card from the steps above.
+Implementer creates a Git Worktree before touching any file; all edits happen inside it.
+
+1. Read the Technical Plan before touching any file.
+2. Apply the minimal diff — only what the plan specifies.
+3. Run the project test suite and make the previously written failing tests pass.
+4. Produce an Implementation Summary: what changed, which files, how to verify
+   locally.
+
+---
+
+## Step 6 — Code review (Reviewer role)
+
+Invoke the `reviewer` subagent via the Task tool.
+
+Use the complete diff and the Task Card.
+
+Produce a Review Report with findings categorized as CRITICAL, WARNING, or
+SUGGESTION.
+
+If any CRITICAL findings exist, **STOP and report them**. Do not proceed until
+they are resolved and the diff is re-reviewed.
+
+---
+
+## Step 7 — Documentation (Docs role)
+
+Invoke the `docs` subagent via the Task tool.
+
+Invoke this step only if any of the following changed:
+
+- A public API endpoint was added or modified
+- A public interface or module was introduced
+- Behavior visible to end users changed
+
+Update: README (if applicable), OpenAPI spec (if applicable), CHANGELOG
+(always), ADR (if an architectural decision was made).
+
+---
+
+## Completion
+
+Report the following:
+
+- Task Card (final)
+- Technical Plan (approved)
+- Implementation Summary
+- Test Report
+- Review Report (all findings resolved)
+- List of documentation files updated (if any)
+
+The feature is complete only when: all tests pass, no CRITICAL review findings
+remain, and documentation reflects the implemented behavior.

package/presets/cursor/commands/cc/fix.md

@@ -0,0 +1,148 @@
+---
+description: >-
+  [cc: alias] Run the bug fix workflow — risk-based routing through task
+  validation, implementation, testing, and optional review.
+---
+
+# Bug Fix Workflow
+
+Bug description: $ARGUMENTS
+
+Provide the following information in $ARGUMENTS:
+
+- What is the incorrect behavior (actual)
+- What is the expected behavior
+- Steps to reproduce
+- Environment or version where the bug occurs (if known)
+- Any relevant error messages or stack traces
+
+---
+
+## Step 0 — CCEP Bootstrap
+
+Command: `fix` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command fix "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command fix "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile fix --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command fix --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 — 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 modules, conventions, and impact radius. Do not write code in this step.
+Record a Repo Map artifact before intake.
+
+---
+
+## Step 2 — Task Card validation (Task Coach role)
+
+Invoke the `task-coach` subagent via the Task tool.
+
+Produce a Task Card that includes:
+
+- A clear statement of actual vs. expected behavior
+- Reproduction steps (or a note that they are unknown)
+- Risk classification: `low`, `medium`, or `high`
+- Scope: which files or modules are likely affected
+
+If reproduction steps are missing, ask for them before classifying risk. A bug
+without a reproduction path cannot be classified reliably.
+
+Capture evidence before tests: reproduction, logs or stack traces, and one
+falsifiable hypothesis of the root cause. Do not patch without that evidence.
+Redact secrets, tokens, and credential dumps from logs before they enter the
+Task Card. Summarize stack traces; do not paste env files.
+
+**STOP here. Show the Task Card and wait for human confirmation.**
+
+---
+
+## Step 3 — Route by risk
+
+Read the risk field from the Task Card and follow the corresponding route.
+
+### Low-risk 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 → Tester → Implementer
+
+Proceed directly to Step 3 (tests), then Step 4a.
+
+### Medium or high-risk route
+
+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 → Tester → Implementer → Reviewer
+
+Invoke the `architect` subagent before implementation. Architect must:
+
+- Identify the root cause (or document that it is unknown)
+- Define the fix approach and affected files
+- Flag any regression risk to adjacent components
+- Produce a Technical Plan
+
+**STOP here if high-risk. Show the Technical Plan and wait for human approval
+before continuing.**
+
+---
+
+## Step 4 — Regression tests (Tester role)
+
+Invoke the `tester` subagent via the Task tool. Apply for all risk levels.
+
+1. Write a regression test that reproduces the original bug and confirm it fails
+   before any fix (RED).
+2. Verify that existing tests still pass.
+3. Produce a Test Report: test added, case covered.
+
+---
+
+## Step 5a — Implementation, low-risk (Implementer role)
+
+Invoke the `implementer` subagent via the Task tool. Use the Task Card.
+Implementer creates a Git Worktree before touching any file; all edits happen inside it.
+
+1. Locate the defect using the reproduction steps.
+2. Apply the minimal fix — no unrelated changes.
+3. Run the suite and make the RED regression test pass.
+4. Produce an Implementation Summary: root cause, fix applied, files changed.
+
+---
+
+## Step 5b — Implementation, medium/high-risk (Implementer role)
+
+Invoke the `implementer` subagent via the Task tool. Use the approved
+Technical Plan and the Task Card.
+Implementer creates a Git Worktree before touching any file; all edits happen inside it.
+
+Follow the plan exactly. Any deviation requires a new Technical Plan approval.
+After implementation, run the full test suite.
+
+---
+
+## Step 6 — Review (Reviewer role) — medium/high-risk only
+
+Invoke the `reviewer` subagent via the Task tool. Use the diff and Task
+Card.
+
+Produce a Review Report with CRITICAL / WARNING / SUGGESTION findings. If any
+CRITICAL findings exist, **STOP**. Do not close the fix until they are resolved.
+
+---
+
+## Completion
+
+Report: Task Card, Implementation Summary, regression test added, Review Report
+(if applicable).
+
+The fix is complete only when: the regression test passes, the full suite
+passes, and no CRITICAL review findings remain.

package/presets/cursor/commands/cc/handoff.md

@@ -0,0 +1,41 @@
+---
+description: >-
+  [cc: alias] Compact the session into gitignored `.codeconductor/sessions/handoff.md` (redact secrets).
+---
+
+# Handoff Workflow
+
+Handoff request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `handoff` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command handoff "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command handoff "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile handoff --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command handoff --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 — Compact (docs)
+
+Invoke `docs`. Write **only** `.codeconductor/sessions/handoff.md` (gitignored).
+Do not write `.codeconductor/handoff.md` or any tracked path.
+
+Before writing, redact secrets, tokens, API keys, passwords, connection strings,
+`.env` contents, and log/stack-trace lines that embed those values. Summarize
+errors instead of pasting dumps. If unresolved credential material remains, stop
+and wait for a human (CCEP `stopOnHighRisk`).
+
+Include: goal, Task Card status (no secret fields), files touched, test
+pass/fail (not log dumps), open questions, and the next `/cc:` command.
+
+Do not edit source or tests.
+
+---
+
+## Completion
+
+Report the handoff path. Another session should be able to continue from that file alone.

package/presets/cursor/commands/cc/iterative.md

@@ -0,0 +1,133 @@
+---
+description: >-
+  [cc: alias] Run the advanced iterative workflow — Wayfinding AST discovery,
+  Relentless Grilling, contract and spec design, TDD, council review, and docs.
+---
+
+# Advanced Iterative Workflow
+
+Iterative request: $ARGUMENTS
+
+---
+
+## Step 0 — CCEP Bootstrap
+
+Command: `iterative` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command iterative "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command iterative "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile iterative --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command iterative --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 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
+`graphify path` / `graphify explain` when two modules or one concept need a
+scoped subgraph). Then invoke the `repo-explorer` subagent via the Task tool
+with that graph output.
+
+repo-explorer maps directory trees, conventions, god nodes, and affected
+modules. Do not write code in this step. Write a short phase handoff (scope,
+files, open questions) before the next phase — do not chain agents on unspoken
+context.
+
+---
+
+## Step 2 — Relentless Grilling & Task Card (task-coach)
+
+Invoke the `task-coach` subagent via the Task tool.
+
+Produce a complete Task Card. The Task Card is ready when it contains: title,
+type, risk classification, scope, context, acceptance criteria, and
+constraints, and every assumption behind it has survived one grilling
+question (Grilling protocol).
+
+If any field is missing or ambiguous, ask one clarifying question at a time and
+wait for the answer. Do not proceed with an incomplete Task Card.
+
+**STOP here.** Unresolved grilling questions or missing fields populate
+`questionsForUser` in the CCEP-1 `planner-output`; the `ConfirmationGate`
+(`ccep evaluate`) reads that field and halts the workflow until a human
+answers. Show the completed Task Card and wait for that confirmation before
+continuing.
+
+---
+
+## Step 3 — Contract & Technical Plan (contract-builder & architect)
+
+Invoke `contract-builder` then `architect` via the Task tool.
+
+1. Define API contracts, JSON Schemas, or TypeScript interfaces.
+2. Formulate the Technical Plan (chosen approach, affected files, trade-offs).
+3. Apply YAGNI, Simplicity First, and Stdlib-First.
+
+**STOP here. Show the Technical Plan and wait for explicit human approval. Do
+not proceed to tests until the plan is approved.**
+
+---
+
+## Step 4 — Test coverage (Tester role)
+
+Invoke the `tester` subagent via the Task tool.
+
+1. Write or extend failing tests for the new behavior before implementation (RED).
+2. Ensure all acceptance criteria from the Task Card have at least one test.
+3. Produce a Test Report: test files added or modified, cases covered.
+
+---
+
+## Step 5 — Implementation (Implementer role)
+
+Invoke the `implementer` subagent via the Task tool.
+
+Use the approved Technical Plan, contracts, and the failing tests.
+Implementer creates a Git Worktree before touching any file; all edits happen
+inside it.
+
+1. Read the Technical Plan before touching any file.
+2. Apply the minimal diff — only what the plan specifies.
+3. Run the project test suite and make the previously written failing tests pass.
+4. If tests fail, run up to 3 repair cycles (`implementer` → `tester`).
+5. Produce an Implementation Summary: what changed, which files, how to verify
+   locally.
+
+---
+
+## Step 6 — Multi-Perspective Council Review
+
+Invoke the `council` skill on the generated diff (`council-review` phase).
+
+The council evaluates Architecture, Security, Product, Delivery, DataOps, and
+Devil. `security-reviewer` may set `securityVeto: true`; that REJECTED verdict
+overrides majority consensus.
+
+If ANY agent votes CRITICAL:
+- The Review Report status is **BLOCKED**.
+- Return to Step 5 with the feedback.
+
+If APPROVED (no CRITICAL findings), continue.
+
+---
+
+## Step 7 — Documentation (Docs role)
+
+Invoke the `docs` subagent via the Task tool when a public API, public module,
+or user-visible behavior changed.
+
+Update: README (if applicable), OpenAPI spec (if applicable), CHANGELOG
+(always when implementation changed), ADR (if an architectural decision was
+made).
+
+If `graphify-out/` is in use, run `graphify update .` (AST-only).
+
+---
+
+## Completion
+
+The iterative workflow is complete only when: all tests pass, the council
+approves the spec and the diff, no CRITICAL findings remain, and documentation
+and the knowledge graph reflect the implemented behavior.

package/presets/cursor/commands/cc/openspec.md

@@ -0,0 +1,159 @@
+---
+description: >-
+  [cc: alias] Run OpenSpec backlog delivery — validate BACKLOG.md, plan TaskCards,
+  orchestrate agents by phase, review gate, and update backlog state.
+---
+
+# OpenSpec Backlog Workflow
+
+Scope: $ARGUMENTS
+
+Orchestrate FIFO delivery from `BACKLOG.md`. CodeConductor owns planning; agents execute one TaskCard per phase with the installed preset model for each role.
+
+---
+
+---
+
+## Step 0 — CCEP Bootstrap
+
+Command: `openspec` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command openspec "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command openspec "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile openspec --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command openspec --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 — Validate (mandatory gate)
+
+Run:
+
+```bash
+npx cc-codeconductor openspec validate
+```
+
+If validation fails:
+
+1. List all errors and recommendations from the CLI output.
+2. Show the canonical BACKLOG.md structure (## Global, ## Items, ### BC-001 | Title, Priority, Status, Type, Depends on, Description, Scope, Acceptance).
+3. **STOP.** Do not scan, plan, or execute until the user fixes BACKLOG.md.
+
+---
+
+## Step 2 — Scan
+
+Run:
+
+```bash
+npx cc-codeconductor openspec scan
+```
+
+Report: new items, modified items, closed/archived items, and whether the file changed.
+
+---
+
+## Step 3 — Select item
+
+If `$ARGUMENTS` contains a `BC-xxx` ID, use that item. Otherwise run:
+
+```bash
+npx cc-codeconductor openspec status
+```
+
+Pick the next `READY` item with satisfied dependencies (FIFO by priority). Skip items in `DONE` or `Archive`.
+
+**STOP if no eligible item.** Report backlog status and wait for the user.
+
+---
+
+## Step 4 — Plan
+
+Run:
+
+```bash
+npx cc-codeconductor openspec plan <BC-id>
+```
+
+Show:
+
+- Generated TaskCards (discover → design → test → implement → review when TDD required)
+- Path to `openspec/changes/<slug>/` (proposal, design, tasks, specs)
+
+Update BACKLOG item status to `PLANNED` (CLI does this automatically).
+
+---
+
+## Step 5 — Model matrix and execute loop
+
+Before executing phases, show resolved models:
+
+```bash
+npx cc-codeconductor scorecard models
+```
+
+For each pending TaskCard, run:
+
+```bash
+npx cc-codeconductor openspec next
+```
+
+Invoke the agent named on the card with **isolated** context (`/clear` between phases unless continuation is required):
+
+| Phase | Agent | Role |
+|-------|-------|------|
+| discover | repo-explorer | Map repo and impact |
+| design | architect | Technical plan |
+| test | tester | TDD tests (before implement if TDD required) |
+| implement | implementer | Minimal diff in worktree |
+| review | reviewer | Acceptance + scope gate |
+
+Use the model configured in the installed preset for each agent role.
+
+After each phase:
+
+- Mark progress in deliverable summary.
+- Set TaskCard status to `done` in `.codeconductor/openspec-state.json` when phase completes.
+
+Implementer: create a Git worktree before editing (`git worktree add ../<branch>-session <branch>`).
+
+---
+
+## Step 6 — Review gate
+
+Run regression when BACKLOG Global `Review required: yes`:
+
+```bash
+npx cc-codeconductor scorecard regression
+```
+
+The `reviewer` agent must verify:
+
+- All acceptance criteria from BACKLOG.md
+- Tests pass
+- Scope matches the backlog item
+- No architectural violations
+
+If **rejected**: set item status `IN_PROGRESS`, record findings in state, **STOP** and report to user.
+
+If **approved**: proceed to Step 6.
+
+---
+
+## Step 7 — Scorecard and update backlog
+
+1. `npx cc-codeconductor scorecard create --task <BC-id> --from-diff`
+2. Complete criteria; `scorecard record` with verdict and optional cost/tokens
+3. Set item `Progress: 100%`, `Status: DONE` if PASS
+4. Move item to `## Archive` in BACKLOG.md if DONE
+5. Run `npx cc-codeconductor openspec scan`
+
+Report completion: Task Cards executed, scorecard verdict, change folder path, files changed.
+
+---
+
+## Skill
+
+Apply `.claude/skills/openspec/SKILL.md` for backlog format rules and state transitions.