cc-codeconductor 1.1.0 → 1.2.0

package/presets/gemini/commands/cc/api-contract.toml

@@ -0,0 +1,82 @@
+description = "compatibility constraints, contract tests, documentation, and review."
+
+prompt = """
+# API Contract Workflow
+
+API contract request: {{args}}
+
+## 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 "{{args}}" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command api-contract "{{args}}" --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 `{{args}}` to planners.
+
+---
+
+## Step 0b — OpenSpec quality gates
+
+If `openspec status` reports an active change folder:
+
+1. Run: `npx cc-codeconductor openspec validate --output json`
+2. Run: `npx cc-codeconductor openspec analyze --output json`
+3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
+4. Next command spelling on this runner: `/cc:api-contract`
+
+Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
+
+---
+
+
+## Step 1 — Task Card validation (Task Coach role)
+
+Invoke the `task-coach` subagent via the Task tool.
+
+The Task Card must classify the task as high risk by default and include the
+affected public interface, request/response examples, compatibility notes,
+versioning impact, consumer impact, contract tests, and docs acceptance
+criteria.
+
+**STOP here. Show the completed Task Card and wait for human confirmation.**
+
+---
+
+## Step 2 — Technical Plan (Architect role)
+
+Invoke the `architect` subagent via the Task tool.
+
+Define the API contract, validation strategy, compatibility behavior, docs or
+OpenAPI changes, and reviewer blocking conditions.
+
+**STOP here. Show the Technical Plan and wait for explicit human approval.**
+
+---
+
+## Step 3 — Implementation (Implementer role)
+
+Invoke the `implementer` subagent via the Task tool.
+
+Apply the minimal diff, preserve compatible behavior unless explicitly approved
+as breaking, and update only the planned files.
+
+---
+
+## Step 4 — Contract Tests (Tester role)
+
+Invoke the `tester` subagent via the Task tool.
+
+Add or update tests for request shape, response shape, status/error behavior,
+and backward compatibility.
+
+---
+
+## Step 5 — Review (Reviewer role)
+
+Invoke the `reviewer` subagent via the Task tool.
+
+Block on missing contract tests, undocumented breaking changes, or docs/OpenAPI
+drift.
+"""

package/presets/gemini/commands/cc/ask.toml

@@ -0,0 +1,54 @@
+description = "[cc: alias] Recommend one CodeConductor slash command from a natural-language problem. Does not start that workflow."
+
+prompt = """
+# Ask — recommend a slash command
+
+Problem: {{args}}
+
+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 "{{args}}" --output json
+```
+
+or:
+
+```bash
+npx cc-codeconductor ask "{{args}}" --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:backlog` | create or append BACKLOG.md / objectives |
+| `/cc:openspec` | BACKLOG / BC-xxx delivery |
+
+If the CLI is unavailable, apply the same catalog and the same priority:
+backlog (author) vs openspec (deliver) → 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/gemini/commands/cc/backlog.toml

@@ -0,0 +1,103 @@
+description = "validate with openspec, and plan OpenSpec change folders for /cc-openspec."
+
+prompt = """
+# Backlog Authoring Workflow
+
+Objectives: {{args}}
+
+Create or append valid `BACKLOG.md` items and OpenSpec change docs. Do **not**
+deliver implementation — that is `/cc-openspec`.
+
+---
+
+## Step 0 — CCEP Bootstrap
+
+Command: `backlog` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command backlog "{{args}}" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command backlog "{{args}}" --output json`
+3. Run: `npx cc-codeconductor ccep profile backlog --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command backlog --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 `{{args}}` to planners.
+
+---
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "{{args}}"` (and
+`graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
+to map modules, conventions, and impact radius. Do not write `BACKLOG.md` in
+this step. Record a Repo Map so Scope names real files or modules.
+
+---
+
+## Step 2 — Relentless Grilling (task-coach)
+
+Invoke `task-coach`. Produce complete backlog item fields: title, type, risk,
+scope, description, out of scope, measurable acceptance criteria.
+
+Every assumption must survive one grilling question. Reject vague acceptance
+("improve UX", "fix bugs").
+
+If any field is missing or ambiguous, ask one clarifying question at a time.
+
+**STOP here.** Unresolved grilling questions populate `questionsForUser` in the
+CCEP-1 `planner-output`; `ccep evaluate --command backlog` halts until a human
+answers. Do not write `BACKLOG.md` until that confirmation.
+
+---
+
+## Step 3 — Write or append BACKLOG.md (docs)
+
+Apply skill `backlog`.
+
+- If `BACKLOG.md` is absent, create it from the canonical template
+  (`presets/templates/BACKLOG.md`). Set Global `Product` from `package.json`
+  `name` when present.
+- If it exists, append new `### BC-xxx` items under `## Items`. Do not rewrite
+  `## Global` or `## Archive`.
+- Next ID = max `BC-NNN` across Items and Archive, plus one.
+- New items: Status `READY`, Progress `0%`, measurable Acceptance checklist.
+
+Do **not** `git add` `BACKLOG.md` or `openspec/`.
+
+---
+
+## Step 4 — 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. Fix the file and re-run validate. **STOP** planning until valid.
+
+---
+
+## Step 5 — Plan new items
+
+For each **new** `BC-xxx` from this run:
+
+```bash
+npx cc-codeconductor openspec plan <BC-id>
+```
+
+Show TaskCards and `openspec/changes/<slug>/` (proposal, design, tasks, specs).
+
+---
+
+## Completion
+
+Report: item IDs added, validate result, change folder paths.
+
+Tell the user to run `/cc-openspec` (optionally `/cc-openspec BC-xxx`) to
+deliver. Do not start delivery in this workflow.
+
+Apply skill `backlog` for create/append rules. Apply skill `openspec` only for
+format and state-machine reference.
+"""

package/presets/gemini/commands/cc/clarify.toml

@@ -0,0 +1,31 @@
+description = "CodeConductor clarify workflow"
+
+prompt = """
+# Clarify Workflow
+
+Clarify request: {{args}}
+
+## 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 "{{args}}" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command clarify "{{args}}" --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 `{{args}}` 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/gemini/commands/cc/council.toml

@@ -0,0 +1,87 @@
+description = "Council-driven workflow with CCEP-1 bootstrap"
+
+prompt = """
+# Council-Driven Workflow
+
+Task request: {{args}}
+
+## 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 "{{args}}" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command council "{{args}}" --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 `{{args}}` to planners.
+
+---
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "{{args}}"` (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 run the Grilling protocol on each one (Think Before Coding).
+3. Draft a Task Card & Technical Plan (The Specification).
+
+**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 3 — Test Definition (TDD)
+
+Invoke `tester` with the approved Task Card & Technical Plan.
+
+tester must:
+1. Write failing tests based on the Acceptance Criteria defined in the Task Card.
+2. Confirm the tests fail as expected (Red state).
+
+**Goal-Driven Execution (Karpathy)**: Do not proceed until verifiable tests are written and fail for the correct reasons.
+
+---
+
+## Step 4 — Surgical Implementation
+
+Invoke `implementer` with the failing tests and the Technical Plan.
+
+implementer must:
+1. Write the minimal code required to pass the tests.
+2. Touch ONLY the files specified in the Technical Plan (Surgical Changes).
+3. NOT refactor adjacent code, change existing styles, or build speculative features.
+4. Run the tests. Loop `implementer` -> `tester` until all tests pass (Green state).
+
+---
+
+## Step 5 — Multi-Perspective Council Review
+
+Invoke the `council` skill on the generated diff to perform the final review phase.
+
+The council will evaluate the diff against the 6 axes (Architecture, Security, Product, Delivery, DataOps, Devil).
+
+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 4 with the feedback.
+
+If APPROVED (no CRITICAL findings):
+- Deliver the final Council Verdict and the diff summary.
+
+---
+
+## Completion
+
+Deliver the complete Council Verdict. The feature is only complete when tests pass and the council explicitly approves the implementation according to the specification.
+"""

package/presets/gemini/commands/cc/db-migration.toml

@@ -0,0 +1,83 @@
+description = "operational sequencing, tests, and review."
+
+prompt = """
+# Database Migration Workflow
+
+Migration request: {{args}}
+
+## 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 "{{args}}" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command db-migration "{{args}}" --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 `{{args}}` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
+## Step 0b — OpenSpec quality gates
+
+If `openspec status` reports an active change folder:
+
+1. Run: `npx cc-codeconductor openspec validate --output json`
+2. Run: `npx cc-codeconductor openspec analyze --output json`
+3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
+4. Next command spelling on this runner: `/cc:db-migration`
+
+Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
+
+---
+
+
+## Step 1 — Task Card validation (Task Coach role)
+
+Invoke the `task-coach` subagent via the Task tool.
+
+The Task Card must classify the task as high risk and include affected schema,
+model, and migration files; data backfill needs; deployment ordering;
+rollback/forward-fix strategy; lock risk; data risk; and verification commands.
+
+**STOP here. Show the completed Task Card and wait for human confirmation.**
+
+---
+
+## Step 2 — Migration Plan (Architect role)
+
+Invoke the `architect` subagent via the Task tool.
+
+Define the schema/data plan, operational sequencing, compatibility strategy,
+rollback/forward-fix notes, and test approach.
+
+**STOP here. Show the Technical Plan and wait for explicit human approval.**
+
+---
+
+## Step 3 — Migration Tests (Tester role)
+
+Invoke the `tester` subagent via the Task tool.
+
+Cover migration-sensitive behavior where the stack supports it, including
+existing-data edge cases and rollback/forward-fix notes when automated rollback
+tests are not practical.
+
+---
+
+## Step 4 — Implementation (Implementer role)
+
+Invoke the `implementer` subagent via the Task tool.
+
+Keep model and migration changes together, avoid unrelated refactors, and
+preserve the deployment order specified by architect.
+
+---
+
+## Step 5 — Review (Reviewer role)
+
+Invoke the `reviewer` subagent via the Task tool.
+
+Block on missing migration tests, missing data-risk notes, undocumented
+deployment sequencing, or model/migration drift.
+"""

package/presets/gemini/commands/cc/explore.toml

@@ -0,0 +1,35 @@
+description = "CodeConductor explore workflow"
+
+prompt = """
+# Explore Workflow
+
+Explore request: {{args}}
+
+## 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 "{{args}}" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command explore "{{args}}" --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 `{{args}}` to planners.
+
+---
+
+## Step 1 — Map (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "{{args}}"`. 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:backlog`, `/cc:openspec`, `/cc:triage`, …) with a one-sentence rationale. Do not start that workflow.
+
+---
+
+## Completion
+
+Report the Repo Map and the recommended next `/cc:` command.
+"""

package/presets/gemini/commands/cc/feature.toml

@@ -0,0 +1,153 @@
+description = "implementation, testing, review, and documentation."
+
+prompt = """
+# Feature Workflow
+
+Feature request: {{args}}
+
+---
+
+## 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 "{{args}}" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command feature "{{args}}" --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 `{{args}}` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
+## Step 0b — OpenSpec quality gates
+
+If `openspec status` reports an active change folder:
+
+1. Run: `npx cc-codeconductor openspec validate --output json`
+2. Run: `npx cc-codeconductor openspec analyze --output json`
+3. If analyze `stop` is true or any finding is CRITICAL, stop. Do not delegate to implementer.
+4. Next command spelling on this runner: `/cc:feature`
+
+Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
+
+Skills: `using-cc-skills`, `openspec`, `testing-tdd`, `evaluation`.
+Do not skip `openspec analyze` when a change folder is active.
+"I'll add tests later" is not allowed — tester before implementer.
+
+---
+
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "{{args}}"` (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.
+"""