cc-codeconductor 1.0.0 → 1.1.0

package/presets/claude/commands/cc/backlog.md

@@ -0,0 +1,104 @@
+---
+description: >-
+  [cc: alias] Author BACKLOG.md — wayfinding, grilling, create or append items,
+  validate with openspec, and plan OpenSpec change folders for /cc:openspec.
+---
+
+# 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 role)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
+`graphify path` / `graphify explain` when needed). Then adopt the **Repo
+Explorer** role. 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 role)
+
+Adopt the **Task Coach** role. 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 role)
+
+Apply skill `backlog`.
+
+- If `BACKLOG.md` is absent, create it from the canonical template. 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/claude/commands/cc/explore.md

@@ -27,7 +27,7 @@ If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"`. Invoke `
 
 ## 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.
+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.
 
 ---
 

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

@@ -96,6 +96,21 @@ Update BACKLOG item status to `PLANNED` (CLI does this automatically).
 
 ---
 
+## Drive card status (CLI)
+
+Do not edit `.codeconductor/openspec-state.json` by hand.
+
+```bash
+npx cc-codeconductor openspec start <cardId>
+npx cc-codeconductor openspec done <cardId>
+npx cc-codeconductor openspec block <cardId> --reason "waiting on design"
+npx cc-codeconductor openspec archive <itemId>
+```
+
+`start` moves the card `pending → doing` and the item `PLANNED → IN_PROGRESS`. `done` marks the card complete, updates Progress, and moves the item to `REVIEW` when every card is done and review is required. `archive` requires all cards done (and review evidence when Global review is required) and moves `openspec/changes/<slug>` to `archive/`.
+
+---
+
 ## Step 4 — Model matrix and execute loop
 
 Before executing phases, show resolved models:
@@ -125,7 +140,7 @@ 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.
+- Run `npx cc-codeconductor openspec done <cardId>` when the phase completes. Do not edit openspec-state.json by hand.
 
 Implementer: create a Git worktree before editing (`git worktree add ../<branch>-session <branch>`).
 

package/presets/claude/commands/cc/security.md

@@ -0,0 +1,179 @@
+---
+description: >-
+  [cc: alias] Run the authorized defensive security workflow — domain
+  security-* skills, authorization gate, risk-based routing, hardening, and review.
+---
+
+# Defensive Security Workflow
+
+Security objective: $ARGUMENTS
+
+Provide the following information in $ARGUMENTS:
+
+- What must be reviewed or hardened, and why
+- Domain: a `security-*` skill id (recon, vuln-assessment, web, cloud, IR,
+  hunting, GRC, …) or `web-app` / `api` / `cloud-config` /
+  `dependency-supply-chain` / `secrets`
+- Authorization: who authorized this work on this target, and the scope boundary
+- Risk classification (`low`, `medium`, or `high`), if known
+- Scope: which files, modules, repos, or environments are in and out of bounds
+
+---
+
+## Scope and authorization
+
+This workflow performs **authorized defensive security work only**: threat
+modeling, hardening, secure configuration, dependency and supply-chain review,
+secret hygiene, and detection coverage.
+
+Refuse outright and offer the defensive equivalent instead (threat model,
+hardening, detection coverage, dependency audit):
+
+- Exploit or proof-of-concept development
+- Malware authoring, or malware analysis intended for reuse
+- Reverse engineering aimed at bypassing a control
+- Red-team playbooks
+- Any unauthorized-access procedure
+
+Scope is limited to the repository under analysis. Do not scan, probe, or
+perform reconnaissance against third-party hosts.
+
+Do not proceed without an authorization statement. Do not produce exploit
+payloads, malware, or attack procedures.
+
+---
+
+## Step 0 — CCEP Bootstrap
+
+Command: `security` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command security "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command security "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile security --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command security --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. Load the matching `security-*` skill
+for the named domain (see `.claude/skills/security-*/SKILL.md`). Keep the OWASP
+`security` skill for application-security reviews.
+
+---
+
+## Step 2 — Task Card validation (task-coach)
+
+Invoke `task-coach` with the security objective above.
+
+task-coach must produce a Task Card that includes:
+
+- Objective: what must be reviewed or hardened, in one sentence
+- Domain: which `security-*` skill applies, or `web-app` / `api` /
+  `cloud-config` / `dependency-supply-chain` / `secrets`
+- Authorization: who authorized this work on this target, and the scope boundary
+- Risk classification: `low`, `medium`, or `high`
+- Scope: which files or modules are likely affected
+
+If authorization is absent, unclear, or names a system the requester does not
+own or operate, **STOP and refuse. Do not route the task.**
+
+Redact secrets, tokens, and credentials from any evidence before it enters the
+Task Card. Summarize logs; 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 weakness is isolated, not exploitable in the current
+configuration, and no authentication, secret, or dependency boundary is
+involved.
+
+Route: `task-coach` → `tester` → `implementer`
+
+Proceed directly to Step 4 (tests), then Step 5a.
+
+### Medium or high-risk route
+
+Applies when: the work touches authentication, authorization, secrets,
+cryptography, trust-boundary input validation, or a dependency upgrade.
+
+Route: `task-coach` → `architect` → `tester` → `implementer` → `reviewer`
+
+Invoke `architect` before implementation. architect must:
+
+- Identify the weakness and the affected trust boundary
+- Define the hardening approach and affected files
+- Flag any regression risk to adjacent components
+- Produce a Technical Plan
+
+On **high** risk, also invoke `security-reviewer` before Reviewer.
+
+**STOP here if high-risk. Show the Technical Plan and wait for human approval
+before continuing.**
+
+---
+
+## Step 4 — Tests (tester)
+
+Invoke `tester` for all risk levels.
+
+tester must:
+
+1. Write a regression test that proves the weakness exists and confirm it fails
+   before any change (RED)
+2. Verify that existing tests still pass
+3. Produce a Coverage Summary: test added, case covered
+
+---
+
+## Step 5a — Implementation, low-risk (implementer)
+
+Invoke `implementer` with the Task Card.
+Implementer creates a Git Worktree before touching any file; all edits happen inside it.
+
+implementer must:
+
+1. Apply the minimal hardening change — no unrelated changes
+2. Run the suite and make the RED regression test pass
+3. Produce an Implementation Summary: weakness, change applied, files changed
+
+---
+
+## Step 5b — Implementation, medium/high-risk (implementer)
+
+Invoke `implementer` with the approved Technical Plan and the Task Card.
+Implementer creates a Git Worktree before touching any file; all edits happen inside it.
+
+implementer must follow the plan exactly. Any deviation requires a new Technical
+Plan approval. After implementation, run the full test suite. No exploit code.
+
+---
+
+## Step 6 — Review (Reviewer role) — medium/high-risk only
+
+Invoke `reviewer` with the diff and Task Card. The Reviewer must apply the OWASP
+rules in the `security` skill.
+
+reviewer produces a Review Report with CRITICAL / WARNING / SUGGESTION findings.
+If any CRITICAL findings exist, **STOP**. Do not close the task until they are
+resolved.
+
+---
+
+## Completion
+
+Report: Task Card, Implementation Summary, regression test added, Review Report
+(if applicable). The task is complete only when: the regression test passes, the
+full suite passes, and no CRITICAL review findings remain.

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

@@ -1,6 +1,6 @@
-# Pre-commit Gate: Typecheck and Test
+# Pre-commit Gate: Typecheck, Lint, 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.
+Este gate instala un hook `pre-commit` que ejecuta `bun run typecheck`, `bun run lint` y `bun run test` antes de permitir commits en el repositorio. Si cualquiera de estos comandos falla, el commit es bloqueado.
 
 ## Cuándo usar
 
@@ -63,6 +63,7 @@ mkdir -p "$GIT_DIR/hooks"
 cat > "$HOOK_PATH" << 'HOOK_EOF'
 #!/bin/bash
 bun run typecheck || exit 1
+bun run lint || exit 1
 bun run test || exit 1
 HOOK_EOF
 
@@ -78,7 +79,7 @@ echo "Pre-commit hook installed successfully."
 - **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`.
+- **Solo Bun**: El hook ejecuta `bun run typecheck`, `bun run lint` y `bun run test`. Asegúrate de que estos scripts están definidos en `package.json`.
 
 ## Verificación
 
@@ -121,7 +122,7 @@ 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`:
+Verifica que `bun run typecheck`, `bun run lint` y `bun run test` existen en `package.json`:
 
     cat package.json | grep -A 5 '"scripts"'
 

package/presets/claude/skills/backlog/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: backlog
+description: >
+  Author BACKLOG.md and OpenSpec change folders for CodeConductor.
+  Trigger: /cc-backlog, /cc:backlog, creating or appending backlog items,
+  writing BACKLOG.md, or preparing work for /cc-openspec.
+---
+
+# Backlog authoring
+
+Use this skill to **create or append** `BACKLOG.md` and generate OpenSpec
+change docs. Delivery of an existing item is `/cc-openspec` (skill `openspec`).
+
+## BACKLOG.md contract
+
+Canonical template: `presets/templates/BACKLOG.md` (or the installed copy).
+Required sections:
+
+- `## Global` — Product, Strategy, Policy, Review required, TDD required
+- `## Items` — active entries
+- `## Archive` — completed entries (never re-execute; never rewrite)
+
+Each item: `### BC-001 | Short title` with Priority (P0–P3), Status, Type,
+Depends on, Description, Scope, Out of scope, Acceptance (measurable checklist).
+
+Status after grilling: `READY`. `openspec plan` then moves the item to `PLANNED`.
+
+## Create vs append
+
+- **No `BACKLOG.md`:** create it from the template. Set Global `Product` from
+  `package.json` `name` when present.
+- **File exists:** append new `### BC-xxx` blocks under `## Items`. Do not
+  rewrite `## Global` or `## Archive`.
+
+Next ID = max numeric suffix across Items and Archive, plus one, zero-padded
+to three digits (`BC-013` after `BC-012`).
+
+## Wayfinding (before Scope)
+
+If `graphify-out/graph.json` exists, run `graphify query "<objectives>"` (and
+`graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`.
+Scope must name real files or modules. Do not write `BACKLOG.md` in this step.
+
+## Grilling (before write)
+
+Invoke `task-coach`. One grilling question per assumption. Reject vague
+acceptance ("improve UX", "fix bugs"). Criteria must be measurable (same rules
+as `openspec validate` / `VAGUE_ACCEPTANCE`).
+
+Unresolved questions go in `questionsForUser`. Run `ccep evaluate --command
+backlog`. If `stop` is true, **STOP** and wait for the human.
+
+Do not write items until the gate passes.
+
+## Validate loop
+
+After writing:
+
+```bash
+npx cc-codeconductor openspec validate
+```
+
+Local CodeConductor dogfood: `bun run dev openspec validate`.
+
+If invalid: list errors and recommendations, show the canonical structure,
+fix the file, re-validate. Do not plan until valid.
+
+## Plan new items only
+
+For each **new** `BC-xxx` this run:
+
+```bash
+npx cc-codeconductor openspec plan BC-xxx
+```
+
+That writes `openspec/changes/<slug>/` (`proposal.md`, `design.md`, `tasks.md`,
+`specs/`). Then tell the user to run `/cc-openspec` (optionally with the ID).
+
+## Local artifacts — do not version
+
+In consumer projects these paths are gitignored (see `init`):
+
+- `BACKLOG.md`
+- `openspec/`
+- `.codeconductor/openspec-state.json`
+
+Do **not** `git add` them. Do not edit `openspec-state.json` by hand.
+
+## Delivery
+
+Format and state machine: skill `openspec`. Authoring is this skill.

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

@@ -2,11 +2,15 @@
 name: openspec
 description:
   OpenSpec backlog format, state machine, and delivery workflow for CodeConductor.
-  Use when running /cc:openspec or editing BACKLOG.md.
+  Use when running /cc:openspec or delivering a BACKLOG.md item.
+  To create or append BACKLOG.md, use /cc:backlog (skill backlog).
 ---
 
 # OpenSpec / BACKLOG Skill
 
+Authoring (create or append `BACKLOG.md`, then `openspec validate` / `plan`) is
+`/cc:backlog` and skill `backlog`. This skill is **delivery**.
+
 ## BACKLOG.md contract
 
 `BACKLOG.md` at repo root is the operational queue. Required sections: