Copy now, adapt freely
Prompts
Short, original instructions for the moments where a better question or process changes the quality of the work.
All resources
58 resultsGrill my feature idea
Expose unclear requirements and hidden decisions before implementation begins.
I have a feature idea that feels plausible but is not yet precise enough to build.
Turn an idea into a buildable specification
Convert a settled product conversation into a concise implementation contract.
The main decisions are understood and I need a specification another developer or agent can implement.
Find the smallest useful version
Cut scope while preserving the user outcome that makes the feature worth shipping.
A plan is growing faster than confidence and I need a smaller first release.
Write testable acceptance criteria
Turn ambiguous requirements into observable behaviors and designed edge states.
I need criteria that product, design, engineering, and QA will interpret the same way.
Find the assumptions most likely to hurt us
Rank product and technical beliefs by consequence and uncertainty.
A proposal sounds convincing but has not been challenged against real constraints.
Write a decision memo
Capture a consequential decision, its alternatives, and the conditions for revisiting it.
A team has made or is about to make a decision that future contributors will otherwise relitigate.
Break work into vertical slices
Create independently useful pieces of work with explicit dependency edges.
A feature plan is organized by technical layer and cannot be shipped or verified incrementally.
Plan the complete user flow
Design the populated, partial, empty, loading, failure, and recovery states together.
A feature has a happy path but its surrounding states are still implicit.
Map an unfamiliar codebase
Build a useful model of modules, data flow, boundaries, and domain language before changing code.
I need to understand how a repository fits together before planning or implementing a change.
Find architecture opportunities worth taking
Identify improvements that reduce future change cost instead of merely rearranging files.
A codebase feels harder to change and I need architecture priorities tied to real change costs.
Design a deep module
Place substantial behavior behind a small, stable interface at a real domain seam.
Related policy is leaking through callers or an abstraction exposes nearly as much complexity as it hides.
Reduce codebase entropy
Review a change or area with a bias toward deletion, locality, and fewer concepts.
Code looks organized but requires too many files, helpers, layers, or concepts to understand a simple behavior.
Define the project’s domain vocabulary
Create a shared language that improves naming, documentation, and agent comprehension.
The same concept is described with several terms or explanations are becoming verbose and inconsistent.
Write an architecture decision record
Record a technical choice as context, forces, consequences, and revisit conditions.
A technical decision will constrain future work and deserves durable repository context.
Plan a behavior-preserving refactor
Create a sequence of small structural changes with explicit regression protection.
The structure needs improvement but production behavior must remain unchanged.
Find boundaries that leak
Trace knowledge duplicated across consumers and locate the missing owner.
Several modules must understand another module’s internal rules to use it correctly.
Implement one vertical slice
Deliver a small end-to-end behavior with tests and repository-aligned structure.
I have an agreed slice and want it implemented without expanding the scope.
Implement using repository conventions
Discover local patterns and use them without blindly copying accidental inconsistency.
I need a change to feel native to an unfamiliar or mature codebase.
Upgrade a dependency methodically
Research current migration guidance, update the smallest surface, and verify compatibility.
A library or framework version needs to change without introducing unrelated modernization.
Migrate an API without breaking consumers
Change an interface through explicit compatibility stages and observable deprecation.
A public or internal contract needs to evolve while existing callers still rely on it.
Implement faithfully from a specification
Build the agreed behavior while tracking every acceptance criterion and resisting scope drift.
A specification is settled and implementation should be judged against it.
Preserve behavior during refactoring
Refactor with characterization, small transformations, and continuous proof of equivalence.
I want structural improvement only, with no intentional product change.
Implement behind a feature flag
Ship dormant behavior with clean ownership, fallback, and removal criteria.
A change must deploy separately from its release or needs controlled exposure.
Review an implementation before calling it finished
Audit a completed change against intent, repository standards, and forgotten states.
The code appears complete and I want a final engineering pass before handoff.