Dev playbook

Different models have different failure modes. Recording `model` on a tip lets the next reader (human or assistant) calibrate trust: reasoning-heavy models may over-engineer; fast models may skip edge cases.

When you paste a tip into another tool, append the model you used there too—future you can diff "Sonnet suggested X" vs "GPT refined Y" without guessing.

End each playbook entry with an optional `addendum` in git: what changed when you ran the same idea through a different model or IDE. The playbook isn't scripture—it's a conversation log.

In PRs, tag commits with `playbook:` when you append tips so reviewers know prose changed without hunting.

Put stack, file layout, and non-negotiables in `.cursor/rules` (or your editor's equivalent). The model stops re-deriving "how we do CSS" every session.

Keep rules short and scannable; link out to longer docs instead of pasting novels.

Encode repeatable flows (e.g. "run probes, then summarize") in `.cursor/commands`. Copy the same markdown to `~/.cursor/commands` if you want them globally.

Commands are free documentation: new collaborators read the steps before they run them.

Open the files that actually matter, @-mention symbols, paste the error verbatim. The best edit is the one grounded in the buffer you meant—not the whole monorepo guessed from vibes.

If the model drifts, reset: smaller prompt, fewer files, one outcome per message.

L0: surface/route smoke. L1: build artifacts or static HTML contracts. L2: crawls, Lighthouse, lint matrices. L3: real browser behavior. Skip ahead only when the cheaper layer already passes or the risk demands it.

Teach assistants to announce which layer they're using—stops "run every test" panic on typo fixes.

If a class of bug escaped once, add the smallest check that would have caught it. If it escaped twice, promote it to CI or a mandatory pre-push script.

Prefer stable selectors (ids, data attributes, canonical URLs) over brittle full-page snapshots unless you own the churn.

"Make it nice" fails; "use existing button classes, no new colors, WCAG AA contrast" succeeds. Translate taste into inspectable requirements.

Use the Chatbot Instruction Copier pattern: one block the user pastes so every assistant gets the same contract.

Let agents read, test, and propose diffs; keep `rm -rf`, force-push, and production deploys as typed confirmations from a human.

If your tool supports it, separate "plan" from "execute" modes—review the plan in plain language first.

Prototype fast where mistakes are cheap (UI polish, internal tools). Slow down where mistakes are expensive (auth, money, migrations, user data).

Document the boundary aloud in chat: "we're in spike mode" vs "this ships to prod."

Boring names and straight-line flow beat clever abstractions unless the abstraction deletes real duplication.

When AI generates dense code, ask for a second pass whose only job is readability—same behavior, fewer surprises.

Each tip renders as <details id="tip-{id}">. Share `…/developers/playbook/#tip-mp-001` when you want someone to land on one card. They may need to expand the section and nested tip—browser support for :target on closed details varies, so prefer sending the URL plus the tip title in chat.

Use Copy tip on the card when you want plain text in Slack or another model without retyping metadata.

The tag filter matches a single tag at a time; combine it with search for finer slices (e.g. tag `safety` plus search `git`).

When adding tips, reuse existing tags when they fit—new tags should be short, lower-case, and hyphenated if multi-word.