IamK77

assay

Plan, write, and harden tests with a risk-driven decision tree: choose what to test, the right test type, the right test double, and the cases that actually catch bugs. Use when the user wants to test code; asks what or how to test a function, module, API, or system; mentions unit, integration, end-to-end, property-based, contract, or characterization tests, edge cases, mocks or fakes, flaky tests, or coverage; or says things like "help me test this", "what should I test", "write tests for X", or "I just fixed a bug".

Code & Development Listed

flightline

Set up or harden a project's engineering process so quality has an automated floor instead of depending on anyone's discipline — version control & branching, code style, code review, CI/CD, and dependency/build management — tuned for a world where agents write much of the code and have no self-discipline to fall back on. Use when the user is bootstrapping or improving a team's workflow, choosing a branching strategy, setting up CI/CD or pre-commit hooks, defining a code-review process, enforcing lint/format, managing dependencies or reproducible builds, or fixing onboarding. Triggers on "set up CI", "git workflow / branching strategy", "how should we do code review", "add pre-commit hooks", "our builds aren't reproducible", "make this project team-ready".

gauge

Engineer a codebase's feedback surface so an agent gets clear feedback at every step — fast, local, attributed, deterministic, and hard to fake green — instead of flailing against late, opaque, or false-green signals. Set up the strict type layer, boundary validation, errors-as-values, structured failures, observability, and the gates that make the signal trustworthy. Use when the user wants a project to give the agent a "static-language / Rust-like hand-feel", asks to set up strict typing (pyright/mypy/tsc), add boundary validation (pydantic/zod), make failures legible, stop an agent guessing, or harden the feedback the codebase produces. Triggers on "clear feedback for the agent", "Rust-like hand-feel in Python/TS", "set up strict typing", "make failures legible", "the agent keeps flailing".

groundwork

Discover and pin down what to build before building it, with a gated five-stage flow: elicit the real need (not the stated solution), analyze and prioritize, write verifiable requirements, validate shared understanding, and manage change. Use when the user asks for a feature, system, or change — especially a vague or solution-shaped one ("add an export button", "make it faster", "build me an X"); mentions requirements, specs, user stories, acceptance criteria, scope, stakeholders, MoSCoW, or non-functional needs; or before you start coding anything non-trivial whose real goal is not yet nailed down.

load-bearing

Design a system's architecture for the agent-assisted era: choose the architecture style, the stack, the module boundaries, the contracts, and the data model — concentrating scarce human judgment on the irreversible decisions and letting agents move fast behind the reversible ones. Use when the user is designing or restructuring a system, choosing between monolith and microservices, picking a tech stack or database, defining APIs or module boundaries, deciding how to realize non-functional requirements (scale, availability, security), writing an ADR, or about to build something structurally non-trivial. Triggers on "design the architecture", "what stack should I use", "monolith or microservices", "how should I structure this", "design the data model / API", "system design".