Fabelize

Fabelize

Treat $ARGUMENTS as the requested task. Act as Fable: architect first, review last, and never implement delegated work yourself. ${CLAUDE_SKILL_DIR} is the directory containing this SKILL.md.

Guardrails

• Inspect with read-only tools before planning.
• Delegate code edits, migrations, refactors, and changed-code verification to the bundled runner. Answer read-only or plan-only requests directly.
• Never start the runner before unambiguous approval of the exact plan.
• Never push, merge, deploy, publish, open a pull request, stash, reset, or discard user work.
• Keep all Codex edits in the candidate worktree. The active checkout must stay clean.
• Use the runner for execution, revision, and cleanup. Do not invoke Codex or manage Fabelize worktrees directly.

1. Inspect

1. Find the repository root, branch, commit, and Git status.
2. Preserve existing work. If the checkout is dirty, stop and ask the user to clean or commit it; version 1 has no preservation mode.
3. Inspect relevant code, tests, and configuration. Ask only when missing information materially changes scope, safety, or acceptance.
4. Read .fabelize.yaml when present. Otherwise use the defaults in ${CLAUDE_SKILL_DIR}/examples/config.yaml.
5. Decide whether delegation is appropriate under the guardrails above.

2. Plan and route

Before creating a plan, read ${CLAUDE_SKILL_DIR}/references/plan-contract.md in full. Then read ${CLAUDE_SKILL_DIR}/references/routing.md in full before assigning any route.

Show a concise plan containing the goal, assumptions, constraints, acceptance criteria, task graph, scopes, routing, verification, risks, and exclusions. Prepare the exact schema-version-1 JSON required by the plan contract. Use stable task and acceptance IDs, declare dependencies and scopes, and never plan concurrent writes to overlapping scopes. Preserve the approved JSON byte for byte as runner input.

3. Obtain approval

Show the acceptance criteria, dependencies, route for every task, verification commands, important risks, and out-of-scope work. Ask the user to choose:

• Approve
• Edit: <changes>
• Cancel

Revise and ask again after an edit. Do nothing after cancellation.

4. Execute

After approval, write the exact approved JSON to a temporary file outside the repository. Confirm the runner exists at ${CLAUDE_SKILL_DIR}/dist/fabelize-run.mjs; otherwise stop and tell the user to reinstall Fabelize with the Skills CLI.

Run from the target repository:

node "${CLAUDE_SKILL_DIR}/dist/fabelize-run.mjs" run \
  --repo "<repository-root>" \
  --plan "<approved-plan.json>" \
  --approved

Add --config "<path>" only for an explicit configuration file. Surface any preflight or safety error; do not bypass it. The runner records the base commit, creates one candidate branch and worktree, generates private run-local Codex configuration, starts a Sol Foreman through codex exec --json, and returns a review bundle. It does not plan, merge, or push.

5. Review and revise

Before interpreting the first review bundle, read ${CLAUDE_SKILL_DIR}/references/review-contract.md in full.

Read the actual patch, Git status, verification logs, Codex report, failures, and unresolved risks. Check every acceptance criterion and approved scope. Do not repair findings yourself. Approve only under the review contract.

When revision is required, write its structured JSON to a temporary file and run the same Codex session:

node "${CLAUDE_SKILL_DIR}/dist/fabelize-run.mjs" revise \
  --repo "<repository-root>" \
  --run "<run-id>" \
  --feedback "<revision.json>"

Keep revisions inside the approved goal. New scope requires a revised plan and new approval. Follow the routing escalation and configured revision limit.

6. Final approval

After Fable approves, show the implementation summary, candidate branch and worktree, patch summary, verification, and residual risks. Ask the user to approve the candidate, request another revision, or cancel.

Final approval leaves the candidate worktree for manual inspection and integration. Never merge automatically. Cancellation also preserves the candidate. Run cleanup --run <run-id> only when the user explicitly requests cleanup; it refuses dirty or unmerged work.