| name | rezics-apply |
| description | Apply a code-first plan — route each durable item to its home in code (types/tests/comments), then make the source document disposable. No validation CLI, no state machine. Use when implementing a plan/proposal. |
| metadata | {"version":"0.1.0","license":"AGPL-3.0-only"} |
Implement work whose durable knowledge must end up in code, not in a planning
document. This is the routing half of the workflow: /rezics-propose produces a
plan and tags its durable items; this skill lands those items in their natural
home and lets the source document become disposable.
It is deliberately thin — no validation CLI, no state machine, no ceremony. It
is a checklist you load at implement time, nothing more. Skills are loaded on
invocation, so this is also where the routing rule actually reaches the
implementer — a plan written in one session is applied in another, and the rule
must be in context then, not at propose time.
The source is a plan at plan/proposal/<slug>.md (items tagged
(comment)/(test)/(type)).
The four-way routing rule
Triage every item — per requirement, not per document — into exactly one home:
| Item | Home |
|---|
| Shape, legal values, types, indexes | Types / Valibot / Prisma — drop the prose |
| Behavior under conditions (GIVEN/WHEN/THEN) | A test |
| Irreducible invariant / why / deliberate non-restriction / known staleness | A concise comment at the owning code |
| History, migration steps, rename maps | The git commit message — drop after landing |
The highest-value items are the negative ones — "no ancestry check", "no
domain restriction on url", "this cache may be stale for up to N s". Without them
a future dev "fixes" intended behavior. Capture these first.
Cross-cutting invariants live in the owning file's comment, with a one-line
back-pointer at each remote site. Only the genuinely scattered ones earn a short
package/.../README.md — a handful across the repo, not one per spec.
Comment format — match the site, never invent one
The codebase already has conventions. A migrated comment adopts whichever fits its
target; it does not introduce a new style:
| What the comment documents | Format |
|---|
| An exported symbol (fn / type / env field / API route) | /** … */ JSDoc |
| A local decision / branch / invariant inside a body | // … at that line |
| A named region spanning several lines | // ANCHOR: … (existing convention) |
Rules:
- Never wrap a one-line local "why" in JSDoc to look formal — use
//.
- Never leave a
spec.md back-reference. A comment like // per foo/spec.md
must become the actual invariant inline — the spec is being deleted; the
knowledge cannot point at a corpse.
- If a type already says it, say nothing. Prefer a concise comment to a verbose one.
Steps
- Read the source (plan or spec) and the code it constrains. Ground every
item in the real files before moving it.
- Route each item with the table above: land the types, write the tests,
write the comments at the owning code.
- Verify — run the package's tests and
task check:* as relevant.
- Update plan progress. Mark every completed
## Tasks checkbox as
- [x]. Leave unfinished or deliberately skipped work unchecked and call it
out in the final response.
- Make the source disposable. A plan: set
status: done only when all
task-owned work is complete or explicitly no longer applicable (a human
deletes it later). History/migration prose goes into the commit message, not
back into a file.
Guardrails
- Route per requirement, not per document — a half-migrated spec is worse than
an untouched one. Finish a spec atomically or leave it for later.
- Knowledge lands in code or it is dropped; never create a parallel spec corpus.
- Do not invent behavior. This is a migration of knowledge into code, not a
refactor; if an item is ambiguous, ask rather than guess.
