How to prompt

With your context layer built, prompting gets simpler, not harder. The goal of a prompt is no longer to carry every convention, just to define the task. The concept to hone is delegation: spend more time on a good initial prompt so you can walk away.

Be as specific as you would be writing a spec for a coworker. A strong prompt has four parts:

1. Context: what you're trying to do and why. ("Users report X on the checkout page…")
2. Step-by-step expectations: sequence, constraints, what not to touch.
3. Success criteria: what does "done" look like, ideally verifiable without your judgment (tests pass, build green, behavior works as specified).
4. Explicit references: file paths, function names, similar PRs, and wiki links, plus your new tools: /skill-name to invoke a skill (with arguments if it takes them), !macros for any playbooks your team still runs, and ticket links via integrations.

What shouldn't be in the prompt anymore: anything that's true for every task. If you're restating the ui-kit convention or the mock-API setup step, move it into a rule or a skill and delete it from the prompt. Lean prompts plus rich context beat mega-prompts every time.

Scoping guidance (the ACU half): one clearly scoped task per session. Split big projects into sub-tasks. Scope in Ask/Plan mode before spending ACUs on a session. Provide comprehensive details in the first instruction rather than drip-feeding corrections; each follow-up extends the session and adds cost.