mohitagw15856
036511ab3e
Broadens both reach (more tools) and content types (an MCP server), continuing the multi-platform story. Windsurf + Aider: - build-exports.mjs gains two platforms: exports/windsurf/*.md (workspace rules, trigger: model_decision) and exports/aider/*.md (conventions for `aider --read`). Now 5 platforms (ChatGPT, Gemini, Cursor, Windsurf, Aider). - install.sh + bin/cli.mjs install both (windsurf -> .windsurf/rules, aider -> .aider/skills with a --read hint); generated README index is excluded from copies. - One-line windsurf-install.sh / aider-install.sh wrappers for parity. MCP server (new content type): - mcp/server.mjs — zero-dependency stdio MCP server exposing list_skills, search_skills, get_skill. Published as a second bin (pm-claude-skills-mcp). Logs to stderr; reads bundled skills/ at startup. mcp/README.md documents client config. Also: README hero "See it in action" demo placement (ready to swap in a GIF; recording guide in web/docs-assets/README.md), Works-With table + exports + install docs updated, CHANGELOG Unreleased. package.json files/bin updated. Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px Co-authored-by: Claude <noreply@anthropic.com>
2.5 KiB
2.5 KiB
Sprint Brief Skill
Produce a clear, scannable sprint brief that every team member — engineer, designer, PM — can read in under three minutes and understand exactly what we're doing and why.
Required Inputs
Ask the user for these if not provided:
- Sprint name and number
- Sprint goal (1-2 sentences — flag if too vague)
- Ticket list with owners (or a description of the work)
- Known dependencies or blockers
- Carry-over items from previous sprint (if any)
Process
- Read sprint goal and check it's specific and measurable — flag if it's too vague
- Group tickets by theme or feature area
- Identify the critical path — which tickets must complete for the sprint goal to be met?
- Flag risks: tickets with unclear acceptance criteria, missing designs, unresolved dependencies
- Note carry-over items and whether they affect this sprint's goal
- Validate — Confirm the sprint goal is achievable given the ticket scope and capacity. If the critical path items alone would fill the sprint, flag it as overloaded.
Output Structure
Sprint [Number] Brief — [Dates]
Sprint Goal: [1-2 sentences — specific and measurable] Why This Sprint Matters: [Connect to quarterly OKR in 2-3 sentences]
What We're Building:
- [Theme 1]: [tickets and owners]
- [Theme 2]: [tickets and owners]
Critical Path: [The 2-3 tickets everything else depends on]
Risks to Flag:
- [Risk 1 + mitigation]
- [Risk 2 + mitigation]
Carry-over from Last Sprint: [List + impact on current goal]
Definition of Done: [Specific, agreed criteria for sprint success]
Quality Checks
- Sprint goal is specific enough to score pass/fail at the end of the sprint
- Critical path items are named — not just "the important ones"
- Every risk has a mitigation or owner (not just "this is a risk")
- Carry-over items are connected to their impact on this sprint's goal
- Definition of Done is agreed criteria, not a task list
Anti-Patterns
- Do not write a sprint goal as a task list — the goal must be a single outcome-focused statement that can be scored pass/fail
- Do not leave the critical path unnamed — "the important tickets" is not a critical path
- Do not list risks without a mitigation or owner — a risk without a response is just a worry list
- Do not ignore carry-over items' impact on this sprint's capacity and goal
- Do not write a Definition of Done that mixes task completion with outcome criteria — they must be observable and agreed before the sprint starts