using-97 · diff
git:20260506.2d8f99a to git:20260506.bf59116
12 added, 3 removed. Audit A to A.
---
name: using-97
description: Use when starting any coding task — establishes the 97 trigger map so principles fire when relevant
---
## Overview
**97** distills principles from the hard-won lessons of world-renowned programmers into trigger-based skills, in the spirit of *97 Things Every Programmer Should Know* (O'Reilly, ed. Kevlin Henney; CC-BY-3.0 originals at https://github.com/97-things/97-things-every-programmer-should-know). You have eleven themed skills plus this bootstrap. Each one activates on a specific situation — refactoring, writing tests, designing an API, committing — and brings the relevant principles to bear. Per-skill `principles.md` files list every source. Unofficial companion, not affiliated with O'Reilly or any contributor.
+ ## **CRITICAL: invoke matching skills BEFORE any response or action**
+
+ When a user message matches a row in the Trigger Map, you MUST invoke the named skill before taking any other tool action and before writing your reply. Use the `Skill` tool with the **bare skill name** (e.g. `before-you-refactor`). This rule is not negotiable: even a 1% match means invoke. The skill carries the checklist; skipping it means doing the work the default way and losing the point of having 97 installed.
+
+ The trigger fires on user words, not on file size or task complexity. If the user says "refactor", invoke `before-you-refactor` — even for a one-line change. If the user says "clean", "test", or "commit", invoke the matching skill. Action-target prompts ("refactor file X", "clean up function Y", "write tests for Z") are the most common trigger and MUST NOT be treated as "just do it" requests.
+
## Trigger Map
- When the situation matches, invoke the named skill **before** you act. Use the `Skill` tool with the **bare skill name** (e.g., `before-you-refactor`). When in doubt, invoke.
| Skill | Trigger |
|---|---|
| `writing-clean-code` | Adding a new function/class, naming a new entity, or modifying ≥3 lines of non-trivial logic (NOT typos, config, or test code) |
| `before-you-refactor` | About to refactor, restructure, rename across files, or "clean up" existing code |
| `testing-discipline` | Writing tests, designing test data, naming a test, choosing what to assert, or writing test helpers/mocks/fixtures |
| `api-and-interface-design` | Designing a public API, exported function signature, module boundary, exported type, or any contract other code depends on |
| `pre-commit-self-review` | About to commit, finish a task, open a PR, summarize work, or when asked for a review or hand-off |
| `error-and-correctness-traps` | Writing error handling, comparing/calculating with floats, writing concurrent code, calling a remote process, adding a singleton/global, choosing a data structure for a hot path, or adding/changing log statements |
| `security-and-trust-boundaries` | Parsing user input, writing/executing SQL or shell commands, handling secrets/tokens/credentials, hashing passwords, adding/changing an auth check, deserializing untrusted data, or constructing file paths/URLs from input |
| `observability` | Adding a request handler, RPC, or background job that will run in production; adding tracing, metrics, or structured-log calls; or making cross-process diagnosability decisions |
| `build-deploy-and-tooling` | Authoring/changing build scripts, CI config, deploy pipelines, repo setup, or evaluating a new tool/dependency for adoption |
| `domain-modeling` | Introducing a new top-level type/table/domain concept, renaming a domain concept, or deciding where state lives |
| `working-with-users-and-team` | Gathering or interpreting requirements, estimating effort, or communicating with stakeholders about what to build |
## Priority
1. Your human partner's instructions (CLAUDE.md, GEMINI.md, AGENTS.md, direct prompts) override everything below.
2. **Process skills (superpowers) run before content skills (97).** `superpowers/test-driven-development` decides *whether* to write a test; `97/testing-discipline` decides *what makes it good*. `superpowers/verification-before-completion` decides *did it work*; `97/pre-commit-self-review` decides *is it well-considered*.
3. **More specific 97 skill > broader 97 skill.** `before-you-refactor` wins over `writing-clean-code` when both could apply. `testing-discipline` wins over `writing-clean-code` for test code.
4. **Before editing a file you haven't read this session, read it first.** No skill load — just the cheap reminder. Editing without reading is the most common avoidable failure mode.
5. **When debugging, defer to `superpowers/systematic-debugging` if available.** Otherwise fall back to `error-and-correctness-traps` for trap-shaped bugs and `pre-commit-self-review` step 2 (suspect your own code first) for general debugging.
6. **Apply principles silently.** Do not surface source author names, book titles, or principle IDs (e.g. `97/74`, `Fowler/LongMethod`) in user-facing responses. Citations exist for repo provenance, not for user-facing authority.
7. **Match principle weight to stage and stakes.** Production-shaped guidance — resilience patterns (timeouts, circuit breakers, bulkheads), observability instrumentation, deploy hygiene, security boundaries — fires hardest when code is reaching real users in production. In MVPs, prototypes, internal dev tools, debugging endpoints, and one-off scripts, prefer the simplest thing that works. Do not retrofit production discipline onto code whose architecture is not yet settled.
## Red Flags
+ These thoughts mean STOP — invoke the matching skill instead of acting:
+
| Thought | Reality |
|---|---|
- | "The trigger almost matches but not quite." | Almost-matches are the easiest to rationalize past. Invoke and let the skill tell you it doesn't apply. |
+ | "This change is small enough that I'll just do it." | Small changes are exactly where the discipline pays off. Invoke. |
+ | "The user gave me a concrete file or function — I should just go edit it." | Action-target prompts are the most common trigger, not an excuse to skip. Invoke first, then act. |
+ | "I don't need the skill — I already know this one." | Skills evolve and the checklist matters. Invoke and read the current version. |
+ | "The trigger almost matches but not quite." | Almost-matches are the easiest to rationalize past. Invoke; the skill will tell you if it doesn't apply. |
| "Two skills could fit; I'll just pick one." | Priority rule 3 — more specific wins. Invoke that one. |
- | "I read this skill last session, I remember it." | Skills evolve. Invoke and read the current version. |
Principles are distilled in our own words from CC-BY-3.0 originals. Plugin code is MIT; see `CONTENT-LICENSE.md` for attribution and takedown policy.