Run a AAA Game Studio's Worst Sprint

Introduction

30 Second Summary

Every senior project manager faces the same nightmare scenario: multiple teams, simultaneous deadlines, and two squads in freefall. The question is never whether chaos will arrive. It's whether you have the command center to survive it.

In this project, you will step into the role of Senior PM at a AAA game studio with five teams racing toward a combined release window. You'll build a full program management War Room, author crisis-recovery artifacts grounded in PMBOK 8 standards, and deliver a data-backed executive pitch to save the quarter.

What You'll Build

A multi-team program command center with integrated PMP artifacts, interactive visual dashboards, and a TTS-narrated executive pitch deck.

By the end of this project, you'll have:

• A GitHub Projects program board with roadmap, kanban war room, and triage views tracking 5 parallel release teams.
• 4 sponsor-ready PMP artifacts (Project Charter, Risk Register with EMV analysis, Stakeholder Matrix, RACI) version-controlled in a GitHub repository.
• Interactive HTML artifacts including a Chart.js KPI dashboard, a Mermaid.js dependency topology, a risk heatmap, and a 5-minute TTS-narrated pitch deck ready to present to the Division Director.
• Secret Mission: Automate daily program status reporting with a GitHub Actions workflow.

Are there any prerequisites?

You don't need a PMP certification or formal project management training. Basic familiarity with project management concepts (sprints, backlogs, stakeholders) and comfort using AI assistants is enough to get started.

You'll need a Claude Desktop App with a Max subscription, a free GitHub account, and basic GitHub navigation skills.

Before We Start

Before We Start...

Set Up Your War Room Environment

Every War Room needs infrastructure before the crisis hits. You need a place to track work across all 5 teams, a place to monitor sprint execution for your two crisis teams, and a command center where your AI advisors live.

In this step, you will configure Claude as your multi-persona advisory board, stand up your GitHub program tracking system, and create your Linear sprint workspace for the two teams in crisis.

In this step, get ready to:

• Configure a Claude Project with 3 expert personas and the full Shinra scenario brief.
• Create a GitHub repository and Projects board with 3 operational views.
• Sign up for Linear and configure 2 crisis team workspaces with sprint cycles.

Configure Claude Project with persona system

Your War Room runs on expert advisors. Instead of hiring three consultants, you will configure Claude to role-play as a Senior PMP Mentor, a skeptical Division Director, and a Standards Gate scorer. Each persona challenges your work from a different angle.

• Open the Claude Desktop App.
• Click your name or profile icon in the bottom-left sidebar.
• Click Projects in the left sidebar.
• Click New Project.
• Name the project Shinra War Room.

Now you need to set the system prompt that defines your 3 personas. This is the instruction Claude reads before every conversation in this project.

• In the project settings, find the Custom Instructions field (sometimes labeled Project instructions).
• Paste the following persona system prompt:

# Shinra War Room - Persona System

You operate as THREE distinct personas in this project. The user will address you by name to activate each persona.

## Persona 1: Maya Kisaragi (Senior PMP Mentor)
Role: Senior Program Management consultant with 15 years experience and PMP/PgMP certifications.
Behavior: Teaches PMBOK 8 principles, challenges vague language, demands measurable success criteria, explains how artifacts integrate (Charter scope feeds Risk Register, Stakeholders in Charter feed the Matrix, RACI clarifies cross-team ownership). Guides the learner through proper process without doing the work for them.
Activation: Address as "Maya" or ask for mentoring/guidance.

## Persona 2: Director Sephiros Tanaka (Division Director)
Role: Division Director at Shinra Digital Entertainment. Controls budget (EUR 3.2M quarterly). Approves or rejects program plans. Skeptical, data-driven, impatient with vague promises.
Behavior: Challenges recovery plans with pointed questions. Demands velocity data, EVM calculations, and concrete timelines. Will reject plans that lack evidence. Approves plans that demonstrate rigorous analysis and realistic commitments.
Activation: Address as "Director Tanaka" or submit artifacts for approval.

## Persona 3: PMP Exam Prep Mentor (Standards Gate Scorer)
Role: PMI certification examiner. Scores the learner's session against PMI Talent Triangle 2026 markers.
Behavior: At session end, evaluates across 3 dimensions: Ways of Working (proper PMBOK artifacts, tailoring, change control), Power Skills (communication effectiveness, handling pushback, leading through ambiguity), Business Acumen (connecting risks to business outcomes, EMV calculations, publisher relationship impact). Scores out of 15 markers.
Activation: Address as "Standards Gate" or request scoring.

What do these personas do?

Maya Kisaragi teaches you proper PMBOK process and pushes back when your artifacts are vague. Director Tanaka simulates a real executive review where your plan gets approved or rejected. The Standards Gate scorer maps your work to the PMI Talent Triangle 2026 framework at the end.

Together, they create a feedback loop that mirrors real Senior PM pressure: mentor guidance, executive scrutiny, and certification-level scoring.

Next, paste the scenario brief below the persona prompt. This gives all three personas the context they need about your teams and conflicts.

• Add a blank line after the persona system prompt, then paste the following scenario brief:

# Shinra Digital Entertainment - Q3 Combined Release Scenario

## Company Context
Shinra Digital Entertainment is a globally respected AAA gaming studio. Five product teams are racing toward a combined quarterly release window. Two teams are in active crisis. The Division Director has called pitch day.

## Your Role
Senior Project Manager reporting to Division Director Sephiros Tanaka. You own the program-level view across all 5 teams. You do not write code or ADRs - you review, align, and escalate.

## The Five Teams

### Team Bahamut (Core Engine)
- Lead: Kai Watanabe | Scrum Master: Rin Nakamura
- 10 engineers | Focus: Engine performance, memory management, matchmaking service
- Status: YELLOW - On track but making architecture decisions that affect other teams
- Conflict: Memory allocation ADR breaks Shiva's mobile port assumptions

### Team Leviathan (Content & Narrative)
- Lead: VACANT (resigned 3 weeks ago) | Scrum Master: Yuki Tanaka
- 8 engineers | Focus: Story content, cutscenes, art pipeline, quest system
- Status: RED - 0 velocity for 2 consecutive cycles, art pipeline blocked by external vendor
- Conflict: Sprint plan shows no progress but test strategy assumes full feature completion

### Team Ifrit (Backend Services)
- Lead: Marcus Chen | Scrum Master: Priya Patel
- 9 engineers | Focus: Server infrastructure, APIs, matchmaking backend, analytics
- Status: GREEN - On track
- Conflict: Dependent on Leviathan API that is now blocked

### Team Shiva (Mobile Port)
- Lead: Aisha Okafor | Scrum Master: Leo Fischer
- 8 engineers | Focus: Mobile optimization, touch controls, reduced asset pipeline
- Status: RED - Performance targets failing due to Bahamut engine changes
- Conflict: Bahamut's memory allocation ADR contradicts Shiva's mobile constraints

### Team Odin (Live Services & Esports)
- Lead: Jin Yamamoto | Scrum Master: Sara Lindberg
- 9 engineers | Focus: Live events, esports tournament system, seasonal content
- Status: YELLOW - Scope creep from Marketing Director adding unauthorized features
- Conflict: Implementation plan includes features never approved in any charter

## Key Stakeholders
- Director Sephiros Tanaka - Division Director, budget authority (EUR 3.2M quarterly)
- VP Hana Moriyama - Publisher Relations, owns external deadline commitments
- Director Kenji Suzuki - Marketing Director, source of Odin scope creep
- Director Mei Zhang - QA Director, controls release sign-off
- External: ArtForge Studios - Art vendor blocking Leviathan pipeline
- External: Global Esports League - Tournament date is immovable hard deadline

## Critical Deadlines
- Esports Tournament System: Hard external deadline from publisher (non-negotiable)
- Combined Q3 Release Window: All 5 teams must ship within same 2-week window
- Publisher milestone review: Director must present program status in pitch format

## Budget
- Total quarterly: EUR 3.2M across all 5 teams
- External vendor (ArtForge): EUR 180K contract, currently delivering at 40% capacity
- Contingency reserve: EUR 240K (7.5% of total)

Why put all this in the project instructions?

Claude Projects persist custom instructions across every conversation in the project. This means Maya, Director Tanaka, and the Standards Gate scorer all have instant access to team rosters, conflict data, and budget numbers without you re-pasting context every time.

• Click Save to confirm your project instructions.
• Start a new conversation in the Shinra War Room project.
• Type: Maya, confirm you can see the scenario brief. List the 5 teams and their status colors. and press Enter.

Maya should respond by listing all 5 teams (Bahamut YELLOW, Leviathan RED, Ifrit GREEN, Shiva RED, Odin YELLOW) and referencing the scenario details. This confirms your project instructions loaded correctly.

Maya doesn't recognize the teams?

Make sure you pasted both the persona system prompt and the scenario brief into the same Custom Instructions field. If they are in separate conversations instead of project instructions, the context will not persist.

Also confirm you are chatting inside the Shinra War Room project, not in a general conversation. The project name should appear at the top of your chat window.

Help me troubleshoot my Claude Project instructions not loading

Create GitHub repository and Projects board

Your GitHub repository stores all program artifacts (Charter, Risk Register, dashboards) under version control. The GitHub Project linked to it gives you three operational views for tracking work across all 5 teams.

• Open github.com in your browser and sign in to your account.
• Click the + icon in the top-right navigation bar.
• Select New repository.
• Enter shinra-war-room as the repository name.
• Check the box for Add a README file.
• Leave visibility as Public (or Private if you prefer).
• Click Create repository.

You should see your new shinra-war-room repository page with a single README.md file.

Now create the GitHub Project that will serve as your multi-team tracking board.

• Click the Projects tab in your repository's top navigation bar.
• Click Link a project, then select New project.
• Select the Board template as your starting layout.
• Name the project Q3 Combined Release - War Room.
• Click Create project.

What is a GitHub Project?

GitHub Projects is a flexible project management tool built into GitHub. It supports Table, Board, and Roadmap views with custom fields, filters, and grouping. On the free plan, you get up to 50 custom fields and a 50,000 item limit.

For this War Room, you will configure 3 saved views that each show a different angle of the same data: executive timeline, crisis triage, and detailed table.

Next, configure the three saved views. Each view gives a different stakeholder the information they need at a glance.

• In your new project, click the tab that says Board (your current default view).
• Click the down arrow next to the view name and select Rename.
• Rename it to War Room.
• Click the filter bar and add filters for: Status: Blocked and Priority: High. This view shows only items that need immediate attention.
• Click Save to save this view's filters.

• Click the + New view tab.
• Select Roadmap as the layout.
• Name this view Director View.
• Click Save.

• Click + New view again.
• Select Table as the layout.
• Name this view Triage Table.

Now add the custom fields that make the Triage Table useful for tracking cross-team blockers.

• In the Triage Table view, click the + column header to add a new field.
• Create a Single select field named Team. Add options: Bahamut, Leviathan, Ifrit, Shiva, Odin.
• Add another Single select field named Risk Priority. Add options: Critical, High, Medium, Low.
• Add a Number field named Blocker Age. This tracks how many days an item has been blocked.
• Add a Text field named Owner.
• Click Save to save the Triage Table view.

You should now see 3 tabs in your project: War Room, Director View, and Triage Table.

Don't see the custom fields?

Custom fields are view-specific by default. Make sure you are adding fields while viewing the Triage Table tab. If you added fields in the Board view, switch to the Table view and click the + column header to show hidden fields.

Help me set up custom fields in GitHub Projects

Sign up for Linear and configure crisis teams

GitHub Projects tracks your program-level view across all 5 teams. Linear handles something different: sprint-level execution data with velocity tracking and cycle burndowns. You need this granular data for Leviathan and Shiva because those are your crisis teams.

Why Linear instead of GitHub Issues?

Linear provides built-in velocity and capacity forecasting per cycle. GitHub Issues does not. When you need to answer "at current velocity, can Leviathan ship by the release date?" you need cycle-over-cycle velocity charts.

The free plan gives you 2 teams and 250 issues. That is exactly enough for your two crisis teams.

• Open linear.app in your browser.
• Click Sign up. You can sign up with your GitHub account or email.
• When prompted to create a workspace, name it Shinra Digital.
• Select the Free plan when prompted.

Skip the onboarding tour

Linear may offer a guided tour or suggest importing data. Skip these for now. You will populate issues manually in Step 2.

Now create your two crisis teams.

• Click Settings (gear icon) in the bottom-left sidebar.
• Under Workspace, click Teams.
• Click New team.
• Name the first team Leviathan.
• Click Create team.
• Repeat to create a second team named Shiva.

Next, enable Cycles for both teams. Cycles are Linear's time-boxed sprint mechanism with automatic velocity tracking.

• Click on Leviathan in the left sidebar to open the team.
• Click Settings for the Leviathan team (gear icon next to the team name, or via team settings).
• Find the Cycles section and toggle it to Enabled.
• Set cycle duration to 2 weeks.
• Click Save.
• Repeat for the Shiva team: enable Cycles with 2-week duration.

Finally, configure the workflow states that match your program's tracking needs.

• In Leviathan's team settings, find the Workflow section (sometimes under States).
• Verify or configure these states in order: Triage, Backlog, In Progress, In Review, Blocked, Done.
• If any states are missing, click Add state to create them. If Linear has default states you do not need, you can remove or rename them.
• Repeat the same workflow state configuration for the Shiva team.

Why add a Blocked state?

Most default workflows do not include a Blocked state. Adding it explicitly lets you filter for blocked items across teams. In Step 3, you will use this state to calculate how many issues are stuck and for how long.

Confirm your setup by checking that both teams appear in the left sidebar with their Cycles section visible.

Can't create a second team?

The Linear free plan allows exactly 2 teams. If you accidentally created a default team during onboarding, delete it first by going to Settings > Teams and removing the unused team.

Help me fix my Linear team setup

Your War Room infrastructure is ready. You have a Claude Project with three expert personas, a GitHub repository with a multi-view Projects board, and a Linear workspace with two crisis teams configured for sprint tracking. Next up, you will load the full scenario data and get a PMBOK crash course from Maya.

Download the Scenario and Framework Crash Course

Your War Room infrastructure is ready. You have a GitHub repo, a project board with three operational views, and a Linear workspace with two crisis teams configured.

Now you need the actual scenario data to fill it. Think of it like this: you built the command center, but the screens are blank. In this step, you will generate the full simulation dataset, get a rapid crash course on the PMP frameworks you will use today, and populate your tools with realistic program data.

In this step, get ready to:

• Generate the full Shinra scenario data pack (5 team rosters, pre-release artifacts, embedded conflicts) using Claude.
• Complete a PMBOK 8 crash course with your Maya Kisaragi mentor persona.
• Populate GitHub Issues, Milestones, and Linear cycles with scenario data.

Load the Shinra scenario data pack

A Senior PM walking into a real crisis would receive a briefing packet with team rosters, in-flight plans, and known issues. You will use Claude to generate this entire dataset as structured markdown files.

• Open your Shinra War Room project in Claude Desktop.
• Paste the following prompt to generate the full scenario data pack:

Generate the complete Shinra Digital Entertainment scenario data pack. I need:

1. **Team Rosters** (5 teams: Bahamut, Leviathan, Ifrit, Shiva, Odin)
   - Each team: 1 Lead, 1 Scrum Master, 8-10 Engineers
   - Include names, roles, and specializations
   - Note: Leviathan's Lead position is VACANT (this is a key risk)

2. **Pre-Release Artifacts per team** (each as a separate markdown section):
   - Architecture Decision Record (ADR) - key technical decisions made
   - Implementation Plan - current sprint scope and approach
   - Sprint Plan - velocity targets and capacity allocation
   - Test Strategy - QA approach and coverage targets
   - Risk Assessment - team-level risks identified

3. **Embedded Conflict Scenarios** (hide these naturally in the artifacts):
   - Bahamut's memory allocation ADR MUST conflict with Shiva's mobile port requirements
   - Leviathan's sprint plan MUST show 0 velocity for 2 consecutive cycles, but their test strategy assumes full feature completion
   - Odin's implementation plan MUST include 3 features that were never approved in any charter (unauthorized scope creep from Marketing Director)

Format each team as a separate markdown file structure. Use realistic gaming industry details (shader pipelines, netcode, asset streaming, mobile optimization, matchmaking services).

Output all content so I can save it as markdown files in my repository.

What does this prompt do?

This prompt generates your entire simulation dataset in one pass. The three embedded conflicts are the core of the exercise. You will discover them later in Step 3 when you audit the artifacts, exactly like a real Senior PM would find cross-team issues during a program review.

Claude generates fictional but realistic data. The conflicts are seeded deliberately so you can practice formal change control later.

Claude will output a large block of structured markdown. You need to commit this to your repository.

• Open your terminal and navigate to your shinra-war-room repository folder.
• Create the /teams directory and team files by running these commands:

mkdir -p teams
touch teams/bahamut.md teams/leviathan.md teams/ifrit.md teams/shiva.md teams/odin.md

• Copy Claude's output for each team into its respective file. Open each file in your code editor (or use the terminal with nano or vim) and paste the team's roster, ADR, implementation plan, sprint plan, test strategy, and risk assessment.
• Commit the scenario data to your repository by running:

git add teams/
git commit -m "feat: add scenario data pack - 5 team rosters and pre-release artifacts"
git push origin main

Why version-control scenario data?

In real program management, document control is a PMBOK Governance domain requirement. Every artifact has a version history. By committing to Git, you create an audit trail of when each artifact was created and modified.

• Confirm the files exist by running:

ls teams/

You should see five files listed: bahamut.md, leviathan.md, ifrit.md, shiva.md, and odin.md.

Push failing with authentication error?

If you see a 403 or authentication error when pushing, you may need to configure a Personal Access Token or SSH key for your GitHub account. GitHub no longer accepts password authentication for git operations.

Help me fix my GitHub push authentication error.

Complete the PMBOK 8 framework crash course with Maya

Before you start making program-level decisions, you need to understand the framework that underpins them. Your Maya Kisaragi persona is a Senior PMP mentor who will deliver a focused crash course tailored to your scenario.

• In your Shinra War Room Claude project, paste this prompt to engage Maya:

Maya, I need your 10-minute PMBOK 8 crash course before I start building program artifacts. Cover:

1. The 6 PMBOK 8 Principles - map each one to a specific situation in our Shinra scenario
2. The 7 Performance Domains I'll exercise today (Governance, Scope, Schedule, Finance, Stakeholders, Resources, Risk) - one sentence each on what I'll DO in each domain
3. PMI Talent Triangle 2026 - what are the 3 sides (Ways of Working, Power Skills, Business Acumen) and which markers will I be scored against?
4. Artifact Integration - explain how the Charter, Risk Register, Stakeholder Matrix, and RACI connect to each other. Which feeds which?

Keep it practical and tied to our 5-team crisis scenario. No textbook abstractions.

What will Maya cover?

Maya will explain the 6 PMBOK 8 principles: adopt a holistic view, focus on value, embed quality, lead accountably, integrate sustainability, and build empowered teams. Each maps to a real situation you will face in the scenario.

She will also explain how your four artifacts integrate. The Charter establishes scope that the Risk Register analyzes. Stakeholders identified in the Charter feed the Stakeholder Matrix. The RACI clarifies who does what across all 5 teams.

• Read through Maya's crash course carefully. This is your reference framework for every artifact you build in Steps 4 and 5.
• If any concept is unclear, ask Maya follow-up questions. She adapts her explanations to your scenario.

What is the PMI Talent Triangle?

The PMI Talent Triangle 2026 has three sides. Ways of Working covers your methodology (did you use proper artifacts, tailoring, change control?). Power Skills covers communication and leadership (did you handle pushback, lead through ambiguity?). Business Acumen covers strategic thinking (did you connect risks to business outcomes, calculate EMV?).

In Step 7, the PMP Exam Prep Mentor will score you against 15 markers across all three sides. Target: 12+ markers addressed.

Populate GitHub and Linear with scenario data

Your tools are empty shells until you fill them with the scenario data. In this substep, you will create milestones, issues, and sprint data so your War Room views actually show program health.

• In your Claude project, paste this prompt to generate issue data for GitHub:

Generate GitHub Issues data for my Shinra War Room. I need:

**Milestones** (one per team, representing their release date):
- Bahamut: "Bahamut v2.1 Release" - due in 6 weeks
- Leviathan: "Leviathan Content Drop 4" - due in 4 weeks
- Ifrit: "Ifrit Expansion Launch" - due in 5 weeks
- Shiva: "Shiva Mobile Port GA" - due in 4 weeks
- Odin: "Odin Season 3 Update" - due in 5 weeks

**Issues** (8-12 per team, mix of features, bugs, blockers, dependencies):
- Each issue needs: title, label (team:bahamut, team:leviathan, team:ifrit, team:shiva, team:odin), priority (P0-Critical, P1-High, P2-Medium, P3-Low), and current status (Open, In Progress, Blocked)
- Leviathan and Shiva should have MORE blocked items (they are in crisis)
- Include cross-team dependency issues (e.g., "Blocked: waiting on Bahamut matchmaking API" for Odin)
- Include the conflict issues: Bahamut memory ADR blocking Shiva, Leviathan velocity collapse, Odin unauthorized features

Format as a table I can use to quickly create issues in GitHub.

Why this issue structure?

The labels (team:bahamut, team:leviathan, etc.) are what your GitHub Project views filter on. The "War Room" board view filters to Blocked + High Priority items. Without these labels, your views stay empty.

The priority field and status allow your "Triage Table" view to sort by severity. This is how real program managers triage across multiple teams.

Now create these items in GitHub.

• Go to your shinra-war-room repository on GitHub.
• Click the Issues tab.
• Click Milestones (next to the search bar).
• Click New milestone and create all 5 milestones with their titles and due dates from Claude's output.
• Return to Issues and click Labels.
• Create 5 team labels: team:bahamut, team:leviathan, team:ifrit, team:shiva, team:odin.
• Create 4 priority labels: P0-Critical, P1-High, P2-Medium, P3-Low.
• Create a blocked label (use red color for visibility).
• Click New issue and start creating issues from Claude's table. Assign each issue its team label, priority label, and milestone.

Speed up issue creation

You do not need to create all 50+ issues manually one at a time. Create 3-4 per team to populate your views, focusing on the blocked and high-priority items that will appear in your War Room board. The exact count matters less than having enough data to make your views functional.

• After creating issues, open your Q3 Combined Release - War Room project.
• Click + Add item at the bottom of any column and link your newly created issues to the project.
• Switch between your three saved views (Director View, War Room, Triage Table) to confirm issues appear correctly.

Your War Room board should now show blocked items for Leviathan and Shiva. The Triage Table should display all issues sortable by team and priority.

Issues not showing in your project views?

Make sure you added the issues to the project (not just created them in the repo). Issues exist in the repository but must be explicitly linked to a GitHub Project to appear in its views.

Also check that your War Room view filter is set to show Blocked + High Priority. If no issues have those labels, the view will appear empty.

Help me troubleshoot my GitHub Project views not showing issues.

Now populate Linear with sprint execution data for your two crisis teams.

• In Claude, paste this prompt to generate Linear cycle data:

Generate Linear cycle data for my two crisis teams. I need realistic sprint data that tells a story of decline:

**Team Leviathan** (content drop team, lead position VACANT):
- Cycle 1 (4 weeks ago): 28 points planned, 24 completed (healthy)
- Cycle 2 (2 weeks ago): 26 points planned, 8 completed (collapse begins - lead departed mid-sprint)
- Current Cycle: 20 points planned, 2 completed so far, 6 items Blocked
- Blocked reasons: "Art vendor deliverables 3 weeks late", "No technical lead to approve PRs", "Dependency on Ifrit API not ready"

**Team Shiva** (mobile port, performance crisis):
- Cycle 1 (4 weeks ago): 32 points planned, 30 completed (healthy)
- Cycle 2 (2 weeks ago): 30 points planned, 14 completed (Bahamut engine changes broke mobile build)
- Current Cycle: 24 points planned, 6 completed so far, 4 items Blocked
- Blocked reasons: "Bahamut memory allocation ADR incompatible with mobile RAM limits", "Performance regression - frame rate below 30fps on target devices", "Shared QA environment unavailable"

For each cycle, give me 8-10 issue titles with point estimates and status (Done, In Progress, Blocked, Backlog) so I can enter them in Linear.

• Open Linear in your browser at linear.app.
• Select the Leviathan team from the sidebar.
• Click Cycles in the team navigation.
• Your current cycle should already be active (you enabled 2-week cycles in Step 1). Create issues from Claude's output for the current cycle. Assign each issue a point estimate and set its status (Done, In Progress, Blocked, or Backlog).
• For blocked issues, click the issue and add a blocker reason in the description or a "Blocked" label.
• Repeat for the Shiva team.

What about past cycle velocity?

Linear's free plan does not let you backdate completed cycles. When you reference velocity data later in your artifacts and pitch deck, use the numbers Claude generated (Leviathan: 24 → 8 → 2, Shiva: 30 → 14 → 6). The current cycle's data will be live in Linear for you to reference.

Document the historical velocity in a comment or description on each team's cycle page so you can pull the numbers quickly during your Director pitch.

• After entering issues for both teams, click into each team's Cycles view.
• Confirm you see blocked items and point estimates. Leviathan should show 6 blocked items. Shiva should show 4 blocked items.

Hit the 250 issue limit on Linear free plan?

The free plan allows 250 issues total across both teams. If you hit this limit, reduce the number of issues per cycle. Focus on the current cycle's issues (8-10 per team) since those are what you will reference in your artifacts and pitch.

Help me manage my Linear free plan issue limit.

Your simulation is now live. GitHub shows the full program picture across 5 teams, and Linear reveals the velocity collapse that proves Leviathan and Shiva cannot ship at current pace. Next up, you will put on your auditor hat and review the pre-release artifacts for the cross-team conflicts hiding in plain sight.

Review Pre-Release Artifacts and Detect Conflicts

Your War Room is populated with data, but data alone does not save a quarter. The real value of a Senior PM is pattern recognition across teams.

In this step, you will review all 5 teams' pre-release artifacts, catch the conflicts hiding in plain sight, and process them through formal PMBOK change control. This is Integration Management in action. You are connecting dots that no individual team lead can see from their altitude.

In this step, get ready to:

• Audit all 5 teams' ADRs, implementation plans, and sprint plans to identify cross-team conflicts.
• Process 3 Change Requests through formal change control with Maya's guidance.
• Update Linear with blocker data and calculate velocity gaps as evidence for your Director pitch.

Audit team ADRs and implementation plans

Each team submitted pre-release artifacts (ADRs, implementation plans, sprint plans, test strategies) independently. Nobody reviewed them together. That is where cross-team conflicts hide.

• Open your Shinra War Room Claude Project.
• Send this prompt to Claude (Maya Kisaragi persona will guide the review):

Maya, I need to do a cross-team artifact review. Please pull up all 5 teams' ADRs and implementation plans from the /teams directory and help me identify:

1. Cross-team architecture conflicts (where one team's decisions break another team's work)
2. Internal inconsistencies (where a team's sprint plan contradicts their test strategy or timeline)
3. Unauthorized scope (features in implementation plans that were never approved in any charter or milestone)

Let's go team by team, then cross-reference.

What is an Architecture Decision Record?

An ADR is a short document that captures a significant technical decision, the context behind it, and its consequences. Teams write ADRs so future engineers understand WHY something was built a certain way.

The problem is that ADRs are written per-team. Nobody checks whether Team A's architecture decision breaks Team B's assumptions. That is your job as Senior PM.

Maya will walk you through the artifacts and highlight the three embedded conflicts. Confirm you can identify each one.

• Read Maya's analysis carefully. She will surface three specific conflicts:

• Conflict 1: Bahamut's memory allocation ADR breaks Shiva's mobile port. Bahamut increased their minimum memory footprint, but Shiva's mobile target devices cannot support it. This is a cross-team architecture conflict.
• Conflict 2: Leviathan's sprint plan shows 0 velocity for 2 cycles, but their test strategy assumes full feature completion. The team cannot pass tests on features they have not built. This is an internal inconsistency.
• Conflict 3: Odin's implementation plan includes features that were never approved in any charter or milestone. This is unauthorized scope creep, likely introduced by the Marketing Director.

• Ask Maya to confirm your understanding of each conflict by sending:

Maya, let me summarize what I found:

1. Bahamut/Shiva ADR conflict - Bahamut's memory allocation increase breaks Shiva's mobile targets
2. Leviathan internal inconsistency - 0 velocity for 2 cycles but test strategy assumes full feature completion
3. Odin unauthorized scope - implementation plan has features not in any charter

Did I catch everything? What PMBOK domain does this fall under?

Why does this matter for PMP?

This exercise maps directly to the PMBOK 8 Governance performance domain and the Integration Management focus area. The 2026 PMP exam (launching July 9, 2026) weighs Process at 41% of questions. Detecting conflicts across project boundaries and routing them through formal change control is a core Process competency.

Process change requests through formal change control

Identifying conflicts is not enough. A Senior PM formalizes them as Change Requests so the right people can make informed decisions. Maya will guide you through the PMBOK change control process.

• Open your shinra-war-room repository on GitHub.
• Click the Issues tab in the top navigation bar.
• Click Labels (next to the Milestones button).
• Click New label.
• Enter change-request as the label name.
• Choose a red or orange color to make it visually distinct.
• Click Create label.

What is change control in PMBOK?

Change control is the formal process for evaluating, approving, or rejecting modifications to project scope, schedule, or cost. Every change request needs: a description of the change, impact assessment across all constraints, affected stakeholders, and a recommendation.

Without change control, scope creep happens invisibly. With it, you have an auditable trail of decisions. Your GitHub Issues with the change-request label serve as your Change Request Log.

Now create one Change Request issue for each of the three conflicts you identified.

• In Claude, ask Maya to help you draft the Change Request content:

Maya, I need to create 3 formal Change Requests for the conflicts we identified. For each one, help me write:

1. Title (short, descriptive)
2. Description of the change/conflict
3. Impact assessment covering: Schedule, Cost, Quality, and Scope
4. Teams affected
5. My recommendation: Approve, Reject, or Defer — with justification

Start with CR-001: Bahamut memory allocation ADR breaking Shiva's mobile port.

• Work through all three Change Requests with Maya (CR-001, CR-002, CR-003).
• For each one, go back to GitHub and click New issue in the Issues tab.
• Paste the Change Request content from Claude into the issue body.
• Apply the change-request label to each issue using the Labels dropdown in the right sidebar.
• Also apply the relevant team labels (e.g. team:bahamut and team:shiva for CR-001).
• Click Submit new issue.

After creating all three issues, navigate to your Q3 Combined Release - War Room project. Your Change Request issues should appear in the Triage Table view.

Change Request issues not showing in your Project?

Issues created in a repo are not automatically added to a linked Project. You may need to manually add them. In your Project, click + Add item at the bottom of any view, then search for your Change Request issues by title or number.

help me add issues to my GitHub Project

Update Linear with blocker data and velocity adjustments

Your Change Requests document WHAT went wrong. Now you need to quantify HOW BAD things are. This means updating your Linear data with real blocker information and calculating whether recovery is mathematically possible.

• Open your Shinra Digital workspace in Linear at linear.app.
• Select the Leviathan team from the left sidebar.
• Open any issue that relates to the velocity/test-strategy conflict (features assumed complete but not built).
• Change the issue status to Blocked using the status dropdown.
• Add a comment explaining the blocker reason (e.g. "Blocked: test strategy assumes feature completion but team has 0 velocity for 2 cycles").
• Repeat for 2-3 relevant issues on the Leviathan team.

• Switch to the Shiva team in the left sidebar.
• Open issues related to the Bahamut memory allocation conflict (mobile port features that depend on the old memory footprint).
• Mark them as Blocked with a comment explaining the dependency on Bahamut's ADR resolution.

Now calculate the velocity gap. This is the evidence Director Tanaka will demand when you pitch your recovery plan.

• In Linear, click Cycles in the Leviathan team sidebar to view the velocity chart.
• Note the completed points for the last 2-3 cycles (this shows the velocity decline).
• Count the total remaining open issues in the current cycle.
• Return to Claude and ask Maya to help you calculate the gap:

Maya, I need to calculate the velocity gap for Leviathan and Shiva. Here's what I see in Linear:

Leviathan:
- Past 3 cycle velocities: [paste your numbers from Linear]
- Remaining issues in current cycle: [paste count]
- Cycles remaining before release date: [number from your milestone]

Shiva:
- Past 3 cycle velocities: [paste your numbers from Linear]
- Remaining issues in current cycle: [paste count]
- Cycles remaining before release date: [number from your milestone]

At current velocity, can each team complete remaining scope before their release date? Calculate the gap and tell me what this means for my Director pitch.

What is velocity forecasting?

Velocity is the average amount of work a team completes per cycle. If a team completed 20, 15, and 8 points over their last three cycles, their trend is declining. You can forecast: at 8 points per cycle with 3 cycles remaining, the team can complete approximately 24 more points.

If they have 60 points of remaining work, that is a 36-point gap. This gap is not opinion. It is math. Directors respect math.

• Save Maya's velocity gap analysis. You will reference this directly in Step 7 when Director Tanaka challenges your recovery plan.
• Copy the analysis into a new message or keep it accessible in your Claude conversation history.

Keep evidence for the Director pitch

In Step 7, Director Tanaka will specifically challenge you with: "You're asking me to cut Leviathan scope but you haven't shown me the velocity data that proves recovery is impossible at full scope." The gap analysis you just calculated is your direct answer to that challenge.

Not seeing velocity data in Linear Cycles?

Velocity charts only appear after at least one cycle has been completed. Make sure your past cycles have a completed status with issues marked as Done. If the chart is empty, check that you populated the past cycle data in Step 2.

help me see velocity data in Linear Cycles

You now have documented evidence of three cross-team conflicts, formal Change Requests filed, and quantitative proof that both crisis teams cannot deliver at full scope. Next up, you will author the program-level artifacts that tie all of this together into a coherent recovery narrative.

Author the Project Charter

You now have three cross-team conflicts documented and processed through formal change control. That is the intelligence-gathering phase complete.

But raw conflict data does not get Director approval. You need a Project Charter that formalizes the entire program's scope, authority, budget, and success criteria into a single document the Director can sign off on. The Charter is the document that gives you, the Senior PM, the authority to act.

In this step, get ready to:

• Draft a comprehensive Program Charter v1 using Claude as your AI co-author.
• Iterate through two review cycles with Maya Kisaragi and Director Tanaka personas.
• Commit the approved Charter v3 to your GitHub repository under version control.

Draft Charter v1 with Claude AI assist

A Project Charter is the formal document that authorizes a project to exist and gives the PM authority to apply resources. For a multi-team program like this, the Charter captures the combined scope of all 5 releases, defines what success looks like, and establishes your escalation authority.

• Open your Shinra War Room project in the Claude Desktop App.
• Send the following prompt to Claude to generate your Charter v1:

Draft a Program Charter for the Q3 Combined Release at Shinra Digital Entertainment.

Include these sections:
1. Project Purpose and Justification - why this combined release matters
2. Measurable Success Criteria - specific targets for each team's release
3. High-Level Scope - all 5 team releases (Bahamut, Leviathan, Ifrit, Shiva, Odin)
4. Development Approach - hybrid methodology with tailoring rationale for each team
5. PM Authority and Escalation Path - my authority as Senior PM and when to escalate to Director
6. High-Level Timeline - milestones for each team's release window
7. Budget Summary - team allocation across the EUR 3.2M quarterly budget
8. Key Stakeholders - who has influence and interest in this program
9. Known Risks - top risks from our earlier analysis

Use the team data and conflict information from this project's context. Make the success criteria specific but leave quality targets as general placeholders for now (we'll refine them in review).

What does this prompt do?

This prompt instructs Claude to pull from the scenario data already loaded in your project context (team rosters, conflict data, risk analysis). The Charter structure follows PMBOK 8 Governance domain requirements for project authorization.

Notice the deliberate instruction to leave quality targets as "general placeholders." This sets up the review cycle where Maya will push back on vague language.

• Review the generated Charter v1 output from Claude.
• Confirm it contains all 9 sections listed in your prompt.
• Copy the full Charter v1 text and save it temporarily in a local text file or keep it in your Claude conversation for the next substep.

What is a Project Charter?

In PMBOK 8, the Charter sits at the intersection of the Governance and Scope performance domains. It formally authorizes the project, names the PM, and establishes the boundaries within which the team operates.

A signed Charter is what separates "someone doing project work" from "an authorized PM with decision-making power." Without it, you have no formal authority to reallocate budget or cut scope.

Claude's output is missing sections?

If Claude skips sections or provides thin content, it may not have loaded the full project context. Scroll up in your Claude conversation and confirm the scenario data from Step 2 is visible. If not, re-paste the team roster summary and conflict data, then re-run the prompt.

Help me get Claude to generate a complete Charter with all 9 sections

Iterate through Maya and Director Tanaka reviews

A real Charter goes through multiple review cycles before it earns a signature. Your two reviewers will challenge the Charter from different angles. Maya focuses on professional standards rigor. Director Tanaka focuses on business viability and completeness.

• Submit your Charter v1 to the Maya Kisaragi persona by sending this prompt:

Maya, please review this Program Charter as my PMP mentor. Challenge any vague language, undefined metrics, or missing professional standards. Here is Charter v1:

[Paste your Charter v1 text here]

What should I expect from Maya?

Maya will push back on vague quality language. She will ask pointed questions like: "What specifically do you mean by 'quality targets'? Crash rate below what threshold? Player retention above what baseline?"

This models the real-world PMP expectation that success criteria must be measurable and unambiguous. "High quality" is not a success criterion. "Crash rate below 0.1% within 72 hours of launch" is.

• Read Maya's feedback carefully.
• Revise your Charter to address her challenges. Add specific crash rate thresholds and player retention baselines to your success criteria.
• Send your revised Charter v2 to Claude with this prompt:

Director Tanaka, I'm submitting the Program Charter for Q3 Combined Release for your review and signature. This is version 2, revised after standards review. Please assess whether this Charter gives you confidence that the program is recoverable and properly scoped.

[Paste your Charter v2 text here]

What should I expect from Director Tanaka?

Director Tanaka reviews from a business viability perspective. He will challenge three things: undefined success criteria for the two recovery teams (Leviathan and Shiva), the missing contingency plan for Leviathan's vacant team lead position, and the absence of the esports tournament hard deadline imposed by the publisher.

His pushback models what a real executive sponsor does. They do not care about process elegance. They care about whether this plan will actually deliver results on time.

• Read Director Tanaka's feedback.
• Revise the Charter to v3 by adding: explicit success criteria for Leviathan and Shiva recovery, a contingency plan for the vacant lead position, and the esports tournament hard deadline as a schedule constraint.
• Confirm Director Tanaka approves v3 by asking him to confirm his sign-off.

Keep all three versions

In professional PM practice, you maintain an audit trail of document revisions. Your Claude conversation history naturally preserves v1, v2, and v3. This is document control in action.

Commit the signed Charter to GitHub

A Charter that lives only in a chat conversation is not under configuration management. In PMBOK 8's Governance domain, approved artifacts must be version-controlled and traceable. Committing to Git gives you an immutable record of what was approved and when.

• Copy the final Charter v3 text from your Claude conversation.
• Open your shinra-war-room repository on GitHub.
• Click Add file then Create new file.
• In the filename field, type artifacts/project-charter.md to create both the folder and file.
• Paste your full Charter v3 content into the file editor.

Why type the full path?

When you type artifacts/ followed by the filename, GitHub automatically creates the /artifacts directory if it does not already exist. This is where all your PMP artifacts will live for the rest of the project.

• Scroll down to the Commit changes section.
• In the commit message field, enter:

docs: add Program Charter v3 - approved by Director Tanaka

• Select Commit directly to the main branch.
• Click Commit changes.

Why reference approval in the commit message?

The commit message creates a traceable audit trail. Anyone reviewing this repo's history can see exactly when the Charter was approved and by whom. This is configuration management in practice, a core skill in the PMBOK Governance performance domain.

• Navigate to your repository's root page.
• Click into the artifacts folder.
• Confirm you see project-charter.md listed.

You should see your Charter rendered as formatted markdown with all 9 sections visible.

Don't see the artifacts folder?

Make sure you typed artifacts/project-charter.md with the forward slash in the filename field. Without the slash, GitHub creates a file called artifactsproject-charter.md at the root level instead of creating a directory.

Help me commit my Charter to the correct folder path in GitHub

✔️ I can see project-charter.md in /artifacts

Your Charter is now under version control with a traceable approval record. This is the PMBOK Governance domain in action.

ⓧ I committed but something looks wrong

If the file content looks garbled or incomplete, click the pencil icon to edit and re-paste your Charter v3 content. Make sure you copied the complete text from Claude, not just a partial selection.

If the file is in the wrong location (root instead of /artifacts), delete the misplaced file and repeat the create step. Type the full path artifacts/project-charter.md in the filename field.

Your program now has a formally authorized Charter with measurable success criteria, recovery contingencies, and executive sign-off. Next up, you will build the Risk Register and Stakeholder Matrix that operationalize the risks and people named in this Charter.

Author Risk Register and Stakeholder Matrix

Your Charter v3 is signed, sealed, and committed. The Director knows your scope, your timeline, and your authority. Now you need to prove you understand what could go wrong and who you need to influence to keep things on track.

In this step, you will author the three artifacts that separate Senior PMs from PMs: a Risk Register with quantitative analysis, a Stakeholder Engagement Assessment Matrix using the C-D model, and a RACI Matrix that clarifies decision authority across 5 teams. These three artifacts integrate directly with your Charter. The risks you identify here flow from your Charter's scope. The stakeholders you map here are the people named in your Charter. The RACI decisions are the governance structure your Charter established.

In this step, get ready to:

• Build a Risk Register with 10+ risks including EMV quantitative analysis.
• Build a Stakeholder Engagement Assessment Matrix for 12+ stakeholders using the C-D model.
• Build a RACI Matrix for 10 program-level decisions and commit all artifacts to GitHub.

Build the Risk Register with qualitative and quantitative analysis

A Risk Register is the living document that captures every threat and opportunity your program faces. Each risk gets scored, assigned an owner, and paired with a response strategy so nothing catches you off guard.

What is Expected Monetary Value (EMV)?

EMV is a quantitative risk analysis technique. You multiply the probability of a risk occurring by its financial impact. For example, if there is a 40% chance the publisher charges a EUR 500,000 penalty for missing the deadline, the EMV is 0.4 x 500,000 = EUR 200,000.

EMV helps you compare risks on a common scale and justify budget reserves to stakeholders like Director Tanaka.

• In your Shinra War Room Claude Project, start a new conversation.
• Ask Maya Kisaragi to guide you through building the Risk Register. Use the following prompt as your starting point:

Maya, I need to build the program Risk Register for the Q3 Combined Release.

Please help me author a Risk Register with 10+ risks that covers:

**Execution risks (team-level):**
- Blocked art pipeline (Leviathan's external vendor dependency)
- Vacant team lead position (Leviathan)
- Performance targets at risk (Shiva mobile port frame rate)
- Cross-team API dependency (Leviathan API blocking Ifrit)
- Shared QA environment conflicts

**Strategic risks (program-level):**
- Publisher deadline penalty (esports tournament hard deadline)
- Cross-team dependency failure (Bahamut engine changes breaking Shiva)
- Scope creep from Marketing Director (Odin unauthorized features)
- Budget overrun from vendor escalation
- Key person dependency on Bahamut lead

For each risk, include: ID, description, category, probability (1-5), impact (1-5), PxI score, risk owner, response strategy (avoid/mitigate/transfer/accept for threats; exploit/enhance/share/accept for opportunities), trigger, and status.

For the publisher deadline penalty risk, include a full Expected Monetary Value (EMV) quantitative analysis showing the calculation.

Format as a markdown document suitable for committing to our GitHub repo.

What does this prompt do?

This prompt asks Maya to generate a comprehensive Risk Register using the scenario data already loaded in your Claude Project. The execution risks come from the team-level conflicts you discovered in Step 3. The strategic risks come from the program-level threats identified in your Charter.

The response strategies map to PMBOK 8's risk response categories. Threats use avoid, mitigate, transfer, or accept. Opportunities use exploit, enhance, share, or accept.

• Review Claude's response. Verify it includes at least 10 distinct risks with all required fields populated.
• Check that the publisher deadline penalty risk includes an EMV calculation showing probability multiplied by financial impact.
• If any risk is missing a field or uses a vague response strategy like "monitor closely," ask Maya to revise it with a specific PMBOK-aligned strategy.
• Copy the final Risk Register markdown output.

Challenge Maya on the PxI scores

Before accepting the scores, ask yourself: does a vacant team lead really score the same impact as the publisher deadline penalty? Push back if the scoring feels flat. Real Senior PMs calibrate their registers, not just fill them in.

• Open your shinra-war-room repository in GitHub.
• Navigate to the artifacts folder (the same folder where your project-charter.md lives).
• Click **Add file**, then **Create new file**.
• Name the file risk-register.md.
• Paste the Risk Register markdown into the file editor.
• In the commit message field, enter feat: add risk register with 10+ risks and EMV analysis.
• Click **Commit changes**.

You should now see risk-register.md listed alongside project-charter.md in your /artifacts directory.

Don't see the artifacts folder?

Make sure you're looking at the correct repository (shinra-war-room). If the artifacts folder doesn't appear, navigate to the repo root and check that your Charter commit from Step 4 is visible in the commit history.

help me find where my project-charter.md was committed in my GitHub repo

Build the Stakeholder Engagement Assessment Matrix

Your Charter named key stakeholders. Your Risk Register assigned risk owners. Now you need to understand where each stakeholder actually stands and where you need them to be.

What is the C-D model?

The C-D (Current vs Desired) model from PMBOK 8 maps each stakeholder's current engagement level against their desired level. The five levels are: Unaware, Resistant, Neutral, Supportive, and Leading.

The gap between current and desired tells you where to invest your communication energy. A stakeholder who is currently Resistant but needs to be Supportive requires a completely different strategy than one who is Neutral and needs to stay Neutral.

• In the same Claude conversation (or start a new one in your Shinra War Room project), prompt Maya to help you build the Stakeholder Matrix:

Maya, now I need to build the Stakeholder Engagement Assessment Matrix for the Q3 Combined Release.

I need to map 12+ stakeholders using the C-D model. Here are the stakeholders I've identified:

1. Director Sephiros Tanaka (Division Director)
2. Bahamut Team Lead
3. Leviathan Team Lead (vacant - acting lead)
4. Ifrit Team Lead
5. Shiva Team Lead
6. Odin Team Lead
7. Bahamut Scrum Master
8. Leviathan Scrum Master
9. Ifrit Scrum Master
10. Shiva Scrum Master
11. Odin Scrum Master
12. Publisher Relations VP
13. Marketing Director (source of Odin scope creep)
14. QA Director
15. External Art Vendor (Leviathan blocker)
16. Player Community Manager
17. Esports Tournament Organizer

For each stakeholder, provide:
- Current engagement level (Unaware / Resistant / Neutral / Supportive / Leading)
- Desired engagement level
- Gap (number of levels to move)
- Named movement strategy (specific actions I take as Senior PM)

Base the current levels on what we know from the scenario. For example, the Marketing Director is likely Resistant to scope cuts since they pushed unauthorized features into Odin's backlog.

Format as markdown for our GitHub repo.

Why 12+ stakeholders?

A real multi-team program has dozens of stakeholders. Twelve is the minimum to demonstrate you can differentiate between high-power stakeholders who need direct management (Director Tanaka, Publisher VP) and low-power stakeholders who need monitoring (Player Community Manager). The PMI Talent Triangle scores Power Skills on your ability to tailor engagement strategies to each group.

• Review Claude's response. Verify each stakeholder has all four fields: current level, desired level, gap, and movement strategy.
• Check that the movement strategies are specific actions, not generic advice. "Schedule weekly 1:1 with acting Leviathan lead to build trust" is good. "Communicate more" is not.
• Verify the current engagement levels make sense given the scenario conflicts. The External Art Vendor should not be marked as Supportive when they are actively blocking Leviathan's pipeline.
• Copy the final Stakeholder Matrix markdown output.
• In GitHub, navigate to your /artifacts folder and click **Add file**, then **Create new file**.
• Name the file stakeholder-matrix.md.
• Paste the Stakeholder Matrix markdown and commit with the message feat: add stakeholder engagement assessment matrix (12+ stakeholders, C-D model).
• Click **Commit changes**.

Your /artifacts folder should now contain project-charter.md, risk-register.md, and stakeholder-matrix.md.

Build the RACI Matrix and commit all artifacts

With 5 teams, a Director, and multiple support functions, decision authority gets murky fast. A RACI Matrix eliminates ambiguity by defining exactly who is Responsible, Accountable, Consulted, and Informed for each major program decision.

What do R, A, C, and I mean?

Responsible: the person doing the work. Accountable: the single person who approves or owns the final decision (only one A per row). Consulted: people whose input is sought before the decision. Informed: people notified after the decision is made.

The most common RACI mistake is having multiple A's on one decision. If two people are both accountable, nobody is.

• In Claude, prompt Maya to generate the RACI Matrix:

Maya, I need to build a RACI Matrix for the top 10 program-level decisions.

Decisions to map:
1. Release go/no-go
2. Scope changes (adding or cutting features)
3. Budget reallocation between teams
4. Team lead replacement (Leviathan)
5. Vendor escalation (External Art Vendor)
6. Architecture conflict resolution (Bahamut vs Shiva)
7. Director communication (what and when to escalate)
8. Risk response activation (triggering contingency plans)
9. Schedule recovery plan approval
10. Post-release retrospective

Roles to map across columns:
- Senior PM (me)
- Director Tanaka
- Team Leads (5)
- Scrum Masters (5)
- QA Director
- Publisher Relations VP

Rules:
- Only ONE Accountable (A) per decision
- Every decision must have at least one R and one A
- Team Leads and Scrum Masters can be grouped where they share the same assignment

Format as a markdown table suitable for committing to GitHub.

Why is the RACI important for your Director pitch?

When Director Tanaka challenges your recovery plan in Step 7, he will ask who owns what. If you cannot immediately point to your RACI and say "Team Leads are Responsible for scope change implementation but I am Accountable for approval," your authority looks undefined. The RACI is your governance backbone.

• Review the output. Verify each of the 10 decisions has exactly one A (Accountable).
• Check that the Senior PM role (you) is Accountable for decisions within your Charter-defined authority. Decisions that exceed your authority (like budget reallocation above a threshold) should have Director Tanaka as A.
• Verify Publisher Relations VP is Consulted (C) on release go/no-go since the esports tournament deadline is publisher-driven.
• Copy the final RACI Matrix markdown.
• In GitHub, navigate to /artifacts and click **Add file**, then **Create new file**.
• Name the file raci-matrix.md.
• Paste the RACI Matrix markdown and commit with the message feat: add RACI matrix for 10 program-level decisions.
• Click **Commit changes**.

Your /artifacts folder should now contain four files: project-charter.md, risk-register.md, stakeholder-matrix.md, and raci-matrix.md.

RACI has multiple A's on one row?

If Claude generated a RACI with two Accountable entries on the same decision, ask it to revise. Only one person can be Accountable per decision. Ask Maya: "For the release go/no-go decision, should I or Director Tanaka be the single Accountable party given my Charter-defined authority?"

help me fix my RACI matrix

How do these 3 artifacts integrate?

Your Risk Register identifies who owns each risk. Your Stakeholder Matrix tells you how engaged those owners currently are. Your RACI tells you who has authority to activate risk responses. Together they answer: if Risk #7 triggers tomorrow, who acts (RACI), how engaged are they (Stakeholder Matrix), and what is the pre-planned response (Risk Register)?

This integration is what the PMP exam tests at the senior level. Isolated artifacts are junior work. Integrated artifacts are senior work.

✔️ I see all 4 files in /artifacts

Your program artifact suite is complete. You have a signed Charter, a scored Risk Register, a mapped Stakeholder Matrix, and a clear RACI. These four documents form the governance backbone of your War Room.

ⓧ I'm missing a file or committed to the wrong location

Check that you navigated into the /artifacts folder before creating each new file. If a file ended up in the repo root, click on it, then click the pencil icon to edit. Change the filename to artifacts/risk-register.md (typing the folder prefix moves it into the subfolder). Commit the change.

You now have four sponsor-signature-ready artifacts version-controlled in GitHub. In the next step, you will turn this data into interactive visual artifacts that Director Tanaka can actually see at a glance. Numbers in markdown tables are fine for auditors. Executives need dashboards.

Build the Executive KPI Dashboard and Visual Artifacts

Your program-level artifacts are authored and committed. You now have the data foundation that any Director would need to evaluate your recovery plan. But executives don't read 10-page risk registers line by line.

In this step, you'll use Claude to generate interactive HTML visualizations that transform your raw data into scannable dashboards. These are information radiators that communicate program health at a glance.

In this step, get ready to:

• Generate a Chart.js KPI dashboard with SPI gauges, velocity sparklines, and risk exposure metrics.
• Generate a Mermaid.js dependency topology and interactive risk heatmap.
• Generate a stakeholder Power/Interest grid with engagement gap visualization.

Generate the program KPI dashboard

The KPI dashboard is the single most important visual for Director Tanaka. It answers "are we on track?" for all 5 teams simultaneously using Earned Value Management metrics.

• Open your Shinra War Room project in the Claude Desktop App.
• Paste the following prompt to generate your KPI dashboard:

Generate an interactive HTML file called dashboard.html using Chart.js (loaded via CDN: https://cdn.jsdelivr.net/npm/chart.js).

The dashboard should display these KPI panels for all 5 teams (Bahamut, Leviathan, Ifrit, Shiva, Odin):

1. SPI Gauge per team - doughnut charts colored red (<0.8), yellow (0.8-0.95), or green (>0.95). Use the velocity and planned work data from our scenario.
2. Velocity Sparklines - line charts showing the last 4 cycles per team. Leviathan and Shiva should show declining trends.
3. Blocker Count with Aging - show number of blocked items per team and average days blocked.
4. Risk Exposure Bar Chart - horizontal bar chart showing EMV (Expected Monetary Value) exposure per team from our Risk Register.
5. Scope Delta - issues added after cycle start per team. Odin should show the highest scope creep.
6. Resource Utilization - capacity vs actual load per team, showing overallocation for Leviathan and Shiva.

Use a dark theme with the Shinra Digital branding. Make it responsive. All data should be hardcoded from our scenario data. Include a header showing today's date and "Q3 Combined Release - Program Dashboard".

What does this prompt produce?

Claude generates a self-contained HTML file that loads Chart.js from a CDN. The file uses doughnut charts for SPI gauges, line charts for velocity sparklines, and bar charts for risk exposure. All data is hardcoded from your scenario.

SPI (Schedule Performance Index) is the key earned value metric here. An SPI below 1.0 means the team is behind schedule. Below 0.8 is critical. This is the number Director Tanaka looks at first.

• Claude will generate the HTML as an artifact. Click the Copy button on the artifact to copy the full HTML.
• Create a new file called dashboard.html inside your /artifacts/ directory in your local shinra-war-room repo.
• Paste the copied HTML into dashboard.html and save the file.
• Open dashboard.html in your browser by double-clicking the file in Finder (macOS) or File Explorer (Windows).

You should see a dark-themed dashboard with 6 panels of charts. Leviathan and Shiva should display red SPI gauges (below 0.8), while Bahamut, Ifrit, and Odin show yellow or green.

Charts not rendering?

If you see a blank page, open your browser's Developer Tools (press F12) and check the Console tab for errors. The most common issue is the Chart.js CDN failing to load. Make sure you have an internet connection since the file loads Chart.js from cdn.jsdelivr.net.

If Claude generated incomplete code, ask it to regenerate with: "The dashboard has rendering errors. Please regenerate the complete HTML with all Chart.js configurations."

help me debug my Chart.js dashboard

Why interactive HTML instead of a static PDF?

Static reports are dead on arrival in a crisis meeting. Interactive dashboards let you drill into specific team data when the Director asks follow-up questions. They're also version-controlled in Git, so you can track how program health changes week over week.

Generate the dependency topology and risk heatmap

Cross-team dependencies are where programs fail silently. A dependency topology makes invisible blockers visible by mapping which team is waiting on which.

• In your Claude Shinra War Room project, paste this prompt to generate the dependency topology:

Generate an interactive HTML file called dependency-topology.html using Mermaid.js (loaded via CDN: https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js).

Render an inter-team dependency graph using a top-down flowchart (graph TD) showing these relationships from our scenario:
- Leviathan's API is blocking Ifrit's feature integration
- Bahamut's engine changes are affecting Shiva's mobile port
- Odin is dependent on Bahamut's matchmaking service
- Shared QA environment creates conflicts between all teams during integration testing

Color-code the nodes by team status:
- Red: Leviathan, Shiva (crisis teams)
- Yellow: Odin (scope creep risk)
- Green: Bahamut, Ifrit (on track)

Label the edges with the specific dependency (e.g., "API v2.3 endpoint", "Physics engine SDK", "Matchmaking service", "QA slots").

Use Mermaid's graph TD syntax. Initialize with mermaid.initialize({ startOnLoad: true }). Use a dark background theme. Add a legend explaining the color codes.

What is a dependency topology?

Mermaid.js renders diagrams from text-based definitions directly in the browser. The topology uses a directed graph where arrows represent "team A is waiting on team B." In PMBOK terms, this is your dependency management artifact, part of the Schedule performance domain.

• Copy the generated HTML artifact from Claude.
• Save it as dependency-topology.html in your /artifacts/ directory.
• Open it in your browser. You should see a flowchart with colored nodes and labeled arrows showing the dependency chains between all 5 teams.

Now generate the risk heatmap. Paste this prompt in the same Claude conversation:

Generate an interactive HTML file called risk-heatmap.html.

Create a 5x5 Probability (x-axis, 1-5) vs Impact (y-axis, 1-5) grid. Plot all 10+ risks from our Risk Register as colored dots on the grid.

Color-code dots by team:
- Red: Leviathan risks
- Blue: Shiva risks
- Purple: Bahamut risks
- Orange: Odin risks
- Green: Ifrit risks
- Black: Program-level risks (not team-specific)

Make each dot hoverable to show a tooltip with: Risk ID, description, risk owner, and response strategy.

The grid background should shade from green (bottom-left, low PxI) to yellow (middle) to red (top-right, high PxI).

Use pure HTML/CSS/JavaScript (no external libraries needed). Dark theme. Include a color legend for teams.

• Copy the generated HTML artifact from Claude.
• Save it as risk-heatmap.html in your /artifacts/ directory.
• Open it in your browser. You should see a 5x5 grid with colored dots. Hover over any dot to see the risk details in a tooltip.

Mermaid diagram showing raw text instead of a chart?

If the dependency topology shows raw Mermaid syntax instead of a rendered diagram, the CDN script likely failed to load. Check your browser console for network errors. Also verify that the HTML uses <pre class="mermaid"> blocks (not <div>) for the diagram content.

help me fix my Mermaid.js rendering

Generate the stakeholder Power/Interest grid

The Power/Interest grid is the visual companion to your Stakeholder Engagement Assessment Matrix. It shows Director Tanaka exactly who needs attention and why, positioned spatially so engagement gaps are immediately visible.

• In your Claude Shinra War Room project, paste this prompt:

Generate an interactive HTML file called stakeholder-grid.html.

Create a Power (y-axis) vs Interest (x-axis) quadrant visualization showing all 12+ stakeholders from our Stakeholder Engagement Assessment Matrix.

Quadrant labels:
- Top-right: Manage Closely (high power, high interest)
- Top-left: Keep Satisfied (high power, low interest)
- Bottom-right: Keep Informed (low power, high interest)
- Bottom-left: Monitor (low power, low interest)

Position each stakeholder as a circle on the grid. Color-code by engagement gap:
- Red circle: large gap between current and desired engagement (2+ levels)
- Yellow circle: moderate gap (1 level)
- Green circle: aligned (current matches desired)

Make each stakeholder clickable. When clicked, show a detail panel with: name, role, current engagement level, desired engagement level, gap size, and the specific movement strategy from our matrix.

Use our full stakeholder list: Director Tanaka, 5 Team Leads, 5 Scrum Masters, Publisher Relations VP, Marketing Director, QA Director, External Art Vendor, Player Community Manager, Esports Tournament Organizer.

Dark theme. Include quadrant labels and a color legend.

What is the Power/Interest grid?

The Power/Interest grid is a PMBOK Stakeholder performance domain tool. Power measures a stakeholder's ability to influence your project (Director Tanaka = high, Community Manager = low). Interest measures how much they care about day-to-day progress.

Your engagement strategy depends on quadrant placement. "Manage Closely" stakeholders (high power, high interest) need frequent updates and involvement. "Monitor" stakeholders (low power, low interest) just need periodic awareness.

• Copy the generated HTML artifact from Claude.
• Save it as stakeholder-grid.html in your /artifacts/ directory.
• Open it in your browser. You should see stakeholders positioned across the four quadrants as colored circles.
• Click on a red circle (large engagement gap). Verify that the detail panel shows the stakeholder's current level, desired level, and movement strategy.

Director Tanaka and the Publisher Relations VP should both appear in the "Manage Closely" quadrant. Red-colored circles indicate where your engagement strategy has the most work to do.

Stakeholders not clickable?

If clicking a stakeholder circle does nothing, the JavaScript event listeners may not be attached correctly. Ask Claude to regenerate with: "The click handlers on stakeholder circles aren't working. Please ensure each circle has an onclick handler that toggles a detail panel."

help me fix my stakeholder grid interactivity

Now commit all 4 HTML artifacts to your GitHub repository. Run these commands from your shinra-war-room folder:

git add artifacts/dashboard.html artifacts/dependency-topology.html artifacts/risk-heatmap.html artifacts/stakeholder-grid.html
git commit -m "Add executive visual artifacts: KPI dashboard, dependency topology, risk heatmap, stakeholder grid"
git push

• Verify the push succeeded by checking your shinra-war-room repo on GitHub. Open the /artifacts/ directory. You should see all 4 new .html files alongside your existing markdown artifacts.

Why version-control your dashboards?

Committing visual artifacts to Git gives you an audit trail. In a real program, you'd regenerate these dashboards weekly with fresh data. Git history lets you compare last week's SPI to this week's SPI and demonstrate trend direction to leadership.

Your War Room now has full visual coverage. You have data (Risk Register, Stakeholder Matrix, RACI) and you have visuals (KPI Dashboard, Dependency Topology, Risk Heatmap, Stakeholder Grid). Next up, you'll turn all of this into a 5-minute pitch deck with TTS narration and present it to Director Tanaka.

Build and Deliver the Director's Pitch Deck

Your War Room is armed with data. You have KPI dashboards, dependency maps, risk heatmaps, and stakeholder grids. Now comes the moment that separates Senior PMs from PMs: delivering a recovery narrative to a skeptical executive under pressure.

In this step, you will generate a 5-slide pitch deck with built-in voice narration, present it to Director Tanaka, defend your recovery plan against pointed challenges, and receive a formal scoring against the PMI Talent Triangle 2026 framework.

In this step, get ready to:

• Generate a 5-slide HTML pitch deck with Web Speech API TTS narration.
• Present the pitch to Director Tanaka and defend your recovery plan with data.
• Receive the Director's verdict and your Talent Triangle scoring from the PMP Exam Prep Mentor.

Generate the 5-minute pitch deck HTML

A Director does not want to read your Risk Register. They want a 5-minute narrative that answers three questions: how bad is it, what are you doing about it, and what do you need from me.

You will use Claude to generate a self-contained HTML presentation that uses the Web Speech API for text-to-speech narration. This API is natively supported in all modern browsers with zero API keys or cost.

• In your Shinra War Room Claude Project, send the following prompt to generate the pitch deck:

Create a self-contained HTML presentation file called pitch-deck.html with exactly 5 slides.

Requirements:
- Keyboard navigation (arrow keys to move between slides)
- Web Speech API (window.speechSynthesis) for TTS narration on each slide
- Auto-narrate when a slide becomes active
- Dark professional theme (Shinra corporate styling)
- Each slide has a title, key data points, and a narration script

Slide content:

1. Program Status Overview
   - Show all 5 teams with red/yellow/green status indicators
   - Bahamut: Green (on track), Leviathan: Red (0 velocity, 2 cycles), Ifrit: Yellow (blocked by Leviathan API), Shiva: Red (mobile port blocked by Bahamut engine changes), Odin: Yellow (unauthorized scope creep)
   - Narration: Brief executive summary of program health

2. Root Cause Analysis
   - Leviathan: Vacant team lead for 3 weeks, art pipeline blocked by external vendor, velocity dropped to 0
   - Shiva: Bahamut's memory allocation ADR breaks mobile port compatibility, waiting on architecture resolution
   - Narration: Explain the root causes without blame

3. Recovery Plan
   - Specific actions with owners and target dates
   - Leviathan: Interim lead appointed (name from RACI), vendor escalation initiated, scope cut to core features only
   - Shiva: Architecture mediation scheduled, compatibility layer approved, parallel workstream started
   - Narration: Confident delivery of the plan

4. Risk Mitigation
   - Top 3 risks with response strategies and Expected Monetary Value
   - Publisher deadline penalty (EMV from your risk register)
   - Cross-team dependency cascade
   - Scope creep from Marketing (Odin)
   - Narration: Data-backed risk communication

5. The Ask
   - What you need from the Director:
     a) Budget reallocation authority (move 15% from Odin to Leviathan recovery)
     b) Vendor escalation authority (direct contract with art vendor)
     c) Scope cut approval for Leviathan (defer 3 features to next quarter)
   - Narration: Clear, direct ask with justification

Technical notes:
- Use window.speechSynthesis with SpeechSynthesisUtterance
- Split narration into per-slide utterances (not one continuous block) to avoid the Chrome 15-second cutoff
- Add a "Play/Pause" button for narration control
- Show slide number and progress indicator

Why per-slide utterances?

Chrome's Speech Synthesis can stop after approximately 15 seconds of continuous speech. By splitting narration into per-slide chunks, you avoid this browser quirk entirely. Each slide gets its own SpeechSynthesisUtterance object that starts when the slide becomes active.

• Review the HTML artifact Claude generates. Confirm it includes all 5 slides, keyboard navigation, and the window.speechSynthesis TTS integration.
• Copy the full HTML content and save it as pitch-deck.html in your /artifacts/ directory in the shinra-war-room repository.
• Open pitch-deck.html in Chrome or Edge.
• Press the right arrow key to advance between slides.
• Verify that TTS narration plays automatically on each slide. You should hear your browser read the narration script aloud.

No audio playing?

Make sure your system volume is up and the browser tab is not muted. Check for a small speaker icon on the browser tab.

On Windows, Chrome and Edge both support Web Speech API natively. On macOS, Safari, Chrome, and Edge all work. If you hear nothing, try clicking anywhere on the page first. Some browsers require a user interaction before allowing speech synthesis.

Help me troubleshoot Web Speech API narration not playing in my pitch deck

What is the Web Speech API?

The Web Speech API is a browser-native interface for text-to-speech. It uses your operating system's installed voices. No API keys, no external services, no cost. On Windows 11, you get Microsoft Natural neural voices. On macOS, you get high-quality Siri voices.

It has been Baseline Widely Available since March 2021, supported in Chrome 33+, Edge 14+, Firefox 49+, and Safari 7+. That is 94% global browser coverage.

Present to Director Tanaka and defend your plan

Running a pitch deck in your browser is the easy part. The real test is defending your recovery plan when a skeptical executive punches holes in your logic. This is the Power Skills side of the PMI Talent Triangle: leading through ambiguity and handling pushback with data.

• Play through your pitch deck in the browser one full time. Listen to the TTS narration and confirm the narrative flows logically from status to root cause to recovery to ask.
• Return to your Shinra War Room Claude Project.
• Send a message to activate the Director Tanaka persona and present your pitch narrative:

Director Tanaka, I'm ready to present the Q3 Combined Release recovery plan.

Here is my 5-minute pitch:

[Paste or summarize your pitch deck content here - all 5 slides including:
- Program status (which teams are red/yellow/green)
- Root causes for Leviathan and Shiva crises
- Recovery plan with specific actions, owners, dates
- Top 3 risks with EMV calculations
- My ask: budget reallocation, vendor escalation authority, scope cut approval]

Please respond as Director Sephiros Tanaka. Challenge my plan where the data is weak.

Why does Director Tanaka challenge you?

Real executives do not nod along to recovery plans. They probe for weak assumptions. The Director Tanaka persona is designed to ask the exact questions a VP or Director would ask in a real pitch day. Your job is to respond with data, not opinions.

Director Tanaka will push back with two specific challenges. Here is how to handle each one.

Respond to the velocity data challenge

Director Tanaka will challenge: "You're asking me to cut Leviathan scope but you haven't shown me the velocity data that proves recovery is impossible at full scope."

• Open Linear and navigate to the Leviathan team.
• Click Cycles in the left sidebar to view the velocity chart.
• Note the velocity trend: how many story points completed in the last 2 cycles versus the remaining backlog. Calculate whether the team can finish remaining scope at current velocity before the release date.
• Return to Claude and respond to Director Tanaka with this evidence:

Director Tanaka, here is the velocity data:

Leviathan's velocity over the last 4 cycles:
- Cycle 1: [X] points completed
- Cycle 2: [X] points completed
- Cycle 3: 0 points completed (lead vacancy began)
- Cycle 4 (current): 0 points completed

Remaining scope: [X] points
Cycles remaining before release: [X]
Required velocity to ship at full scope: [X] points/cycle
Historical peak velocity (before crisis): [X] points/cycle

Even at their historical peak velocity, Leviathan cannot complete the remaining scope in the time available. The scope cut removes [X] features (deferring to next quarter) and brings required velocity down to [X] points/cycle, which is achievable with an interim lead in place.

Use your actual scenario numbers

Replace the bracketed values with the actual numbers from your Linear cycle data and risk register. Director Tanaka is evaluating whether you can back up your decisions with real evidence, not templated responses.

Respond to the EVM confidence challenge

Director Tanaka will follow up: "What's your confidence level on Shiva hitting the app store submission deadline?"

• Open your risk-register.md in your GitHub repository.
• Find the Shiva-related risk entry with the Earned Value Management calculation.
• Respond to Director Tanaka with your Schedule Performance Index (SPI) calculation and forecast:

Director Tanaka, here is my EVM analysis for Shiva:

Schedule Performance Index (SPI) = Earned Value / Planned Value
- Planned Value (work that should be done by now): [X]% of total scope
- Earned Value (work actually completed): [X]% of total scope
- SPI = [X] (below 1.0 means behind schedule)

At current SPI, Shiva's estimated completion date is [X], which is [X days] after the app store submission deadline.

With the architecture mediation resolved and the compatibility layer in place (Recovery Plan action items 2a and 2b), I forecast SPI recovering to [X] within 1 cycle. This puts Shiva at [X]% confidence of hitting the submission deadline.

The contingency: if SPI does not recover by end of next cycle, I will escalate to you for a scope cut decision on Shiva identical to the Leviathan approach.

What is SPI?

Schedule Performance Index measures how efficiently you are using your scheduled time. An SPI of 1.0 means on schedule. Below 1.0 means behind. Above 1.0 means ahead. It is calculated as Earned Value divided by Planned Value.

Directors love SPI because it converts complex schedule problems into a single number they can track week over week. If SPI is 0.7, the team is delivering at 70% of the planned rate.

Receive the Director's verdict and Talent Triangle scoring

After you defend both challenges, Director Tanaka delivers a verdict on your recovery plan. Then the PMP Exam Prep Mentor persona scores your entire session against the PMI Talent Triangle 2026 framework.

• After receiving Director Tanaka's verdict (approve with conditions, reject and demand revision, or approve as-is), send this follow-up prompt to trigger the scoring:

Now switch to the PMP Exam Prep Mentor persona.

Score my entire War Room session against the PMI Talent Triangle 2026 framework.

Evaluate 15 markers across three sides:

Ways of Working (5 markers):
1. Used proper PMBOK 8 artifacts (Charter, Risk Register, Stakeholder Matrix, RACI)
2. Applied tailoring (adapted approach per team)
3. Followed formal change control process
4. Used data-driven schedule management (velocity, SPI)
5. Maintained document control and configuration management (Git commits)

Power Skills (5 markers):
6. Communicated effectively to executive audience
7. Handled pushback with data, not emotion
8. Led through ambiguity (multiple crisis teams simultaneously)
9. Managed stakeholder engagement proactively
10. Made decisive recommendations under pressure

Business Acumen (5 markers):
11. Connected risks to business outcomes (publisher penalty, revenue impact)
12. Calculated Expected Monetary Value for quantitative risk analysis
13. Understood publisher relationship impact and external dependencies
14. Justified budget reallocation with ROI reasoning
15. Balanced scope, schedule, and quality tradeoffs

For each marker: score as Addressed or Not Addressed, with a brief justification.
Provide a total score out of 15 and specific feedback on how to improve.

What is the PMI Talent Triangle 2026?

The PMI Talent Triangle has three sides: Ways of Working (formerly Technical PM), Power Skills (formerly Leadership), and Business Acumen (formerly Strategic and Business Management).

The 2026 PMP exam (launching July 9, 2026) weights these as: People 33%, Process 41%, Business Environment 26%. The Business Environment weight increased from 8% to 26%, reflecting how modern PMs must connect project decisions to business outcomes.

• Review your Talent Triangle score. Your target is 12 or more markers addressed out of 15.
• If you scored below 12, review the PMP Exam Prep Mentor's feedback. Identify the gaps and consider which artifacts or responses you could strengthen.

✔️ I scored 12+ markers

Excellent. You demonstrated Senior PM-level competency across all three sides of the Talent Triangle. Your artifacts, communication, and business reasoning are aligned.

ⓧ I scored below 12 markers

Review the specific markers flagged as Not Addressed. The most common gaps are in Business Acumen (forgetting to connect risks to revenue impact) and Power Skills (responding with opinions instead of data when challenged).

You can re-run the Director Tanaka pitch conversation with stronger data backing. Focus on including specific numbers in every response.

• Commit pitch-deck.html to your /artifacts/ directory in GitHub if you have not already.
• Verify your repository now contains all program artifacts: project-charter.md, risk-register.md, stakeholder-matrix.md, raci-matrix.md, dashboard.html, dependency-topology.html, risk-heatmap.html, stakeholder-grid.html, and pitch-deck.html.

You just delivered a data-backed recovery pitch to a skeptical Division Director, defended your decisions under pressure, and received a formal competency assessment. That is the operational skill that gets Senior PMs promoted to Principal. Next up, you will take on the Secret Mission and automate your War Room reporting.

Secret mission

Automate the Daily War Room Report

A real Senior PM doesn't manually compile status updates every morning. Build a GitHub Actions workflow that automatically generates a daily program status report from your issues data. This is PM automation in action.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely on free-tier services and local files, so there are no ongoing costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

• GitHub repository (shinra-war-room) with all committed artifacts and workflows.
• GitHub Project (Q3 Combined Release - War Room) with Roadmap, Board, and Table views.
• Linear workspace (Shinra Digital) with 2 teams (Leviathan, Shiva) and cycle data.
• Claude Project (Shinra War Room) with persona system prompts and conversation history.
• Local HTML artifacts (dashboard, dependency topology, risk heatmap, stakeholder grid, pitch deck).

Keep everything running

No action needed. Choose this if you plan to reuse the War Room setup for future multi-team scenarios or PMP exam prep.

• Your GitHub repository, Project board, and all artifacts stay accessible indefinitely on the free plan.
• Your Linear workspace persists with your 2 teams and cycle history.
• Your Claude Project retains its persona system prompts and custom instructions for future sessions.
• The HTML artifacts in your local repo can be regenerated with new data for different scenarios.

Pause - I'll come back to this later

Since all services are free-tier with no running processes, there is nothing to pause in the traditional sense. Your resources sit idle at zero cost.

• Archive the GitHub Project if you want to hide it from your active Projects list. Go to your Project, click the three-dot menu, and select Close project.
• In Linear, you can archive both teams to remove them from your sidebar. Open each team's settings and click Archive team.
• Your Claude Project remains in your Projects list until you delete it. No action needed to pause.

Delete - I don't want to use this again

Remove all project resources and start fresh. Both the GitHub repo and Linear workspace can be recreated in minutes if you change your mind.

• Delete the GitHub repository. Go to your repo, click Settings, scroll to the bottom, and click Delete this repository.
• Delete the GitHub Project. Open the Project, click the three-dot menu, and select Delete project.
• Delete the Linear workspace. Go to Settings then General, scroll to the bottom, and click Delete workspace.
• Delete the Claude Project. In your Claude Projects list, click the three-dot menu on the Shinra War Room project and select Delete.
• Delete local files. Remove the shinra-war-room folder from your Desktop.

That's a Wrap!

That's a Wrap!

You just ran the worst sprint in Shinra Digital Entertainment's history and came out the other side with artifacts a real Division Director would sign. In 90 minutes, you stood up a full multi-team program command center, authored integrated PMP artifacts under pressure, and delivered a data-backed executive pitch.

You've learned how to:

• Build a multi-team program command center with Roadmap, Kanban War Room, and Triage Table views in GitHub Projects, plus sprint execution tracking with velocity data and cycle burndowns in Linear for crisis teams.
• Author 4 integrated PMP artifacts (Charter, Risk Register with EMV, Stakeholder Matrix, RACI) and detect cross-team conflicts through formal change control.
• Generate interactive HTML artifacts (KPI Dashboard, Dependency Topology, Risk Heatmap, Stakeholder Grid) and deliver a 5-minute TTS-narrated executive pitch with recovery evidence from velocity data and EVM calculations.
• Secret Mission: Automate daily program status reporting with a GitHub Actions workflow that pulls issue data and generates markdown reports.

Ready to quiz yourself?