writing-workflow-skills

name	writing-workflow-skills
description	Use when adding a new workflow skill to pi-thinkrail-workflow, changing an existing workflow skill's role, trigger, handoff, or structure, or checking a workflow skill against the workflow system's rules. Not for authoring general-purpose skills outside this package.

Writing Workflow Skills

The authoring checklist for workflow skills in packages/pi-thinkrail-workflow. It carries the what to do; every why — the concept model, the three roles, the meta-rules cited as "(rule N)" below — lives once in the workflow-system spec beside this directory, skills/SPEC.md. Read that spec first; where this checklist and that spec disagree, the spec wins.

Workspace guard. This checklist edits packages/pi-thinkrail-workflow in the thinkrail repo. If that package is not in the current workspace (a ThinkRail-managed project, where these skills are a read-only staged cache), the family cannot be extended from here: say so in one line and stop — the terminal state for foreign workspaces.

Design (before writing)

• Read skills/SPEC.md: concept model, the three roles, meta-rules 1–15.
• Scope the skill to one externally reachable workflow — or, for a concept, one topic (rule 1). Internal forks, branches, stages, and shared tails are sibling docs, planned with the choice rules in the doc (or spine) before the fork; a doc is promoted to its own skill when it needs independent addressability (an external caller, a genuine self-trigger, or a direct entry point such as a /skill: command seed) — never for shape or size alone.
• Pick the role (rule 2): router (classification rules + handoffs, nothing else), worker (one phase's steps), or concept (one topic's reusable rules/mental model — no steps, no handoffs).
• For a concept: confirm a second skill needs it (rule 3) — reference detail with a single consumer stays a sibling file, not a concept skill.
• Pick the ending (rule 6): a router ends by naming what runs next; a worker ends with a fixed successor, back to its caller, or a declared terminal state — an internally forking worker ends by naming the sibling doc that continues the flow, with the terminal state declared in the doc where the flow ends; a concept has no ending at all — it writes no ending section, control simply returns to its reader. Know the exact wording before writing the body.
• If the change reshapes the system itself — a new role, a new meta-rule, a changed entry model or topology — stop: update skills/SPEC.md first, then come back here (rule 13).

Write

• Name the skill verb-first, active voice, kebab-case (rule 15): a gerund for process skills, the topic for a concept — name the work or the insight, never the artifact or a role. Directory name = frontmatter name.
• Create skills/<name>/SKILL.md with frontmatter name + description. Nothing else changes — package.json's pi.skills already points at ./skills.
• description = triggering conditions only, "Use when …" (plus a "Not for …" negative trigger if the boundary is confusable) — never a summary of the steps (rule 5). Skills are reached by routing; a self-trigger description is for unmistakable triggers only (rule 4).
• Keep every file under ~150 lines (rule 3) — the SKILL.md spine and each sibling doc. Internal workflow nodes (branches, stages, shared tails) and heavy reference material live in sibling docs inside skills/<name>/, named in the exact step that hands to them; the spine carries the doc map, and each internal-node doc opens with a one-line contract (entry state, what it saves, where control goes next).
• Say each thing once (rule 7): cross-reference other skills by name; never inline another skill's steps, never force-load its files.
• Put gates where discipline matters, matching the form to the failure (rule 11): prohibitions + red flags for discipline violations, positive recipes for output shape.
• Durable output goes to the spec graph (rule 8). If the workflow needs ephemeral working files — resume state, scratch plans — declare them (rule 9): name their shape in the skill and put them in the workspace's gitignored .thinkrail/context/ (the home for every temp doc), consume/delete them when the work lands, and promote anything durable to specs before cleanup.
• End the body by naming the ending chosen in Design (rule 6) — a concept skips this: no ending section.

Register (rule 12)

• Add one routing line in the router that owns the new skill: the root router (skills/choosing-a-workflow/SKILL.md) by default, or the nearest sub-router when the skill is a branch under an already-routed workflow (fractal routing). Exception (rule 4): a skill outside any router's work classification — self-trigger-only skills and concept skills — skips the router line; that's a designed property of the skill, never a size call, and it is instead named in skills/SPEC.md's family table as outside the routing table.
• Add or update the skill's row in skills/SPEC.md's Workflow family table, including its Routed from entry (which router routes to it — or that it sits outside the routing table).
• Nothing else should have changed shape — if it did, revisit rule 13 in Design.

Verify by use (rule 14 — currently suspended)

• Rule 14 is a known limitation today, not a done-gate (see skills/SPEC.md). When practical, still run a real request through the new or changed skill and watch it flow: the router (or the description) triggers it, the body is followed, the ending fires as designed. For a concept: a referencing skill (or its self-trigger) loads it and its rules are applied.
• Either way, keep the family-table row honest: unverified by use until a run has been observed; update the row when one has.

Red flags — stop and fix

• The description mentions any step of the workflow.
• The name is noun-first or names an artifact/role instead of the work (rule 15).
• The body of a router or worker ends without naming a successor or terminal state.
• A concept skill contains steps, routing, a handoff, or an ending section.
• The same rules are copied into two skills instead of extracted into a concept (rule 7).
• A step restates another skill's (or skills/SPEC.md's) content instead of pointing at it.
• An internal node that nothing outside the skill reaches was made its own skill (or given frontmatter) — internal nodes are sibling docs, not skills (rule 1).
• "Too small to need a router line / family-table row." Every skill registers (rule 12); skipping the router line is only for self-trigger-only skills and concept skills per rule 4 — size is never the reason.
• Calling a skill verified without a real request observed flowing through it — rule 14 is suspended as a done-gate, but an unobserved skill is still unverified by use, never "verified".

Done (terminal state)

This checklist ends here — no successor skill. Done means: skills/<name>/SKILL.md exists and passes the checks above, and the router line and family-table row are in place — the row honestly marked unverified by use until a real request has been observed flowing through the skill (rule 14, currently suspended as a done-gate).