Workflow & Playbook Templates

A browsable shelf of workflow and playbook templates worth keeping. Each one is something you can run, not just admire. Read the where it breaks line on each before you trust it.

Anthropic's "Claude Code: Best practices for agentic coding" names four durable, shareable units that live inside a working harness. These are the templates that compound. Treated as a set they are the most portable thing in this section.

• A CLAUDE.md (or project memory file). A refined, context-consuming prompt that loads automatically at the start of every session. It holds the conventions, the source-of-truth rules, and the do-not list the model should never have to be re-told. It earns its place because it converts "things I keep re-explaining" into a one-time write. Where it breaks: it is itself a context tax. Everything in it is loaded on every turn before your real question arrives, so a bloated CLAUDE.md quietly steals the budget the actual task needs. Keep it lean and treat length as a cost.
• Custom slash commands stored as markdown in .claude/commands/. Each file is a reusable prompt template invoked by name. The PKOS workspace this Handbook is built in runs more than sixty of them, and the shape is consistent and copyable. A command declares its trigger in frontmatter, names the primitives it composes, and lays out its steps as numbered sections. Where it breaks: a command that hard-codes one project's folder paths or naming scheme is the textbook idiosyncrasy trap. The skeleton travels; the baked-in paths do not.
• Subagents to preserve the main context window. A worker spawned to do a bounded piece of work — read a large file, run a search, draft one section — and return only a short result, so the bulk of the material never enters your main thread. It earns its place by keeping the orchestrator's window clean across long runs. Where it breaks: a subagent cannot see your conversation. Anything you have not written into its brief, it does not know, and it will guess rather than ask.
• A project convention-check script. A small deterministic check that verifies the codebase or workspace still obeys its own rules. It earns its place because deterministic code beats asking the model to "remember" a convention. Where it breaks: it only catches what you taught it to check; a green run means "the rules I encoded still hold," not "the work is correct."

Demote the PKOS specifics here to what they are: one live workspace as a case study, not a universal standard. The principle travels everywhere — a loaded memory file, named reusable commands, context-preserving workers, a deterministic checker. The exact filenames are local color.

This is the durable shape behind those sixty-plus commands, stripped of any one project's specifics. Save a workflow you have run more than twice as a file like this and you stop re-typing it.

The load-bearing parts are the frontmatter trigger and the read-state-first / verify bookends. The trigger line is the whole API of the command — it decides whether the right thing fires. Read-state-first stops the command acting on a stale picture, and the verify step stops it reporting success it did not earn.

Three moves that make a high-autonomy agent run survivable, sequenced. The recurring practice among people who run CLI agents daily reduces to this: plan mode first, commit often, read the diff. Enter plan mode before any non-trivial task so the agent reasons through the approach before it touches anything. Commit frequently so rollback is cheap. Read every diff because the agent will confidently do the wrong thing some of the time, and the read is where you catch it.

The triad earns its place because the cost of being wrong at high autonomy is asymmetric. When an agent is right it saves you an hour; when it is wrong across a dozen files you can spend two hours reviewing and fixing, more than if you had done the work yourself. The triad is what shifts that distribution back in your favor. Where it breaks: it assumes you actually read the diff rather than skim it. The failure mode it does not protect against is rubber-stamping — a long, plausible diff that you approve without comprehension, which is exactly the "subtly wrong across twelve files" case the triad exists to catch. The higher the autonomy, the more the burden of specifying the task well shifts onto you, because vague instructions produce vague results, amplified.

A reusable triage shape for any "which leads deserve attention now" decision, drawn from signal-based selling. Rather than personalizing a long cold list, you tier incoming signals by how strongly each correlates with the action you want, and you act fastest on the strongest. One GTM engineer's working taxonomy: Tier 1 high-intent signals run 10–20x baseline conversion — a prospect on your pricing page, a G2 comparison-page visit, a job posting for a role your product supports — and the play is to reach out within roughly two hours, while the signal is hot. Lower tiers are weaker and decay fast; a generic "this account is showing surging interest" score sits near the bottom and is oversold.

It earns its place because it is the rare playbook with a number attached to the discipline: signal-based systems in that account reported 9.1% reply rates against a 2.3% cold-outbound average, a roughly 4x lift attributable to timing, not copy. The template generalizes past sales — it is a priority-by-decay-rate rule for any inbound stream. Where it breaks: the tiers are only as good as the correlation behind them, and most "intent data" is noise. Copy the structure, but re-derive your own Tier 1 from signals you have watched actually convert. Borrowing someone else's tier definitions is the idiosyncrasy trap in playbook form.

The repeatable three-stage move for turning a workspace-specific lesson or template into something reusable without hollowing it out. This is the answer to the idiosyncrasy problem the Understand section names, run as a process.

• Stage 1 — base. Write it concrete, with your real examples and your real machinery. This is the honest version, full of specifics, and it is also where all the idiosyncrasy lives.
• Stage 2 — enriched. Keep the same spine. Add the glossary callouts, the worked cost example, the side-by-side good/bad comparison — the layer that makes it teachable rather than merely correct.
• Stage 3 — agnostic. Hold the spine and the depth, but swap the vendor-specific parts for neutral equivalents. The reusable shell.

In the build that grounds this Handbook, that transform ran across a full teaching guide: a base draft full of real workspace examples, an enriched pass that held the same heading spine while adding beginner callouts and a worked cost example, and an agnostic rewrite that renamed the workspace's project-truth.md / working-notes / task-queue files to neutral overview.md / notes.md / todos.md and swapped the real examples for a generic persona. It earns its place because it makes de-vendoring a procedure instead of an act of taste. Where it breaks: the agnostic stage trades concreteness for portability. The neutral examples read lighter than the real ones, so the credible move for a published asset is to pull structure and ordering from the agnostic version and re-inject real specifics where the reader needs to see the thing actually work. Agnostic for the skeleton, concrete for the flesh.