cc-codeconductor 1.0.0 → 1.1.0

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

@@ -0,0 +1,105 @@
+---
+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)
+
+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/cursor/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/cursor/commands/cc/openspec.md

@@ -86,6 +86,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 5 — Model matrix and execute loop
 
 Before executing phases, show resolved models:
@@ -115,7 +130,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/cursor/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/cursor/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/cursor/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/cursor/skills/openspec/SKILL.md

@@ -2,13 +2,17 @@
 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).
 
 disable-model-invocation: true
 ---
 
 # 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:

package/presets/cursor/skills/security-ai-llm/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: security-ai-llm
+description: >
+  Harden LLM and agent integrations you operate: prompt injection, tool allowlists, secret leakage, and supply-chain of models. Defensive only.
+---
+
+# AI / LLM Security
+
+## Authorization
+
+Use this skill only with **explicit written authorization** for a named
+scope (systems, environments, and time window). If authorization is missing,
+expired, or the request is for someone else's systems, **stop**.
+
+This skill is **defensive and owner-authorized**. It does not authorize
+offensive cyber operations.
+
+## Do
+
+- Treat model output as untrusted; never exec it without a schema
+- Allowlist tools and paths; contain file writes
+- Keep secrets out of prompts and logs
+
+## Do not
+
+- Help jailbreak third-party products or steal model weights
+- Log raw user PII to prompt-debug stores
+
+- Do not produce exploit payloads, malware, or attack procedures.
+
+## How to Use
+
+Load this skill from `/cc-security` when the Task Card domain is `security-ai-llm`.
+Example prompts:
+
+- `Review our agent tool runner for path traversal and unbounded shell.`
+- `Add tests that a prompt cannot make the bot dump .env.`
+
+## Integration
+
+- Workflow: `/cc-security` (CCEP command `security`)
+- Existing OWASP application-security skill remains `security` (not this id)
+- High-risk changes still require `security-reviewer`

package/presets/cursor/skills/security-blue-team/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: security-blue-team
+description: >
+  Improve detections, hardening, and response for the estate you defend. Detection-as-code and control design, not offense.
+---
+
+# Blue Team Defense
+
+## Authorization
+
+Use this skill only with **explicit written authorization** for a named
+scope (systems, environments, and time window). If authorization is missing,
+expired, or the request is for someone else's systems, **stop**.
+
+This skill is **defensive and owner-authorized**. It does not authorize
+offensive cyber operations.
+
+## Do
+
+- Tune detections for true positives; document exceptions
+- Pair every new control with a test or canary
+- Share hunt hypotheses with IR, not with the public internet
+
+## Do not
+
+- Disable EDR or logging to 'reduce noise' without a ticket
+- Copy attacker malware into production 'for training'
+
+- Do not produce exploit payloads, malware, or attack procedures.
+
+## How to Use
+
+Load this skill from `/cc-security` when the Task Card domain is `security-blue-team`.
+Example prompts:
+
+- `We missed a token-replay. Propose a detection plus a unit test for the API gateway.`
+- `Harden CI: pin actions, require reviews on workflows that deploy.`
+
+## Integration
+
+- Workflow: `/cc-security` (CCEP command `security`)
+- Existing OWASP application-security skill remains `security` (not this id)
+- High-risk changes still require `security-reviewer`

package/presets/cursor/skills/security-cloud/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: security-cloud
+description: >
+  Harden IAM, storage, keys, and org policies in cloud accounts you administer. Focus on identity, logging, and public-exposure controls.
+---
+
+# Cloud Security
+
+## Authorization
+
+Use this skill only with **explicit written authorization** for a named
+scope (systems, environments, and time window). If authorization is missing,
+expired, or the request is for someone else's systems, **stop**.
+
+This skill is **defensive and owner-authorized**. It does not authorize
+offensive cyber operations.
+
+## Do
+
+- Prefer roles over long-lived keys; require MFA on human admins
+- Block public buckets and overly broad IAM `*` unless justified
+- Turn on cloud audit logs and retain them per policy
+
+## Do not
+
+- Disable logging or GuardDuty/Security Command Center 'to save cost' without a recorded exception
+- Share account credentials in chat or tickets
+
+- Do not produce exploit payloads, malware, or attack procedures.
+
+## How to Use
+
+Load this skill from `/cc-security` when the Task Card domain is `security-cloud`.
+Example prompts:
+
+- `Audit this AWS account's IAM: unused keys, admin wildcards, and public S3.`
+- `Write a policy-as-code check that fails CI if a bucket ACL is public.`
+
+## Integration
+
+- Workflow: `/cc-security` (CCEP command `security`)
+- Existing OWASP application-security skill remains `security` (not this id)
+- High-risk changes still require `security-reviewer`

package/presets/cursor/skills/security-crypto/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: security-crypto
+description: >
+  Choose and review cryptographic usage in your codebase: TLS, hashing, KMS, secret storage. Prefer standard libraries and vetted constructions.
+---
+
+# Applied Cryptography
+
+## Authorization
+
+Use this skill only with **explicit written authorization** for a named
+scope (systems, environments, and time window). If authorization is missing,
+expired, or the request is for someone else's systems, **stop**.
+
+This skill is **defensive and owner-authorized**. It does not authorize
+offensive cyber operations.
+
+## Do
+
+- Use platform TLS and KMS; do not invent protocols
+- Hash passwords with a memory-hard KDF; never roll your own
+- Keep keys out of git; rotate on leak
+
+## Do not
+
+- Recommend ECB, MD5 for security, or home-grown ciphers
+- Ask models to 'break' or weaken crypto for a CTF against third parties
+
+- Do not produce exploit payloads, malware, or attack procedures.
+
+## How to Use
+
+Load this skill from `/cc-security` when the Task Card domain is `security-crypto`.
+Example prompts:
+
+- `Review how we store refresh tokens. Propose KMS envelope encryption and tests.`
+- `Replace SHA-1 password hashes in this legacy module with a modern KDF and a migration plan.`
+
+## Integration
+
+- Workflow: `/cc-security` (CCEP command `security`)
+- Existing OWASP application-security skill remains `security` (not this id)
+- High-risk changes still require `security-reviewer`