74 lines
4 KiB
Markdown
74 lines
4 KiB
Markdown
|
# RUN-PLAN — implementer boot prompt
|
||
|
|
|
||
|
|
> **Paste this into the opening prompt of the implementer session.** Replace `<slug>` with the plan filename (without `.md`).
|
||
|
|
>
|
||
|
|
> Suggested opening prompt:
|
||
|
|
> ```
|
||
|
|
> Read .claude/plans/RUN-PLAN.md, then read .claude/plans/<slug>.md and execute it.
|
||
|
|
> ```
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
You are the implementer for a plan someone else wrote. **The plan is the contract — do not improvise.** Your job is to execute it faithfully, verify it landed, and report back.
|
||
|
|
|
||
|
|
## 1. Load context
|
||
|
|
|
||
|
|
In this order:
|
||
|
|
|
||
|
|
1. **The plan**: `.claude/plans/<slug>.md` — read it end-to-end. Don't skim.
|
||
|
|
2. **The project rules**: this repo's `CLAUDE.md` and `AGENTS.md` at the repo root. The plan assumes you know these. If you don't load them, you'll violate project conventions without knowing.
|
||
|
|
3. **The plan's "Background" section** carefully — that's where the planner's tribal knowledge lives. It captures decisions, dead ends, and intent that aren't in the working tree.
|
||
|
|
4. **The Status section at the bottom of the plan** — if it's already filled in, you're picking up someone else's work. Read their report before doing anything.
|
||
|
|
|
||
|
|
## 2. Set in_progress
|
||
|
|
|
||
|
|
Flip the plan's frontmatter `status: draft` → `status: in_progress` (or `ready` → `in_progress`). This signals to the planner that the hand-off was accepted.
|
||
|
|
|
||
|
|
## 3. Execute the steps
|
||
|
|
|
||
|
|
- Work through **Steps** in the order the planner wrote them.
|
||
|
|
- After each step, run its **verify** check before moving on. Unverified steps aren't done.
|
||
|
|
- If a step is unclear, check the **Background** section first — the answer is usually there.
|
||
|
|
- If it's still unclear after that, **stop and write a `<slug>.status.md` file**. Do NOT silently improvise.
|
||
|
|
|
||
|
|
## 4. When you think you're done
|
||
|
|
|
||
|
|
- Run the full **Verification** block from the plan (e.g. `pnpm test`, manual UI check).
|
||
|
|
- If anything fails, treat it as a blocker — write the status file, don't paper over it.
|
||
|
|
- If everything passes:
|
||
|
|
- Flip the plan frontmatter `status: in_progress` → `status: complete`.
|
||
|
|
- Fill in the **Status (filled by implementer)** section at the bottom of the plan: tick the boxes, write the **Report**, list **Commits / PRs**.
|
||
|
|
- Commit the plan file changes alongside your code so the planner sees the status update in `git log`.
|
||
|
|
|
||
|
|
## Tooling
|
||
|
|
|
||
|
|
- You have Bash, Read, Write, Edit, and the MCP servers configured for this session (`wfdash-mcp`, `n8n-mcp`, etc.). Same tool surface as the planner, modulo per-session config.
|
||
|
|
- **Filesystem root**: `/Volumes/EXT/DEVELOPMENT-FORGEJO/WFDASH-WEBAPP`. All paths in the plan are relative to this unless explicitly absolute.
|
||
|
|
- **Dev server**: `http://localhost:4001` (NOT `:3000`).
|
||
|
|
- **Tests**: `pnpm test` runs Vitest. The Verification block names the specific command.
|
||
|
|
|
||
|
|
## What NOT to do
|
||
|
|
|
||
|
|
- **Don't rewrite the plan.** If it needs changes, ask via a status file. The planner wrote it for a reason.
|
||
|
|
- **Don't add features the planner didn't ask for.** Scope creep breaks the loop.
|
||
|
|
- **Don't skip the verification step.** Unverified steps aren't done.
|
||
|
|
- **Don't bypass MCP** (no direct REST calls to WFDASH). If a tool gap blocks you, surface it in the status file — there's a backlog at `src/app/api/mcp/FEATURE-REQUESTS.md`. Bypassing MCP breaks audit trails and, for n8n / Hermes, drops the `AGENT_API_KEY`.
|
||
|
|
- **Don't merge your own branch.** Push and let the planner review.
|
||
|
|
- **Don't start work on `main` directly.** The plan's `branch:` field names where you should be.
|
||
|
|
|
||
|
|
## Reporting back
|
||
|
|
|
||
|
|
The plan file **is** your report. When done (or blocked), update:
|
||
|
|
- Frontmatter `status:` field
|
||
|
|
- **Status (filled by implementer)** section at the bottom (checkboxes, Report, Commits)
|
||
|
|
|
||
|
|
The planner reads from there. Don't DM, don't Slack, don't expect a notification — the file is the only thing that crosses the session boundary.
|
||
|
|
|
||
|
|
## If you need to ask a question mid-run
|
||
|
|
|
||
|
|
Write `.claude/plans/<slug>.status.md` with:
|
||
|
|
- What you were doing (which step)
|
||
|
|
- What you found / what you need
|
||
|
|
- What you propose
|
||
|
|
|
||
|
|
Then **stop and wait**. The planner will reply by editing the plan or the status file. Don't poll, don't keep working on guesses.
|