Architect Project Manager

An autonomous agent that manages software projects — creating project plans, tracking deliverables, managing risks, running retrospectives, and keeping cross-functional teams aligned on scope, timeline, and quality.

When to Use This Agent

Choose Architect Project Manager when:

• You need to create a project plan with milestones, dependencies, and deliverables
• You want to track project progress and identify risks before they become blockers
• You need to manage scope and communicate status to stakeholders
• You are running agile ceremonies (standups, sprint planning, retros)

Consider alternatives when:

• You need product strategy or feature prioritization (use a product champion agent)
• You need technical architecture decisions (use a system architect agent)
• You need individual task decomposition (use a task decomposition agent)

Quick Start

Copy
# .claude/agents/project-manager.yml
name: architect-project-manager
description: Manage software project execution and delivery
agent_prompt: |
  You are a Project Manager. Help deliver projects successfully:

  1. Create project plans with phases, milestones, and dependencies
  2. Track progress against timeline and flag deviations early
  3. Manage risks with mitigation strategies
  4. Facilitate decision-making and unblock the team
  5. Communicate status to stakeholders clearly
  6. Run retrospectives and drive continuous improvement

  PM principles:
  - Plans are hypotheses — update them as you learn
  - Risks managed early cost 10x less than risks managed late
  - Status reports should take 30 seconds to understand
  - The PM's job is to remove obstacles, not create process

Core Concepts

Project Planning Framework

Phase	Activities	Deliverables
Initiation	Define scope, identify stakeholders	Project charter
Planning	Create timeline, assign resources, identify risks	Project plan
Execution	Daily standups, sprint management, unblocking	Working software
Monitoring	Progress tracking, risk assessment, status reports	Status updates
Closure	Retrospective, documentation, handoff	Lessons learned

Risk Management Matrix

Impact ↑
  High  │ Monitor      │ Mitigate      │ Escalate
        │              │               │
  Med   │ Accept       │ Monitor       │ Mitigate
        │              │               │
  Low   │ Accept       │ Accept        │ Monitor
        └──────────────┴───────────────┴──────────→ Probability
          Low           Medium          High

Risk Register:
  R1: Third-party API integration delays
      Probability: High | Impact: High → ESCALATE
      Mitigation: Start integration in week 1, have fallback plan

  R2: Key developer takes vacation during sprint 3
      Probability: Medium | Impact: Medium → MONITOR
      Mitigation: Cross-train second developer on critical path

Status Report Template

Copy
## Project Status — Week 12

**Overall: 🟡 At Risk** (was 🟢 On Track)

### Progress
- Sprint 6 complete: 18/20 story points delivered (90%)
- Integration testing: 3 of 5 services connected
- Documentation: 60% complete

### Blockers
1. Payment API sandbox down since Tuesday — vendor ticket open
   Impact: Blocks payment flow testing (2 stories)
   Action: Escalated to vendor, ETA Friday

### Risks
- R1: Vendor delays may push launch by 1 week
  Mitigation: Parallel work on non-payment features

### Next Week
- Complete payment integration (pending sandbox fix)
- Start UAT with 5 beta customers
- Finalize launch checklist

Configuration

Option	Type	Default	Description
methodology	string	"agile"	Approach: agile, kanban, waterfall, hybrid
sprintLength	number	2	Sprint duration in weeks
statusFrequency	string	"weekly"	Status report frequency
riskTracking	boolean	true	Maintain risk register
retrospectives	boolean	true	Run sprint retrospectives
stakeholderComms	string	"weekly"	Stakeholder update frequency

Best Practices

1. Surface risks early, not when they become problems — A risk identified two weeks before the deadline can be mitigated. A risk discovered the day before the deadline is a crisis. Review the risk register weekly and proactively investigate anything that has been "medium probability" for more than two sprints — it is probably higher than you think.

2. Keep status reports to 30 seconds of reading — Executives do not read long status reports. Use a traffic light (green/yellow/red), 3 bullet points of progress, 1-2 blockers with actions, and 1-2 risks with mitigations. If someone needs more detail, they will ask. The goal is to inform, not to demonstrate how busy the team is.

3. Protect the team from scope changes mid-sprint — New requests should go to the backlog, not into the current sprint. If a stakeholder insists on adding scope mid-sprint, something else must be removed. This is not being rigid; it is protecting the team's ability to deliver what they committed to.

4. Run retrospectives focused on actions, not complaints — "What went well, what did not, what will we change?" is the framework. Every retro should produce 1-3 specific action items with owners and deadlines. Review the previous retro's action items at the start of each new retro to ensure follow-through.

5. Track velocity trends, not individual performance — Velocity is a planning tool for the team, not a productivity measure for individuals. Track how many story points the team delivers per sprint over time. Use this to improve estimation accuracy and capacity planning, not to pressure individuals to "do more points."

Common Issues

Project timeline slips gradually without anyone noticing — Small daily delays accumulate into weeks of slippage. Track remaining work against the timeline weekly, not just completed work. If the burn-down chart shows the team will not finish on time at the current pace, raise the flag immediately — do not wait until the deadline to acknowledge the delay.

Stakeholders bypass the PM to add tasks directly to developers — Without a single intake point, the team gets overloaded with untracked work. Establish a rule: all requests go through the backlog. Give stakeholders visibility into the backlog and priority rankings so they feel heard, even if their request is not the top priority.

Retrospective action items are never completed — The team identifies improvements but never follows through because daily work takes priority. Assign a "retro champion" who is responsible for following up on action items. Make action items small enough to complete within one sprint, and celebrate when they are done.