Prompt generator

# Meta-prompt - implementation prompt plan for "[SYSTEM NAME]"

You are a senior software architect and prompt engineer.

Do **not** write application code in this response. Produce an ordered plan of
implementation prompts that I will paste, one at a time, into a fresh coding-LLM
session to build the system below from an empty repository up to a working product.

## Target system

- **Name:** [SYSTEM NAME]
- **Environment / runtime:** [ENVIRONMENT]
- **Core features:**
  1. [first core feature]

## What to return

1. **Assumptions** - every ambiguity you resolved and the default you picked. Never ask me
   questions: decide, and record the decision.
2. **Stack and architecture** - concrete libraries and versions that fit the environment above,
   the data model, module boundaries, and the folder layout every prompt will assume.
3. **Prompt plan** - the numbered prompts, in execution order.
4. **Coverage table** - a table mapping each core feature above to the prompts that implement it,
   so nothing is silently dropped.

## Shape of every prompt in the plan

### Prompt <n> - <short title>

- **Goal:** one sentence.
- **Depends on:** prompt numbers, or "none".
- **Files:** exact paths created or changed.
- **Prompt text:**

```text
The verbatim text I can paste into a fresh session. It must be self-contained:
restate the stack, the file paths, the types and the conventions it needs,
because the model receiving it has not seen any of the other prompts.
```

- **Acceptance criteria:** checkable statements, not aspirations.
- **Verify:** the command I run and what I should see.

## Rules for the plan

- Prompt 1 bootstraps the project - dependencies, folder layout, run and build scripts - and
  repeats the environment constraints verbatim.
- The repository must build and run after every single prompt. No prompt may leave it broken.
- One coherent unit of work per prompt (roughly one feature slice, or one to three files).
  Split anything larger.
- Data model and shared types come before the UI that consumes them.
- Each prompt states the conventions it must follow (naming, folder layout, state management,
  error handling) instead of relying on the model remembering them.
- Cover the whole life cycle: setup, data model, persistence, core features, state, UI,
  empty / loading / error states, accessibility (WCAG AA: keyboard, focus, contrast, ARIA),
  automated tests, build and deployment.
- End with a hardening prompt (edge cases, performance, accessibility audit) and a release
  checklist I can walk through by hand.
- Keep the plan as short as it can be while still covering everything above.

## Output format

Markdown, written in English. Assumptions first, then stack and architecture,
then the numbered prompts, then the coverage table. Then package the whole plan as described below.

---

## Deliverable: an importable speckit

When everything above is finished, output one more file named `speckit.json`,
which I will import at openspeckit.com/new/import. Return valid JSON only: no comments, no
trailing commas, nothing after the closing brace.

{
  "schemaVersion": "1.0",
  "title": "Short name of the system",
  "slug": "short-name-of-the-system",
  "description": "One sentence describing what gets built and for whom.",
  "category": "web-app",
  "tags": ["tag-one", "tag-two"],
  "stack": ["angular", "firebase"],
  "contentLanguage": "en",
  "complexity": "standard",
  "recommendedModel": "Claude Sonnet 5",
  "structureMode": "steps",
  "articles": [
    { "type": "README", "title": "Overview", "slug": "readme", "order": 0,
      "summary": null, "body": "# Overview\n\n…" },
    { "type": "CONSTITUTION", "title": "Constitution", "slug": "constitution", "order": 5,
      "summary": "Cross-cutting rules", "body": "# Constitution\n\n…" },
    { "type": "ARTICLE", "title": "Step 1 - Data model", "slug": "data-model", "order": 10,
      "summary": "Entities and relations", "body": "# Data model\n\n…" }
  ]
}

Field rules

- `title`: 3-120 characters. `slug`: lowercase letters, digits and hyphens only.
- `description`: one sentence, at most 300 characters.
- `category`: one of web-app, mobile-app, api-backend, data-analytics, ai-agent, automation, integration, devtool, game, e-commerce, internal-tool, other.
- `tags`: 1-10 short kebab-case tags. `stack`: up to 10 technologies.
- `contentLanguage`: the language the articles are written in - en, pl, de, fr, es, it, pt, uk, cs.
- `complexity`: starter, standard or advanced.
- `structureMode`: steps when the articles are ordered implementation steps,
  modules when they are functional modules.
- `articles`: exactly one README - the overview a reader sees first, at least
  200 characters. At most one CONSTITUTION holding the rules every
  other article must respect. Then one ARTICLE per step or module, `order`
  10, 20, 30 and so on.
- `body`: the complete markdown of that article, starting with a level-1
  heading. Inside JSON, line breaks are \n and quotes are escaped.
- Close every ARTICLE with acceptance criteria that can be ticked off, so the
  agent building from this specification knows when it is done.

If you cannot write files, print the JSON in a single block and I will save it.

### How the prompt plan maps onto the articles

- **README** - what gets built, for whom, the environment it runs in, and how to work through
  the prompts. This is the overview a reader sees first, so repeat the feature list here.
- **CONSTITUTION** - the stack and architecture decisions plus every convention the prompts rely
  on (naming, folder layout, state management, error handling, accessibility, testing). Rules
  that apply to more than one prompt belong here, not repeated in each article.
- **One ARTICLE per prompt**, in execution order. The article title is the prompt title, its
  body carries the goal, dependencies, files, the verbatim prompt text in a fenced block, the
  acceptance criteria and the verification step.
- `structureMode` is `steps`, because the articles are ordered implementation steps.
- `title`, `description`, `stack` and `tags` come from the target system and environment above;
  `contentLanguage` is the language you are writing in.
- The assumptions and the coverage table go into the README, so nothing you decided is lost.