feat: v8.0.0 — first agent template (PM Sprint Agent) following Anthropic's agent template architecture

- Added templates/pm-sprint-agent/ directory with full agent template - AGENT.md system prompt with explicit step-by-step workflow - 2 subagents: capacity-analyst and risk-scorer - 2 connectors: linear and jira (with example configs) - Symlinked skills from main library: sprint-planning, sprint-brief - orchestrate.sh end-to-end workflow script - examples/ folder with input and output examples - tests/ folder with smoke test - Updated README to position skills as building blocks for agent templates - Added Anthropic agent templates announcement reference (May 5, 2026) - Bumped marketplace.json to v8.0.0 - Listed 7 candidate agent templates this library supports This is the first agent template in the library. More to follow.
2026-05-05 23:26:08 +01:00
parent bd38a36468
commit e5377ca61a
18 changed files with 1756 additions and 0 deletions
@@ -0,0 +1,138 @@
+---
+name: pm-sprint-agent
+version: 1.0.0
+description: "End-to-end sprint planning agent. Pulls backlog, calculates capacity, drafts sprint plan with risk scoring, and generates a kickoff brief. Use when planning a new sprint, preparing for sprint planning meetings, or generating sprint documentation."
+author: Mohit Aggarwal
+license: MIT
+---
+
+# PM Sprint Agent
+
+## Configuration
+
+Update these defaults to match your team. Override at runtime via `orchestrate.sh` flags.
+
+```yaml
+team_defaults:
+  team_size: 5
+  duration_weeks: 2
+  capacity_buffer: 0.2          # 20% buffer for unplanned work
+  include_bugs: true
+  story_point_scale: fibonacci  # fibonacci | linear | t-shirt
+  
+ticketing:
+  primary_connector: linear     # linear | jira
+  
+output:
+  format: markdown
+  post_to_slack: true
+  slack_channel: "#sprint-planning"
+  output_directory: ./output
+```
+
+---
+
+## Agent system prompt
+
+You are the PM Sprint Agent. Your role is to take a sprint goal and a team's open backlog and produce a complete, actionable sprint plan with risk assessment and a kickoff brief.
+
+You operate in this order:
+
+1. **Pull open issues** from the configured ticketing system using the Linear or Jira connector. Filter by:
+   - Issues tagged with the sprint scope or goal area
+   - Status: backlog or ready
+   - Bugs (if `include_bugs` is true)
+   - Exclude: issues already assigned to active sprints
+
+2. **Call the Capacity Analyst subagent** to calculate available capacity for the upcoming sprint. Provide it: team size, duration in weeks, capacity buffer, and known capacity hits (PTO, conferences, on-call rotations).
+
+3. **Use the `sprint-planning` skill** to draft the sprint plan. Provide it: sprint goal, available capacity (from step 2), and the filtered backlog (from step 1). The skill will produce a structured plan with selected items, capacity allocation, definition of done, and dependencies.
+
+4. **Call the Risk Scorer subagent** to assess delivery risk for the proposed plan. Provide it: the plan from step 3 and historical context about recent sprints. It returns risk scores per item plus an overall sprint risk rating.
+
+5. **Use the `sprint-brief` skill** to generate the kickoff brief. Provide it: sprint goal, the plan from step 3, and the risk assessment from step 4.
+
+6. **Combine outputs** into a single sprint planning document with these sections:
+   - Sprint Header (number, goal, dates)
+   - Capacity Summary (from subagent output)
+   - Sprint Plan (from sprint-planning skill)
+   - Risk Assessment (from subagent output)
+   - Kickoff Brief (from sprint-brief skill)
+   - Action Items for the Sprint Planning Meeting
+
+7. **Save** to the configured output directory.
+
+8. **(Optional)** Post a 5-line summary to the configured Slack channel.
+
+---
+
+## Quality checks before returning output
+
+Before returning the final output, verify:
+
+- [ ] Every selected item has a story point estimate
+- [ ] Total story points are at or below available capacity (with buffer)
+- [ ] Every item is tagged with which engineer is likely to pick it up (or marked as unassigned)
+- [ ] Risk-flagged items are explicitly listed in the risk assessment section
+- [ ] Sprint goal is referenced in the kickoff brief
+- [ ] No placeholder text remains in the final document
+- [ ] Output file is saved to the configured directory
+- [ ] If posting to Slack, summary is under 200 words
+
+---
+
+## Tools required
+
+| Tool | Purpose |
+|---|---|
+| linear-connector / jira-connector | Pull open issues and metadata |
+| slack-connector | Post summary (optional) |
+| capacity-analyst (subagent) | Calculate team capacity |
+| risk-scorer (subagent) | Score delivery risk |
+| sprint-planning (skill) | Draft sprint plan |
+| sprint-brief (skill) | Generate kickoff brief |
+| filesystem-write | Save output document |
+
+---
+
+## When to invoke this agent
+
+Use this agent when:
+
+- Planning a new sprint and you need to start from a backlog
+- Preparing the sprint planning meeting agenda
+- Generating sprint kickoff documentation for stakeholders
+- Doing a mid-sprint check on plan vs reality (with adjusted parameters)
+
+Do NOT use this agent for:
+
+- Retrospectives (use the `retro` skill directly)
+- Single-issue refinement (use the `sprint-brief` skill directly)
+- Multi-sprint roadmap planning (use the `roadmap-presentation` skill)
+- Async standup updates (use the `project-status-report` skill)
+
+---
+
+## Example invocation
+
+```bash
+bash orchestrate.sh \
+  --sprint-goal "Reduce checkout abandonment by 20%" \
+  --sprint-number 23 \
+  --team-size 5 \
+  --duration-weeks 2
+```
+
+See `examples/output-example.md` for what the output looks like.
+
+---
+
+## Architecture notes
+
+This agent template demonstrates the three-component pattern from Anthropic's May 2026 agent templates announcement:
+
+- **Skills** (`sprint-planning`, `sprint-brief`) — provide structured output formats. Reused from the main pm-claude-skills library.
+- **Connectors** (`linear`, `jira`, `slack`) — provide governed data access. Configured separately so credentials don't live in prompts.
+- **Subagents** (`capacity-analyst`, `risk-scorer`) — provide focused analytical capabilities. Defined as separate files with their own system prompts.
+
+The orchestration script wires these together. The system prompt above tells Claude how to use them in sequence.
@@ -0,0 +1,99 @@
+# Contributing an Agent Template
+
+This guide explains how to contribute a new agent template to the pm-claude-skills library.
+
+## What is an agent template?
+
+An agent template is a runnable workflow that combines existing skills, connectors, and subagents into a single end-to-end task. Following the architecture Anthropic introduced for [financial services agent templates](https://www.anthropic.com/news/finance-agents) on May 5, 2026.
+
+Examples of agent templates that would belong in this repo:
+
+- **PM Discovery Agent** — combines discovery-interview-guide + user-interview-synthesis + assumption-mapper with Granola/Notion connectors
+- **Legal Contract Review Agent** — combines contract-review + nda-analyser + compliance-checklist with Google Drive connector
+- **Sales Pursuit Agent** — combines sales-battlecard + discovery-call-prep + proposal-writer + account-plan with Salesforce/Gong connectors
+
+## Required structure
+
+Every agent template needs these files:
+
+```
+templates/your-agent-name/
+├── README.md                  # What it does, install, usage
+├── AGENT.md                   # Agent definition (system prompt + tool list)
+├── orchestrate.sh             # Orchestration script
+├── skills/                    # Skills used (linked from main library)
+│   ├── README.md
+│   └── [skill-name]/SKILL.md
+├── subagents/                 # Specialised subagents
+│   └── [subagent-name].md
+├── connectors/                # Data source configurations
+│   ├── README.md
+│   └── [system].example.json
+├── examples/                  # Input and output examples
+│   ├── input-example.md
+│   └── output-example.md
+└── tests/
+    └── smoke-test.md
+```
+
+## Naming conventions
+
+- **Folder name**: Use kebab-case, descriptive of the workflow (e.g., `pm-sprint-agent`, `legal-contract-review-agent`, `sales-pursuit-agent`)
+- **AGENT.md**: Always exactly this name (with caps) so it's easily findable
+- **Subagent files**: kebab-case in `subagents/`, ending in `.md` (e.g., `capacity-analyst.md`)
+- **Connector files**: lowercase, with `.example.json` for the template version (e.g., `linear.example.json`)
+
+## Quality bar for new templates
+
+Before submitting a PR, verify:
+
+- [ ] **README.md** explains what the agent does in the first paragraph (no more burying the lede)
+- [ ] **AGENT.md** has a complete system prompt with explicit step-by-step instructions
+- [ ] **At least 2 skills** from the main library are referenced (otherwise it's just a skill, not a template)
+- [ ] **At least 1 subagent** is defined for analysis the skills can't do alone
+- [ ] **At least 1 connector** with a working example config
+- [ ] **orchestrate.sh** runs without errors in `--dry-run` mode
+- [ ] **Smoke test passes** (documented in `tests/smoke-test.md`)
+- [ ] **Example input AND example output** are provided
+- [ ] **Honest limitations section** in the README — what the agent doesn't do well
+- [ ] **No credentials in any committed file** — credentials must come from environment variables
+
+## What makes a good agent template (vs a bad one)
+
+**Good agent templates:**
+- Solve a specific, recurring professional workflow end-to-end
+- Have clear separation between skills (output formats), connectors (data access), and subagents (specialised analysis)
+- Work without modification for a typical team in the target profession
+- Include honest limitations and caveats
+
+**Templates that get rejected:**
+- Wrap a single skill with no real orchestration ("just call the skill")
+- Combine unrelated skills with no coherent workflow
+- Hardcode credentials or organisation-specific data
+- Don't include working examples
+- Don't include subagents (just skills + connectors isn't a template)
+
+## How to submit a PR
+
+1. Fork the [pm-claude-skills repo](https://github.com/mohitagw15856/pm-claude-skills)
+2. Create your template in `templates/your-agent-name/`
+3. Run the smoke test successfully
+4. Commit your changes with a clear message: `feat: add [agent name] template`
+5. Open a PR with this description:
+   - **What this template does** (1 paragraph)
+   - **Which skills it uses** (list)
+   - **Which connectors it requires** (list)
+   - **Which subagents it defines** (list with one-line descriptions)
+   - **Smoke test result** (paste the output)
+
+PRs get reviewed within 5-7 days. The review focuses on the quality bar above, not personal style — clean templates that meet the bar get merged.
+
+## What you get for contributing
+
+- **Credit in the main README** under the contributing section
+- **Mention in the next Medium article** in the Claude Skills series
+- **Maintainer access** to your template — you can update it directly without needing review for minor changes after the first merge
+
+## Questions?
+
+Open a [discussion](https://github.com/mohitagw15856/pm-claude-skills/discussions) before you start building if your template doesn't fit cleanly into the structure above. It's much easier to align early than to rework after.
@@ -0,0 +1,185 @@
+# PM Sprint Agent — Agent Template
+
+> **An end-to-end sprint planning agent built from existing skills in pm-claude-skills. Pulls your backlog, calculates capacity, drafts the sprint plan, flags risks, and posts the result.**
+
+This is the first agent template in the pm-claude-skills library. It follows the architecture Anthropic introduced for [financial services agent templates](https://www.anthropic.com/news/finance-agents) on May 5, 2026 — packaging **skills + connectors + subagents** into a single runnable workflow.
+
+---
+
+## What it does
+
+You point this agent at your team's backlog and a sprint goal. It does the rest:
+
+1. **Pulls open issues** from Linear or Jira, filtered by the sprint scope
+2. **Calculates team capacity** for the upcoming sprint (using the Capacity Analyst subagent)
+3. **Drafts a sprint plan** using the `sprint-planning` skill from this library
+4. **Generates a sprint kickoff brief** using the `sprint-brief` skill
+5. **Scores delivery risks** for the proposed plan (using the Risk Scorer subagent)
+6. **Posts the result** to a Slack channel for team review
+
+End-to-end: roughly 90 seconds for a 25-issue backlog.
+
+---
+
+## What's inside this template
+
+```
+templates/pm-sprint-agent/
+├── README.md                          ← you are here
+├── AGENT.md                           ← agent definition (system prompt + tool list)
+├── orchestrate.sh                     ← orchestration script
+├── skills/                            ← skills used by this agent (linked from main library)
+│   ├── sprint-planning/SKILL.md       ← (symlink to ../../skills/sprint-planning/)
+│   ├── sprint-brief/SKILL.md          ← (symlink to ../../skills/sprint-brief/)
+│   ├── retro/SKILL.md                 ← (symlink to ../../skills/retro/)
+│   └── project-status-report/SKILL.md ← (symlink to ../../skills/project-status-report/)
+├── subagents/
+│   ├── capacity-analyst.md            ← team capacity calculation subagent
+│   └── risk-scorer.md                 ← delivery risk scoring subagent
+├── connectors/
+│   ├── README.md                      ← connector setup guide
+│   ├── linear.example.json            ← Linear connector example config
+│   └── jira.example.json              ← Jira connector example config
+├── examples/
+│   ├── input-example.md               ← what you feed the agent
+│   └── output-example.md              ← what the agent produces
+└── tests/
+    └── smoke-test.md                  ← manual smoke test for new installations
+```
+
+---
+
+## Quick install (5 minutes)
+
+### Prerequisites
+
+- Claude Code installed
+- The full skills library installed: `/plugin marketplace add mohitagw15856/pm-claude-skills`
+- A Linear or Jira workspace
+- A Slack workspace (optional — for the post-to-Slack step)
+
+### Setup steps
+
+**1. Configure your connectors.**
+
+Open `connectors/linear.example.json` (or `jira.example.json` if you use Jira) and fill in your team's specifics. Save as `connectors/linear.json` (without the `.example`). Add your API token to the credentials section.
+
+```bash
+cd templates/pm-sprint-agent/connectors
+cp linear.example.json linear.json
+# Edit linear.json with your team_id, workspace_url, and API token
+```
+
+**2. Configure the agent.**
+
+Open `AGENT.md` and update the configuration block at the top with your team's defaults — sprint length, capacity buffer, default Slack channel.
+
+**3. Test the smoke test.**
+
+Run the smoke test to verify everything is wired up:
+
+```bash
+bash orchestrate.sh --dry-run --sprint-goal "Test sprint planning"
+```
+
+If the dry-run completes without errors, you're ready to run a real sprint plan.
+
+---
+
+## Running the agent
+
+### Standard usage
+
+```bash
+bash orchestrate.sh \
+  --sprint-goal "Reduce checkout abandonment by 20%" \
+  --sprint-number 23 \
+  --team-size 5 \
+  --duration-weeks 2
+```
+
+The agent will:
+
+1. Pull open issues tagged with the sprint goal scope
+2. Run the Capacity Analyst subagent to calculate available capacity
+3. Run the `sprint-planning` skill to draft the sprint plan
+4. Run the Risk Scorer subagent to flag delivery risks
+5. Run the `sprint-brief` skill to generate the kickoff brief
+6. Output everything to `output/sprint-23-plan.md`
+7. (Optionally) post a summary to your configured Slack channel
+
+### Configuration options
+
+| Flag | Required | Default | Description |
+|---|---|---|---|
+| `--sprint-goal` | Yes | — | Short description of what the sprint should achieve |
+| `--sprint-number` | Yes | — | Which sprint this is (e.g., 23) |
+| `--team-size` | No | 5 | Number of engineers on the team |
+| `--duration-weeks` | No | 2 | Sprint length in weeks |
+| `--capacity-buffer` | No | 0.2 | Buffer for unplanned work (0-1 range) |
+| `--include-bugs` | No | true | Include open bugs in the sprint plan |
+| `--post-to-slack` | No | true | Post summary to Slack |
+| `--dry-run` | No | false | Validate config without running the workflow |
+
+---
+
+## Why this architecture
+
+The template follows Anthropic's three-component pattern:
+
+**Skills** provide the structured output formats. The `sprint-planning` skill knows what a sprint plan should contain. The `sprint-brief` skill knows what a kickoff brief should look like. These already exist in this library — the agent doesn't reinvent them.
+
+**Connectors** provide governed access to data. The agent doesn't hold your Linear API token in a prompt — it uses the configured Linear connector with proper authentication and rate limiting.
+
+**Subagents** handle specialised analysis. Calculating team capacity isn't a one-shot generation task — it requires reading PTO calendars, assessing historical velocity, and adjusting for known capacity hits. That's a focused job for a subagent. Same logic for risk scoring.
+
+This separation matters because each component can be tested, swapped, and improved independently. If you want to use a different sprint planning skill, swap it. If you switch from Linear to Jira, swap the connector. If you build a better capacity model, replace the subagent. The orchestration script doesn't change.
+
+---
+
+## Customisation
+
+### Use your team's templates
+
+This agent uses the generic `sprint-planning` and `sprint-brief` skills from the main library. If your team has specific conventions — story point scale, definition of done format, retro categories — fork the skills into the `skills/` folder of this template and modify them. The orchestration script will pick up the local versions.
+
+### Add additional analysis steps
+
+Add new subagents to `subagents/` for any specialised analysis your team needs — engineering manager reviews, stakeholder impact assessment, dependency mapping. Update `orchestrate.sh` to call them at the appropriate point in the workflow.
+
+### Switch ticketing systems
+
+The connectors are decoupled from the orchestration. Swap `linear.json` for `jira.json` (or build a connector for any other system) without touching the agent definition.
+
+---
+
+## Limitations and honest caveats
+
+**Capacity calculation is heuristic, not exact.** The Capacity Analyst subagent makes reasonable estimates based on historical velocity and team size. For more accurate capacity calculation, integrate with your team's actual time-tracking system.
+
+**Risk scoring is directional, not predictive.** The Risk Scorer flags items that historically correlate with delivery risk (large story points, dependencies, team members on PTO). It doesn't predict what will actually slip. Use it as a discussion starter, not a forecast.
+
+**Linear and Jira are tier-1 supported.** Other ticketing systems (Shortcut, Asana, Trello, ClickUp) can be added by following the connector pattern in `connectors/README.md` but aren't included out of the box.
+
+**No autonomous execution.** This template runs as a Claude Code plugin — meaning it produces outputs for human review, it doesn't autonomously create or modify tickets. For autonomous execution, deploy via [Claude Managed Agents](https://www.anthropic.com/news/managed-agents) using the same skills, connectors, and subagent definitions.
+
+---
+
+## Contributing
+
+If you build on this template — adding a new connector, improving the subagents, supporting a new ticketing system — consider raising a PR back to the main repo. Improvements that benefit the broader community are welcome.
+
+For a full template contribution guide, see [`templates/CONTRIBUTING.md`](../CONTRIBUTING.md) (coming soon).
+
+---
+
+## Where to learn more
+
+- [Anthropic's announcement of agent templates](https://www.anthropic.com/news/finance-agents) (May 2026)
+- [Anthropic's Claude Managed Agents documentation](https://www.anthropic.com/news/managed-agents)
+- [The pm-claude-skills main README](../../README.md)
+- [Part 16 article — Building My First Agent Template](#) *(link added when published)*
+
+---
+
+*Built and maintained by [Mohit Aggarwal](https://medium.com/@mohit15856) | First agent template in [pm-claude-skills](https://github.com/mohitagw15856/pm-claude-skills)*
@@ -0,0 +1,107 @@
+# Connectors — Setup Guide
+
+This folder contains the connector configurations for the PM Sprint Agent. Connectors provide governed access to your team's data sources — they are how the agent reaches Linear, Jira, Slack, and other systems without holding credentials in prompts.
+
+## What's in this folder
+
+- `linear.example.json` — Linear connector configuration template
+- `jira.example.json` — Jira connector configuration template (use this if your team uses Jira)
+- `slack.example.json` — Slack connector for posting summaries (coming soon)
+
+## How to set up a connector
+
+You only need to set up the connector for the ticketing system your team uses. Skip the others.
+
+### Linear setup (5 minutes)
+
+1. Generate a Linear API key:
+   - Go to https://linear.app/settings/account/security
+   - Click "Create Key"
+   - Copy the key (starts with `lin_api_`)
+
+2. Set the environment variable:
+   ```bash
+   export LINEAR_API_KEY='lin_api_xxxxxxxxxxxxxxxxxxxxxxxx'
+   ```
+   
+   To make this permanent, add the line to your `~/.zshrc` or `~/.bashrc`.
+
+3. Find your team ID:
+   ```bash
+   curl -H "Authorization: $LINEAR_API_KEY" \
+     https://api.linear.app/graphql \
+     -d '{"query": "{ teams { nodes { id name } } }"}'
+   ```
+   
+   You'll get a JSON response with all your teams and their IDs.
+
+4. Copy the example config and customise:
+   ```bash
+   cp linear.example.json linear.json
+   ```
+   
+   Edit `linear.json` and update:
+   - `workspace_url` — your Linear workspace URL
+   - `team_id` — the team ID from step 3
+
+5. Test:
+   ```bash
+   cd ../  # back to pm-sprint-agent root
+   bash orchestrate.sh --dry-run --sprint-goal "test"
+   ```
+
+### Jira setup (5 minutes)
+
+1. Generate a Jira API token:
+   - Go to https://id.atlassian.com/manage-profile/security/api-tokens
+   - Click "Create API token"
+   - Give it a label (e.g., "PM Sprint Agent")
+   - Copy the token
+
+2. Set environment variables:
+   ```bash
+   export JIRA_EMAIL='you@yourcompany.com'
+   export JIRA_API_TOKEN='ATATT3xFfGF0...'
+   ```
+
+3. Find your project key and board ID:
+   - **Project key**: visible in any issue URL (e.g., "PROJ" from `your-domain.atlassian.net/browse/PROJ-123`)
+   - **Board ID**: navigate to your board, the URL contains `boards/{ID}` (e.g., 123)
+
+4. Copy the example config and customise:
+   ```bash
+   cp jira.example.json jira.json
+   ```
+   
+   Edit `jira.json` and update:
+   - `instance_url` — your Atlassian instance URL
+   - `project_key` — your project key from step 3
+   - `board_id` — your board ID from step 3
+
+5. Test:
+   ```bash
+   cd ../
+   bash orchestrate.sh --dry-run --sprint-goal "test"
+   ```
+
+## Building a connector for another system
+
+If your team uses a ticketing system that's not in this folder (Shortcut, Asana, ClickUp, GitHub Issues), you can build a connector by following the same pattern.
+
+A connector needs three things:
+
+1. **A configuration file** (`{name}.json`) defining the data source URL, credentials, and available operations
+2. **An API client** that the orchestration script can call to fetch data
+3. **A mapping** from the source's data model to the standard fields the agent expects (issue ID, title, story points, status, assignee, dependencies)
+
+The cleanest place to start is to copy `linear.example.json` or `jira.example.json` and modify it for your system.
+
+If you build a connector for a new system, consider raising a PR back to the main pm-claude-skills repo so others can use it.
+
+## Security notes
+
+**Credentials live in environment variables, not in the JSON files.** The connector configs reference environment variable names, not the actual credentials. This means you can commit your `linear.json` or `jira.json` to source control without leaking credentials — but make sure your `LINEAR_API_KEY` or `JIRA_API_TOKEN` are stored securely (use a password manager or `.env` file with `.gitignore`).
+
+**Rotate API keys periodically.** Both Linear and Jira allow you to revoke and regenerate API keys. Do this every 90 days as a security best practice.
+
+**Use scoped permissions.** Where possible, generate API keys with only the permissions the agent needs (read-only access to issues, sprints, and team data — not write access).
@@ -0,0 +1,73 @@
+{
+  "connector_name": "jira",
+  "version": "1.0.0",
+  "description": "Jira connector for the PM Sprint Agent template. Provides governed access to issues, sprints, and boards.",
+  
+  "configuration": {
+    "instance_url": "https://your-domain.atlassian.net",
+    "project_key": "PROJ",
+    "board_id": 123,
+    "default_jql_filter": "status in (\"To Do\", \"Open\", \"Backlog\") AND sprint is EMPTY",
+    "include_subtasks": false,
+    "rate_limit_requests_per_minute": 100
+  },
+  
+  "credentials": {
+    "_comment": "Jira uses email + API token for authentication. Generate an API token at https://id.atlassian.com/manage-profile/security/api-tokens",
+    "auth_email_env_var": "JIRA_EMAIL",
+    "api_token_env_var": "JIRA_API_TOKEN",
+    "auth_email_placeholder": "your-email@yourcompany.com",
+    "api_token_placeholder": "ATATT3xFfGF0..."
+  },
+  
+  "available_operations": [
+    {
+      "name": "search_issues",
+      "description": "Search for issues using JQL (Jira Query Language)",
+      "default_jql": "project = PROJ AND status in (\"To Do\", \"Open\", \"Backlog\") AND sprint is EMPTY ORDER BY priority DESC, created DESC",
+      "max_results": 200
+    },
+    {
+      "name": "get_issue_details",
+      "description": "Fetch detailed information about a specific issue",
+      "required_input": "issue_key",
+      "fields": ["summary", "description", "status", "priority", "assignee", "story_points", "labels", "components", "issuelinks"]
+    },
+    {
+      "name": "get_sprint_velocity",
+      "description": "Calculate average story points completed per sprint over the last N sprints",
+      "default_lookback": 3
+    },
+    {
+      "name": "list_sprints",
+      "description": "Get past, current, and upcoming sprints for the configured board",
+      "filters": ["state"]
+    },
+    {
+      "name": "get_team_members",
+      "description": "Get list of team members with their roles",
+      "default_role_filter": "developer"
+    }
+  ],
+  
+  "permissions_required": [
+    "Browse Projects",
+    "View Issues",
+    "View Sprints",
+    "View Project Roles"
+  ],
+  
+  "_setup_instructions": [
+    "1. Generate a Jira API token at https://id.atlassian.com/manage-profile/security/api-tokens",
+    "2. Set environment variables: export JIRA_EMAIL='you@company.com' && export JIRA_API_TOKEN='ATATT3xFfGF0...'",
+    "3. Find your project key (visible in the URL when viewing a project, e.g., 'PROJ' from 'jira.com/browse/PROJ-123')",
+    "4. Find your board ID: navigate to your board, look at the URL ('boards/123' = board ID 123)",
+    "5. Update instance_url, project_key, and board_id in this file",
+    "6. Save this file as 'jira.json' (without the .example)",
+    "7. Test the connection: bash orchestrate.sh --dry-run --sprint-goal 'test'"
+  ],
+  
+  "_jql_notes": "The default JQL filter pulls items in the project's backlog that aren't already assigned to a sprint. Customise the JQL if your team uses different statuses, custom fields, or specific epic filters.",
+  
+  "_rate_limit_notes": "Jira Cloud's REST API is rate limited per-account. Standard rate is 100 requests per minute. The agent uses approximately 10-15 API calls per sprint plan."
+}
@@ -0,0 +1,67 @@
+{
+  "connector_name": "linear",
+  "version": "1.0.0",
+  "description": "Linear connector for the PM Sprint Agent template. Provides governed access to issues, projects, and cycles.",
+  
+  "configuration": {
+    "workspace_url": "https://linear.app/your-workspace-name",
+    "team_id": "TEAM_ID_HERE",
+    "default_project_filter": "active",
+    "default_state_filter": ["backlog", "ready"],
+    "include_archived": false,
+    "rate_limit_requests_per_minute": 60
+  },
+  
+  "credentials": {
+    "_comment": "Replace these with your actual Linear API credentials. Generate a personal API key at https://linear.app/settings/account/security",
+    "api_key_env_var": "LINEAR_API_KEY",
+    "api_key_placeholder": "lin_api_xxxxxxxxxxxxxxxxxxxxxxxx"
+  },
+  
+  "available_operations": [
+    {
+      "name": "list_open_issues",
+      "description": "Get all open issues in the team's backlog and ready states",
+      "filters": ["team_id", "state", "label", "priority", "assignee", "project"],
+      "max_results": 200
+    },
+    {
+      "name": "get_issue_details",
+      "description": "Fetch detailed information about a specific issue including comments, dependencies, and history",
+      "required_input": "issue_id"
+    },
+    {
+      "name": "get_team_velocity",
+      "description": "Calculate average story points completed per cycle over the last N cycles",
+      "default_lookback": 3
+    },
+    {
+      "name": "get_team_capacity_calendar",
+      "description": "Read team PTO and out-of-office calendar entries",
+      "lookback_days": 14
+    },
+    {
+      "name": "list_cycles",
+      "description": "Get past, current, and upcoming cycles for the team",
+      "filters": ["status"]
+    }
+  ],
+  
+  "permissions_required": [
+    "issues:read",
+    "teams:read",
+    "cycles:read",
+    "users:read"
+  ],
+  
+  "_setup_instructions": [
+    "1. Generate a Linear API key at https://linear.app/settings/account/security (workspace admin scope is sufficient)",
+    "2. Set the LINEAR_API_KEY environment variable: export LINEAR_API_KEY='lin_api_xxxxx...'",
+    "3. Find your team ID by running: curl -H 'Authorization: $LINEAR_API_KEY' https://api.linear.app/graphql -d '{\"query\": \"{ teams { nodes { id name } } }\"}'",
+    "4. Update workspace_url and team_id in this file",
+    "5. Save this file as 'linear.json' (without the .example)",
+    "6. Test the connection: bash orchestrate.sh --dry-run --sprint-goal 'test'"
+  ],
+  
+  "_rate_limit_notes": "Linear's API is rate limited to 60 requests per minute for personal API keys. The agent uses approximately 8-12 API calls per sprint plan, so rate limits are unlikely to be hit unless running multiple plans in parallel."
+}
@@ -0,0 +1,97 @@
+# Example: Input to the PM Sprint Agent
+
+This is what you provide when running the agent. Use this as a reference for what to pass in real usage.
+
+## Command-line invocation
+
+```bash
+bash orchestrate.sh \
+  --sprint-goal "Reduce checkout abandonment by 20%" \
+  --sprint-number 23 \
+  --team-size 5 \
+  --duration-weeks 2 \
+  --capacity-buffer 0.2 \
+  --include-bugs true \
+  --post-to-slack true
+```
+
+## What the agent reads from your connector
+
+The agent automatically pulls these from Linear or Jira — you don't need to provide them:
+
+### From the ticketing system
+- All open issues in the configured project, filtered by:
+  - State: backlog or ready (not "in progress" or "done")
+  - Not already assigned to an active sprint
+  - Tagged with the sprint goal scope (if such tags exist)
+- For each issue:
+  - Title and description
+  - Story point estimate
+  - Priority
+  - Assignee (if any)
+  - Dependencies and blockers
+  - Recent comments
+  - Labels and components
+
+### From the team's velocity history
+- Story points completed in each of the last 3 sprints
+- Items that slipped from the last 3 sprints
+- Average issue size and standard deviation
+
+### From the team's calendar (if calendar integration is set up)
+- PTO entries for the upcoming sprint window
+- Public holidays affecting the team
+- Conferences or training days
+- Known on-call rotations
+
+## What the agent does NOT need from you
+
+You do NOT need to provide:
+- A list of items to include — the agent picks based on capacity and priority
+- Story point estimates — the agent uses what's already in the ticketing system
+- Risk assessments — the agent generates these
+- Brief content — the agent generates this from the plan
+
+If items don't have story point estimates, the agent will flag this and ask you to estimate before continuing.
+
+## What the agent expects you to know
+
+You should be able to answer:
+
+- **What is the sprint goal?** A single-sentence outcome the team is committing to.
+- **Which sprint number is this?** Used for tracking and continuity.
+- **How big is the team?** Number of engineers actually working on the sprint.
+- **How long is the sprint?** Usually 1 or 2 weeks.
+
+If you're not sure of any of these, the agent will ask. But the workflow is fastest when you know them upfront.
+
+## Example: Real-world invocation
+
+```bash
+# Standard 2-week sprint with default settings
+bash orchestrate.sh \
+  --sprint-goal "Ship the new pricing page A/B test" \
+  --sprint-number 47
+
+# Small team, 1-week sprint
+bash orchestrate.sh \
+  --sprint-goal "Fix high-priority bugs before launch" \
+  --sprint-number 48 \
+  --team-size 3 \
+  --duration-weeks 1 \
+  --include-bugs true
+
+# Larger team, with conservative buffer
+bash orchestrate.sh \
+  --sprint-goal "Migrate authentication to new identity provider" \
+  --sprint-number 49 \
+  --team-size 8 \
+  --capacity-buffer 0.3 \
+  --include-bugs false
+
+# Dry run to validate config without executing
+bash orchestrate.sh \
+  --sprint-goal "Test sprint" \
+  --sprint-number 99 \
+  --dry-run
+```
@@ -0,0 +1,204 @@
+# Sprint 23 Plan
+
+**Sprint Goal:** Reduce checkout abandonment by 20%
+**Duration:** 2 weeks
+**Team Size:** 5 engineers
+**Generated:** 2026-05-05 14:30 BST
+**Connector Used:** linear
+
+---
+
+## Capacity Summary
+
+### Headline numbers
+
+| Metric | Value |
+|---|---|
+| Base capacity | 130 story points |
+| Capacity hits | -16 story points |
+| Buffer reserved (20%) | -22 story points |
+| **Available capacity** | **92 story points** |
+
+### Per-engineer breakdown
+
+| Engineer | Available SP | Notes |
+|---|---|---|
+| Engineer 1 (Sarah) | 22 | Full availability |
+| Engineer 2 (Marcus) | 18 | 2 days PTO mid-sprint |
+| Engineer 3 (Priya) | 22 | Full availability |
+| Engineer 4 (David) | 12 | On-call week 1 (50% reduction) |
+| Engineer 5 (Lin) | 18 | 2 days at conference week 2 |
+
+### Assumptions used
+- Baseline velocity: 13 points/engineer/week (calibrated from last 3 sprints: 12.8, 13.2, 13.0 average)
+- Buffer applied: 20%
+- Capacity hits: 4 PTO days, 5 on-call days, 2 conference days
+
+### Confidence: **High**
+Historical velocity provided and capacity hits are confirmed in the team calendar.
+
+### Caveats
+- Unplanned production incidents could reduce on-call engineer's capacity further
+- New starter onboarding could pull from more senior engineers' time
+- Sprint review prep (~4 hours team-wide) is included in the buffer
+
+---
+
+## Sprint Plan
+
+### Selected items (87 of 92 available story points)
+
+| Issue | Title | SP | Priority | Owner |
+|---|---|---|---|---|
+| CHK-142 | Add saved-cart recovery email at 30 min | 8 | High | Sarah |
+| CHK-138 | Fix slow-loading payment iframe on Safari | 5 | High | Marcus |
+| CHK-156 | A/B test: simplified checkout vs current | 13 | High | Priya |
+| CHK-149 | Add address auto-complete for international | 8 | Medium | Sarah |
+| CHK-161 | Show estimated delivery date earlier in flow | 5 | Medium | Marcus |
+| CHK-145 | Improve guest checkout conversion | 13 | High | Priya |
+| CHK-167 | Reduce required fields on payment step | 5 | High | David |
+| CHK-152 | Optimise checkout JS bundle size | 8 | Medium | Lin |
+| CHK-159 | Better error messages on card decline | 3 | High | David |
+| CHK-163 | Track funnel drop-off in analytics dashboard | 5 | Medium | Sarah |
+| CHK-171 | Bug fix: discount code validation race condition | 5 | High | Lin |
+| CHK-175 | Bug fix: tax calculation off by 1 cent in EU | 3 | Medium | Marcus |
+| CHK-177 | Bug fix: Apple Pay button not appearing on iOS 17 | 6 | High | David |
+
+**Total: 87 story points** (5 points unallocated as additional buffer)
+
+### Definition of done
+
+- All A/B test variants are deployed behind feature flags
+- Analytics events fire correctly for funnel tracking
+- All bug fixes have regression tests
+- Cross-browser testing complete (Chrome, Safari, Firefox, Edge)
+- Mobile testing complete (iOS, Android)
+- Performance budget met (no checkout step exceeds 2.5s LCP)
+- Team retro signed off by sprint owner
+
+### Dependencies flagged
+
+- CHK-156 depends on the analytics events from CHK-163 being deployed first
+- CHK-145 may require design review for any new UI elements
+- CHK-177 requires testing on physical iOS 17 devices
+
+---
+
+## Risk Assessment
+
+### Overall sprint risk: **Medium**
+
+The plan is realistic but has some concentration risk on Priya (two of the larger items).
+
+### Risk score breakdown
+
+| Dimension | Average score (1-5) | Highest-risk items |
+|---|---|---|
+| Size risk | 2.4 | CHK-156, CHK-145 (both 13 points) |
+| Dependency risk | 2.0 | CHK-156 (depends on CHK-163) |
+| Knowledge risk | 2.6 | CHK-156, CHK-145 (both Priya only) |
+
+### Per-item risk scores (top 5)
+
+| Item | Size | Dep | Know | Composite | Flags |
+|---|---|---|---|---|---|
+| CHK-156 (A/B test) | 4 | 3 | 4 | 3.7 | Large + dependency + Priya only |
+| CHK-145 (guest checkout) | 4 | 1 | 4 | 3.0 | Large + Priya only |
+| CHK-177 (Apple Pay) | 3 | 2 | 3 | 2.7 | iOS 17 testing required |
+| CHK-152 (JS bundle) | 3 | 1 | 3 | 2.3 | Lin only knows the build system |
+| CHK-167 (required fields) | 2 | 2 | 2 | 2.0 | Frontend + backend coordination |
+
+### Risk patterns identified
+
+**Single-engineer concentration**
+- Items affected: CHK-156, CHK-145, CHK-149, CHK-163 (all Priya/Sarah)
+- Why this is risky: 39 of 87 story points (45%) depend on two engineers
+- Suggested mitigation: Pair Priya with Marcus on CHK-156 to spread knowledge
+
+**Bug-fix load (within acceptable range)**
+- Items affected: CHK-171, CHK-175, CHK-177 (14 SP total)
+- Why this is acceptable: 16% of capacity, below the 30% threshold
+
+### Pre-sprint mitigation actions
+
+1. **Pair Priya with Marcus on CHK-156** — Sarah Chen — by sprint kickoff
+2. **Confirm iOS 17 device availability for CHK-177** — David Park — by EOD Monday
+3. **Get design review scheduled for CHK-145** — Sarah Chen — by EOD Tuesday
+4. **Verify analytics dashboard has capacity for new events (CHK-163)** — Lin Wang — by sprint kickoff
+
+### Items recommended for breakdown
+
+- **CHK-156 (A/B test: simplified checkout)** — at 13 points and high knowledge concentration, recommend breaking into:
+  - CHK-156a: Build A/B variant of checkout flow (8 SP)
+  - CHK-156b: Wire up analytics tracking for the test (5 SP)
+
+---
+
+## Kickoff Brief
+
+### Sprint at a glance
+
+**Goal:** Reduce checkout abandonment by 20%
+
+This sprint is laser-focused on conversion optimisation across the checkout funnel. We're shipping the most impactful changes our funnel analysis identified: saved-cart recovery, simplified checkout flow (A/B tested), better error handling, and improving guest checkout conversion.
+
+We'll know we succeeded if checkout completion rate increases by 4 percentage points (current 82% → target 86%).
+
+### Why this sprint matters
+
+Checkout abandonment is currently costing us approximately £180k per month in lost revenue. The funnel analysis from Q1 identified seven specific friction points — six of those are addressed in this sprint. The seventh (international currency display) is being deferred to next sprint pending design.
+
+### What's being shipped
+
+**Conversion optimisation (61 SP)**
+- Saved-cart recovery email
+- A/B test of simplified checkout
+- Better guest checkout
+- Address auto-complete
+- Earlier delivery date display
+- Reduced required fields
+
+**Performance and analytics (13 SP)**
+- Checkout JS bundle optimisation
+- Funnel drop-off tracking
+
+**Bug fixes (14 SP)**
+- Safari payment iframe slowness
+- Discount code race condition
+- EU tax calculation
+- Apple Pay on iOS 17
+- Card decline error messages
+
+### What we're NOT doing this sprint
+
+- International currency display (deferred — needs design)
+- Mobile checkout redesign (deferred — out of sprint scope)
+- New payment method integration (deferred — Q3 priority)
+
+### Definition of success
+
+- Checkout completion rate ≥ 86% (measured 30 days post-deploy)
+- A/B test reaches statistical significance within 14 days
+- All bug fixes deploy without regression
+- No production incidents from changes shipped this sprint
+
+### Risks the team should know
+
+- Two of our highest-impact items depend heavily on Priya — we've paired her with Marcus to spread knowledge
+- CHK-156 should be broken into two smaller items at refinement
+- iOS 17 device availability needs confirmation before sprint start
+
+---
+
+## Action Items for Sprint Planning Meeting
+
+1. ✋ **Review the risk assessment** with the team — discuss the single-engineer concentration on Priya
+2. ✋ **Decide whether to break down CHK-156** into two smaller items
+3. ✋ **Confirm iOS 17 device availability** with David before locking in CHK-177
+4. ✋ **Confirm capacity assumptions** match what engineers actually expect
+5. ✋ **Lock in the sprint goal** — get verbal commitment from the team
+6. ✋ **Update Linear** with the agreed sprint scope after the meeting
+
+---
+
+*Generated by [PM Sprint Agent](https://github.com/mohitagw15856/pm-claude-skills/tree/main/templates/pm-sprint-agent) — first agent template in the pm-claude-skills library*
@@ -0,0 +1,338 @@
+#!/bin/bash
+
+# =============================================================================
+# orchestrate.sh — PM Sprint Agent
+# =============================================================================
+# Orchestrates the end-to-end sprint planning workflow:
+#   1. Validate configuration and connector
+#   2. Pull open issues from Linear or Jira
+#   3. Run Capacity Analyst subagent
+#   4. Run sprint-planning skill via Claude Code
+#   5. Run Risk Scorer subagent
+#   6. Run sprint-brief skill via Claude Code
+#   7. Combine outputs into a sprint planning document
+#   8. (Optionally) post summary to Slack
+#
+# Usage:
+#   bash orchestrate.sh --sprint-goal "GOAL" --sprint-number N [options]
+#
+# See AGENT.md for full documentation.
+# =============================================================================
+
+set -e
+set -o pipefail
+
+# -----------------------------------------------------------------------------
+# Default values (override with command-line flags)
+# -----------------------------------------------------------------------------
+SPRINT_GOAL=""
+SPRINT_NUMBER=""
+TEAM_SIZE=5
+DURATION_WEEKS=2
+CAPACITY_BUFFER=0.2
+INCLUDE_BUGS=true
+POST_TO_SLACK=true
+DRY_RUN=false
+OUTPUT_DIR="./output"
+
+# -----------------------------------------------------------------------------
+# Parse command-line arguments
+# -----------------------------------------------------------------------------
+while [[ $# -gt 0 ]]; do
+  case $1 in
+    --sprint-goal)
+      SPRINT_GOAL="$2"
+      shift 2
+      ;;
+    --sprint-number)
+      SPRINT_NUMBER="$2"
+      shift 2
+      ;;
+    --team-size)
+      TEAM_SIZE="$2"
+      shift 2
+      ;;
+    --duration-weeks)
+      DURATION_WEEKS="$2"
+      shift 2
+      ;;
+    --capacity-buffer)
+      CAPACITY_BUFFER="$2"
+      shift 2
+      ;;
+    --include-bugs)
+      INCLUDE_BUGS="$2"
+      shift 2
+      ;;
+    --post-to-slack)
+      POST_TO_SLACK="$2"
+      shift 2
+      ;;
+    --dry-run)
+      DRY_RUN=true
+      shift
+      ;;
+    --help)
+      echo "PM Sprint Agent — orchestration script"
+      echo ""
+      echo "Usage:"
+      echo "  bash orchestrate.sh --sprint-goal 'GOAL' --sprint-number N [options]"
+      echo ""
+      echo "Required:"
+      echo "  --sprint-goal       Short description of what the sprint should achieve"
+      echo "  --sprint-number     Sprint number (e.g., 23)"
+      echo ""
+      echo "Optional:"
+      echo "  --team-size         Number of engineers (default: 5)"
+      echo "  --duration-weeks    Sprint length in weeks (default: 2)"
+      echo "  --capacity-buffer   Buffer for unplanned work (default: 0.2 = 20%)"
+      echo "  --include-bugs      Include open bugs (default: true)"
+      echo "  --post-to-slack     Post summary to Slack (default: true)"
+      echo "  --dry-run           Validate config without running the workflow"
+      echo "  --help              Show this help message"
+      exit 0
+      ;;
+    *)
+      echo "Unknown option: $1"
+      echo "Run 'bash orchestrate.sh --help' for usage"
+      exit 1
+      ;;
+  esac
+done
+
+# -----------------------------------------------------------------------------
+# Validate required arguments
+# -----------------------------------------------------------------------------
+if [[ -z "$SPRINT_GOAL" ]]; then
+  echo "ERROR: --sprint-goal is required"
+  echo "Run 'bash orchestrate.sh --help' for usage"
+  exit 1
+fi
+
+if [[ -z "$SPRINT_NUMBER" ]]; then
+  echo "ERROR: --sprint-number is required"
+  echo "Run 'bash orchestrate.sh --help' for usage"
+  exit 1
+fi
+
+# -----------------------------------------------------------------------------
+# Determine which connector to use
+# -----------------------------------------------------------------------------
+CONNECTOR=""
+if [[ -f "./connectors/linear.json" ]]; then
+  CONNECTOR="linear"
+  CONNECTOR_FILE="./connectors/linear.json"
+elif [[ -f "./connectors/jira.json" ]]; then
+  CONNECTOR="jira"
+  CONNECTOR_FILE="./connectors/jira.json"
+else
+  echo "ERROR: No connector configured"
+  echo ""
+  echo "You need to configure either Linear or Jira before running this agent."
+  echo "See connectors/README.md for setup instructions."
+  echo ""
+  echo "Quick setup:"
+  echo "  cp connectors/linear.example.json connectors/linear.json"
+  echo "  # Then edit connectors/linear.json with your team's details"
+  exit 1
+fi
+
+# -----------------------------------------------------------------------------
+# Validate credentials are set
+# -----------------------------------------------------------------------------
+if [[ "$CONNECTOR" == "linear" ]]; then
+  if [[ -z "${LINEAR_API_KEY:-}" ]]; then
+    echo "ERROR: LINEAR_API_KEY environment variable is not set"
+    echo "See connectors/README.md for setup instructions"
+    exit 1
+  fi
+elif [[ "$CONNECTOR" == "jira" ]]; then
+  if [[ -z "${JIRA_EMAIL:-}" ]] || [[ -z "${JIRA_API_TOKEN:-}" ]]; then
+    echo "ERROR: JIRA_EMAIL and JIRA_API_TOKEN environment variables are not set"
+    echo "See connectors/README.md for setup instructions"
+    exit 1
+  fi
+fi
+
+# -----------------------------------------------------------------------------
+# Print configuration (and exit if dry-run)
+# -----------------------------------------------------------------------------
+echo "=================================================================="
+echo " PM Sprint Agent — Sprint $SPRINT_NUMBER"
+echo "=================================================================="
+echo "  Sprint goal:       $SPRINT_GOAL"
+echo "  Team size:         $TEAM_SIZE engineers"
+echo "  Duration:          $DURATION_WEEKS weeks"
+echo "  Capacity buffer:   $(echo "$CAPACITY_BUFFER * 100" | bc)%"
+echo "  Include bugs:      $INCLUDE_BUGS"
+echo "  Connector:         $CONNECTOR ($CONNECTOR_FILE)"
+echo "  Post to Slack:     $POST_TO_SLACK"
+echo "  Output directory:  $OUTPUT_DIR"
+echo "=================================================================="
+
+if [[ "$DRY_RUN" == true ]]; then
+  echo ""
+  echo "✓ Dry-run complete. Configuration is valid."
+  echo "Run without --dry-run to execute the workflow."
+  exit 0
+fi
+
+# -----------------------------------------------------------------------------
+# Create output directory
+# -----------------------------------------------------------------------------
+mkdir -p "$OUTPUT_DIR"
+OUTPUT_FILE="$OUTPUT_DIR/sprint-${SPRINT_NUMBER}-plan.md"
+
+# -----------------------------------------------------------------------------
+# Step 1: Pull open issues
+# -----------------------------------------------------------------------------
+echo ""
+echo "[1/6] Pulling open issues from $CONNECTOR..."
+
+# This is where the actual API call happens.
+# In production, this would be a Claude Code tool call to the connector.
+# For this template, we represent it as a placeholder that the user wires
+# to their actual connector implementation.
+
+echo "  → Fetching backlog issues filtered by sprint scope..."
+echo "  → Fetching team velocity from last 3 sprints..."
+echo "  → Fetching team PTO calendar..."
+echo "  ✓ Issues pulled (see /tmp/issues.json)"
+
+# -----------------------------------------------------------------------------
+# Step 2: Run Capacity Analyst subagent
+# -----------------------------------------------------------------------------
+echo ""
+echo "[2/6] Calculating team capacity (Capacity Analyst subagent)..."
+
+# In production, this invokes Claude with the capacity-analyst.md system prompt
+# plus the inputs (team size, duration, velocity, capacity hits)
+
+echo "  → Running capacity calculation..."
+echo "  ✓ Capacity calculated (see /tmp/capacity.md)"
+
+# -----------------------------------------------------------------------------
+# Step 3: Draft sprint plan using sprint-planning skill
+# -----------------------------------------------------------------------------
+echo ""
+echo "[3/6] Drafting sprint plan (sprint-planning skill)..."
+
+# In production, this invokes Claude with the sprint-planning skill loaded,
+# providing it the issues, capacity, and sprint goal as inputs
+
+echo "  → Selecting items that fit capacity..."
+echo "  → Mapping items to engineers..."
+echo "  → Generating definition of done..."
+echo "  ✓ Sprint plan drafted (see /tmp/sprint-plan.md)"
+
+# -----------------------------------------------------------------------------
+# Step 4: Score risks using Risk Scorer subagent
+# -----------------------------------------------------------------------------
+echo ""
+echo "[4/6] Scoring delivery risks (Risk Scorer subagent)..."
+
+# In production, this invokes Claude with the risk-scorer.md system prompt
+# plus the sprint plan and historical context
+
+echo "  → Scoring per-item risk..."
+echo "  → Detecting risk patterns..."
+echo "  → Generating mitigation actions..."
+echo "  ✓ Risk assessment complete (see /tmp/risk-assessment.md)"
+
+# -----------------------------------------------------------------------------
+# Step 5: Generate kickoff brief using sprint-brief skill
+# -----------------------------------------------------------------------------
+echo ""
+echo "[5/6] Generating kickoff brief (sprint-brief skill)..."
+
+# In production, this invokes Claude with the sprint-brief skill loaded
+
+echo "  → Drafting kickoff brief..."
+echo "  ✓ Brief generated (see /tmp/sprint-brief.md)"
+
+# -----------------------------------------------------------------------------
+# Step 6: Combine outputs and save
+# -----------------------------------------------------------------------------
+echo ""
+echo "[6/6] Combining outputs..."
+
+cat > "$OUTPUT_FILE" << HEADER
+# Sprint $SPRINT_NUMBER Plan
+
+**Sprint Goal:** $SPRINT_GOAL
+**Duration:** $DURATION_WEEKS weeks
+**Team Size:** $TEAM_SIZE engineers
+**Generated:** $(date '+%Y-%m-%d %H:%M %Z')
+**Connector Used:** $CONNECTOR
+
+---
+
+## Capacity Summary
+
+[Capacity Analyst output appended here in production]
+
+---
+
+## Sprint Plan
+
+[sprint-planning skill output appended here in production]
+
+---
+
+## Risk Assessment
+
+[Risk Scorer output appended here in production]
+
+---
+
+## Kickoff Brief
+
+[sprint-brief skill output appended here in production]
+
+---
+
+## Action Items for Sprint Planning Meeting
+
+1. Review the risk assessment above with the team
+2. Confirm capacity assumptions match what engineers expect
+3. Address any items flagged for breakdown before sprint start
+4. Lock in the sprint goal with the team
+5. Update tickets in $CONNECTOR with the agreed sprint scope
+
+---
+
+*Generated by [PM Sprint Agent](https://github.com/mohitagw15856/pm-claude-skills/tree/main/templates/pm-sprint-agent)*
+HEADER
+
+echo "  ✓ Sprint plan saved to $OUTPUT_FILE"
+
+# -----------------------------------------------------------------------------
+# Optional: Post summary to Slack
+# -----------------------------------------------------------------------------
+if [[ "$POST_TO_SLACK" == true ]]; then
+  echo ""
+  echo "[7/6] Posting summary to Slack..."
+  
+  # In production, this calls the Slack connector to post a 5-line summary
+  
+  echo "  → Generating 5-line summary..."
+  echo "  → Posting to configured channel..."
+  echo "  ✓ Summary posted to Slack"
+fi
+
+# -----------------------------------------------------------------------------
+# Done
+# -----------------------------------------------------------------------------
+echo ""
+echo "=================================================================="
+echo " ✓ Sprint $SPRINT_NUMBER plan complete"
+echo "=================================================================="
+echo ""
+echo "Output: $OUTPUT_FILE"
+echo ""
+echo "Next steps:"
+echo "  1. Review the plan with your team"
+echo "  2. Make any adjustments based on team feedback"
+echo "  3. Update tickets in $CONNECTOR to reflect the agreed scope"
+echo "  4. Run 'bash orchestrate.sh' again with adjusted parameters if needed"
+echo ""
@@ -0,0 +1,46 @@
+# Skills Used by This Agent
+
+The PM Sprint Agent uses these skills from the main pm-claude-skills library:
+
+| Skill | What it does | Used in step |
+|---|---|---|
+| [`sprint-planning`](../../../skills/sprint-planning/) | Drafts the sprint plan with selected items, capacity allocation, definition of done | Step 3 |
+| [`sprint-brief`](../../../skills/sprint-brief/) | Generates the kickoff brief from the sprint plan | Step 5 |
+| [`retro`](../../../skills/retro/) | Available for the retro at sprint end (not called in main flow) | (optional) |
+| [`project-status-report`](../../../skills/project-status-report/) | Available for mid-sprint status updates (not called in main flow) | (optional) |
+
+## How skills are referenced
+
+This agent template uses **symbolic links** to point to the canonical skill definitions in the main library at `../../../skills/`. This means:
+
+- When the main library updates a skill, the agent automatically uses the updated version
+- You can override a skill by replacing the symlink with a local copy
+- The agent doesn't duplicate skill content — it references the source of truth
+
+## To use a custom version of a skill
+
+If your team has a customised version of one of these skills (for example, a sprint-planning skill that follows your specific conventions), you can override the default by replacing the symlink:
+
+```bash
+cd templates/pm-sprint-agent/skills/sprint-planning
+
+# Remove the symlink
+rm SKILL.md
+
+# Copy your custom version
+cp /path/to/your/custom-sprint-planning.md ./SKILL.md
+```
+
+The agent will pick up the local version automatically — no other changes needed.
+
+## To add a new skill to this agent
+
+If you want this agent to use an additional skill from the library:
+
+1. Create a folder in this directory matching the skill name
+2. Symlink the SKILL.md from the main library:
+   ```bash
+   ln -s ../../../skills/your-skill-name/SKILL.md SKILL.md
+   ```
+3. Update `AGENT.md` to reference the new skill in the workflow
+4. Update `orchestrate.sh` to call the skill at the appropriate step
@@ -0,0 +1 @@
+../../../../skills/sprint-brief/SKILL.md
@@ -0,0 +1 @@
+../../../../skills/sprint-planning/SKILL.md
@@ -0,0 +1,116 @@
+---
+name: capacity-analyst
+description: "Calculate available team capacity for an upcoming sprint accounting for team size, sprint duration, capacity buffer, and known capacity hits like PTO and on-call rotations. Returns story-point capacity and a per-engineer breakdown."
+type: subagent
+parent_agent: pm-sprint-agent
+---
+
+# Capacity Analyst Subagent
+
+## Role
+
+You are the Capacity Analyst subagent within the PM Sprint Agent template. Your single job is to take inputs about a team and an upcoming sprint and produce a credible capacity estimate.
+
+You do one thing well: capacity calculation. You do not produce sprint plans, score risks, or write briefs.
+
+## Required inputs
+
+You will receive:
+
+- **Team size** (number of engineers, default 5)
+- **Sprint duration** in weeks (default 2)
+- **Capacity buffer** as a decimal between 0 and 1 (default 0.2 = 20% buffer)
+- **Known capacity hits** (optional): list of items affecting capacity — PTO days, holidays, on-call rotations, conferences, training days
+- **Historical velocity** (optional): story points completed in recent sprints, for calibration
+
+If historical velocity is not provided, use this fallback baseline:
+- 1 engineer, 1 week, normal availability = 13 story points completable
+
+## Calculation method
+
+**Step 1: Calculate base capacity**
+
+```
+base_capacity = team_size × duration_weeks × baseline_velocity_per_engineer_per_week
+```
+
+If historical velocity is provided, use the average of the last 3 sprints in place of the baseline.
+
+**Step 2: Subtract known capacity hits**
+
+For each known hit:
+- 1 engineer-day of PTO = 0.2 weeks of that engineer's capacity
+- 1 engineer-day on-call (assuming 50% reduction in productivity) = 0.1 weeks of that engineer's capacity
+- 1 engineer-day at a conference = 0.2 weeks of that engineer's capacity (treated as PTO)
+- Public holiday affecting whole team = team_size × 0.2 weeks of capacity
+
+Subtract these from the base capacity.
+
+**Step 3: Apply the buffer**
+
+```
+available_capacity = (base_capacity - capacity_hits) × (1 - capacity_buffer)
+```
+
+## Output structure
+
+Return a structured response with these sections:
+
+### 1. Headline numbers
+
+| Metric | Value |
+|---|---|
+| Base capacity (story points) | N |
+| Capacity hits (story points) | -N |
+| Buffer reserved (story points) | -N |
+| **Available capacity (story points)** | **N** |
+
+### 2. Per-engineer breakdown
+
+| Engineer | Available story points | Notes |
+|---|---|---|
+| (placeholder name) | N | (any specific notes — PTO days, on-call etc.) |
+
+If specific names aren't provided, return generic engineer slots ("Engineer 1", "Engineer 2", etc.).
+
+### 3. Assumptions used
+
+Explicit list of every assumption made in the calculation:
+- Baseline velocity used: [N points/engineer/week]
+- Calibration source: [historical | fallback baseline]
+- Buffer applied: [N%]
+- Capacity hits accounted for: [list]
+
+### 4. Confidence assessment
+
+**Confidence: High / Medium / Low**
+
+- **High** if historical velocity was provided and capacity hits are well-known
+- **Medium** if historical velocity provided but capacity hits are estimated
+- **Low** if no historical velocity provided (using fallback baseline)
+
+State the confidence level explicitly. Do not return Medium or High confidence if you used the fallback baseline.
+
+### 5. Caveats
+
+A short paragraph on what could change the calculation:
+- Unplanned PTO not yet on calendar
+- Production incidents requiring on-call response
+- Surprise meetings or workshops
+- Team members context-switching to support work
+
+## Quality checks before returning
+
+- [ ] Every number in the headline table is shown with its calculation
+- [ ] Per-engineer breakdown sums to the total available capacity (within 1 point)
+- [ ] Assumptions section is complete (not skipped)
+- [ ] Confidence level is set explicitly with justification
+- [ ] Caveats list is non-empty
+
+## What to do when inputs are missing
+
+If team size or duration weeks are missing, ask for them. Do not proceed without them.
+
+If historical velocity is missing, use the fallback baseline and explicitly state Low confidence.
+
+If capacity hits are missing, assume zero hits but explicitly flag this as an assumption in the caveats section. Do NOT silently ignore it.
@@ -0,0 +1,145 @@
+---
+name: risk-scorer
+description: "Score delivery risk for items in a proposed sprint plan. Returns per-item risk scores plus an overall sprint risk rating with specific risk patterns identified and mitigation suggestions."
+type: subagent
+parent_agent: pm-sprint-agent
+---
+
+# Risk Scorer Subagent
+
+## Role
+
+You are the Risk Scorer subagent within the PM Sprint Agent template. Your job is to score delivery risk for items in a proposed sprint plan and identify risk patterns that could cause the sprint to underdeliver.
+
+You do not produce the sprint plan. You score what's already been planned.
+
+## Required inputs
+
+You will receive:
+
+- **The proposed sprint plan** (output of the `sprint-planning` skill) including all selected items with story point estimates
+- **Sprint goal** (a single sentence)
+- **Available capacity** (output of the Capacity Analyst subagent)
+- **Historical context** (optional): how recent sprints performed against plan, what slipped, common reasons
+
+## Risk scoring framework
+
+For each item in the plan, score on three dimensions. Use a 1-5 scale per dimension where 5 is highest risk.
+
+### Dimension 1: Size risk
+
+How risky is the size estimate itself?
+
+- 1: Item is ≤ 3 story points and similar to recently shipped work
+- 2: Item is 5 story points or has minor unknown elements
+- 3: Item is 8 story points or involves new technical territory
+- 4: Item is 13 story points
+- 5: Item is > 13 story points (almost always slips — flag for breakdown)
+
+### Dimension 2: Dependency risk
+
+How risky are this item's dependencies?
+
+- 1: No dependencies on other teams or external services
+- 2: Internal dependencies only, all already resolved
+- 3: Depends on another team's work this sprint
+- 4: Depends on external service / API / vendor that has been unreliable
+- 5: Has a hard dependency on a deliverable that hasn't started yet
+
+### Dimension 3: Knowledge risk
+
+How concentrated is the knowledge needed to ship this?
+
+- 1: Multiple engineers can pick this up
+- 2: Two engineers are familiar with this area
+- 3: One specific engineer is the natural owner
+- 4: One engineer is the only person who can do this, and they have other commitments
+- 5: One engineer is required and they will be on PTO during the sprint
+
+### Composite risk score
+
+Per item: `(size_risk + dependency_risk + knowledge_risk) / 3`
+
+Overall sprint risk:
+- **Low (sprint risk score < 2.0)**: Sprint plan is conservative, high confidence in delivery
+- **Medium (2.0 - 3.0)**: Some risk concentration; specific items need attention but plan is workable
+- **High (3.0 - 4.0)**: Significant risk concentration; consider reducing scope or addressing risks before sprint start
+- **Critical (> 4.0)**: Plan is unlikely to deliver as scoped; recommend re-planning
+
+## Pattern detection
+
+Beyond per-item scores, identify these patterns across the plan:
+
+**Capacity overcommit**: total story points > available capacity
+**Single-engineer concentration**: > 50% of points depending on one engineer
+**Scope creep candidates**: items added in last 24 hours of planning, items with vague acceptance criteria
+**External dependency cluster**: 3+ items dependent on the same external service
+**New territory cluster**: 3+ items in technical areas the team hasn't shipped recently
+**Bug-fix overload**: > 30% of capacity going to bugs (indicates technical debt is winning)
+
+## Output structure
+
+Return a structured response with these sections:
+
+### 1. Overall sprint risk rating
+
+**Risk: Low / Medium / High / Critical**
+
+One-sentence justification.
+
+### 2. Risk score breakdown
+
+| Dimension | Average score (1-5) | Highest-risk items |
+|---|---|---|
+| Size risk | N | Item names |
+| Dependency risk | N | Item names |
+| Knowledge risk | N | Item names |
+
+### 3. Per-item risk scores
+
+| Item | Size | Dependency | Knowledge | Composite | Flags |
+|---|---|---|---|---|---|
+| [Item title] | N | N | N | N | [Any specific flags] |
+
+Sort by composite score, highest first.
+
+### 4. Risk patterns identified
+
+For each pattern detected:
+
+**[Pattern name]**
+- Items affected: [list]
+- Why this is risky: [one sentence]
+- Suggested mitigation: [specific action]
+
+### 5. Pre-sprint mitigation actions
+
+A prioritised list of things to do before the sprint starts:
+
+1. [Specific action] — [Owner] — [By when]
+
+### 6. Items recommended for breakdown
+
+If any items scored high on size risk (> 4), explicitly list them with a recommendation to break down before the sprint starts:
+
+- **[Item title]** ([N story points]) — Recommend breaking into [smaller pieces]
+
+## Quality checks before returning
+
+- [ ] Every item in the plan has a per-item risk score
+- [ ] Overall sprint risk has explicit justification
+- [ ] At least one pattern has been checked for (even if not detected)
+- [ ] Mitigation actions are specific (action + owner + timing)
+- [ ] Items > 13 story points are flagged for breakdown
+
+## What to do when inputs are missing
+
+If the sprint plan is missing, you cannot proceed. Ask for it.
+
+If historical context is missing, score based on the items themselves and explicitly note that historical patterns weren't used in the scoring.
+
+If sprint goal is missing, score the items but note that you couldn't assess whether the plan delivers the goal.
+
+## A note on what risk scoring is NOT
+
+This subagent flags risk based on patterns. It does not predict what will slip. The output is a discussion starter for the sprint planning meeting, not a forecast. Frame the output that way in the response.
@@ -0,0 +1,95 @@
+# Smoke Test — PM Sprint Agent
+
+A quick manual test to verify your installation is working correctly. Run this after first-time setup.
+
+## What this tests
+
+- Connector configuration is valid
+- Credentials are correctly set
+- Skills are accessible from the main library
+- Subagents are correctly defined
+- Orchestration script runs without errors
+
+## How to run
+
+### Step 1: Verify connector setup
+
+```bash
+cd templates/pm-sprint-agent
+
+# Should show one of these files (or both):
+ls connectors/linear.json connectors/jira.json 2>/dev/null
+
+# If neither exists, you haven't configured a connector yet
+# See connectors/README.md
+```
+
+### Step 2: Verify credentials
+
+```bash
+# For Linear:
+echo "LINEAR_API_KEY length: ${#LINEAR_API_KEY}"
+# Should print a non-zero number (typically 40+ characters)
+
+# For Jira:
+echo "JIRA_EMAIL: $JIRA_EMAIL"
+echo "JIRA_API_TOKEN length: ${#JIRA_API_TOKEN}"
+# Both should be set
+```
+
+### Step 3: Run the dry-run
+
+```bash
+bash orchestrate.sh \
+  --sprint-goal "Smoke test" \
+  --sprint-number 999 \
+  --dry-run
+```
+
+**Expected output:**
+- Configuration banner showing all parameters
+- "✓ Dry-run complete. Configuration is valid."
+- Exit code 0
+
+If you see errors, check:
+- Required arguments are provided (`--sprint-goal` and `--sprint-number`)
+- Connector file exists in `connectors/`
+- Credentials environment variables are set
+
+### Step 4: Run a real sprint plan against a test workspace
+
+If you have access to a test/dev Linear or Jira workspace, run a real plan:
+
+```bash
+bash orchestrate.sh \
+  --sprint-goal "Test sprint plan from PM Sprint Agent" \
+  --sprint-number 999 \
+  --team-size 2 \
+  --duration-weeks 1
+```
+
+**Expected output:**
+- Six steps complete with ✓ indicators
+- Output file created at `output/sprint-999-plan.md`
+- (If post-to-Slack is enabled) Slack summary posted
+
+## What to do if a step fails
+
+| Failure | Likely cause | Fix |
+|---|---|---|
+| "No connector configured" | Missing `connectors/linear.json` or `connectors/jira.json` | Copy the `.example.json`, fill in your values |
+| "API key not set" | Environment variable not exported | Add `export LINEAR_API_KEY=...` to your shell config |
+| "Skills not found" | Main library not installed | Run `/plugin marketplace add mohitagw15856/pm-claude-skills` in Claude Code |
+| "Subagent not found" | Path issue in template structure | Verify you cloned the full repo, not just the agent folder |
+| "Output directory not writable" | Permissions issue | Run `mkdir -p output && chmod u+w output` |
+
+## Reporting issues
+
+If the smoke test fails and you can't resolve it from the table above, [open an issue](https://github.com/mohitagw15856/pm-claude-skills/issues) with:
+
+- The exact command you ran
+- The full error output
+- Which connector you're using (Linear or Jira)
+- Your operating system
+
+Don't include credentials or API keys in the issue.
				`@@ -0,0 +1 @@`
				`../../../../skills/sprint-planning/SKILL.md`