Create a more-loop prompt file
You are helping the user create a prompt.md spec file for use with more-loop, an iterative development script that wraps the claude CLI.
How more-loop uses this file
- Bootstrap phase — Claude reads the prompt file and generates:
acceptance.md — checklist of acceptance criteria (definition of done)
tasks.md — checklist of atomic implementation steps
- Task iterations — Claude picks one task at a time and implements it
- Each iteration is a fresh
claude -p process with no shared context — the prompt file is the only source of truth for intent
What makes a good more-loop prompt
A good prompt file should be self-contained and include:
- What to build — clear description of the feature, tool, or change
- Context — relevant codebase info, existing patterns, tech stack
- Constraints — language, framework, style, performance requirements
- Scope boundaries — what is explicitly out of scope
- Examples — sample inputs/outputs, API shapes, UI behavior
It should NOT include:
- Step-by-step implementation instructions (more-loop generates those)
- Acceptance criteria checklists (more-loop generates those too)
- Vague or open-ended goals ("make it better")
Your process
- Ask the user what they want to build. If
$ARGUMENTS was provided, use it as the topic name.
- Ask clarifying questions to fill gaps — scope, constraints, tech stack, existing code context. Ask at most 3 rounds of questions. Be specific: offer choices rather than open-ended questions where possible.
- Scan the codebase if relevant — look at existing patterns, tech stack, directory structure to add concrete context to the prompt.
- Write the prompt file in markdown with these sections:
# <Title>
## Overview
<1-3 sentences: what to build and why>
## Context
<Relevant codebase info, tech stack, existing patterns>
## Requirements
<Bulleted list of specific, testable requirements>
## Constraints
<Language, framework, style, performance, compatibility>
## Out of Scope
<What NOT to do>
## Examples
<Sample inputs/outputs, API shapes, UI mockups — if applicable>
- Write the file to the output path determined below.
Output path
Files are organized under .more-loop/runs/<run-name>/:
- Determine the run name: Use
$ARGUMENTS if provided (as a slug, e.g., web-dashboard). Otherwise, derive a short kebab-case slug from the topic the user described (e.g., "Add auth system" → auth-system).
- Create the directory:
.more-loop/runs/<run-name>/
- Write the file:
.more-loop/runs/<run-name>/prompt.md
If $ARGUMENTS looks like an explicit file path (contains / or ends in .md), respect it as-is instead of using the directory convention.
1---2name: more-loop-prompt3description: Create a prompt.md spec file for use with the more-loop iterative development script4---56# Create a more-loop prompt file78You are helping the user create a **prompt.md** spec file for use with `more-loop`, an iterative development script that wraps the `claude` CLI.910## How more-loop uses this file11121. **Bootstrap phase** — Claude reads the prompt file and generates:13 - `acceptance.md` — checklist of acceptance criteria (definition of done)14 - `tasks.md` — checklist of atomic implementation steps152. **Task iterations** — Claude picks one task at a time and implements it163. Each iteration is a **fresh `claude -p` process** with no shared context — the prompt file is the only source of truth for intent1718## What makes a good more-loop prompt1920A good prompt file should be **self-contained** and include:2122- **What to build** — clear description of the feature, tool, or change23- **Context** — relevant codebase info, existing patterns, tech stack24- **Constraints** — language, framework, style, performance requirements25- **Scope boundaries** — what is explicitly out of scope26- **Examples** — sample inputs/outputs, API shapes, UI behavior2728It should NOT include:29- Step-by-step implementation instructions (more-loop generates those)30- Acceptance criteria checklists (more-loop generates those too)31- Vague or open-ended goals ("make it better")3233## Your process34351. **Ask the user** what they want to build. If `$ARGUMENTS` was provided, use it as the topic name.362. **Ask clarifying questions** to fill gaps — scope, constraints, tech stack, existing code context. Ask at most 3 rounds of questions. Be specific: offer choices rather than open-ended questions where possible.373. **Scan the codebase** if relevant — look at existing patterns, tech stack, directory structure to add concrete context to the prompt.384. **Write the prompt file** in markdown with these sections:3940```markdown41# <Title>4243## Overview44<1-3 sentences: what to build and why>4546## Context47<Relevant codebase info, tech stack, existing patterns>4849## Requirements50<Bulleted list of specific, testable requirements>5152## Constraints53<Language, framework, style, performance, compatibility>5455## Out of Scope56<What NOT to do>5758## Examples59<Sample inputs/outputs, API shapes, UI mockups — if applicable>60```61625. **Write the file** to the output path determined below.6364## Output path6566Files are organized under `.more-loop/runs/<run-name>/`:67681. **Determine the run name**: Use `$ARGUMENTS` if provided (as a slug, e.g., `web-dashboard`). Otherwise, derive a short kebab-case slug from the topic the user described (e.g., "Add auth system" → `auth-system`).692. **Create the directory**: `.more-loop/runs/<run-name>/`703. **Write the file**: `.more-loop/runs/<run-name>/prompt.md`7172If `$ARGUMENTS` looks like an explicit file path (contains `/` or ends in `.md`), respect it as-is instead of using the directory convention.