How I built grill-with-pmp — a Claude skill that interviews you into a complete set of project-management documents, modelled on the project lifecycle taught in LinkedIn's Project Management Foundations.
The problem with project templates
Every project-management course ends the same way: a zip file of templates. A charter template. A RACI template. A risk register with three example rows and a lot of empty cells. They look professional. They feel like a head start.
Then you open the charter template on a real project and type "improve customer experience" into the Objectives box, "TBD" into the budget, and "various stakeholders" into the stakeholder field. The template didn't make your thinking sharper — it just gave your fuzzy thinking somewhere official-looking to live.
The problem is that a template is passive. It asks nothing of you. It can't tell that "improve customer experience" isn't a SMART objective. It can't notice that you listed user training as a deliverable but never put it in the schedule or assigned anyone to it. It can't push back when you make yourself accountable for everything and therefore for nothing.
A good project manager — or a good mentor reviewing your plan — does all of those things. They grill you. "Improve it by how much, measured how, by when?" "Who actually signs off on that?" "If the vendor slips two weeks, does the launch date move or do we cut scope? Decide now."
That conversation is where the value is. So I built a tool that has it with you.
The inspiration: grill-with-docs
The shape of the idea comes from Matt Pocock's
grill-with-docs,
a Claude skill for engineers. Its premise is simple and a little confrontational: before you write
code, it interviews you "relentlessly about every aspect of this plan until we reach a shared
understanding," one question at a time, challenging fuzzy terminology against your codebase and
documenting decisions inline as they crystallise.
What makes it work isn't the documents it produces — it's the interrogation. The skill walks down each branch of your design, resolves dependencies one at a time, and refuses to let you get away with vague language.
I wanted that exact energy, but pointed at project management instead of domain modelling.
The result is grill-with-pmp: grill me to
create project and management documentation.
Anchoring it in real curriculum
A grilling tool is only as good as the questions it asks. I didn't want to invent a personal theory of project management — I wanted the skill to ask the questions a foundational PM course would teach you to answer.
So I anchored the whole thing to LinkedIn Learning's Project Management Foundations (Bob McGannon's course). Its lifecycle is the spine of the skill:
Initiate → Plan → Execute → Monitor & Control → Close
And its chapters map almost one-to-one onto the documents a project actually needs:
| Course chapter | Document it powers |
|---|---|
| First things first | Project Charter |
| Develop a project plan | Stakeholder Register, Scope Statement, Work Breakdown Structure |
| Build a project schedule | Project Schedule (critical path) |
| An overview of agile | Schedule — agile variant (backlog + sprints) |
| Work with teams | RACI Matrix |
| While you run the project | Communication Plan, Risk Register, Budget, Status Report |
| Monitor & control | Change Log |
| Close a project | Project Closure Report + lessons learned |
That mapping is now baked into the project's README, because the tool is explicitly not a substitute for learning. The grilling only produces good documents if you can recognise a good answer when the skill pushes back. The intended workflow is: study the course first, then use the tool to build your real projects.
How the grilling actually works
The skill is a single SKILL.md plus a folder of templates. But the templates aren't fill-in-the-
blank forms — each one carries the questions to grill for it and a definition of done. The
SKILL.md ties them together with a set of behaviours that make the conversation feel like a
planning workshop run by a senior PM.
A few of the rules it follows:
It asks one question at a time, and always recommends an answer. You're never staring at a blank page. The skill proposes a SMART objective, a scope boundary, a risk response — and you confirm or correct it. Editing a draft is far easier than authoring from nothing.
It forces objectives to be SMART. Say "make it faster" and it comes back with "faster by how much, measured how, by when?" It won't write the objective down until it has a number and a date.
It polices the scope boundary constantly. Every deliverable you name, it asks "in scope or out?" Every time you describe work the objective doesn't justify, it flags scope creep. The explicit out-of-scope list is treated as just as valuable as the in-scope one — because that's where hidden assumptions hide.
It demands a single accountable owner. For every deliverable and every risk response: one name, not a committee. "Two people can't both be ultimately accountable — who signs off if they disagree?"
It stress-tests risks with scenarios. A risk isn't "bad weather." It's "if a storm hits in week 3, then the outdoor install stops, causing a one-week slip." Then: "walk me through what we actually do the day that happens." If the response doesn't survive the scenario, it isn't a real response.
The part I'm proudest of: cross-referencing
Here's the discipline that separates a real plan from a folder of nice-looking documents. The skill continuously checks that the documents agree with each other:
- Every deliverable in the scope statement appears in the WBS.
- Every WBS work package maps to a scheduled task with an owner and a duration.
- Every stakeholder in the register appears in the communication plan and the RACI.
- Every high or critical risk has an owner and a response.
- The budget rolls up from the WBS, not from a guess.
When it finds a mismatch, it surfaces it out loud:
"Your scope lists user training as a deliverable, but there's no training task in the schedule and no owner in the RACI — which document is wrong?"
That single sentence is the kind of thing that, on a real project, gets caught three weeks before go-live by an exhausted PM at 11pm — or doesn't get caught at all. Having it caught at planning time is the whole point.
The document set
Twelve templates, each with structure, grilling questions, and a definition of done:
- Project Charter — authorises the project; sponsor vs. PM, SMART objectives, business case.
- Stakeholder Register — interest/influence analysis and engagement strategy.
- Scope Statement — deliverables with acceptance criteria, and an explicit out-of-scope list.
- Work Breakdown Structure — deliverable-oriented decomposition of the work.
- Project Schedule — milestones, dependencies, the critical path; plus an agile variant (backlog → sprints → release).
- RACI Matrix — exactly one Accountable per row, no exceptions.
- Risk Register — cause → event → effect, scored by probability × impact, owned responses.
- Communication Plan — who needs what, how often, in what format, with an escalation path.
- Budget — built bottom-up from the WBS, with a basis of estimate per line.
- Status Report — a one-minute RAG heartbeat for execution.
- Change Log — change control with impact assessment before decision.
- Project Closure Report — objectives vs. outcomes, acceptance, and actionable lessons learned.
Testing for consistency — does it actually work?
A skill that produces beautiful documents for one project but falls apart on the next isn't useful. The real requirement was consistent, relevant output across very different kinds of project. So I tested it the way you'd test any generator: run it on diverse inputs and verify the output holds up.
I generated three complete document sets by following the skill, choosing deliberately different project types:
- Healthcare EHR migration — a regulated IT project (the kind of case study the course itself uses). Full set, including budget, a status report, and a closure report.
- Mobile app launch — an agile product effort, exercising the release/sprint-plan variant.
- Office relocation — a non-software, physical project, to prove the templates generalise beyond IT.
Then I wrote a validation harness, scripts/validate-docs.sh, that checks each set for
structural completeness and internal consistency:
- Required documents and sections exist.
- Charter objectives are measurable (contain an actual number).
- The out-of-scope list is non-empty.
- Every deliverable traces from the scope statement into both the WBS and the RACI.
- Every RACI deliverable row has exactly one Accountable.
Across the three example projects:
== Summary == PASS=78 FAIL=0
Seventy-eight checks, zero failures, across a healthcare migration, an agile app launch, and a physical office move. The same skill, the same discipline, three completely different domains — and the documents stay complete and consistent every time. That's the evidence that the grilling isn't just theatre; it produces plans that actually hang together.
Try it
# Install as a Claude Code skill
cp -r skills/grill-with-pmp .claude/skills/grill-with-pmp
# or with the skills CLI
npx skills add https://github.com/grvpanchal/grill-with-pmp --skill grill-with-pmp
Then invoke it and answer the first question: "In a sentence, what is this project and what does
done look like?" From there it walks the lifecycle, building each document into docs/project/
as your answers crystallise — and pushing back whenever they don't.
But study the course first. The tool keeps you honest; it can't do the knowing for you.
grill-with-pmp is modelled on grill-with-docs by Matt
Pocock and aligned to LinkedIn Learning's Project Management Foundations.
Source and worked examples: github.com/grvpanchal/grill-with-pmp.
No comments:
Post a Comment