How do I take a feature from idea to launch?
When the requirement is vague and time is short, the tempting move is to ask AI for code right away. This workflow keeps the uncertainty in the early steps and closes it with tests and a config check.
How to do it
Turn the raw requirement into entities and states
Paste the requirement as written into 'Turn a requirement into a data model' and don't ask for code yet. Have it list the entities, relationship cardinalities, the core object's state machine, and the fields that will almost certainly change within six months, such as price, permissions, and soft deletes. It should end with three questions you must take to the product owner; until those are answered, every later split is built on guesses.
Split the work by contract, not by layer
Hand the entities and state machine from step 1 to 'Split the Work So It Can Run in Parallel', along with team size. It should mark the ordering constraints first (data model, API contract, migration), then cut the rest into units one person can deliver and verify in a week, each with inputs, outputs, and acceptance criteria, plus the shared files most likely to collide.
Close the test gaps before code review
Once the code runs, paste the implementation and existing tests into 'Find the gaps in your tests'. Focus on the uncovered branches it lists, rank the top five cases by production impact, and write the input and expected result for each. Delete duplicate tests and tests that assert implementation details; they only add maintenance cost.
Map what the change can break before launch
Give the diff, the caller list, and traffic volume to 'Map the Blast Radius of a Change'. Ask it to rank the three riskiest areas by people affected and recovery difficulty, name the assumptions the change relies on but nobody has verified, and produce a rollout order and rollback plan with the metric thresholds that trigger a rollback.
Audit the config, then ship
Finally, hand the config files and per-environment variables to 'Audit the Config Before Launch'. It should spell out every setting that only works because of a default, the paths that work locally and fail in production, and a risk-ordered checklist. Store that checklist next to the rollback plan from step 4 so the next release can reuse it.
Prompts used
FAQ
Can I ship code that AI wrote?
No, not as-is. The model cannot see your deployment environment, real data volumes, or the history behind the current design, and those are often what breaks after launch. Steps 4 and 5 cover that gap by mapping impact and checking config, but a person still has to read the diff, run the tests, and own the rollback.
The requirement is one sentence. Can AI split it into tasks?
It can, but the tasks will be built on guesses. Ask for the parts of the requirement that are unclear and must be confirmed with the product owner first, get answers, then split. Without that, inputs and acceptance criteria are invented.
Do small changes need the whole workflow?
No. A copy change or an extra log line may only need steps 3 and 5. Changes touching the data model, permissions, or external callers deserve all five. The test is whether you can undo it quickly if it goes wrong, not how many lines it touches.