Writing Your First Skill / Project Rulebook

Every time you re-explain a task from scratch in a fresh chat, you're paying a tax — re-establishing context, re-stating your standards, re-correcting the same mistakes you corrected last time. A saved workflow (a Skill, or a Project's standing instructions) pays that tax once and then applies the result every time the task comes up again.

This is the shift from prompting to capability-building: instead of having a conversation about how to do something, you write down how it should be done, save it, and invoke it. The AI stops being a tool you have to re-teach and starts being a colleague who already knows your standards.

Not every task deserves this treatment. The right candidate is repeated at least twice a month, has a clear quality bar you could describe to someone else, and is fundamentally text-shaped — something involving reading, writing, structuring, or summarizing information rather than physical action.

A weekly client report, a proposal intake structure, an email triage routine, a content brief format — these are classic candidates. A one-off strategic decision or a task with no consistent shape is a poor fit; the effort of writing a rulebook only pays off through repetition.

A well-formed Skill or rulebook has six parts. Purpose: one sentence on what this capability is for and why it exists. Inputs: exactly what raw material it needs to run (a data export, a transcript, a previous version). Step-by-step process: the actual sequence of reasoning or actions to follow, in order.

Output format: precisely what the final deliverable should look like — structure, length, template. Quality checklist: a short list of checkable pass/fail criteria the output must meet. Examples: at least one sample of genuinely good output, so the model has a concrete target, not just an abstract description.

Rules only work if they're specific and testable. "Be thorough" gives the model nothing concrete to aim for and gives you no way to check whether it succeeded. "Include a numbered next-actions section with at least three items" can visibly pass or fail — you can look at the output and know immediately.

Good rules often come with counter-examples: not just what to do, but a specific example of what not to do and why. "Don't include prices unless copied verbatim from the price list — writing '~$500' instead of an exact quoted figure is a failure" teaches the boundary far better than a vague instruction to be careful.

These three live at different scopes. Skills are the most portable — a defined capability that can be invoked explicitly, good for a specific repeatable task like drafting a certain report type. Project instructions apply broadly to everything happening inside one Project, good for standing context like "you're writing for B2B SaaS founders, always avoid jargon."

Custom GPTs (or their equivalents) bundle instructions, files, and sometimes custom actions into a shareable, standalone assistant — useful when you want to hand a whole capability to someone else, like a teammate who needs the same reporting standard without building it themselves. Choosing the right home depends on how narrow the capability is and who else needs to use it.

A rulebook is a hypothesis until you've tested it. Run it five times on real inputs, score each output against your quality checklist, and note exactly where it falls short. A first run might score 6 out of 9 on the checklist — maybe two checklist items about number-traceability keep failing.

Revise the rulebook specifically to address those failures — add an explicit rule, tighten an ambiguous instruction — and run the shakedown again. In the client report example, two targeted rule fixes take the score from 6/9 to 9/9, and from that point forward, the weekly report becomes a one-sentence trigger instead of a fresh conversation.

Even a lightweight rulebook benefits from a simple versioning habit: date every meaningful change and note in one line what you changed and why. This doesn't need to be a formal system — a single line at the top of the document ("2026-03: added rule against vague deadline language after two failed shakedown runs") is enough.

The payoff shows up months later, when the rulebook has drifted from its original form and you need to know what actually improved things versus what was an untested guess. Dating changes turns your rulebook from a static document into a record of accumulated learning.