cc-codeconductor 1.0.0 → 1.2.0

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

@@ -53,6 +53,20 @@ Command: `openspec` (fixed for this workflow — do not infer from user text)
 
 ---
 
+## 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:openspec`
+
+Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
+
+---
+
+
 ## Step 1 — Scan
 
 Run:
@@ -96,6 +110,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 +154,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/review.md

@@ -197,3 +197,6 @@ npx cc-codeconductor scorecard regression
 Example: if the combined verdict is `blocked` (either axis found CRITICAL), record with `--verdict REJECT`.
 
 Map each review outcome for trend tracking and decision audit.
+
+Skill: `evaluation`. "Looks fine" is not a verdict. Run
+`scorecard create --from-diff` and record PASS|REVISE|REJECT.

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

@@ -26,6 +26,8 @@ Command: `scorecard` (fixed for this workflow — do not infer from user text)
 
 Use `$ARGUMENTS` as task id (e.g. `BC-001`) or read active item from `npx cc-codeconductor openspec status`.
 
+If a change folder exists, run `npx cc-codeconductor openspec analyze --output json` first. `--from-diff` overlays FR/SC coverage onto `acceptance` and TDD evidence onto `tests`.
+
 ---
 
 ## Step 2 — Create scorecard with auto-signals

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/commands/cc/spec-mutation.md

@@ -0,0 +1,190 @@
+---
+description: >-
+  [cc: alias] Spec-locked TDD with a mutation-testing gate — refine the intent
+  into an immutable Gherkin contract (SHA-256 frozen), implement under the
+  three laws of TDD, pass a judge audit, and merge only if every mutant dies.
+---
+
+# Spec-Mutation — Hard Spec → TDD → Judge → Mutation Gate
+
+Scope: $ARGUMENTS
+
+Describe what behavior you want to implement. Include:
+
+- The function, method, or feature to implement
+- The expected behavior (inputs, outputs, invariants, edge cases)
+- The allowed file scope (production files that may change)
+- The test command for the affected suite (e.g. `pytest tests/test_billing.py`)
+
+---
+
+## Step 0 — CCEP Bootstrap
+
+Command: `spec-mutation` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command spec-mutation "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command spec-mutation "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile spec-mutation --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command spec-mutation --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:spec-mutation`
+
+Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
+
+---
+
+## Contract
+
+The Gherkin specification is the **immutable contract** of the system. No code
+merges unless it survives intentional source mutations. The loop is closed:
+
+```
+[Human + spec_partner] ──> [gherkin_author] ──> [Test Freeze: SHA-256]
+                                                       │
+┌──────────────────────────────────────────────────────┘
+▼
+[tdd_craftsman] <───────────────┐ (surviving mutant)
+   (Red-Green-Refactor)         │
+        │                       │
+        ▼                       │
+     [judge] ───────────> [mutation_testing] ───> [Safe Merge]
+```
+
+Role mapping onto Conductor Agents (AGENTS.md):
+
+| Workflow role      | Conductor Agent   | Deliverable                                |
+| ------------------ | ----------------- | ------------------------------------------ |
+| `craftsman_lead`   | `orchestrator`    | Routed Task Cards, per-stage scorecards    |
+| `spec_partner`     | `task-coach`      | Spec draft with invariants and boundaries  |
+| `gherkin_author`   | `contract-builder`| Strict `.feature` file (Given/When/Then)   |
+| `tdd_craftsman`    | `tester` → `implementer` | Failing test, then minimal production code |
+| `judge`            | `reviewer`        | Binary verdict (PASS/REJECT) with scoring  |
+| `mutation_testing` | `tester` (runner) | Killed/survived mutant report              |
+
+## Stage 1 — Interactive refinement (`spec_partner` / task-coach)
+
+Do not jump to implementation. Apply Socratic questioning to the initial intent:
+
+- Preconditions, postconditions, and edge cases.
+- Invariant matrix: what must always be true.
+- Scope boundaries: explicit `Scope / Files` and `Scope / Out` for the Task Card.
+
+Stop gate: human confirms the draft before formalization.
+
+## Stage 2 — Hard Spec formalization (`gherkin_author` / contract-builder)
+
+Formalize the agreed draft into `specs/<task>.feature` using strict Gherkin:
+
+- No vague language ("must respond fast" is forbidden — use measurable Then steps).
+- Every scenario declares preconditions (`Given`), actions (`When`), and
+  observable states (`Then`).
+- Once the human approves the `.feature`, freeze it:
+
+```bash
+shasum -a 256 specs/<task>.feature tests/ > .codeconductor/tasks/<task_id>.lock
+```
+
+From this point `specs/` and `tests/` are **read-only** for implementation
+agents. Before every later gate, recompute the hash; any single-byte difference
+aborts the pipeline with scorecard 0 (Specification Gaming).
+
+## Stage 3 — TDD under the three laws (`tdd_craftsman`)
+
+Delegates to the `/cc:tdd-cycle` state machine (`tddCycleStateMachine` in
+`domain/loop`). Evidence must be captured with `captureTddSuiteEvidence` — do
+not hand-edit JSON under `.codeconductor/evidence/`.
+
+1. **Law 1 (RED):** no production code except to make a failing test pass. A
+   compile error from a missing interface counts as a failure.
+2. **Law 2:** write exactly one failing assertion or scenario at a time.
+3. **Law 3 (GREEN):** write only the minimal production code to pass. No
+   speculative code, no preventive heuristics, stdlib-first.
+
+Hard rule: any write attempt against `specs/` or `tests/` during GREEN/REFACTOR
+is a harness violation — stop execution and report.
+
+## Stage 4 — Judge audit (`judge` / reviewer)
+
+Deterministic gates before spending compute on mutation:
+
+- Clean compile / diagnostics exit code 0.
+- Traceability: every Gherkin step maps to an implemented test step.
+- Scope Gaming audit: `git diff --name-only` must match the Task Card
+  `Scope / Files` exactly. Relaxed types, weakened assertions, or out-of-scope
+  edits → REJECT with findings.
+
+Verdict is binary: PASS continues to the mutation gate; REJECT returns to the
+`implement` phase with the findings attached.
+
+## Stage 5 — Mutation gate (`mutation_testing`)
+
+Run the deterministic AST mutator shipped with this preset:
+
+```bash
+python3 presets/shared/mutation_runner.py \
+  --target <production_file.py> \
+  --test-command "<test command>" \
+  --spec-folder specs
+```
+
+The runner applies deterministic operator mutations (`>` → `<=`, `==` → `!=`,
+`is` → `is not`, …) one at a time, re-runs the suite per mutant, and restores
+the original source unconditionally (`finally` rollback).
+
+- **Mutant killed (tests fail):** the suite detects the corruption. Continue.
+- **Mutant survived (tests pass):** the tests are blind to this branch. The
+  runner writes `specs/handover.md` + appends to
+  `specs/implementation-summary.md` and exits with code **2**.
+
+Non-Python stacks: substitute Stryker (JS/TS), PITest (JVM), or Mutmut
+(Python full-suite) with the same contract — 100% kill rate or hands-off.
+
+### Hands-off protocol (exit code 2)
+
+1. Do NOT modify production code to "fix" a surviving mutant.
+2. Route back to `tdd_craftsman` with `specs/handover.md` as input: write the
+   missing failing test (Law 1 & 2) that asserts the mutated branch.
+3. Re-run stages 3–5.
+
+### Circuit breaker (max 3 loops)
+
+The orchestrator keeps a persistent counter per Task Card. If the
+`tdd_craftsman ↔ mutation_testing` loop does not reach a 100% kill rate after
+**3 iterations**:
+
+- Cancel active subagents (stop token/context spend).
+- `git checkout -- <scope>` rollback to the last clean state.
+- Scorecard: `STATUS = BLOCKED`; escalate to a human operator. The branch stays
+  frozen until human arbitration.
+
+## Guardrails (harness-enforced, not prompt-enforced)
+
+- **Test Freezing:** SHA-256 of `specs/` + `tests/` stored in
+  `.codeconductor/tasks/<task_id>.lock`; hash mismatch aborts the pipeline.
+- **Scope Guardian:** `fs_write`/`fs_patch` paths are validated against the Task
+  Card `Scope / Files`; path escapes (`../`) and critical files (`**/.env*`,
+  `**/credentials*`, infrastructure roots) are denied per `policy.yml`.
+- **RBAC per role:** `gherkin_author` writes only `specs/`; `tdd_craftsman`
+  reads specs/tests and writes only scoped `src/`; `judge` and
+  `mutation_testing` are read-only except the runner's rolled-back patch.
+- **Worktree isolation:** run the whole flow in a dedicated `git worktree`;
+  protected branches (`main`, `master`, `develop`) are never touched.
+
+## Completion criteria
+
+- [ ] `.feature` approved and frozen (SHA-256 lock file exists and matches).
+- [ ] RED → GREEN → REFACTOR evidence captured per phase.
+- [ ] Judge verdict PASS (compile clean, traceability complete, scope clean).
+- [ ] Mutation runner exits 0 with `total_mutants_killed == total_points`.
+- [ ] Scorecard records the kill rate and iteration count (≤ 3).

package/presets/claude/commands/cc/tdd-cycle.md

@@ -31,6 +31,20 @@ Command: `tdd-cycle` (fixed for this workflow — do not infer from user text)
 
 ---
 
+## 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:tdd-cycle`
+
+Local development: `bun run dev <same argv>`. Published package: `npx cc-codeconductor`.
+
+---
+
+
 ## Before you begin — mandatory pre-check
 
 This command enforces strict TDD discipline. The three phases are sequential and
@@ -274,3 +288,6 @@ The TDD cycle is complete when:
 
 If the behavior requires additional test cases, start a new `/tdd-cycle` with
 the next scenario. One cycle = one behavior.
+
+Skill: `testing-tdd`. Evidence from the verification runner only — handmade TDD
+JSON is rejected. Optional gate: `bun run dev scorecard suite-run --suite workflow-gates`.

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/settings.json

@@ -151,15 +151,7 @@
         "hooks": [
           {
             "type": "command",
-            "command": "if echo \"$CLAUDE_TOOL_INPUT_FILE_PATH\" | grep -qE '\\.(ts|tsx|js|jsx|mjs|cjs|json|jsonc|md|mdx|css|scss|html|astro|yaml|yml)$'; then npx --no-install prettier --write \"$CLAUDE_TOOL_INPUT_FILE_PATH\" 2>/dev/null || true; fi"
-          },
-          {
-            "type": "command",
-            "command": "if echo \"$CLAUDE_TOOL_INPUT_FILE_PATH\" | grep -qE '\\.(ts|tsx|js|jsx|mjs|cjs)$'; then npx --no-install eslint --fix \"$CLAUDE_TOOL_INPUT_FILE_PATH\" 2>/dev/null || true; fi"
-          },
-          {
-            "type": "command",
-            "command": "if echo \"$CLAUDE_TOOL_INPUT_FILE_PATH\" | grep -qE '\\.py$'; then ruff format \"$CLAUDE_TOOL_INPUT_FILE_PATH\" 2>/dev/null && ruff check --fix \"$CLAUDE_TOOL_INPUT_FILE_PATH\" 2>/dev/null || true; fi"
+            "command": "node .claude/hooks/invoke-hook.cjs post-tool"
           }
         ]
       }
@@ -170,7 +162,17 @@
         "hooks": [
           {
             "type": "command",
-            "command": "if echo \"$CLAUDE_TOOL_INPUT_COMMAND\" | grep -qE '(\\.env|secrets/|id_rsa|\\.pem|\\.key)\\b' && echo \"$CLAUDE_TOOL_INPUT_COMMAND\" | grep -qE '(cat|less|more|head|tail|cp |mv |scp )'; then echo 'Bloqueado: intento de leer archivos sensibles' >&2; exit 2; elif echo \"$CLAUDE_TOOL_INPUT_COMMAND\" | grep -qE '^\\s*git\\s+(push|reset\\s+--hard)' || echo \"$CLAUDE_TOOL_INPUT_COMMAND\" | grep -qE '^\\s*git\\s+clean\\s+(-[a-z]*f[a-z]*|--force)' || echo \"$CLAUDE_TOOL_INPUT_COMMAND\" | grep -qE '^\\s*git\\s+branch\\s+(-D|--delete\\s+--force)' || echo \"$CLAUDE_TOOL_INPUT_COMMAND\" | grep -qE '^\\s*git\\s+checkout\\s+(-f|--force|--discard-changes|--theirs|--ours|-\\s|-$)' || echo \"$CLAUDE_TOOL_INPUT_COMMAND\" | grep -qE '^\\s*git\\s+restore\\s+(-f|--force|--discard-changes|--theirs|--ours)'; then echo \"Bloqueado: El agente no tiene autoridad sobre este comando.\" >&2; exit 2; fi"
+            "command": "node .claude/hooks/invoke-hook.cjs pre-tool"
+          }
+        ]
+      }
+    ],
+    "SessionStart": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node .claude/hooks/invoke-hook.cjs session-start"
           }
         ]
       }
@@ -180,7 +182,7 @@
         "hooks": [
           {
             "type": "command",
-            "command": "echo \"[subagent fin] $(date -Iseconds)\" >> ~/.claude/subagent.log"
+            "command": "node -e \"var fs=require('fs');var os=require('os');var p=require('path');var dir=p.join(os.homedir(),'.claude');fs.mkdirSync(dir,{recursive:true});fs.appendFileSync(p.join(dir,'subagent.log'),'[subagent fin] '+new Date().toISOString()+'\\n');\""
           }
         ]
       }

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

@@ -0,0 +1,61 @@
+---
+name: backlog
+description: >
+  Guides agents through authoring BACKLOG.md and OpenSpec change folders.
+  Use when running /cc-backlog or /cc:backlog, creating or appending backlog
+  items, or preparing work for /cc-openspec. Delivery is skill openspec.
+---
+
+# Backlog authoring
+
+## Overview
+
+Create or append `BACKLOG.md`, then `openspec validate` / `plan`. Do not deliver
+the item here.
+
+## When to Use
+
+- `/cc-backlog`, first backlog in a repo, or appending `### BC-xxx` items
+
+**NOT** for executing an item (`openspec`) or for scorecards (`evaluation`).
+
+## Process
+
+1. If `graphify-out/graph.json` exists, `graphify query "<objectives>"`. Then
+   `repo-explorer`. Scope names real files.
+2. Invoke `task-coach`. One grilling question per assumption. Reject vague
+   acceptance ("improve UX"). At most 3 `[NEEDS CLARIFICATION]`.
+3. `ccep evaluate --command backlog`. If `stop`, wait for the human.
+4. Create `BACKLOG.md` from `presets/templates/BACKLOG.md` or append under
+   `## Items`. Do not rewrite `## Global` or `## Archive`.
+5. Next ID = max numeric suffix in Items + Archive + 1, zero-padded (`BC-013`).
+6. `bun run dev openspec validate` (or `npx cc-codeconductor`). Fix until valid.
+7. `openspec plan BC-xxx` for each **new** item this run. Then tell the user
+   to run `/cc-openspec`.
+
+Required sections: `## Global`, `## Items`, `## Archive`. Each item:
+`### BC-001 | Title` with Priority, Status (`READY` after grilling), Type,
+Depends on, Description, Scope, Out of scope, Acceptance.
+
+Local artifacts (`BACKLOG.md`, `openspec/`, `.codeconductor/openspec-state.json`)
+are gitignored in consumer projects. Do not `git add` them.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+| --- | --- |
+| This fix is small; skip the Task Card | Every item needs measurable acceptance. |
+| I'll validate later | Do not plan until `openspec validate` passes. |
+| Archive can be rewritten | Archive is history. Never rewrite or re-execute. |
+
+## Red Flags
+
+- Acceptance that cannot fail a check
+- Editing `openspec-state.json` by hand
+- Planning an invalid backlog
+
+## Verification
+
+- [ ] `openspec validate` exit 0
+- [ ] New items have `FR`/`SC`-ready measurable acceptance
+- [ ] User pointed at `/cc-openspec` for delivery