cc-codeconductor 1.1.0 → 1.3.0

package/presets/codex/skills/cc-clarify/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: cc-clarify
+description: Re-explain the last deliverable in Task Card vocabulary when it did not land.
+---
+
+# clarify
+
+Invoke as `$cc-clarify`. The user request follows the skill mention.
+
+# 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/codex/skills/cc-council/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: cc-council
+description: Council-driven workflow with CCEP-1 bootstrap
+---
+
+# council
+
+Invoke as `$cc-council`. The user request follows the skill mention.
+
+# Council-Driven Workflow
+
+Task request: $ARGUMENTS
+
+## 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 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.
+
+## Next
+
+Approved: merge. Blocked: return the findings to `$cc-fix` or `$cc-feature`.

package/presets/codex/skills/cc-db-migration/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: cc-db-migration
+description: Run the database migration workflow for schema/data changes, operational sequencing, tests, and review.
+---
+
+# db-migration
+
+Invoke as `$cc-db-migration`. The user request follows the skill mention.
+
+# Database Migration Workflow
+
+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 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)
+
+Adopt the `task-coach` role as defined in `AGENTS.md`.
+
+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)
+
+Adopt the `architect` role as defined in `AGENTS.md`.
+
+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)
+
+Adopt the `tester` role as defined in `AGENTS.md`.
+
+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)
+
+Adopt the `implementer` role as defined in `AGENTS.md`.
+
+Keep model and migration changes together, avoid unrelated refactors, and
+preserve the deployment order specified by architect.
+
+---
+
+## Step 5 — Review (Reviewer role)
+
+Adopt the `reviewer` role as defined in `AGENTS.md`.
+
+Block on missing migration tests, missing data-risk notes, undocumented
+deployment sequencing, or model/migration drift.
+
+## Next
+
+Run `$cc-review` on the diff before merging.

package/presets/codex/skills/cc-explore/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: cc-explore
+description: Map the repository and recommend the next CodeConductor slash command. Read-only.
+---
+
+# explore
+
+Invoke as `$cc-explore`. The user request follows the skill mention.
+
+# 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-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/codex/skills/cc-feature/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: cc-feature
+description: Run the full feature workflow — task validation, technical design, implementation, testing, review, and documentation.
+---
+
+# feature
+
+Invoke as `$cc-feature`. The user request follows the skill mention.
+
+# 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 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 "$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)
+
+Adopt the `task-coach` role as defined in `AGENTS.md`.
+
+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)
+
+Adopt the `architect` role as defined in `AGENTS.md`.
+
+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)
+
+Adopt the `tester` role as defined in `AGENTS.md`.
+
+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)
+
+Adopt the `implementer` role as defined in `AGENTS.md`.
+
+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)
+
+Adopt the `reviewer` role as defined in `AGENTS.md`.
+
+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)
+
+Adopt the `docs` role as defined in `AGENTS.md`.
+
+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.
+
+## Next
+
+Run `$cc-review` on the diff before merging.

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

@@ -0,0 +1,172 @@
+---
+name: cc-fix
+description: Run the bug fix workflow — risk-based routing through task validation, implementation, testing, and optional review.
+---
+
+# fix
+
+Invoke as `$cc-fix`. The user request follows the skill mention.
+
+# 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 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-fix`
+
+Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
+
+---
+
+
+## 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)
+
+Adopt the `task-coach` role as defined in `AGENTS.md`.
+
+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)
+
+Adopt the `tester` role as defined in `AGENTS.md`. 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)
+
+Adopt the `implementer` role as defined in `AGENTS.md`. 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)
+
+Adopt the `implementer` role as defined in `AGENTS.md`. 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
+
+Adopt the `reviewer` role as defined in `AGENTS.md`. 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.
+
+Skills: `testing-tdd`, `evaluation`. Record `scorecard create --from-diff`.
+A small fix still needs a Task Card and a failing regression test first.
+
+## Next
+
+Run `$cc-review` on the diff before merging.

package/presets/codex/skills/cc-handoff/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: cc-handoff
+description: Compact the session into gitignored `.codeconductor/sessions/handoff.md` (redact secrets).
+---
+
+# handoff
+
+Invoke as `$cc-handoff`. The user request follows the skill mention.
+
+# 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.