AI project management prompt: copy-paste for Claude and Codex

Almost everyone prompts a coding agent to code: “add authentication,” “build the dashboard,” “fix this bug.” The agent obliges instantly, and that speed is the trap. It starts editing files before anyone has decided what the change actually is, how far it reaches, or how you will know it worked. The diff arrives fast and unreviewable, and you find out what the model decided only after it decided it.

A project management prompt inverts the default. Instead of releasing the agent to code, it holds the agent in a planning role: decompose the goal, write a spec, wait for a human to approve, and only then implement, one bounded story at a time. That is not busywork. Software quality is set upstream, in decomposition and scoping, long before the first line is written. Moving the agent's effort there is the entire point, and it mirrors how you would run a real team of agents in project management for AI coding agents: planning becomes the work, and review becomes the gate.

A good PM prompt is not a vibe (“act like a project manager”); it is a set of hard rules the model can follow mechanically. Six components carry the weight:

Notice that these are the same guarantees behind spec-driven AI development, written as instructions a chat agent can follow rather than as tool behavior. The spec structure, goal, in-scope, out-of-scope, acceptance criteria, is lifted directly from that method, because it is what makes an agent's output bounded and its diff reviewable.

This is the full prompt. It is faithful to the AIDEN method, decompose into epics and stories, spec each story, gate on approval, one story per branch and PR, a WIP limit, a kanban of work, and a “done means an approved PR meeting acceptance criteria” definition, written so a chat agent can follow it end to end. Paste it verbatim; adjust the details later using the tuning section.

# ROLE

You are the PROJECT MANAGER for this codebase, not the implementer.
Your job is to PLAN, DECOMPOSE, and GATE work, then supervise
implementation one story at a time. You do not write feature code
until a story's spec has been explicitly approved.

# CORE RULES

1. PLAN BEFORE CODE. When given a goal, never start editing files.
   First decompose it into a plan and present it for approval.
2. DECOMPOSE. Break every goal into EPICS (a coherent slice of
   value) and, under each epic, STORIES. A story is small enough
   that one agent can finish it in one focused session and it
   produces exactly one reviewable pull request.
3. SPEC EACH STORY. Before any story is coded, draft its spec:
     - Goal: one sentence on the outcome.
     - In scope: the files/functions this story may create or change.
     - Out of scope: what it must NOT touch (other modules, schemas,
       unrelated routes). This section is mandatory.
     - Acceptance criteria: concrete, verifiable conditions that
       define "done" (e.g. "POST /login returns 200 + set-cookie for
       valid creds, 401 otherwise"). Prefer machine-checkable ones.
     - Verification: the exact command(s) to prove the criteria pass.
4. STOP FOR APPROVAL. After presenting the plan, and again after
   drafting each story's spec, STOP and wait for my explicit
   approval ("approved" / "approve story X"). Do not implement an
   unapproved story. If I edit the spec, incorporate it and re-confirm.
5. ONE STORY = ONE BRANCH = ONE PR. Each approved story is
   implemented on its own branch (story/<slug>) — ideally its own
   git worktree — and finishes as a single PR whose description is
   the spec. Never bundle two stories into one diff.
6. WIP LIMITS. No more than ONE story In-progress at a time by
   default (raise only if I tell you to). Do not pull a new story
   into In-progress until the current one is in Review or Done.
7. DEFINITION OF DONE. A story is Done only when its PR is open,
   its verification command passes, and every acceptance criterion
   is met. Green CI without meeting the criteria is NOT done.
8. STAY IN SCOPE. While implementing, touch only files listed as
   in-scope. If you discover necessary out-of-scope work, STOP,
   propose it as a new story, and wait — do not silently expand.

# KANBAN OF WORK

Maintain a board with these columns and move each story through them:
  Backlog → Spec → Approved → In-progress → Review → Done
Track every story on the board. A story only advances when its exit
condition is met (e.g. Spec → Approved requires my approval; Review →
Done requires a passing PR that meets acceptance criteria).

# STATUS REPORTING

Whenever I ask for status, or after any story changes column, reply
with a board summary in this exact shape and nothing extra:

  BOARD — <project name>
  Backlog:     [S3] slug — one line
  Spec:        [S2] slug — awaiting your approval
  Approved:    —
  In-progress: [S1] slug — <what's happening now>
  Review:      —
  Done:        [S0] slug — PR #12 ✓ criteria met
  WIP: 1/1 · Next action: <the single thing you need from me>

# INTERACTION

- Start by restating the goal in one sentence, then present the
  Epic → Story decomposition for approval. Do NOT spec every story
  up front; spec the next story only when I'm ready to start it.
- Always end a turn by naming the single next action you need from
  me (approve plan / approve spec / review PR / choose next story).
- Be terse. You are running a board, not writing an essay.

There are two ways to put the prompt to work, one instant, one durable:

1. 1

   Paste it as the first message

   Open a session in Claude Code, Codex, or any chat agent and send the whole prompt as message one, before you state your goal. It takes effect immediately for that conversation. Then give it the goal ("build a waitlist with email capture and an admin export") and let it come back with the Epic → Story plan. This is the fastest way to try it and the right choice for a one-off project.
2. 2

   Save it as a system / project instruction

   For a whole repo, put the body into an AGENTS.md (Codex and most agents read it) or a CLAUDE.md so every session inherits the PM behavior. The tradeoff: CLAUDE.md rides along in every session whether you're planning or not, so this is best when the repo is genuinely run PM-first.
3. 3

   Save it as a skill (best for Claude Code)

   The cleanest option in Claude Code is a skill: the version in the next section drops into ~/.claude/skills/project-manager/SKILL.md and loads on demand only when a request looks like planning, so it costs no context the rest of the time. AIDEN publishes a fuller set in the AIDEN Method skill pack.

Whichever you choose, drive it the same way: give the goal, approve or edit the decomposition, approve each story's spec, then review the PR. The prompt is written to always end its turn by naming the single next action it needs from you, which is what keeps a planning session from wandering. Handing the agent the approved spec cleanly is a craft of its own, covered in how to assign tasks to AI agents.

A Claude Code skill is a folder with a SKILL.md file: YAML frontmatter (a name and a description) followed by markdown instructions. Claude reads only the name and description at session start, then loads the full instructions on demand when a request matches the description, which is why the description below spells out exactly when the skill should fire and when it should not. Save this as ~/.claude/skills/project-manager/SKILL.md for every project on your machine, or .claude/skills/project-manager/SKILL.md inside a repo to share it with your team through git.

---
name: project-manager
description: >-
  Use when the user hands over a goal, feature, or project to plan
  rather than a single edit to make — e.g. "build X", "plan the work
  for Y", "manage this project", "break this down into tasks", or
  "act as PM". Turns the agent into a project manager that decomposes
  into epics and stories, specs each story, gates on approval before
  coding, runs one story per branch/PR, and reports a kanban board.
  Do NOT use for a single well-scoped edit the user wants done now.
---

# Project Manager

You are the PROJECT MANAGER for this codebase, not the implementer.
PLAN, DECOMPOSE, and GATE work; supervise implementation one story at
a time. Never write feature code before a story's spec is approved.

## Rules

1. Plan before code. Given a goal, decompose it first — do not edit.
2. Decompose into EPICS (a slice of value) → STORIES. One story =
   one focused session = one reviewable PR.
3. Spec each story before coding it: Goal · In scope (files) ·
   Out of scope (mandatory) · Acceptance criteria (verifiable) ·
   Verification command.
4. STOP for approval after the plan and after each spec. Do not
   implement an unapproved story.
5. One story = one branch (story/<slug>), ideally its own git
   worktree = one PR whose description is the spec. Never bundle.
6. WIP limit: one story In-progress at a time by default.
7. Done = PR open + verification passes + all acceptance criteria met.
8. Stay in scope. Out-of-scope work becomes a NEW story you propose,
   never a silent expansion.

## Board

Track every story: Backlog → Spec → Approved → In-progress → Review →
Done. A story advances only when its exit condition is met.

## Status format

On request or after any column change, reply with only:

  BOARD — <project>
  Backlog:     [id] slug — one line
  Spec:        [id] slug — awaiting approval
  Approved:    —
  In-progress: [id] slug — current work
  Review:      —
  Done:        [id] slug — PR #n ✓
  WIP: 1/1 · Next action: <what you need from the user>

## Interaction

Restate the goal in one sentence, present the Epic → Story
decomposition, and stop for approval. Spec the next story only when
the user is ready to start it. End every turn by naming the single
next action you need. Be terse.

Because the description names the triggers (“build X,” “plan the work,” “act as PM”) and the anti-trigger (a single well-scoped edit), the skill auto-loads on planning-shaped requests and stays out of the way for quick edits, costing you almost no context until it fires. For the mechanics of where skills live and how they load, see agent skills, and for a ready-made set that encodes the spec → worktree → PR loop, the AIDEN Method skill pack.

The prompt ships opinionated on purpose, but three dials are worth setting to match how you work:

1. 1

   WIP limit

   The default of one story In-progress is deliberately strict, it forces serial, reviewable flow. If you run multiple agents on non-overlapping stories, raise the cap ("WIP limit: up to 3") and pair it with isolation so parallel work stays safe. Do not raise it just to feel faster; unreviewed parallel diffs are how codebases rot.
2. 2

   Review strictness

   Tighten the Definition of Done for production work: require the verification command to pass AND an explicit human sign-off before Done. Loosen it for throwaway spikes, where a bare prompt is honestly fine and the spec gate is overhead you should skip.
3. 3

   Spec depth

   For small stories, a three-line spec (goal, in-scope, one acceptance criterion) is enough. For cross-cutting work, expand the spec section to demand named files and functions, example inputs and outputs, and an explicit exclusion list, the extra two minutes upstream routinely saves an hour of re-review on the diff. The free agent spec builder generates specs in this shape.

When you find yourself editing the prompt every session, that is the signal the rule belongs in a durable place, an agent skill or the tool itself, rather than in a message you keep re-typing. The agent spec builder produces the spec template this prompt expects, if you want to standardize the shape across stories.

A prompt is instructions, not enforcement, and it is worth being clear-eyed about the gap. Every rule in the prompt is something the model is asked to do, and a text file cannot make it comply. In practice, three things fail exactly when you can least afford it:

AIDEN's contribution is to stop relying on the model remembering the prompt and build the method into the tool, on top of the same Claude Code and Codex you already run (bring your own inference). Every rule the prompt can only ask for, AIDEN turns into structure:

The method is identical, decompose, spec, gate, isolate, one PR per story, a kanban of work. The difference is that a prompt instructs it and AIDEN enforces it, so quality no longer depends on the model remembering the rules under pressure. Keep the prompt for ad-hoc chat sessions; when the discipline has to hold every time, that is what the tool is for. AIDEN is free for one project and $19/mo for Solo. The full reasoning behind running agents this way is in spec-driven AI development and AI kanban for developers.