31 Claude Skills for Running a Project

What these skills are

A project's life, as installable Claude skills. The skills follow the life of a project. You start it with a charter, a kickoff and an agreed scope, then stop scope creep with change control and hard priorities. You estimate and schedule in ranges, catch risks while they are still cheap, and get decisions made by the people who own them. You run the delivery rhythm without process theatre, report status that means something, and close well.

The red line: Claude plans and tracks. The people doing the work commit to the dates, and no status goes green to dodge a hard conversation.

Each skill is one artifact you walk away with: a charter, a sized change request, a PERT range, a risk register, an escalation email, a status report, a handover. Each works from what you paste — the email that started the project, the tracker export, last week's RAID log, a meeting transcript — with no connector to install, and each one ends in the decision a named person makes, by a date. Contract, employment, data protection and safety questions go to a qualified adviser rather than being answered.

The maths is done rather than named: PERT with spread, float on the critical path, SPI and CPI with a forecast at completion — each with the case where the number misleads, so you do not carry a figure into a steering meeting you cannot defend.

Mechanically, each skill is one folder with a SKILL.md file. The 31 are grouped into eight stages of a project, and each one gives full value on its own: run one, run a stage, or work through the lot in the order the project arrives.

Download all 31 skills. One zip: ready-to-install skill zips, readable SKILL.md files, and the evidence notes behind every method. Free, no signup. The same 31 skills are open on GitHub: polar-bear-org/claude-skills.

The 31 skills you get

The set follows the project, in eight stages: starting it, stopping scope creep, estimating and scheduling, catching risks early, getting decisions made, running the delivery rhythm, reporting honestly, and closing well.

1 · Start the project

1. Project Charter

Use when: The project arrived as one sentence, with no sponsor named

Output: Outcome-based objectives with success measures, sponsor and project manager authority by role, high-level scope with named exclusions, milestones, a budget envelope and a sign-off block

2. Kickoff Meeting Agenda

Use when: You want the kickoff to settle scope, owners and change handling

Output: A timed agenda with the hard questions — what done looks like, what is out, who decides, how changes are handled — a roles walkthrough, a pre-read, and the outputs to confirm by the end

3. Project Scope Statement

Use when: Every “small” ask is arguable because scope was never agreed

Output: In-scope deliverables with testable acceptance criteria, named exclusions, constraints and owned assumptions, and a sign-off block

2 · Stop scope creep

4. Change Request Form

Use when: Someone says “it's just one small change”

Output: The ask sized on time, cost, scope, quality and risk, the options — accept, defer, swap, reject — with a named decider and a date, and the change log entry

5. MoSCoW Prioritization

Use when: Scope, date and team are fixed and something has to give

Output: A Must, Should, Could and Won't-this-time list with the effort share per category, the drop order if a new Must arrives, and a sign-off line

6. Work Breakdown Structure

Use when: The project is one big blob and nobody can say what done contains

Output: A deliverable tree down to work packages with a 100% rule check, dictionary rows, a proposed owner per package, and a gaps list of forgotten work

3 · Estimate and schedule

7. Three-Point Estimate

Use when: Leadership wants a date before anyone has estimated

Output: PERT mean and spread per work package, the forgotten work listed, and a range with a confidence line for the whole project

8. Dependency Map

Use when: Nobody can see what is blocking what

Output: A cross-team and external dependency table, a text diagram of what blocks what, and the at-risk list

9. Critical Path

Use when: Everything is urgent and you need to know which slip moves the end date

Output: The activity network, a forward and backward pass, total float per activity, and the list of delays that move the end date

10. Gantt Chart

Use when: The Gantt got the project approved and has not been touched since

Output: A schedule table and a Mermaid Gantt chart, baseline against current dates, rolling-wave detail for the next period, and change notes

11. Resource Allocation Plan

Use when: Leadership wants twice what the team can deliver

Output: Demand by role and skill per period against capacity, the overloaded and bottleneck roles, levelling options with their date impact, and the trade-off for the sponsor

4 · Catch risks early

12. Pre-Mortem Analysis

Use when: Risks only surface after something nearly goes wrong

Output: Grouped failure reasons from the team, the top five turned into owned risks, and the plan changes to make now

13. Risk Register

Use when: The register was built at kickoff and never opened again

Output: Each risk worded as cause, event and effect, likelihood and impact scored on defined scales, an owner, a trigger, a response and a review date

14. RAID Log

Use when: The log died by month three

Output: The top risks from the register, assumptions with a test date, issues with owner and tolerance, dependencies with need-by dates, stale-entry flags, and the weekly review agenda

5 · Get decisions made

15. Stakeholder Map

Use when: Decisions stall because nobody is sure who decides

Output: The stakeholder list by role, a power and interest grid built on formal decision rights and how much the project changes each role's work, and a table of who decides what

16. RACI Matrix

Use when: A missed deadline traced back to nobody owning the task

Output: Deliverables against roles with exactly one Accountable per row, gaps and overloaded role columns flagged, and the questions to settle in the room

17. Escalation Email

Use when: Six people are “reviewing” and nobody has a deadline

Output: One named decider asked for one decision by a date, the options with their impact, a recommendation, the default if no answer comes, and a short version for chat

18. Steering Committee Deck

Use when: The steering meeting became an update session

Output: The decisions needed first, then delivery confidence with its reasons, milestones against forecast, top risks, changes for approval, and draft resolutions for the minutes

19. Decision Log

Use when: Every review someone disputes what was decided last time

Output: Per entry: the decision, date, decider, options considered, reason, what it changes, a review date and a superseded-by link

6 · Run the delivery rhythm

20. Project Management Plan

Use when: The process is heavier than the project, or there is none

Output: One page: the lifecycle picked with a reason, only the meetings and documents this project needs, and the reporting cadence and tolerances

21. Meeting Minutes

Use when: People remember decisions differently

Output: Decisions, actions with one owner and a due date, risks raised and open questions only, plus a chat-ready summary and a same-day send note

22. Sprint Planning

Use when: Someone else committed the team to more than fits

Output: One sprint goal written as an outcome, the sprint's capacity by role, the items the team selected with its own estimates, a definition of done check, and what was left out and why

23. Kanban Board

Use when: Everyone is busy and nothing finishes

Output: Columns that match the real workflow, WIP limits per column and blocked markers, the four flow measures computed, and the oldest items to swarm

24. Sprint Retrospective

Use when: The same retro actions repeat for months

Output: Last retro's action reviewed first, a format picked for this sprint's question, the team's input grouped into themes, one improvement with an owner and a check date, and the items that belong above the team

7 · Report honestly

25. Project Status Report

Use when: “On track” every week has stopped meaning anything

Output: A one-screen weekly report with a subject line that carries the news, the asks at the top, and a RAG rating backed by written definitions and evidence

26. Burndown Chart

Use when: Leaders do not trust the dashboard

Output: A burndown and a burnup from the tracker export with the scope line shown separately, a two-sentence reading of the trend, and what the chart cannot show

27. Earned Value Management

Use when: There is a budget and a baseline, and you need a number

Output: A planned value, earned value and actual cost table, SPI, CPI and a forecast at completion in plain words, and a one-line verdict for the status report

28. Communication Plan

Use when: Sixty people got the go-live email and few opened it

Output: An audience table, one cut of the status per audience, go-live and change announcements, and a check that the key messages were read

8 · Close well

29. Lessons Learned

Use when: The lessons register is full and nobody reads it

Output: A blameless review of what was planned against what happened and why, what to sustain and improve, and each lesson turned into an owned action or a template change

30. Project Closure Report

Use when: The team is moving on and the project never formally ends

Output: Objectives against results, acceptance status per deliverable, final schedule and cost against baseline, open items with new owners, a benefits owner with review dates, and sponsor sign-off

31. Project Handover

Use when: The project passes to operations or another project manager

Output: Acceptance criteria met or not, open items and known issues with workarounds, contacts by role, the support period, access and documents, and the receiver's confirmation checklist

Where to start, and what the pack rests on

There is no compulsory sequence. You bring one real thing — the email that started the project, last week's RAID log, the tracker export, the notes from a meeting nobody minuted — and open the skill that matches what is loudest this week. The order in the catalogue is the order a project arrives in: the mandate first, because a scope nobody agreed is what every later argument traces back to.

Several of them chain. proj-project-charter sets the mandate and proj-project-scope-statement makes it testable, which is what proj-change-request-form then measures a "small" ask against. proj-work-breakdown-structure feeds proj-three-point-estimate, whose ranges feed proj-critical-path and proj-gantt-chart. The top five failure reasons from proj-pre-mortem become entries in proj-risk-register, reviewed every week in proj-raid-log. proj-project-status-report takes its evidence from proj-burndown-chart and proj-earned-value-management, and anything it cannot resolve leaves as proj-escalation-email or a decision in proj-steering-committee-deck. At the end, proj-lessons-learned, proj-project-closure-report and proj-project-handover close it out.

The pack is research-informed, not validated. A scan of what project, delivery and programme managers say they struggle with set the order of the skills and the words in each "use when": public posts and searches collected on 27 September 2026, about 600 raw items, of which 189 carried a real struggle, grouped into 15 struggles. Reddit leans to venting and to people new to the job, the agile communities lean to scrum masters and coaches, LinkedIn leans to leaders, consultants and vendors, and relevance search is not a random sample, so the counts show emphasis in what was pulled, not prevalence across the profession. The methods themselves come from public guidance and originator pages — the GOV.UK Teal Book on governance, change, risk and handover, the US GAO Schedule Assessment Guide on a reliable critical path, NASA and the US DoD on earned value, the Infrastructure and Projects Authority on delivery confidence as "a judgement not a calculation", the Agile Business Consortium on MoSCoW, the Institute of Risk Management on RAID, the Scrum and Kanban guides, Klein (2007) on the pre-mortem, Mendelow (1981) on stakeholder mapping, Buehler, Griffin and Ross (1994) on the planning fallacy, Flyvbjerg (2008) on optimism bias, and the PMI learning library on the charter, the scope statement, the WBS, RACI and close-out. The one shared file in the pack, resources/evidence-and-sources.md, lists them source by source with the finding used and the limit on it. No skill here has been tested in a trial.

Setup guide

1. Download the pack. One zip: an install folder with 31 ready-to-upload skill zips, a skills folder with the same 31 skills as readable SKILL.md files, and the evidence notes — resources/evidence-and-sources.md — which name the source behind every method and where it stops.
2. Install your skills. In Claude Code, add the marketplace and install ai-for-project-management-pack, and all 31 load at once. In Claude, turn on code execution in Settings, Capabilities, then go to Customize, Skills and upload one zip per skill from the install folder. Prefer working from files? Add the SKILL.md files to your Project knowledge instead; it works, just less cleanly.
3. Bring one real thing from the project. No connector, no integration, no admin: every skill works from what you paste — the email that started the project, last week's RAID log, the tracker export, the transcript of the meeting nobody minuted. Start with whatever is loudest this week and write "run proj-project-status-report". Where you have little, each skill starts from the minimum and marks what is still to find.

Where to start

The quality bar

Every skill in the pack holds the same standard, the one we hold when we run our own projects:

• One artifact per skill, the same shape every time, and it says what to paste, when not to use it and when it is done
• The maths is done, not named: PERT ranges with spread, the critical path with float, SPI and CPI with a forecast
• Every number comes with the case where it misleads, so nobody reports a figure they cannot defend
• Every status rating cites its evidence in words, and nothing is marked green that the evidence does not support
• Every decision, action and risk has a named owner and a date, and every log entry has a review date
• Nothing grades, ranks or profiles people: capacity is shown by role and skill, stakeholders by decision rights, never by attitude or output per person
• The red line: Claude plans and tracks — the people doing the work commit to the dates, and no status goes green to dodge a hard conversation

Who made this

Polar Bear is a people ops consultancy for human-size teams (20 to 200 people). Built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. This pack is the free, self-serve version of how we work.

The pack carries one project manager's work. When you want your whole team working this way, AI carrying the overhead so people do the part only people can do, across delivery, management and everyday operations, that's what we build with clients.

Meet Pauline. Green every week until it isn't? Bring the plan, last week's status, or the scope nobody agreed — we'll look at what the evidence supports. Book a 30-minute call · Pauline on LinkedIn

Install in Claude Code

Two lines, and every skill in the pack loads at once.

/plugin marketplace add polar-bear-org/claude-skills
/plugin install ai-for-project-management-pack@polar-bear-skills

Using Claude on the web instead? Download the zip and upload each skill from its install folder under Customize → Skills.