Read how professionals write agent skills.

Why read it

• The writing-skills skill shows how to test a skill the way you test code: run a pressure scenario without the skill, record the agent's rationalizations word for word, then write guidance against them, and micro-test the wording against a no-guidance control.
• The execution skills show how to keep a long autonomous run on track and recoverable: a ledger file that survives compaction, helper scripts for task briefs and review packages, and a short, fixed list of conditions that allow stopping.

Why read it

• It shows how to split skills into user-invoked ones that run a process and model-invoked ones that hold reusable rules, so a wrapper like grill-with-docs can be one line that calls two other skills.
• The writing-for-agents skill sets out the author's own rules for writing skills (context pointers, progressive disclosure, completion criteria, leading words), and the other files apply those rules.

Why read it

• The collection shows how to keep a long, multi-step skill manageable. The main file is a decision-tree skeleton, and it tells the agent to read each on-demand section at the step where that section applies, not to work from memory.
• It shows how to make an agent prove its claims before it reports them. Each finding needs a quoted line, confidence scores decide how findings are displayed, and the rules ban completion claims without fresh verification evidence.

Why read it

• The collection shows how to write a contract skill: a numbered list of hard rules backed by a CLI checker that prints a `Fix:` line for each violation, with the other skills deferring to it.
• It shows how to write a verification loop that checks visual work against measured numbers: SSIM diffs against the original, dB thresholds, and checking an ffprobe duration after a render.

Why read it

• It shows how a skill can push all checking into one CLI command (`finalize`) that returns a machine-readable receipt, and then tell the agent to treat that receipt, not its own judgment, as the definition of success.
• It shows how to keep a large skill short by sending the agent to reference files only when a named trigger applies, and by using a type-router table that maps each case to an exact schema and example path.

Why read it

• It shows how to put design taste into short, numbered rules an agent can check, such as "one claim per figure" and "every arrow gets a verb", plus a mapping table from content type to figure type.
• It shows how to send detail out to reference files, so the main skill file stays a short router that says which reference to read for plans, motion, slides or video.

Why read it

• It shows how to put one central idea at the top of a skill ("the object is the explanation") and back it with a table of past concept-to-object mappings and the two ways it has failed in practice.
• It shows how to pair a skill with its own checking tools, an audit script and a line-end check, that must reach zero before the agent may call the work done.

Why read it

• It shows how to split a creative task into two stages: the agent writes an intermediate document (a manifesto for an art movement), then reads that document back as its brief for making the artwork.
• It shows how to raise output quality using framing alone: a refinement round where the user is assumed to have already asked for more, and craftsmanship language that the skill deliberately repeats.

Why read it

• You would learn how to give many skills one shared backbone: the same activation sequence, customization resolver, memlog script and fallback wording repeat across skills, while each skill keeps its own voice and method.
• You would see how to write facilitation skills that deliberately work against the model's habits, such as doing the thinking for the user, agreeing too readily, or wrapping up too early, by naming each habit and the counter-rule.

Why read it

• It shows how to build skills that call each other: an orchestrator like lfg calls child skills with mode tokens, and each child sends back a structured status that the caller branches on.
• It shows how to keep a SKILL.md short. The detail lives in reference files, and the skill tells the agent to read each one when it enters that phase and never to rebuild a file's rules from memory.

Why read it

• You can see how a family of skills hands work between its members: each description says when not to use the skill and names the sibling to use instead, and a small routing skill holds only a table of situations.
• You can learn how to turn hard-won domain practice into numeric thresholds an agent can check, such as data split sizes, TPR/TNR targets and sample counts, instead of vague advice.

Why read it

• It shows how to write a long multi-agent protocol that a forgetful orchestrator can still follow. The orchestrator's only memory is state.md, file-based handoffs carry the work between steps, and a script prints one-word verdicts that tell it what to do next.
• It shows ways to stop the model from overclaiming. These include an append-only claims ledger, two independent verify queries before a proof counts, and a required Status section that says plainly what is and is not proved.

Why read it

• You can see how one set of skills is wired together: a router skill sends each request to one skill or chain, chain commands run skills in a fixed order with a gate between steps, and every skill ends by offering a short list of next skills.
• The skills show how to set out exactly which actions need approval, where reading is free, sending waits for a yes, and text from emails or documents is never treated as an instruction.

Why read it

• The agent files show how to write safety into a workflow with plain sentences. Untrusted documents go only to reader workers that have no tools, only one subagent can write, and the agent itself never posts, publishes or approves.
• The modeling skills show how to make long, error-prone builds checkable. They set pause points where the user confirms each stage, and they include checks that prove the output is correct, such as a sensitivity table whose center cell must equal the model's base case.

Why read it

• It shows how to say exactly how much of a skill was tested. Each skill states which parts actually ran, which were mocked and which are only illustrative, and it pins the version it was reviewed against.
• It shows how to set firm limits in high-stakes domains, such as research use only and no diagnosis, while still giving the agent detailed, useful steps.

Why read it

• You can see how a large set of skills shares one foundation: every skill reads the same context file before it asks anything, and each one ends by pointing to related skills.
• You can learn how to make an agent's writing sound less machine-made. The skills ban AI tells by name, such as "it's not X, it's Y" reveals, and give a three-question gate that every line of copy must pass.

Why read it

• The files share one section scaffold (Identity & Memory, Core Mission, Critical Rules, Technical Deliverables, Workflow, Success Metrics), so a reader can see how one template carries a role across very different domains.
• Several agents show how to write guardrails for agents that act on their own, such as idempotency checks before a payment, fail-closed authorization, and retry limits that end in escalation.