Prompts for Project Management With AI Assistants

The prompts below are grouped by the job they do: planning, triage, status, risks, meetings, retros and stakeholder updates. Each one is written for an AI assistant that is connected to your task board over MCP, so it reads the real tasks instead of working from whatever you remembered to paste. And each one is written to be safe: it reads first, shows you what it would change, and changes nothing until you say so. Paste them into Claude, ChatGPT, Cursor or any assistant that can reach your board, and swap the square-bracketed parts for your own.

A prompt is for a job you do by hand, in the moment. Once you find yourself pasting the same one every Monday, it has earned a permanent home: Claude skills for project management shows how to turn the weekly ones into skills that run the same way every time.

How these prompts are written

• Read first, always. Every prompt starts from what is on the board, and says “read only” where the job is only reading. An assistant that is told to look before it answers makes up less.
• Propose, then wait. Where a job ends in a change, the prompt asks for a list of proposed changes and stops. Anthropic’s prompting best practices↗ (opens in a new tab) note that asking Claude to suggest changes tends to get suggestions, and telling it to make them gets action; these prompts use that on purpose.
• Refs everywhere. Every task mentioned carries its ref, such as BUG-031, so any line in the answer can be checked against the board in seconds.
• No guessing. Dates, owners and estimates the board does not record are written as “not recorded”, not invented.
• Plain lane names. The prompts use To Do, Next Up, In Progress and Completed. If your board names them differently, change the words; the assistant maps them to whatever the tools call them.

The preamble: paste this first

Start a conversation with these rules, then use any prompt below. If your assistant supports standing instructions (a project, a rules file, custom instructions), put them there instead so you only write them once.

Rules for this conversation:
- You are connected to my task board. Read it before you answer; do not work from memory.
- First check who you are acting as and what you are allowed to do on the board.
- Quote the ref (e.g. BUG-031) for every task you mention. If something is not on the board, say so.
- Do not create, edit, move, comment on or delete anything until you have shown me
  the list of proposed changes and I have replied "go ahead".
- If a tool refuses you, repeat the refusal word for word and stop.
- Never guess dates, owners or estimates. If the board does not say, write "not recorded".

On a fenbs board, “check who you are acting as” is fenbs_whoami, which returns the assistant’s role on each board, and the refusal line matters because a fenbs refusal is a full sentence naming the missing permission and the role held. An assistant that repeats it gives you something to act on; one that paraphrases it usually does not.

Planning

Read Next Up and To Do for project [name]. Propose the ten tasks that should be in
Next Up for the coming week, in order, with one line each on why. Put the most urgent
first, then anything a Next Up task depends on. List separately anything you would move
out of Next Up, and why. Do not move anything.

Read [ref]. If it cannot be finished in a day, propose how to split it into tasks that
can: for each, a title, the kind (feature, enhancement or bug), a one-sentence outcome
and how we would check it is done. Show me the list. Create nothing until I approve it,
then link each new task to [ref].

List the tasks in Next Up for project [name] that have no plan written. For each, say in
one line what someone would need to know before they could write the plan. Read only.

For the full planning conversation, with capacity and a person making the final cut, see sprint planning with AI. For how small the pieces should be, see AI agent task decomposition.

Triage

List the To Do tasks created or changed since [date]. For each one:
1. Is the kind right? Bug = something is broken. Feature = something new.
   Enhancement = something that exists should work better.
2. Is it a likely duplicate? Search the board for its key words and name the older ref.
3. What is missing that someone fixing it would need (where, what was expected,
   steps to reproduce)?
4. Suggest a priority from 1 (most urgent) to 10, with one line of why.
Answer as a table. Change nothing.

Apply only the rows I marked "yes": change the kind and priority as proposed. On each
duplicate, comment "Looks like a duplicate of [older ref]" instead of deleting it.
Then list every change you made, with its ref.

For each To Do task whose note has no location or no steps to reproduce, draft one short
question for the person who filed it. Show me the drafts. Post them as comments only
after I say go ahead.

Triage is where a split into two steps pays off most. The first prompt is safe to run on any connection; the second is the only one that writes, and it writes only what you ticked. The board structure that makes triage quick is in how to track bugs and feature requests in one board.

Status

Write this week's status for project [name], from the board only.
- Completed: tasks that reached Completed in the last 7 days, one line each.
- In Progress: each task, with what its latest comment says is left.
- Stuck: anything In Progress that has not changed for 5 days or more.
Under 200 words. Refs in brackets. No adjectives about how well it went. Read only.

Since [date and time], what changed on the board? Group it: new tasks, tasks that moved
lane, and new comments that ask a question nobody has answered. Say which comments came
from an AI assistant and which from a person, where the board shows it. Read only.

Risks

Look at every task in Next Up and In Progress. List the ones that look risky and why:
no plan; a plan that touches something shared (payments, sign-in, customer data);
a bug that came back; a task too big for one sitting; a comment that mentions a blocker.
Rank the top five. Suggest one action for each. Take none.

Assume the release planned for [date] slipped by two weeks. Using only what is on the
board, give the three most likely reasons, each tied to specific refs. Then list the
questions I should ask the team to rule each one out. Read only.

Both prompts produce a list for you to act on, not actions. That is deliberate: flagging a task, reassigning work or moving a date are judgements about people and priorities, and they belong with whoever answers for the project.

Meetings

Build a 30-minute agenda for tomorrow's [team] meeting from the board: tasks waiting on
a decision, tasks In Progress with an unanswered question in the comments, and anything
flagged. Under each heading give the ref and the one question to settle. Read only.

Here are the meeting notes: [paste]. Sort every line into actions, decisions and
information. For each action, propose a task: title, kind, project, and a note saying
who asked for it and why. Search the board first and mark any action that is already a
task, with its ref. Show me the list. Create only the ones I tick.

Keep decisions out of the task list. A decision is not something to do; it is something that holds. On fenbs, decisions have their own page and refs (DEC-001), and an assistant may record one but never be named as the one who decided, so ask it to propose decisions separately and name the person who made each.

Retros

For project [name], list what reached Completed in the last [two weeks]. For each,
roughly how long it spent In Progress (from the dates on the board) and whether a bug
linked to it was filed afterwards. Then list tasks that were moved back out of Completed.
Facts from the board only, no opinions. Read only.

From that list, write five retro questions for the team. Each must point at specific
refs or a pattern, e.g. "Three bugs came back from the checkout work: what did testing
miss?". Do not answer them.

Splitting facts from questions keeps the assistant where it is strong. It is good at counting what the board records; it is not in the room, and a retro’s conclusions should come from the people who did the work.

Stakeholder updates

Write an update for [client] about project [name]. Plain English, no refs, no internal
names, no technical terms. Three parts: what is finished and what they can now do; what
is being worked on; what we need from them. Under 150 words. Show me the draft. Do not
send, post or comment anything.

In three sentences for [manager]: where project [name] stands, the one risk they should
know about, and the one decision we need from them. After the three sentences, list the
refs behind each claim so I can check them.

For release notes built from finished work, which is a stakeholder update with stricter rules, see generating release notes with AI from finished tasks.

Adapting a prompt to your own board

The prompts name lanes, kinds and a 1 to 10 priority because those are what most small boards have. Three changes cover most other set-ups:

• Swap the words, not the shape. If your board says “Backlog” and “Done”, write those. Keep the order of the prompt: read, list, propose, wait.
• Name the project every time. On a board that holds several products, a prompt without a project reads everything, and a status report about all of it helps nobody.
• Put the facts in the board, not the prompt. “Releases go out on Tuesdays” or “never name the client in a report” belong in the notes every assistant reads before it starts; on fenbs that is AI context. The prompt then only carries the job.

When a prompt gives a poor answer, fix the prompt rather than arguing with the reply. The usual cause is a missing limit: no time window, no project, or no rule about what to do when the board says nothing.

Make “ask before changing” more than a request

Every “read only” and “show me first” above is an instruction, and an instruction can be forgotten halfway through a long conversation. The limits that hold regardless live in the connection, not the prompt. OWASP’s entry on excessive agency↗ (opens in a new tab) makes the same point: keep an extension’s permissions to the minimum necessary and have a person approve high-impact actions.

• Connect with the smallest scope that does the job. On fenbs the approval screen offers three: Read the board, which is always on, Add and change tasks, and Comment. For the planning, status, risk, meeting-agenda and retro prompts, read is enough.
• Keep your client’s confirmations on. The MCP tools specification↗ (opens in a new tab) says there should always be a human in the loop able to deny a tool call, and asks clients to confirm operations with the user. Approving each write as it comes is the second check behind your “go ahead”.
• Read the record afterwards. On fenbs every change is recorded with who made it, and an assistant’s changes show as the assistant acting for you, so what the triage prompt changed can be checked line by line.