AI Coding Spec Packet Generator

Turn a vague implementation request into a reviewable Markdown packet before you ask an AI coding tool to touch the repo.

proposal.mdWhy, impact, affected users
spec.mdRequirements, scenarios, boundaries
design.mdDecisions, trade-offs, rollout
evidence.mdTests, screenshots, logs, stop signals

Browse worked examples · Coupon case · Notification case

Inspectable output

Every generated file maps to a review decision.

The tool is useful only if the output can survive code review. These are the checks a reviewer should be able to perform before the packet is handed to an AI coding agent.

proposal.mdWhy the work matters, who is affected, and which risks justify a spec.
spec.mdRequirements, non-goals, edge cases, and scenarios that constrain implementation.
tasks.mdSmall implementation slices that prevent a single broad prompt from changing unrelated code.
evidence.mdTests, screenshots, logs, metrics, and rollback signals required before merge.

1. Describe the change

Write the messy version first. The output will make the review structure explicit.

2. Add boundaries for AI coding

Packet readiness

Needs detail
0/100
    Copy for
    Load example

    Copy into the issue

    Use Copy full packet when the work needs a shared proposal, behavior spec, design note, task plan, and evidence bar.

    Download into the repo

    Use the ZIP export when the team stores specs beside code, such as /docs/specs/ or /changes/feature-name/.

    Give AI a boundary

    Paste the packet above the coding prompt and require the diff to map back to requirements, tasks, and acceptance criteria.

    What this generator is responsible for

    Turn ambiguity into review fields

    The tool does not pretend that a vague request is already safe. It forces the request through concrete fields: owner, users affected, constraints, non-goals, known risks, and release signals. Those fields are the parts reviewers usually need when an AI-generated diff starts to drift.

    Create files that fit a repo

    The output is shaped as Markdown because the packet should live where implementation decisions are reviewed: an issue, a pull request, or a folder such as /docs/specs/. A chat transcript disappears quickly; a small file can be linked, diffed, and updated.

    Make evidence part of the prompt

    The generated evidence file is not a reporting form after the work is done. It tells the coding agent and reviewer what proof should exist before the change is merged: tests, screenshots, logs, metrics, manual checks, and stop signals.

    A practical review workflow

    Use the generated packet before implementation, not after. The strongest workflow is simple: one person drafts the packet, one reviewer challenges the boundaries, then the coding assistant receives the approved packet as its instruction source. If the assistant changes behavior outside the packet, the reviewer can request changes without debating intent.

    The packet should stay small. A useful spec.md is usually one or two pages, but it must name the uncomfortable parts: what is not included, what could break, which users are affected, and which evidence will prove the change. A long packet that avoids those decisions is still low-value; a short packet that names them is useful.

    Before coding

    Fill the form, load the example if needed, and edit the generated Markdown until scope and non-goals are obvious.

    During coding

    Paste the packet above the AI prompt and require every changed file to map back to a task and acceptance criterion.

    Before merge

    Attach the final packet and evidence summary to the pull request so reviewers can compare the diff against the original contract.

    Limits and review responsibilities

    The generator is intentionally deterministic. It does not know your codebase, your release process, or your customer commitments. That is a feature, not a flaw: the tool creates a stable draft shape, while the human reviewer supplies the project-specific judgment. Treat the output as a structured starting point, not as approval to implement.

    Before a packet is used, replace placeholders with concrete names. "Run tests" should become a command. "Watch metrics" should become a metric or dashboard. "Avoid breaking existing users" should become a compatibility rule, migration step, or rollback signal. Those replacements are where the content becomes unique to your project.

    Best-fit use cases

    Small feature with hidden risk

    Use it when the ticket looks simple but touches data migration, money, permissions, or a public API.

    AI coding handoff

    Use it when the assistant needs a narrow source of truth before changing files.

    Review reset

    Use it when a PR is already too broad and the team needs to restate the intended behavior.

    From vague request to reviewable packet

    Weak input

    Improve notification settings.
Make it less confusing and support mobile push.

    Spec-ready output

    Goal:
- Make email, in-app, and push preferences explicit.

Non-goals:
- no new provider
- no pricing changes

Evidence:
- migration dry run
- duplicate notification test
- old mobile client screenshot

    Read the full notification migration case or compare it with the quick before/after rewrites.

    Where to use the packet

    Before prompting AI

    Paste the packet above the coding prompt and tell the assistant to implement only the listed scope.

    Read the workflow

    Inside a pull request

    Attach acceptance criteria and evidence so reviewers can compare the diff against the original contract.

    Open review checklist

    As a repo template

    Keep the generated files in /docs/specs/ or next to the issue that owns the change.

    Open SDD template

    FAQ

    Is this an AI code generator?

    No. It generates the spec packet that should constrain AI coding before implementation starts.

    Does it store my input?

    The draft is generated locally in your browser. Do not enter secrets or private customer data.

    When is it ready?

    When a reviewer can reject scope creep and verify the result with the listed evidence.

    Editorial note

    This browser tool is maintained as an editorial utility. The generated packet is a draft: review scope, risks, and evidence before using it to guide implementation.