skillify

/skillify

The meta-skill (skillify_everything). When a task recurs (quarterly sale, monthly report, periodic reconciliation), this stamps out a new folder skill with the generated-skill skeleton: a phased pipeline with hard halts, parameterized SQL/steps, a QC checkpoint, a golden-replay regression test, and a hard halt before any external post. Candidates come from two places: the repeat check in repeats.md (recall.py --repeats: this ticket reads the same tables as an earlier one), which /ticket, /ship's retro and a session's closing message run at the second instance, and the --recurring flag of tools/build_ticket_index.py ("this object shows up in 7 tickets").

Where it came from. When the run starts from a repeat suggestion, it arrives with the tickets the pattern came from. Use them as the golden fixture's known-good run (Phase 1) and write them, always as <owner>/<id>, into the new skill's built_from:, with the tables they read in read_objects:. That is how the next repeat check finds this skill instead of suggesting a second one. A bare id that more than one owner has is not written: ask which ticket it meant.

How this skill asks the person something

The kit's one question rule, the same in every skill that asks:

• Read capabilities from this skill's kit_paths.py --json probe the first time a question comes up, and keep the result.
• capabilities.structured_questions is yes and capabilities.question_tool is not none → ask with that tool, within capabilities.question_limits (when that says unknown: one question per call, at most four options). Group up to the limit only questions that do not depend on each other's answers; ask a dependent question after the one it depends on.
• Otherwise (no / unknown, or the probe failed) → ask in chat as a short numbered list, one question at a time unless this skill says a set goes in one round, and wait for an explicit answer.
• The question content is the same either way; only how it is shown changes. No skill names a runtime's tool: the runtime's own adapter (adapters/runtime/<name>.md) does. A question tool is not available inside a subagent, so the main session asks.
• Never invent an option. Options come from what this run found or the fixed choices a step names. A recommended option goes first, marked recommended, with where it came from; the person still picks. Each option says what choosing it changes, and free text is always possible (the tool's own "Other", or "or tell me something else" in prose).
• Whatever the person needs to answer is already in chat before the question, so a picker never hides it.
• A reply the kit asks for word for word (ship unreviewed, the yes before destructive SQL) stays typed: an unreviewed ship or an irreversible write is never one click. The external-send gate (go ahead) is asked like any other question once the full delivery plan is in chat: its first option is "Go ahead", which delivers exactly the printed plan, and with no question tool the person types go ahead.