Delivering Requirements Driven Work
Markdown--- name: delivering-requirements-driven-work description: Guides end-to-end execution of a deliverable (project, website, code, written content, etc.) from requirements analysis through research, planning, drafting, testing, refinement, and final delivery. Use when a user requests a complete deliverable that needs to be built, created, or produced, especially when scope, quality, or accuracy expectations are important and must be clearly communicated. ---
When a user asks for something to be built or created (a project, website, animation, code, document, etc.), work through the full lifecycle before declaring completion:
Progress:
- [ ] 1. Analyze requirements
- [ ] 2. Research & explore
- [ ] 3. Create initial plan
- [ ] 4. Build first draft
- [ ] 5. Test & review
- [ ] 6. Improve & refine
- [ ] 7. Deliver final result
Never skip straight to "done" — each stage must actually happen, and claims of testing/completion must reflect real verification.
1. Analyze requirements
- Restate the user's goal in your own words.
- Identify explicit requirements, implicit expectations, constraints (platform, format, audience, deadline), and success criteria.
- Flag ambiguities; make reasonable assumptions explicitly rather than blocking on questions.
2. Research and explore
- Look for existing solutions, libraries, patterns, or examples relevant to the task.
- Identify the best-fit tools/technologies/methods given the constraints.
- Note any tradeoffs discovered during research.
3. Create an initial plan
- Break the requirements into ordered, concrete steps.
- Choose specific tools/methods and justify briefly.
- Define what "done" looks like for this task.
4. Build the first draft
- Produce a complete, working first version — not a fragment.
- Prioritize covering all required functionality/content over polish.
- Note any shortcuts taken, to revisit during refinement.
5. Test and review
- Actually exercise the output: run the code, proofread the text, check links, verify logic, check compatibility/edge cases.
- Compare against the original requirements line by line.
- List concrete issues found (bugs, gaps, quality problems) — do not gloss over them.
6. Improve and refine
- Fix every issue identified in step 5.
- Fill missing details and polish quality (style, performance, clarity, robustness).
- Re-test anything that was changed.
7. Deliver the final result
- Present the completed work (files, code, content) clearly.
- Explain how to use/run/apply it.
- State explicitly what was tested and what was not.
- Call out known limitations, assumptions, or unfinished edges — never imply completeness or testing that didn't happen.
Example 1: Input: "Build me a simple to-do list web app with local storage." Output: Requirements analysis (add/remove/persist tasks) → research (vanilla JS vs. small framework, chosen: vanilla JS for simplicity) → plan (HTML structure, JS logic, localStorage API) → draft (working HTML/CSS/JS files) → test (add/remove/refresh persistence checked in browser, edge case: empty input) → refine (fix empty-task bug, add delete confirmation) → deliver (files + instructions to open index.html, note: not tested cross-browser beyond Chrome).
Example 2: Input: "Write a product description for a wireless headphone." Output: Requirements analysis (tone, length, key features, audience) → research (comparable product copy, feature terminology) → plan (outline: hook, features, benefits, CTA) → draft (full description) → review (check accuracy of claims, tone consistency, length limit) → refine (tighten wording, fix overstated claim about battery life) → deliver (final copy + note that battery-life figure should be verified against actual spec sheet).
- Always close the loop: draft → test → refine, even under time pressure.
- Be explicit and honest about what has and hasn't been verified.
- State assumptions made during requirements analysis instead of silently guessing.
- Tailor rigor to stakes: a quick script still gets a sanity check; critical/production work gets thorough testing.
- When delivering, separate "what was tested" from "what should be tested by the user."
- Declaring something "done" or "tested" without actually running/reviewing it.
- Skipping research and jumping straight to a draft, missing better existing solutions.
- Treating the first draft as final without a review pass.
- Fixing surface issues in refinement while ignoring requirements gaps found in review.
- Delivering results without usage instructions or without disclosing limitations.