project-charter

TL;DR — Produces a complete, stakeholder-ready project charter that formalizes scope, authority, budget, and success criteria into a single source of truth for project initiation.

---

When to Activate

Invoke this skill when any of these conditions are met:

Signal	Examples
Explicit request	"Create a project charter for X", "Draft an acta de constitucion"
Kickoff preparation	"We need a kickoff document before the steering committee meets"
Scope formalization	"Let's document what's in and out of scope for this initiative"
Governance need	"The PMO requires a formal initiation artifact before we allocate budget"

Do not activate for lightweight task tracking, sprint planning, or informal project briefs that lack budget and governance dimensions.

---

1. Input Analysis & Context Gathering

Before drafting, extract or request the following baseline information:

• Project name and code — the canonical identifier used across tools and governance.
• Business case — the problem being solved, the opportunity being captured, or the compliance mandate being addressed. Quantify impact where possible (revenue, cost savings, risk reduction).
• Sponsorship chain — executive sponsor, project manager, key decision-makers. Map to RACI if more than five stakeholders.
• Known constraints — budget ceiling, hard deadlines, technology mandates, regulatory boundaries.
• Existing artifacts — any discovery documents, proposals, or pre-analysis that feed into the charter.

If the user provides fewer than three of these dimensions, enter clarification mode and ask targeted questions before proceeding.

---

2. Charter Structure & Content Blocks

The generated charter follows this canonical structure:

1. Header Block — project name, code, date, version, classification level.
2. Business Case — problem statement, strategic alignment, expected ROI or value delivered.
3. Objectives — SMART goals (Specific, Measurable, Achievable, Relevant, Time-bound). Maximum five primary objectives.
4. Scope Definition — explicit in-scope items as a numbered list; explicit out-of-scope items as a separate numbered list. Ambiguous items flagged as [OPEN].
5. Stakeholder Register — table with Name, Role, Influence Level (H/M/L), Interest Level (H/M/L), Communication Preference.
6. Milestone Schedule — table with Milestone, Target Date, Owner, Dependencies, Acceptance Criteria.
7. Budget Range — order-of-magnitude estimate with confidence band (e.g., USD 120K-160K at 70% confidence). Breakdown by phase if available.
8. Risk Register — top 5-8 risks with Probability (H/M/L), Impact (H/M/L), Mitigation Strategy, Owner.
9. Success Criteria — measurable conditions that define project success, linked back to objectives.
10. Assumptions & Constraints — numbered list with evidence tags.
11. Approval Block — signature table with Name, Role, Date, Signature placeholder.

---

3. Output Formatting

• Markdown mode (default): clean GitHub-flavored markdown with tables and horizontal rules.
• HTML mode: when the user requests "branded" or "HTML" output, generate a self-contained HTML document with inline CSS using the JM Labs design tokens (navy headers, system font stack, 8px grid, bordered tables).
• Always include a metadata footer: Generated by project-charter skill | {date} | v1.0.

---

4. Iterative Refinement Protocol

After the first draft:

1. Present the charter with a quality self-assessment checklist.
2. Highlight any sections marked [OPEN] or [INFERRED] and prompt the user for confirmation.
3. Offer to adjust scope, add risks, or reformat as HTML.
4. On final approval, write the artifact to disk at the path the user specifies or propose ./output/project-charter-{slug}-{date}.md.

---

Trade-off Matrix

Dimension	Priority	Rationale
Completeness	HIGH	A charter with missing sections loses governance credibility
Brevity	MEDIUM	Executives skim; keep each section concise but sufficient
Visual polish	MEDIUM	HTML mode elevates perceived quality for steering committees
Speed	LOW	Thoroughness matters more than turnaround for initiation docs

---

Assumptions & Limits

1. The user provides or confirms the business case — the skill does not fabricate financial projections. [EXPLICIT]
2. Budget figures are order-of-magnitude unless the user supplies detailed estimates. [EXPLICIT]
3. Stakeholder influence/interest ratings are inferred from role descriptions unless corrected. [INFERRED]
4. The skill does not replace PMO governance review — the charter is a draft for human approval. [EXPLICIT]
5. Risk register covers top risks only; a full risk assessment requires the risk-assessment skill. [EXPLICIT]

---

Edge Cases

1. No budget information available — generate the charter with a "Budget TBD" placeholder and add a risk entry: "Unquantified budget increases probability of scope creep."
2. Single-person project — collapse the stakeholder register to a single row, simplify RACI to owner-only, and note that lightweight governance applies.
3. Multi-phase initiative — generate a master charter with per-phase scope sections and a consolidated milestone timeline. Flag inter-phase dependencies.
4. Charter amendment — if the user provides an existing charter for update, diff the changes and produce a versioned amendment rather than a full rewrite.

---

Good vs Bad Example

Good output (excerpt):

### 3. Objectives
1. Reduce customer onboarding time from 14 days to 5 days by Q3 2026. [EXPLICIT]
2. Achieve 90% self-service completion rate for Tier-1 accounts. [EXPLICIT]
3. Integrate with Salesforce CRM by milestone M3. [EXPLICIT]

### 4. Scope
**In scope:**
1. Redesign of onboarding wizard (web + mobile)
2. API integration with Salesforce and HubSpot
3. Automated welcome-email sequence

**Out of scope:**
1. Legacy system decommissioning (Phase 2)
2. Billing module changes

Bad output (excerpt):

### Objectives
- Make onboarding better
- CRM stuff
- Emails

### Scope
We will do the onboarding project and related things.

The good example uses SMART objectives, evidence tags, and explicit in/out scope. The bad example is vague, unmeasurable, and lacks boundary definition.

---

Validation Gate

Before delivering the charter, confirm every item:

• Frontmatter contains name, description, model, context, allowed-tools with no angle brackets
• Business case section includes quantified impact or explicit [OPEN] tag
• At least three SMART objectives are defined
• Scope has separate in-scope and out-of-scope lists with numbered items
• Stakeholder register contains at least one executive sponsor row
• Milestone table has target dates and owners for every entry
• Budget section states confidence level or marks as TBD with associated risk
• Risk register contains at least five entries with probability, impact, and mitigation
• Success criteria are measurable and traceable to objectives
• Approval block includes signature placeholders
• All unconfirmed data tagged [INFERRED] or [OPEN]
• Output file written to disk at confirmed path

---

Reference Files

File	Purpose
references/charter-template.md	Canonical charter markdown template
references/body-of-knowledge.md	PMI/PRINCE2 charter standards and best practices
references/html-template.html	Branded HTML output template with JM Labs design tokens
evals/evals.json	Evaluation scenarios for charter completeness and quality