cc-codeconductor 0.4.3 → 1.0.0

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

@@ -0,0 +1,54 @@
+---
+name: openspec
+description:
+  OpenSpec backlog format, state machine, and delivery workflow for CodeConductor.
+  Use when running /cc:openspec or editing BACKLOG.md.
+---
+
+# OpenSpec / BACKLOG Skill
+
+## BACKLOG.md contract
+
+`BACKLOG.md` at repo root is the operational queue. Required sections:
+
+- `## Global` — Product, Strategy, Policy, Review required, TDD required
+- `## Items` — active backlog entries
+- `## Archive` — completed entries (do not re-execute)
+
+Each item: `### BC-001 | Short title` with Priority (P0–P3), Status, Type, Depends on, Description, Scope, Out of scope, Acceptance (measurable checklist).
+
+## Status machine
+
+`TODO` → `READY` → `PLANNED` → `IN_PROGRESS` → `REVIEW` → `DONE` → Archive
+
+`BLOCKED` can return to `READY` when resolved. Reviewer rejection: `REVIEW` → `IN_PROGRESS`.
+
+## CLI commands
+
+```bash
+npx cc-codeconductor openspec validate   # gate — must pass before delivery
+npx cc-codeconductor openspec scan
+npx cc-codeconductor openspec plan BC-001
+npx cc-codeconductor openspec status
+npx cc-codeconductor openspec next
+```
+
+## OpenSpec folders
+
+Each item generates `openspec/changes/<slug>/` with `proposal.md`, `design.md`, `tasks.md`, `specs/` — compatible with Fission-AI OpenSpec layout (no external CLI required).
+
+## Agent phases
+
+| Phase | Agent |
+|-------|-------|
+| discover | repo-explorer |
+| design | architect |
+| test | tester |
+| implement | implementer |
+| review | reviewer |
+
+When Global `TDD required: yes`, test runs before implement.
+
+## Reject vague backlog
+
+Do not process items with acceptance like "improve UX" or "fix bugs". Require verifiable criteria.

package/presets/codex/AGENTS.md

@@ -102,18 +102,19 @@ When multiple signals apply, take the highest risk level. Do not average.
 
 | Task Type            | Risk        | Route                                               |
 | -------------------- | ----------- | --------------------------------------------------- |
-| New feature design   | any         | `architect` → `implementer`                         |
-| Bug fix              | low         | `implementer`                                       |
-| Bug fix              | medium–high | `task-coach` → `implementer` → `tester`             |
+| New feature design   | any         | `architect` → `tester` → `implementer`              |
+| Bug fix              | low         | `tester` → `implementer`                            |
+| Bug fix              | medium–high | `task-coach` → `tester` → `implementer`             |
 | Refactor             | low         | `implementer`                                       |
 | Refactor             | medium–high | `architect` → `implementer` → `reviewer`            |
 | API change           | any         | `architect` → `implementer` → `reviewer`            |
-| Database migration   | any         | `architect` → `implementer` → `tester` → `reviewer` |
+| Database migration   | any         | `architect` → `tester` → `implementer` → `reviewer` |
 | Test coverage        | any         | `tester`                                            |
 | Documentation update | any         | `docs`                                              |
 | Codebase exploration | any         | `repo-explorer`                                     |
 | Code review          | any         | `reviewer`                                          |
 | Security review      | high        | `security-reviewer` → `reviewer`                    |
+| DDD→SDD→TDD pipeline | any         | `contract-builder` → `architect` → `tester` → `implementer` |
 
 ---
 
@@ -790,6 +791,62 @@ module, or identifying the impact radius of a change.
 
 ---
 
+### contract-builder
+
+**Role:** Defines API contracts, data shapes, and behavior specs before
+implementation. Produces OpenAPI specs, JSON Schema, or TypeScript interfaces
+that the implementer and tester use as the source of truth.
+
+**Use when:** New feature needs spec-before-implementation, API contract needs
+definition, or the DDD→SDD→TDD pipeline is triggered.
+
+**Permissions:**
+
+- read: `allow`
+- edit: `ask` (docs, ADRs, OpenAPI only)
+- bash: `deny`
+- network: `deny`
+
+**Does not:** Write implementation code. Modify production source files.
+
+**Model:** `{{MODEL_CODEX}}`
+
+**Deliverables:**
+
+- OpenAPI 3.x spec (`openapi.yaml` or `*-api.yaml`)
+- JSON Schema for request/response bodies
+- TypeScript interfaces for shared types
+- Contract test matrix (endpoint × status × shape)
+
+**Contract specification format:**
+
+```markdown
+## API Contract
+
+**Task**: [objective from Task Card]
+
+### Endpoints / Interfaces
+
+| Method | Path | Request | Response | Errors |
+| ------ | ---- | ------- | -------- | ------ |
+| POST | /api/v1/... | [schema ref] | [schema ref] | 400, 401, 422 |
+
+### Data shapes
+
+- `[TypeName]`: [field list with types and constraints]
+
+### Compatibility
+
+- Breaking changes: [yes/no — list if yes]
+- Versioning strategy: [URL prefix | header | none]
+
+### Contract tests required
+
+- [ ] [test description — request shape, response shape, error cases]
+```
+
+---
+
 ### goal-planner
 
 **Role:** Transforms an objective string into a YAML task graph with
@@ -811,7 +868,7 @@ needs a multi-step plan before delegation.
 
 The planner matches objective keywords against built-in templates (auth, crud,
 search, notification, migration) and falls back to a generic 4-task chain:
-`task-coach → architect → implementer → tester`.
+`task-coach → architect → tester → implementer`.
 
 **Dependency order delegation (orchestrator):**
 

package/presets/codex/commands/cc-ask.md

@@ -0,0 +1,55 @@
+---
+description: >-
+  [cc: alias] Recommend one CodeConductor slash command from a natural-language
+  problem. Does not start that workflow.
+---
+
+# Ask — recommend a slash command
+
+Problem: $ARGUMENTS
+
+This is a **router**, not a delivery workflow. Recommend exactly one command.
+Do **not** run the recommended `/cc:` command unless the human confirms.
+
+---
+
+## Step 1 — Recommend (deterministic)
+
+Run (local repo: `bun run dev`; published package: `npx cc-codeconductor`):
+
+```bash
+bun run dev ask "$ARGUMENTS" --output json
+```
+
+or:
+
+```bash
+npx cc-codeconductor ask "$ARGUMENTS" --output json
+```
+
+The catalog is only:
+
+| Slash | When |
+| ----- | ---- |
+| `/cc:feature` | new behavior |
+| `/cc:fix` | bug / regression |
+| `/cc:refactor` | structure, no behavior change |
+| `/cc:review` | inspect a diff/PR |
+| `/cc:tdd-cycle` | red → green → refactor |
+| `/cc:openspec` | BACKLOG / BC-xxx delivery |
+
+If the CLI is unavailable, apply the same catalog and the same priority:
+openspec → tdd-cycle → review → refactor → fix → feature (default).
+
+---
+
+## Step 2 — Show and stop
+
+Print:
+
+- **Recommended:** the slash command
+- **Why:** one or two sentences from the CLI `reason` (or your matching)
+
+**STOP.** Wait for the human. Do not invoke the recommended workflow.
+
+For a full preset inventory (skills, commands on disk), use `/cc:help` / `cc-help`.

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

@@ -0,0 +1,136 @@
+# Pre-commit Gate: Typecheck 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.
+
+## Cuándo usar
+
+**Para agentes**: Integra este gate en flujos de desarrollo local cuando quieras garantizar que los cambios typecheck correctamente y pasan los tests antes de ser cometidos.
+
+**Para equipos**: Utiliza este gate como barrera de calidad local (sin dependencias externas) para prevenir commits con errores de tipado o tests fallidos.
+
+## Instalación
+
+### Paso 1: Descarga el script
+
+El script está embebido abajo (sección "Script Installer").
+
+### Paso 2: Ejecuta en la raíz de tu proyecto
+
+Desde la raíz del repositorio (o cualquier subdirectorio), extrae el bloque ```bash de este archivo y ejecuta:
+
+    bash << 'SCRIPT_EOF'
+    #!/bin/bash
+    set -e
+    # [contenido del bloque bash de abajo]
+    SCRIPT_EOF
+
+O, más simplemente, guarda el script en un archivo temporal y ejecútalo:
+
+    curl -s https://raw.githubusercontent.com/.../ | bash
+
+### Paso 3: Verifica
+
+Después de la instalación, debería verse:
+
+    Pre-commit hook installed successfully.
+
+## Script Installer
+
+```bash
+#!/bin/bash
+set -e
+
+# Resolver git directory dinámicamente (worktree-safe)
+GIT_DIR=$(git rev-parse --git-dir)
+HOOK_PATH="$GIT_DIR/hooks/pre-commit"
+
+# Detectar Husky o lint-staged en package.json
+if grep -q '"husky"' package.json 2>/dev/null || grep -q '"lint-staged"' package.json 2>/dev/null; then
+  echo "Warning: Husky or lint-staged detected in package.json. Installation skipped."
+  exit 0
+fi
+
+# Verificar si un pre-commit hook ya existe
+if [ -f "$HOOK_PATH" ]; then
+  echo "Warning: Pre-commit hook already exists at $HOOK_PATH. Not overwriting."
+  exit 0
+fi
+
+# Crear directorio hooks si no existe
+mkdir -p "$GIT_DIR/hooks"
+
+# Escribir el hook pre-commit
+cat > "$HOOK_PATH" << 'HOOK_EOF'
+#!/bin/bash
+bun run typecheck || exit 1
+bun run test || exit 1
+HOOK_EOF
+
+# Hacer el hook ejecutable
+chmod +x "$HOOK_PATH"
+
+echo "Pre-commit hook installed successfully."
+```
+
+## Notas de implementación
+
+- **Sin dependencias externas**: El script no instala Husky, lint-staged, ni ninguna otra herramienta. Solo escribe un archivo shell y configura permisos.
+- **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`.
+
+## Verificación
+
+Después de instalar, verifica que el hook está en su lugar.
+
+Para verificar, ejecuta:
+
+    ls -la .git/hooks/pre-commit
+
+Debe mostrar algo como:
+
+    -rwxr-xr-x  user  group  ... .git/hooks/pre-commit
+
+Luego, intenta hacer un commit. Si hay errores de tipo o tests fallidos, el commit será bloqueado:
+
+    git add .
+    git commit -m "test"
+    # Si typecheck o test falla, verás el error y el commit será abortado.
+
+## Troubleshooting
+
+### "Warning: Pre-commit hook already exists"
+
+Ya hay un hook pre-commit. Revisa su contenido:
+
+    cat .git/hooks/pre-commit
+
+Si quieres reemplazarlo, bórralo y ejecuta el script nuevamente:
+
+    rm .git/hooks/pre-commit
+    bash /path/to/installer
+
+### "Warning: Husky or lint-staged detected"
+
+Tu proyecto usa Husky o lint-staged. Este gate no se instala para evitar conflictos. Si quieres usar este gate, remove Husky/lint-staged de `package.json` y ejecuta de nuevo.
+
+### Hook no se ejecuta al hacer commit
+
+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`:
+
+    cat package.json | grep -A 5 '"scripts"'
+
+### "command not found: bun"
+
+Bun no está instalado o no está en PATH. Instala Bun desde https://bun.sh o configura PATH adecuadamente.
+
+## Adicional: Desinstalación
+
+Para remover el hook, simplemente bórralo:
+
+    rm .git/hooks/pre-commit

package/presets/cursor/.cursorignore

@@ -0,0 +1,15 @@
+node_modules/
+dist/
+build/
+.gradle/
+*.lock
+.env*
+coverage/
+graphify-out/
+.next/
+.turbo/
+__pycache__/
+*.pyc
+.venv/
+target/
+vendor/