The field guide
What each principle looks like in the work.
Use the example prompts as structures, not scripts. Replace the situation, evidence, constraints, and checks with the reality of your product.
A request such as “add an AI assistant” is already a proposed solution. Direction starts one level earlier: who is struggling, what are they trying to accomplish, and what decision must the work enable?
- Best for
- Feature requests, roadmap choices, workflow redesign, unclear bugs
- Point in flow
- First—before research, architecture, or implementation
Give the system
- The affected user and situation
- Observed friction or evidence
- The outcome that matters
- What remains unknown
Expect back
- A restated problem, not instant code
- Assumptions that need validation
- Several viable approaches
- A decision or research question
Example prompt“Trial users abandon setup before importing their first résumé. Review the current journey and evidence. What problem is most likely blocking activation, what else should we verify, and which interventions are proportionate?”
AI without current context optimizes for plausibility. Maintain a compact source of truth so requirements, architecture, prior decisions, evidence, and prohibitions travel with the task.
- Best for
- Long builds, unfamiliar codebases, research synthesis, parallel agents
- Point in flow
- Before direction, refreshed whenever the state changes
Give the system
- Relevant files and current behavior
- Decision history and rationale
- User or production evidence
- Known risks and non-negotiables
Expect back
- References to actual system state
- Fewer repeated discoveries
- Explicit conflicts or missing context
- Decisions consistent across sessions
Example prompt“Read the product brief, authentication decision record, route map, and current tests. Summarize the constraints that govern this change and identify any contradiction before proposing work.”
Expertise creates a subtle failure mode: you know enough to suggest a credible fix, so the system never explores whether it is the right fix. Questions create room for dependencies, alternatives, and second-order effects.
- Best for
- Architecture, authentication, vendors, UX patterns, performance
- Point in flow
- After framing the problem, before selecting an approach
ASK“Given our current authentication and account-linking behavior, what is the safest way to reduce sign-in friction? What could each option break?”
Example prompt“Users are waiting too long for generation. Investigate where time is spent, distinguish perceived from actual delay, and compare product and technical interventions before recommending one.”
A session should have one outcome that can be reviewed as a whole. Combining unrelated cleanup, new behavior, and design revisions makes failure harder to locate and approval harder to give.
- Best for
- Features, bug fixes, refactors, migrations, content systems
- Point in flow
- When turning a plan into an execution session
Give the system
- One named outcome
- Included and excluded scope
- A small file or interface boundary
- A stop condition
Expect back
- A reviewable change set
- No opportunistic rewrites
- A focused test result
- A clear handoff before expansion
Example prompt“Implement only the expired-session state in checkout: detect it, explain it, and provide a safe retry. Do not redesign checkout or alter payment creation. Stop after the path and its tests pass.”
“Make it better” invites the model to choose the standard. State the observable outcome, the behavior that must survive, and the evidence that will allow you to accept the work.
- Best for
- Production changes, integrations, performance work, design revisions
- Point in flow
- In the brief, before implementation begins
Give the system
- Observable success criteria
- Protected behavior and data
- Technical or policy constraints
- Required validation environments
Expect back
- Traceability from change to criterion
- Explicit tradeoffs
- No silent scope expansion
- Evidence for each acceptance check
Example prompt“Reduce mobile onboarding to one clear decision per screen. Preserve saved drafts, keyboard navigation, analytics names, and the desktop flow. Validate at 390px and 1440px with no horizontal overflow.”
A list of intentions is not a plan. An executable plan connects the outcome to specific interfaces, files, ordering, risks, acceptance checks, and recovery steps.
- Best for
- Cross-file work, APIs, migrations, infrastructure, risky refactors
- Point in flow
- After choosing an approach, before any mutation
A usable plan names
- Files, routes, schemas, and owners
- Dependencies and sequence
- Failure modes and rollback
- Tests tied to acceptance criteria
Reject a plan when
- Steps say only “update” or “improve”
- Risky data movement is implicit
- Validation happens only at the end
- No one can tell when it is done
Example prompt“Produce an implementation plan for adding saved job targets. Name the data model, API contract, UI states, migration sequence, affected tests, privacy risk, and rollback path. Do not edit files yet.”
The same agent that invents a plan is biased toward defending and completing it. Keep research, approval, execution, and review distinct enough that assumptions can be challenged before they become product behavior.
- Best for
- High-risk changes, parallel work, unfamiliar domains, multi-agent delivery
- Point in flow
- Across planning, execution, and approval
1ResearchInspect reality
→2DirectChoose and brief
→3BuildExecute scope
→4ReviewChallenge result
Example taskOne instance maps the payment flow and writes the approved brief. A separate builder implements it. A third pass reviews security and regression risk. The human decides whether the result ships.
Small does not mean arbitrary. A good slice crosses the system far enough to prove value—interface, backend, data, and feedback—without carrying the whole roadmap at once.
- Best for
- New workflows, migrations, refactors, uncertain product bets
- Point in flow
- During sequencing, implementation, and release
Slice 1Create one job target and show it back.
Slice 2Use that target to generate one grounded recommendation.
Slice 3Add editing, failure recovery, and broader coverage.
Example prompt“Find the smallest end-to-end slice that proves saved job targets are useful. It must be deployable, observable, and reversible. Defer bulk import, sharing, and recommendation history.”
A general “review this” prompt tends to produce a general reassurance. Separate reviews by responsibility so each pass has permission to notice a different class of failure.
- Best for
- Payments, auth, personal data, integrations, major releases
- Point in flow
- After focused tests pass, before release approval
CorrectnessDoes behavior match the brief and edge cases?
ProductDoes it solve the intended user problem coherently?
RiskCan it expose data, lose work, or fail insecurely?
MaintenanceDoes it fit the system without creating a future trap?
Example prompt“Review this change only for regression risk. Trace callers, state transitions, error paths, and existing tests. Do not suggest style improvements unless they create a concrete failure.”
Passing functions can still produce a broken product. Exercise the journey with real rendering, realistic data, latency, validation errors, small screens, keyboard navigation, and recovery paths.
- Best for
- Forms, onboarding, checkout, responsive UI, generated content
- Point in flow
- After code-level tests, before release
Walk the happy path
- Can a user recognize the next action?
- Does the result match their intent?
- Is progress and completion visible?
Walk the awkward path
- Empty, slow, expired, and partial states
- Small screens and keyboard-only use
- Retry, cancellation, and safe recovery
From the buildA payment flow once passed automated checks and still failed in a live demonstration. The rule became simple: critical user journeys must be exercised in the rendered product, not inferred from green tests.
Fixing the visible symptom restores today. Capturing the root cause and adding a guardrail improves every future session. The incident is not complete until the system learns.
- Best for
- Regressions, lost work, hallucinated content, outages, repeated mistakes
- Point in flow
- After containment, before returning to feature work
IncidentGenerated testimonials appeared without real customers.
Rule: never invent evidence or social proof. IncidentA destructive Git operation erased another session’s work.
Rule: inspect shared state and require approval before destructive actions. IncidentA narrow patch fixed one case and broke two others.
Rule: identify root cause and test adjacent behavior before patching. Example prompt“Do not patch yet. Reconstruct the failure, identify the earliest incorrect assumption, explain why existing checks missed it, and propose the smallest durable test or rule that prevents recurrence.”
The next session should not reverse-engineer the previous one. End with a compact handoff that distinguishes verified fact, chosen direction, unfinished work, and open uncertainty.
- Best for
- Long tasks, handoffs, context limits, parallel agents, interrupted work
- Point in flow
- At every meaningful stop, before context is lost
ChangedWhat is now different and where.
WhyThe decision and evidence behind it.
VerifiedTests run and behavior observed.
OpenRisks, unknowns, and the exact next action.
Example prompt“Write a handoff for a new session. Separate completed work from assumptions. Include changed files, decisions, validation evidence, unresolved risks, and the next bounded task. Do not claim anything you did not verify.”
Delegation does not transfer accountability. The human decides what deserves to exist, which evidence is sufficient, what risk is acceptable, and whether the result represents the product honestly.
- Best for
- Prioritization, tradeoffs, scope, release decisions, claims and ethics
- Point in flow
- At every decision gate—from premise to production
AI can
- Surface options and consequences
- Implement an approved direction
- Find inconsistencies and risks
- Produce evidence for review
The auteur must
- Choose the problem and quality bar
- Reject attractive but wrong output
- Protect users and truthful claims
- Accept responsibility for shipping
Release question“Given the original user problem, the evidence collected, the unresolved risks, and the behavior we observed, should this ship now? Present the case for and against. I will make the decision.”