Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From ai-pm-assistant
Generates a complete project charter from a brief or intake summary, formalizing rough ideas into an official document with purpose, scope, risks, and budget.
npx claudepluginhub erica-j-01/ai-pmHow this skill is triggered — by the user, by Claude, or both
Slash command
/ai-pm-assistant:charter <project brief or intake summary><project brief or intake summary>This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
$ARGUMENTS
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Explores codebases via GitNexus: discover repos, query execution flows, trace processes, inspect symbol callers/callees, and review architecture.
Share bugs, ideas, or general feedback.
$ARGUMENTS
If no input is provided above, ask: "Please share the project brief or intake summary - project name, problem, sponsor, timeline, and budget if known."
A charter needs at least these five things. If fewer than three are provided, ask before writing:
| Input | Why it matters |
|---|---|
| Project name + one-line description | Anchors everything else |
| Business problem being solved | Without this, the purpose section is meaningless |
| Sponsor (person with budget authority) | No sponsor = no authorisation |
| Rough timeline or deadline | Shapes scope and constraints |
| Budget range | Even a ballpark - needed for the budget section |
If the user says "just assume" - do so, mark every assumption [assumed], and list them all at the bottom.
Use this structure exactly.
Project: [Name] Date: [Today] | Version: 1.0 Prepared by: [PM name or role]
[2-3 sentences. What problem does this solve? What gets better when it's done? Focus on the business pain, not the solution.]
What success looks like - specific enough to verify:
In scope:
Out of scope:
| Deliverable | What it is | Due |
|---|---|---|
| [Name] | [Brief description] | [Date or phase] |
| Name / Role | Responsibility |
|---|---|
| [Sponsor] | Final decisions, budget authority |
| [PM] | Day-to-day delivery |
| [Others] | [Their role] |
| Milestone | Target Date |
|---|---|
| Project start | [Date] |
| [Key milestone] | [Date] |
| Go-live / delivery | [Date] |
| Item | Amount |
|---|---|
| Estimated delivery cost | [Amount or range] |
| Contingency (10-15%) | [Amount] |
| Budget owner | [Name / role] |
| Risk | Likelihood | Impact | Response |
|---|---|---|---|
| [Specific risk event] | H/M/L | H/M/L | Mitigate / Accept / Escalate |
Keep to 3 risks maximum. These are headline risks only - a full risk scan is a separate step.
Constraints (fixed - cannot change):
Assumptions (believed to be true - must be validated):
| Role | Name | Date | Signature |
|---|---|---|---|
| Sponsor | |||
| Project Manager | |||
| [Other approver] |
All [assumed] items from above - the sponsor should confirm or correct each before sign-off:
| Assumption | Why assumed | Who should confirm |
|---|---|---|
| [assumed item] | [Reason] | [Role] |