Turn Intent Into a Build Specification

You do not need to disguise a business problem as an architectural solution. Your most valuable input is often knowing who performs the work, what arrives, which judgment matters, what can go wrong, and what makes the result useful. Claude can help locate technical seams; it cannot recover business meaning that was never stated.

Describe the workflow in the language of evidence and consequences. Instead of asking for an AI dashboard, explain that an operations manager receives incomplete requests in three channels, must compare them with a policy, and needs a reviewable recommendation before Friday. This gives the agent a problem to model rather than a fashionable interface to imitate.

An outcome describes the observable change for a person. An implementation describes how the system might create it. Keep them separate so Claude can inspect existing patterns before introducing new components. If the repository already has authentication, storage, or form primitives, the safest solution may reuse them rather than follow your guessed stack.

Constraints and non-goals prevent useful exploration from becoming uncontrolled expansion. State what must remain compatible, which files or services are out of scope, whether new dependencies are allowed, and which actions require approval. Naming what the first version will not do is often more powerful than adding another feature requirement.

A useful task packet contains enough context to execute but not every fact in the organization. Point to the canonical files, current behavior, representative examples, and existing pattern the agent should follow. Include the exact error or screenshot when behavior is broken. Ask Claude to inspect referenced sources rather than repeating their entire contents in the prompt.

Acceptance criteria should be observable. `Make it robust` is not a test. `A signed-out user receives a 401, the session is not created, and the existing authentication tests remain green` gives Claude and the reviewer a shared finish line. Include normal, missing-data, permission, and failure cases proportional to the risk of the change.

Anthropic's best-practices guidance recommends separating exploration and planning from implementation for work whose shape is uncertain. In plan mode, ask Claude to trace the current path, identify affected files, surface tradeoffs, and propose tests without editing. Review the model before paying the cost of code changes.

Then switch to implementation with the accepted plan and require the checks in the same request. Finish by reviewing the diff against the original task packet, not merely the plan Claude wrote for itself. A plan can be internally coherent and still drift from the user's outcome; the initial acceptance criteria remain the authority.

For a larger feature, ask Claude to interview you before writing the specification. Good questions expose states, edge cases, permissions, mobile behavior, failure recovery, and tradeoffs that a short idea omits. Ask it to avoid obvious questions and keep going until the hard decisions are explicit, then save the result as a file that a fresh implementation session can use.

During execution, interrupt early when the work moves outside the boundary. Correcting one mistaken assumption after the first file is cheaper than reviewing ten files built on it. If the same misunderstanding survives two corrections, start a clean session with a revised written brief instead of compounding a confused conversation.