Tools

Feature Spec Generator

Fill a structured form, get a complete feature spec in Markdown. Copy or download — ready for your repo.

API Spec Generator

Endpoint contracts, request/response schemas, and error codes in one spec.

DB Spec Generator

Tables, fields, constraints, indexes, and migration plans.

Postmortem Generator

Blameless incident retros with timeline, impact, root cause, and owned action items.

Gherkin Generator

Turn user stories and acceptance criteria into a valid .feature file.

Feature generator preview

The useful output is the part reviewers can inspect immediately: scope, acceptance, evidence, and rollback.

# Feature Spec: Retry failed invoice payment

Non-goals:
- no new payment provider
- no subscription plan changes

Acceptance:
- expired card returns card_declined
- retry uses the same invoice_id
- audit log records retry_source

Evidence:
- payment retry integration test
- dashboard screenshot for declined state
- rollback flag: invoice_retry_v2

API generator preview

API output should give integration partners enough detail to build and enough evidence for reviewers to block risky changes.

# API Spec: Create refund

POST /refunds
Idempotency: required via Idempotency-Key

Errors:
- 409 duplicate_refund
- 422 refund_window_expired

Review gates:
- contract test for replay
- old SDK compatibility check
- release note for refund_status enum

Before implementation

Use the Feature Spec Generator when a task needs clear goals, non-goals, acceptance criteria, edge cases, and implementation notes before code is written.

Before integration

Use the API Spec Generator when two clients, services, or partner teams need to agree on request shape, response shape, error behavior, and compatibility rules.

Before migration

Use the DB Spec Generator when a change touches tables, constraints, indexes, backfills, or rollback strategy. It makes data risk explicit before rollout.

Draft with the generator, review with a checklist

Generate the first pass quickly, then review it against the Spec Review Checklist. The generator gives you structure; the checklist catches missing scope, rollout, observability, and test evidence.

Use examples as calibration, not filler

Each tool includes a realistic example because blank fields produce vague specs. Load the example, study the level of specificity, then replace it with your own domain details before copying the result.

Keep generated docs close to code

Download or copy the output into your issue, design document, or repository. A spec is most useful when reviewers can compare implementation diffs against the exact acceptance criteria that shaped the work.

Prefer small specs over giant documents

If the output becomes long, split it by decision: one feature spec, one API contract, one migration plan, one postmortem. Smaller artifacts are easier to review and less likely to go stale.

Use a meeting for unresolved product decisions

If the team does not yet agree on the user, success metric, release boundary, or failure behavior, do not treat generated output as approval. Use the tool to expose blanks, then resolve the decision with the people who own it.

Use a repository spec for long-lived contracts

For APIs, migrations, billing rules, permission models, and platform behavior, copy the generated draft into version control. Long-lived contracts need review history, owners, and updates when implementation changes.

Use a postmortem for incidents, not a feature spec

When the work starts from a production failure, begin with the Postmortem Generator. It captures timeline, detection gaps, root cause, and follow-up actions before the team jumps into another implementation ticket.

Use Gherkin only when executable examples help

Gherkin is useful when examples become tests or shared QA scenarios. If the team only needs a quick reviewer note, a short checklist may be clearer than a formal .feature file.

Start with the artifact reviewers need

If reviewers need product scope, generate a feature spec. If they need client/server agreement, generate an API spec. If they need migration safety, generate a DB spec. If they need incident learning, generate a postmortem.

Use tools to reveal blanks

A skipped field is often the useful signal. Missing rollback, missing owner, missing error behavior, or missing test evidence tells the team which decision still needs discussion before the work is safe to start.

Keep the output reviewable

After export, trim repeated text and keep the specific decisions. A generated document should make review faster, not give the team a larger artifact to skim without judgment.

What stays in the browser

The generators run client-side and do not require a login. Draft restore uses local browser storage so you can recover work in the same browser session. Avoid pasting secrets, production tokens, or regulated personal data into any web-based tool.

What to review before sharing

Before sending a generated spec to a teammate or AI coding tool, remove customer identifiers, internal hostnames, unreleased pricing details, credentials, and anything that should not leave your project workspace.

Copy the draft into the review venue

Put the generated Markdown where decisions happen: an issue, PR description, design doc, incident tracker, or repository folder. A local download is useful only if the team can comment on it and compare implementation against it.

Add real examples before approval

Replace sample values with one realistic request, migration step, scenario, or timeline entry from your own domain. The examples are what reveal missing assumptions and make the artifact specific enough to review.

Close the loop after implementation

After the work ships, update the spec if the final behavior changed. A tool-generated draft becomes a durable asset only when it reflects the version the team actually released.

Are these tools replacements for human review?

No. They help you produce a structured first draft. Human review is still where teams catch product ambiguity, operational risk, and compatibility concerns that a form cannot know.

Which tool should I start with?

For product behavior, start with the Feature Spec Generator. For service boundaries, start with API. For storage and migration risk, start with DB. For incidents, start with Postmortem. For executable acceptance examples, start with Gherkin.