Reify

Reify

Reify turns an unclear thought into one concrete outcome, then either makes the next safe move or produces a handoff another executor can use. Keep the exchange simple for the user while the working record preserves evidence, choices, uncertainty, and reversibility.

Which commands does this skill accept?

Interpret a plain request as new unless a prior reification record clearly applies.

A decision ID matches ^D-[0-9]{3}$, counts up per record from D-001, and is never reused. A record path looks like reify-log-lighthouse-summers.md.

If the request matches no command and intent cannot be inferred from context, ask one short question and stop. Do not guess at a sensitive target, recipient, payment, publication, or irreversible effect.

How does reification work?

Use this full plan. After each consequential step, run the stated check and fix a failed check before moving on. Keep every user-facing reply at or below 350 words; move detail into the record and the files instead of the reply.

1. Check for an active record. Inspect reachable conversation, files, notes, task systems, and named sources before asking the user to repeat facts. If one missing fact would change the outcome, ask for only that fact and stop. Check: the current thought and source boundary are explicit.
2. Check the installed skill catalog for starting-point. When present, apply it to define the target, constraints, completion proof, and first milestone. When absent, derive those four fields directly. Check: the target is an outcome rather than a topic.
3. Create or resume the record at ./reify-log-<slug>.md in the directory the user is working in, as the reification record defines, and print its absolute path once. Otherwise keep the same visible record in the conversation and state that no file was written. Append the current signal, sources checked, assumptions, decisions, reversibility state, and next check after each remaining step. Check: another executor could resume without asking settled questions again.
4. Reflect the strongest signal in one sentence, offer one provisional outcome, and ask one low-effort question only when its answer changes the form, direction, or the facts a first-person draft would otherwise invent. Check: the response does not turn into an intake form and stays at or below 350 words.
5. Read the tool and skill catalog index once, then open a capability contract only for a capability you are about to call. Name in the record every capability you skipped and the one-line reason. Check: unavailable capability claims name what was actually inspected.
6. Make the smallest useful object that tests the current direction, such as a title, premise, sketch, example, decision, prototype, or first milestone. Recommend one default path. Name an alternative only when it implies a materially different completion proof, at most two, in one line. When a later object absorbs or replaces a probe, move the probe into ./superseded/ in the same turn. Check: the object can reveal whether the idea should continue, change, or stop, and no two live files open with the same text.
7. Never invent first-person biographical fact. When the user's material lacks names, places, dates, or people, write bracketed slots such as [lighthouse name], keep the object short, and ask for the two or three facts that unlock real writing. Check: every concrete personal detail in a draft traces to the user's words or a cited source.
8. Record each accepted choice with a decision ID, reason, dependents, and reversibility. For revert, follow the five revert moves in the record reference, which reopen the affected fields, mark dependents needs-review, and move affected files to ./superseded/ rather than deleting them. For scrap, set status: scrapped and perform no further effect. Check: the record explains the current state without hidden decisions.
9. Converge after one to three useful exchanges unless the user asks to keep exploring. State the outcome, why it fits, first milestone, observable completion proof, next action, and any open decision. Check: only one candidate is active.
10. Execute the next safe action when the user requested execution and the environment permits it. For external writes, publication, deployment, messages, payments, authentication, or destructive changes, resolve the exact target, scope, and authorization first. A first name is not an address and a send instruction is not authorization for an unresolved recipient. Search the reachable address sources once each, stop after that, keep the work in a local handoff file, and ask one sentence for the missing target. Turn a vague deadline into one proposed date, say the date and the reason, and let the user correct it. Check: direct evidence proves any action claimed as complete.
11. When the outcome must pass to another executor, copy the template out of the skill and validate the copy. Never edit files inside the installed skill. Set SKILL_DIR to the absolute path of this skill directory, then run cp "$SKILL_DIR/assets/reification-brief.json" ./BRIEF.json, fill ./BRIEF.json with the ten record fields, and run mise run validate-brief ./BRIEF.json. Exit 0 is required. On exit 1 the brief is wrong: fix every reported field and rerun. On exit 2 the command is wrong, not the brief: the interpreter or the parser could not use the path, so recheck SKILL_DIR, use the absolute script path, and rerun. Check: outcome, completion proof, first milestone, next action, decisions, and status are present and the report reads "status": "PASS".
12. Finalize with either a verified artifact or a usable handoff. Report status: finalized and the milestone state as two separate sentences when the milestone depends on another person. Check: the result names what exists, what was verified, and what remains.

What goes in the record?

Read the reification record when work spans turns, uses multiple sources, or contains decisions that may be reversed. It owns the record path, the ten required fields, the decision ID format, revert semantics, and the probe lifecycle. Read the generation contract before changing this skill's structure or support files.

Load assets/reification-brief.json only when a structured handoff is needed, and copy it out before filling it. Load mise run validate-brief to check that handoff. Load mise run test only when changing script behavior, and run the tests before implementation changes. Load evals/ when measuring activation, behavior, failure handling, recovery, or timing.

Which worked example should you read?

Resource gate: run mise run validate before using package files named here.

Each file in examples/ is one complete run with real command output. Read the one that matches the move you are about to make.

• examples/help-command.md when the user types help or asks what this skill can do.