Prompt specification
Build the prompt in six layers
Complete each layer with facts from the product. Ask the tool to identify missing information rather than inventing business claims.
Outcome
Who is trying to do what, and why now?
ConstraintOne primary audience and one observable job
Useful inputA clinic manager compares three staffing scenarios before approving next month’s rota
Evidence
What real material should shape the result?
ConstraintNo invented customers, metrics, testimonials or capabilities
Useful inputUse these product screenshots, approved claims, terminology and known limitations
Journey
Which steps, decisions and recovery states exist?
ConstraintInclude loading, empty, invalid, denied, failed and successful states
Useful inputCompare, select, confirm, then recover from an unavailable data source
System
Which technical and ownership boundaries are fixed?
ConstraintUse the existing stack and keep privileged decisions server-side
Useful inputNo new dependency without justification; organization-owned environment variables only
Design
Which hierarchy and brand decisions are intentional?
ConstraintUse cards only for comparable items and avoid decorative effects without a role
Useful inputLead with a real output, use this type scale and these approved assets
Verification
How will another person decide the result is acceptable?
ConstraintProvide focused tests and a manual journey; do not self-certify security or compliance
Useful inputRun named commands, record limitations and show one negative-path result
Prompts should reduce invention
Replace style adjectives with product constraints
‘Make it premium, modern and high-converting’ gives no stable acceptance condition. Describe the decision the visitor faces, the proof they need, the content hierarchy and what the interface must never imply. Then provide references for function and information—not screenshots to imitate without understanding.
Prompt in stages when the unknowns are large: ask for a plan and open questions, review the proposed data and component boundaries, then authorize a small implementation. This keeps mistaken assumptions visible before they become a large diff.
- Ask the tool to list assumptions before coding
- Use real content early enough to shape layout
- Define non-goals and prohibited data
- Require a change summary and unresolved risks
Decision matrix
Rewrite vague instructions into testable ones
The right column does not prescribe every implementation detail; it makes the product decision observable.
| Vague request | Hidden ambiguity | Better instruction | Acceptance evidence |
|---|---|---|---|
| Make it look less AI | No definition of distinctiveness or audience | Use the supplied product artifact as the main visual and vary structure by content role | Competitor comparison and comprehension test |
| Add secure login | Roles, recovery and enforcement are undefined | Use the approved provider; enforce organization membership server-side and test two tenants | Negative cross-tenant request fails |
| Make it responsive | No journeys, widths or content extremes | Preserve navigation, form use and reading order at narrow width and enlarged text | Named viewport and zoom checks |
| Improve SEO | Intent, canonical and content value are unspecified | Target this decision, render the answer, use one canonical and link from the hub | Rendered HTML, metadata and internal crawl path |
| Handle errors | Failure classes and recovery are unknown | Separate invalid input, denied access, temporary dependency failure and unknown server error | Each state has safe copy, logging and retry behavior |
Applied example
Prompt example: from generic dashboard to reviewable slice
The original prompt says: ‘Build a modern analytics dashboard with charts, login and a database.’ It produces a polished page, invented metrics and client-side role hiding.
- The audience, decision and authoritative data are missing.
- ‘Login’ does not define authorization or organization boundaries.
- The tool fills absent evidence with plausible content and familiar components.
- A layered prompt could first implement one real metric, two roles and empty, loading, denied and failed states.
Plain answers
Prompt questions
Is there one perfect vibe-coding prompt template?+
No. A reusable structure helps, but the valuable content is product-specific evidence, boundaries, states and acceptance conditions.
Should I tell the tool which framework to use?+
Specify the existing stack or a justified constraint when it matters. Avoid choosing technology only because a generated example used it.
Can a detailed prompt replace code review?+
No. The implementation can misunderstand, omit or violate the prompt. Review and testing evaluate the delivered behavior.