93 Pocket Field Guide
94 How to Use This Book
The master grimoire is for depth. This pocket edition is for the desk, the backpack, the second monitor, and the incident room.
It keeps only what repeatedly earns its keep in real software work: the operative laws, the spell skeleton, six reusable engineering spells, the fifty world-running words, and a field canon of three hundred high-force runes.
Use it in three passes: first learn the cast levels, then steal the example spells, then browse the lexicon until the words begin to arrange themselves more deliberately in your prompts, reviews, and designs.
94.1 Inside
• Field doctrine — what makes a software word operative.
• Cast levels and the canonical spell skeleton.
• Workflow and pathologies for real AI-assisted engineering.
• A short note on sigils, seals, and coil inspection.
• Six ready-made software spells.
• The Fifty World-Running Words.
• A pocket lexicon of 300 high-force runes arranged by house and sigil range.
94.2 Master sigil map
[0001] Architecture, Abstraction, and Design [0001-0112] — Seams, layers, interfaces, models, and the shape of responsibility.
[0113] Language, Semantics, and Formal Shape [0113-0249] — How software means before it runs: syntax, type, parsing, compilation.
[0250] Data, State, and Representation [0250-0371] — The shapes in which meaning is stored, moved, and compared.
[0372] Transformation, Algorithms, and Working Verbs [0372-0511] — The actions that turn one shape into another.
[0512] Control Flow, Coordination, and Temporal Logic [0512-0608] — Time, waiting, ordering, retries, and concurrency.
[0609] Runtime, Memory, and Execution [0609-0684] — Where code lives while running and what it costs to keep it alive.
[0685] Systems Programming and Operating-System Words [0685-0770] — Kernel surfaces, files, processes, descriptors, and host bargains.
[0771] Networking and Distributed Systems [0771-0886] — Distance, coordination, consensus, routing, and failure across nodes.
[0887] Databases, Persistence, and Time-Binding Words [0887-0968] — Stored truth, transactional law, indexes, migration, and rollback.
[0969] Security, Trust, and Warding Words [0969-1063] — Identity, permission, secrecy, integrity, and defensive boundaries.
[1064] Build, Tooling, Versioning, and Release [1064-1139] — How software is assembled, tracked, tested, and shipped.
[1140] Testing, Verification, and Observability [1140-1210] — Evidence surfaces: tests, metrics, traces, profilers, and invariants.
[1211] Hardware, Embedded, and Performance-Near Words [1211-1290] — When software starts bargaining with silicon, buses, timing, and heat.
[1291] Interface, UX, and Human-Facing Words [1291-1350] — The names that shape attention, action, feedback, and usability.
[1351] Promptcraft, AI-Oriented Engineering, and Spell Structure [1351-1420] — Role, context, retrieval, verification, tools, and prompt form.
[1421] Guarantee Words and Quality Attributes [1421-1512] — The adjectives that claim durable behavioral law.
[1513] Failure Words, Pathologies, and Counter-Spells [1513-1582] — The names engineers use when systems lie, stall, diverge, or collapse.
[1583] Naming Runes, Affixes, and Compound Forms [1583-1645] — The modifiers that quietly shift design intent when attached to other words.
95 I. Field Doctrine
This pocket edition begins from a practical claim: some software words do more work than others. A normal word describes. A magic word compresses, constrains, invokes, protects, or exposes. It tells a compiler what law must hold, a reviewer what risk matters, a runtime what surface may be touched, or a model what shape an answer must take.
Software is unusually fertile ground for this because computing is built from named abstractions that must cooperate under strict conditions. A change to the word idempotent, linearizable, rollback, schema, policy, or timeout is not ornament. It is often a change to the system’s actual future.
95.1 Three sources of force
• Semantic density — A magic word compresses a large conceptual bundle into a small token.
• Invocation surface — The word matters because some person, compiler, runtime, database, reviewer, or model can respond to it.
• Positional force — The same word does different work in a prompt, a type signature, an API contract, a migration plan, or an incident report.
95.2 Five laws of the software magic word
• Compression — High-force words carry more concept than their length suggests.
• Placement — A word gains or loses force depending on where it is uttered.
• Adjacency — Good runes amplify or constrain one another; bad neighboring words create ambiguity.
• Verification — A spell is stronger when it binds itself to evidence and a checkable output shape.
• Shadow — Every powerful word casts a failure shadow: race shadows concurrency, drift shadows schema, leak shadows allocation.
95.3 The small practical definition
A software spell is a deliberately shaped instruction artifact that binds role, objective, context, constraints, procedure, output shape, verification, and failure behavior tightly enough that a human or machine can act with less ambiguity and less waste.
96 II. Casting Spells
The full anatomy of a spell has eight limbs, but not every task needs full ritual weight. The goal is not ceremonial verbosity. The goal is minimum adequate structure.
96.1 Cast levels
Quick cast — ROLE | OBJECTIVE | CONTEXT | VERIFY. Use for bounded explanation, review, drafting, and low-risk edits.
Working cast — ROLE | OBJECTIVE | CONTEXT | CONSTRAINTS | OUTPUT | VERIFY. Daily engineering form. Rich enough for real work without ceremonial overhead.
Full ritual — ROLE | OBJECTIVE | CONTEXT | CONSTRAINTS | PROCEDURE | OUTPUT | VERIFY | FAILURE. Use for migrations, refactors, releases, agentic workflows, and anything that can damage durable state.
96.2 Canonical spell skeleton
ROLE: [what expertise is being invoked]
OBJECTIVE: [what outcome matters most]
CONTEXT: [local facts already true]
CONSTRAINTS: [what must not break]
PROCEDURE: [how the work should proceed]
OUTPUT: [required answer shape]
VERIFY: [how truth will be checked]
FAILURE: [what to do if evidence is missing or unsafe]
96.3 From wish to spell
Weak — Design an API for billing.
ROLE: act as a backend architect designing a public billing API.
OBJECTIVE: produce a boring, versionable JSON API that supports invoices, payment attempts, refunds, and idempotent retries.
CONTEXT: mobile and web clients; PostgreSQL storage; slow client upgrade cadence; OAuth-based auth.
CONSTRAINTS: preserve backward compatibility, include pagination and error schema, prefer boring patterns over novelty.
OUTPUT: endpoint table, request/response examples, auth notes, idempotency notes, migration/versioning notes.
VERIFY: call out race conditions, retry hazards, and compatibility risks.
97 Workflow and common prompt pathologies
A useful spell can usually be repaired by walking the same sequence every time. Most prompt failure is not model mystery. It is missing structure.
97.1 Practical workflow
• Name the actor — Decide what expertise is being invoked.
• Bind the outcome — Say what success means in operational terms, not wishes.
• Load the local world — Versions, architecture, symptoms, traffic, dependencies, and facts already true.
• Constrain the motion — State what must not break, what is banned, and where the blast radius must stop.
• Choose the output shape — Diff, plan, checklist, test file, RFC, SQL, diagnosis table, benchmark plan.
• Demand verification — Require checks, edge cases, invariants, or measurements.
• Add failure behavior when risk rises — Tell the spell what to do if context is missing, contradictory, or unsafe.
97.2 Common pathologies and the repair that usually fixes them
Wish instead of objective — Replace ‘make this better’ with a measurable primary outcome.
Context starvation — Load the local world: versions, constraints, symptoms, runtime, and adjacent systems.
No constraint surface — Say what must not break, what may not be changed, and what dependencies are off-limits.
No output contract — Choose the answer shape so the model does not sprawl.
No verification — Require invariants, tests, traces, benchmarks, or validation queries.
No failure behavior — For risky work, specify what the model should do when evidence is insufficient.
False certainty — Separate observations from hypotheses and make assumptions explicit.
Overbroad autonomy — Bound the patch, the system surface, and the class of allowed actions.
98 III. Sigils, Seals, and Coil Inspection
The public field version keeps numeric spellcraft practical. You do not need to hand-compute prime exponents in order to benefit from canonicalization. What matters is that spells can be normalized, named, compared, versioned, and eventually tooled.
98.1 Three identifiers
• Human title — the readable name used in docs and conversation.
• Working seal — a short practical digest or stable token stream used in tools, repos, and prompt registries.
• Formal sigil — the canonical spell identity after normalization; useful for archives, diffs, and exact reproduction.
Use the human title in docs, the working seal in tools, and the formal sigil only when exact archival identity matters.
98.2 The clause circle
Field use does not require you to compute a Godel product by hand. The point of numeric spellcraft is stable identity, not ritual arithmetic.
Think of the seven active clauses on a prime circle — role, objective, context, constraints, procedure, output, verify — while failure behavior acts as a ward around the ring. Strong spells create useful antinodes: objective × verification and context × constraints.
If the coil looks broken, the prompt probably is. Empty objective? Hollow antinode. No verification? Wishful magic. No constraints? The spell leaks into side effects it never meant to summon.
Source diagram reference preserved for the generated visual grammar: media/image2.png.
Clause circle (p = 7). Inspection, not ceremony.
99 IV. Six Field Spells
These are ready-made working forms. Adapt the nouns, keep the structure, and insist on verification.
99.1 Spell of Safe Refactoring
Full ritual - Use when code quality must improve but public behavior must not move.
ROLE:
Act as a senior Python engineer performing behavior-preserving refactoring.
OBJECTIVE:
Refactor the supplied module to reduce duplication and improve readability without changing public behavior.
CONTEXT:
Python 3.12. The module runs inside a web API process and is called on every request.
Existing tests are incomplete. Function signatures are part of a stable public API.
CONSTRAINTS:
Do not add third-party dependencies. Do not change public names, parameter order, or return schema.
Preserve current logging side effects unless they are obviously duplicated.
PROCEDURE:
List invariants first. Identify duplication. Propose the minimal refactor and explain tradeoffs briefly.
OUTPUT CONTRACT:
Return: (1) short summary, (2) invariants, (3) unified diff, (4) revised code, (5) targeted test plan.
VERIFICATION:
Include empty-input, malformed-input, Unicode, and large-input cases. State why behavior is preserved.
FAILURE BEHAVIOR:
If behavior cannot be inferred from the code, say what is ambiguous and proceed with the safest minimal change.
99.2 Spell of Bug Diagnosis from Logs
Full ritual - Use when logs are real but certainty is not, and you need ranked hypotheses instead of performance theater.
ROLE:
Act as a production incident engineer diagnosing a backend failure.
OBJECTIVE:
Determine the most likely root causes of the supplied logs and propose the shortest safe path to confirmation and mitigation.
CONTEXT:
Stateless containerized API backed by PostgreSQL and Redis. Latency SLO is 250 ms p95.
A recent deploy occurred within the last hour.
CONSTRAINTS:
Do not assume facts not present in the logs. Separate observations from hypotheses.
Prefer reversible, low-risk mitigations and mention what to watch during mitigation.
PROCEDURE:
Extract timeline, cluster repeated errors, identify likely failure domain, and rank hypotheses.
For each hypothesis, give one confirming check and one mitigating action.
OUTPUT CONTRACT:
Return: (1) confirmed observations, (2) ranked hypotheses, (3) immediate mitigation options,
(4) confirmation steps, (5) rollback criteria.
VERIFICATION:
Tie every claim to a concrete log line or to the absence of an expected line.
FAILURE BEHAVIOR:
If the logs are insufficient, say what additional evidence would most reduce uncertainty.
99.3 Spell of API Design
Working cast - Use when the interface will outlive the first implementation and backward compatibility matters.
ROLE:
Act as a backend architect designing a public JSON API.
OBJECTIVE:
Design an API for the described resource model that is clean, versionable, secure, and observable.
CONTEXT:
Clients include web, mobile, and internal automation. OAuth-based authorization. PostgreSQL storage.
Backward compatibility matters because mobile clients update slowly.
CONSTRAINTS:
Prefer boring, maintainable patterns over novelty. Include pagination, error schema, idempotency where appropriate,
authorization notes, and migration considerations. Do not hand-wave failure modes.
OUTPUT CONTRACT:
Return: (1) resource model, (2) endpoint table, (3) example requests and responses,
(4) error format, (5) auth model, (6) migration and versioning notes.
VERIFICATION:
Call out edge cases, race conditions, and compatibility risks.
99.4 Spell of Migration Without Data Loss
Full ritual - Use when stored reality must change shape under live traffic and rollback still matters.
ROLE:
Act as a database migration engineer.
OBJECTIVE:
Plan a schema and data migration that preserves correctness, minimizes downtime, and has a clear rollback strategy.
CONTEXT:
PostgreSQL production database, high write volume, zero-downtime preference, mixed old and new application versions during rollout.
CONSTRAINTS:
Assume the table is large. Avoid long exclusive locks where possible. Preserve existing reads during rollout.
Include backfill strategy, validation queries, and rollback conditions.
PROCEDURE:
Describe the expand-and-contract sequence: schema changes, compatibility window, backfill, validation, cutover, cleanup.
OUTPUT CONTRACT:
Return: (1) migration phases, (2) SQL or pseudo-SQL snippets, (3) application changes required,
(4) validation checklist, (5) rollback plan.
VERIFICATION:
State how to verify row counts, nullability, foreign-key integrity, and read/write correctness at each phase.
FAILURE BEHAVIOR:
If downtime or lock risk cannot be avoided, say so explicitly and estimate where the risk concentrates.
99.5 Spell of Test Generation
Working cast - Use when behavior is partly implicit and you need tests that reveal assumptions instead of flattering guesses.
ROLE:
Act as a meticulous test engineer.
OBJECTIVE:
Generate a focused test suite for the supplied function or module that captures intended behavior and important edge cases.
CONTEXT:
The code may be partially undocumented. Existing examples, docstrings, and type hints are the primary clues to behavior.
CONSTRAINTS:
Prefer high-signal tests over high-count tests. Group tests by behavior. Avoid mocking unless boundaries require it.
Call out assumptions whenever behavior is not explicit.
OUTPUT CONTRACT:
Return: (1) inferred behaviors, (2) missing-behavior ambiguities, (3) the test file,
(4) a short rationale for each test group.
VERIFICATION:
Include nominal, boundary, error, and one regression-style case if appropriate.
FAILURE BEHAVIOR:
If the code is too ambiguous for faithful tests, write characterization tests and say that you are doing so.
99.6 Spell of Performance Tuning
Working cast - Use when you need ranked bets, measurement discipline, and permission to say ‘profile first.’
ROLE:
Act as a performance engineer.
OBJECTIVE:
Identify likely causes of latency or throughput loss and propose optimizations ranked by expected benefit versus risk.
CONTEXT:
The service has a strict latency budget and runs on commodity cloud hardware.
A profiler or benchmark may or may not be available.
CONSTRAINTS:
Do not recommend micro-optimizations before addressing algorithmic or I/O-bound issues.
Separate CPU, memory, allocation, database, and network effects. Mention measurement strategy.
OUTPUT CONTRACT:
Return: (1) bottleneck hypotheses, (2) what to measure, (3) optimization options ranked by expected payoff,
(4) benchmark plan, (5) rollback criteria.
VERIFICATION:
State how success will be measured and what regression risks need to be watched.
FAILURE BEHAVIOR:
If evidence is insufficient, say what profile, trace, or benchmark data would most improve the recommendation.
100 V. The Fifty World-Running Words
Read these until they start appearing by reflex in your prompts, reviews, designs, migrations, and incident reports. They are not the only runes that matter. They are the ones that keep real systems from becoming fog.
100.1 Boundaries, seams, and collaboration
[0001] abstraction — A deliberate forgetting of detail so larger structure can be reasoned about without drowning in mechanism. Shadow: hiding the only failure that matters.
[0002] adapter — A negotiated translator between unlike shapes. Use it when two systems must meet without infecting one another. Shadow: adapter jungles that preserve confusion rather than resolve it.
[0006] API gateway — A threshold that centralizes entry, policy, and routing at the edge of a service world. Shadow: a convenience chokepoint that quietly becomes a monolith.
[0012] boundary — The line that says where one responsibility ends and another begins. Shadow: porous edges that smear blame, ownership, and test scope.
[0013] bounded context — A protection against semantic bleed: the same word may not mean the same thing in every subsystem. Shadow: false unification through shared names.
[0030] coupling — The hidden tax paid when change in one place forces change elsewhere. Name it early if you want modularity to survive contact with reality.
[0034] dependency inversion — Stable policy should not kneel before unstable detail. Shadow: concrete dependencies hard-wired into places that should remain portable.
[0055] interface — A disciplined seam that lets unlike bodies cooperate without swapping internal organs. Shadow: tight coupling and type bleed.
[0347] schema — The declared shape of stored meaning. Shadow: drift, silent coercion, and backward-incompatible surprise.
[1152] contract test — A promise checked at the seam between systems. Use it when mocks are too flattering and end-to-end tests are too blunt.
100.2 State, durable truth, and reversibility
[1172] invariant — A law that must remain true while the rest of the system is allowed to move. If you cannot say the invariant, you probably do not yet understand the change.
[0926] migration — Stored reality changing shape without being lost. Good migrations are staged, inspectable, and reversible long enough to discover what the data actually contains.
[0898] commit — The moment a proposed change becomes durable history. Shadow: writing too early, before the world is actually ready to carry the new truth.
[0943] rollback — Permission to retreat toward a previously trusted state. A system without rollback mistakes hope for safety.
[0805] eventual consistency — Agreement postponed rather than denied. Shadow: stale reads treated as if they were fresh truth.
[0848] quorum — Not everyone must agree, but enough must. This word turns distributed action into a threshold question instead of a unanimous fantasy.
[1461] idempotent — The word that makes retries survivable: same request, same lasting effect. Shadow: duplicate charges, duplicate emails, and fear of recovery.
[1425] atomic — No halfway state is allowed to leak across the line. Use it when partial success would be indistinguishable from corruption.
[1445] deterministic — Given the same inputs, the same result should return. This is the antidote to drift, heisenbugs, and unreviewable behavior.
[1492] serializable — Concurrency forced to behave as though transactions happened in one clean order. Expensive when overused, indispensable when history must remain sane.
100.3 Runtime pressure, behavior, and operational physics
[1481] pure — Same inputs, same output, no hidden state smuggled in from the side. Use it to shrink reasoning scope.
[1462] immutable — Once written, this thing does not change in place. Immutability buys clarity, replayability, and safer sharing at the cost of update convenience.
[0576] retry — Failure does not necessarily end the ritual; policy may permit another attempt. Shadow: blind repetition against a broken precondition.
[0598] timeout — Waiting is not free and patience must have a boundary. A timeout is a contract with reality about how long uncertainty is allowed to persist.
[0825] latency — The delay before useful work reaches the caller. Latency is what users feel even when throughput graphs look flattering.
[1281] throughput — How much useful work the system can push through a narrow world in bounded time. Shadow: chasing bulk capacity while tail latency burns the user.
[0778] backpressure — Resistance pushed upstream when demand outruns capacity. Without it, overload spreads faster than truth.
[0615] cache — Keep likely things close so future cost falls. Shadow: stale truth delivered at machine speed.
[0684] zero-copy — Data movement stripped down to the minimum number of duplications. Use it when the bottleneck is physical movement rather than arithmetic.
[1472] memory-safe — A promise that the system will not casually trespass across allocation boundaries. Shadow: leaks, corruption, and security bugs born from illegal touch.
100.4 Observation, release, and proof surfaces
[1180] observability — Enough internal evidence exists that you can infer what the system is doing from the outside. Not logs alone: legible state under pressure.
[1202] telemetry — Measurements leaving the system in a form other systems can compare, store, and alert on. Shadow: metric exhaust without explanatory power.
[1204] trace — A preserved path through execution. Use it when the question is not only what failed, but where the causal thread first bent.
[1146] benchmark — A performance claim forced to meet measurement. Benchmarks are where speed rhetoric either cashes out or dies.
[1073] canary — A deliberately limited release whose job is to discover whether production reality agrees with the story told in staging.
[1086] deploy — The crossing from forge to world. Many good ideas become bad facts only after they are actually shipped.
[1088] diff — A visible account of what changed between one state and another. Good diffs make review local; bad diffs turn truth into fog.
[1186] property-based test — Instead of checking one remembered example, ask whether a law survives many generated cases. Use it when you care more about the invariant than the anecdote.
[0974] attestation — A proof that a thing is what it claims to be or was produced the way it claims. It matters most when trust cannot be assumed.
[1467] linearizable — Every operation behaves as though it took effect at one real instant visible to all observers. Use it rarely, but mean it fully.