Skill Rails

Treat the user's intent as authoritative and the generated package as the durable work surface. Do not hold migration or generation state only in conversation.

Before running a bundled script, resolve <skill-root> to the directory containing this SKILL.md. Use the host's discovered skill path when it exposes one. In Claude Code use ${CLAUDE_SKILL_DIR}; in Codex use the absolute path supplied with the available-skill metadata. On another file-based host, resolve the active SKILL.md location before running a command. Never resolve scripts relative to the user's working project, and stop if the host does not expose a stable skill location.

1. Capture or update an intent brief from intent-brief.json; its eleven requirement fields are the input contract. A judgment_points entry may remain an always-visible string or declare an independently routed { id, when, points } topic. Read authoring-workflow.md for creation or maintenance.
2. Choose the smallest sufficient profile: P0 for judgment-only guidance, P1 for exact formats or deterministic helpers without stateful branching, or P2 for repeated state-dependent guards, stages, ordered effects, and evidence gates.
3. For P2 work, read v5-contract.md. Keep spec.mjs as the only behavior source and keep judgment in body.md.
4. For prose conversion, read migration.md. Create the atom ledger before deleting or rewriting source meaning.
5. Generate with node "<skill-root>/scripts/init.mjs" --intent <intent.json> --out <folder> [--profile auto|p0|p1|p2] or migrate with node "<skill-root>/scripts/migrate.mjs" --source <skill-folder> --out <folder>. Treat generated P1/P2 output as a scaffold, not a finished skill.
6. Maintain an intent-backed P0/P1 or P2 package with node "<skill-root>/scripts/maintain.mjs" --skill <folder> --change <change.json>. P0/P1 accepts intent-only changes, refuses profile changes and hand-edited intent projections, and preserves separately authored helpers and files. P2 uses stable-ID operations and emits a semantic impact report. Read the maintenance rules in authoring-workflow.md before accepting generated edits.
7. Replace every marked scaffold with approved user-specific behavior and tests. Resolve each .skill-rails/obligation-ledger.json atom to stable target and evidence locators; never clear the final P2 DEFERRED item while any atom remains review-required. Run node "<skill-root>/scripts/lint.mjs" --skill <folder> [--full] after every edit, then build P2 before execution.
8. Read evaluation.md and run node "<skill-root>/scripts/eval.mjs" --skill <folder> before claiming behavior quality. Missing execution evidence is unproven, not success.
9. Read platform-adapters.md when installing the creator or building and verifying host-specific outputs.
10. When the user asks to create or revise a skill README, read readme-authoring.md completely before drafting. Use it as a flexible quality guide, not a mandatory template. The user's audience, tone, emphasis, and exclusions take priority, and the README must not claim more than the implementation and evidence support. Do not create a README merely because the guide exists.

Never edit generated artifacts behind .generated.json by hand. Change their canonical source and rebuild. If validation, manifest verification, or the runtime tool fails, stop and report the exact diagnostic instead of reconstructing a decision from prose.