Fergius-Engineering

de-ai-prose

Use before showing any prose a human will read - docs, README, commit bodies, UI copy, store text. Run a read-back pass and cut the tells that make writing sound machine-generated, so it reads like a person wrote it.

logging-for-remote-diagnosis

Use while building any mechanic that could fail on a machine you can't reach - a shipped product, a CLI a user runs, a server. Instrument it as you write it so that one verbose log dump from a stranger is enough to reconstruct what happened.

opportunistic-fixes

Use when you notice an incidental correctness problem (a stale comment, a wrong doc line, a drifted reference) in the area you're already editing - surface it and get the user's OK before fixing it, and stay inside the area you're already touching.

tests-with-teeth

Use whenever you write or review a test. A test that still passes after you delete the feature it covers is hollow. Run the five questions before accepting any test.

using-instincts

Read once when starting work in a project that has the instincts plugin installed - explains that instincts is the reflex layer on top of superpowers and points to the individual instinct skills

critical-thinking

Use when about to build something someone proposed (especially a confident user) - run the idea through one concrete example first. If the example exposes a flaw, stop and say so before writing any code.

entry-point-audit

Use before adding any cross-cutting change - a new gate, limit, permission check, or rule that must apply everywhere. Find ALL the places the action can happen first, not just the obvious one in front of you.

feasibility-guard

Use before building or agreeing to build something - push back when the work is unnecessary, over-complex, fragile, or heavier than the value it returns. Saying "skip this" or "simpler is enough" is part of the job.

fix-in-the-shared-layer

Use when you hit a bug while building on your own shared code - a library, base class, SDK, or component. Fix it in the shared layer so every other caller inherits the fix, instead of patching around it in the one spot that surfaced it.

fix-the-root-cause

Use when fixing any bug - find the layer that creates the bad state and fix it there, instead of patching the symptom where it happened to surface.

independent-review-gate

Use before you call complex or shippable work done - get a fresh, independent review of the whole change. Your own pass plus green tests is not enough; you read past your own mistakes.

project-onto-all-systems

Use when adding or changing any feature - project it onto every part of the system it touches (cache, notifications, persistence, undo, permissions, search, tests), not just the code directly in front of you.

question-the-premise

Use when stuck after several failed fixes on the same hypothesis - step back and question whether you're fixing the right layer at all, before trying the next fix. Being data-driven inside a wrong frame still fails.

user-action-edge-cases

Use before finishing anything that depends on external state a person controls - a file, an asset, a record. Walk through what happens if they rename it, move it, delete it, or duplicate it.

verify-against-code

Use when about to assert any factual claim about what code or a product does - in an answer, a doc, a commit message, or anything a user will see. Confirm the claim against the primary source before stating it; never trust memory, the user's framing, plan headers, or doc tables on faith.