cc-codeconductor 1.1.0 → 1.2.0

package/presets/codex/skills/cc-api-contract/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: cc-api-contract
+description: compatibility constraints, contract tests, documentation, and review.
+---
+
+# api-contract
+
+Invoke as `$cc-api-contract`. The user request follows the skill mention.
+
+# API Contract Workflow
+
+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 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/codex/skills/cc-backlog/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: cc-backlog
+description: validate with openspec, and plan OpenSpec change folders for /cc-openspec.
+---
+
+# backlog
+
+Invoke as `$cc-backlog`. The user request follows the skill mention.
+
+# Backlog Authoring Workflow
+
+Objectives: $ARGUMENTS
+
+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 "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command backlog "$ARGUMENTS" --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 `$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 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/codex/skills/cc-clarify/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: cc-clarify
+description: CodeConductor clarify workflow
+---
+
+# 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,92 @@
+---
+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.

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

@@ -0,0 +1,88 @@
+---
+name: cc-db-migration
+description: 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)
+
+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/codex/skills/cc-explore/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: cc-explore
+description: CodeConductor explore workflow
+---
+
+# 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,154 @@
+---
+name: cc-feature
+description: 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`.
+
+---
+
+
+## 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.