Merge pull request #12 from mohitagw15856/claude/add-engineering-skills-IfBhz

Add 21 engineering skills — complete the 500-star milestone
2026-05-20 08:32:18 +01:00 · 2026-05-20 07:28:51 +00:00 · 2026-05-17 15:45:45 +05:30 · 2026-05-17 11:14:40 +01:00
45 changed files with 14585 additions and 119 deletions
@@ -1,8 +1,8 @@
 {
  "$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
  "name": "pm-claude-skills",
-  "version": "10.0.0",
-  "description": "114 Claude Skills + 4 agent templates across 23 plugin bundles covering 16 professions — product management, engineering, customer success, legal, finance, HR, sales, design, Figma, marketing, and more. Building blocks for the Anthropic agent template architecture.",
+  "version": "11.0.0",
+  "description": "PM stands for Professional, not just Product Management. 135 Claude Skills + 4 agent templates across 23 bundles covering 16 professions — engineering, customer success, legal, finance, HR, sales, design, Figma, marketing, and more. Built by a PM, used by everyone. Building blocks for the Anthropic agent template architecture.",
  "owner": {
    "name": "Mohit Aggarwal",
    "email": "mohit15856@gmail.com"
@@ -82,8 +82,8 @@
    },
    {
      "name": "pm-engineering",
-      "description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record, Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer, CI/CD Playbook, SLO & Error Budget, Developer Onboarding Doc, On-Call Runbook. 14 structured skills for engineering teams, SREs, and technical PMs.",
-      "version": "3.0.0",
+      "description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record, Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer, CI/CD Playbook, SLO & Error Budget, Developer Onboarding Doc, On-Call Runbook, Security Threat Model, Performance Budget, Database Schema Design, Database Migration Plan, Technical Debt Register, RFC Writer, Capacity Planning, Load Testing Plan, Disaster Recovery Plan, Feature Flag Guide, Dependency Audit, Service Catalog Entry, Monitoring Setup Guide, Local Dev Setup, API Versioning Strategy, Infra-as-Code Review, Engineering Weekly Report, Tech Radar, Sprint Velocity Analysis, Microservices Decomposition, Engineering Hiring Rubric. 35 structured skills for engineering teams, SREs, and technical PMs.",
+      "version": "4.0.0",
      "category": "productivity",
      "source": "./plugins/pm-engineering",
      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -1,17 +1,18 @@
-# 🧠 Claude Skills Library — 114 Skills for Every Profession
+# 🧠 PM Claude Skills — 135 Skills for Every Profession

 [![Stars](https://img.shields.io/github/stars/mohitagw15856/pm-claude-skills?style=social)](https://github.com/mohitagw15856/pm-claude-skills/stargazers)
-[![Skills](https://img.shields.io/badge/skills-114-blue)](https://github.com/mohitagw15856/pm-claude-skills)
-[![Version](https://img.shields.io/badge/version-10.0.0-brightgreen)](https://github.com/mohitagw15856/pm-claude-skills/releases)
+[![Skills](https://img.shields.io/badge/skills-135-blue)](https://github.com/mohitagw15856/pm-claude-skills)
+[![Version](https://img.shields.io/badge/version-11.0.0-brightgreen)](https://github.com/mohitagw15856/pm-claude-skills/releases)
 [![Install](https://img.shields.io/badge/Install%20in%20Claude%20Code-2%20minutes-orange)](https://github.com/mohitagw15856/pm-claude-skills#-quick-install-2-minutes)
 [![License](https://img.shields.io/badge/license-MIT-lightgrey)](LICENSE)
 [![Sponsor](https://img.shields.io/badge/sponsor-❤️-ff69b4)](https://github.com/sponsors/mohitagw15856)

-> **114 Claude Skills + 4 agent templates across 16 professions. Save 8-10 hours per week.**
+> **PM stands for Professional, not just Product Management.**
+> 135 Claude Skills + 4 agent templates across 16 professions. Built by a PM, used by everyone.

-A community-built library of Claude Skills covering product management, engineering, customer success, marketing, data, design, Figma, leadership, legal, finance, HR, sales, operations, research, education, and more. Each skill is a structured SKILL.md file that teaches Claude how to produce professional-grade outputs for your specific workflows.
+A community-built library of Claude Skills for professionals across every field — product management, engineering, customer success, marketing, design, legal, finance, HR, sales, operations, research, and more. Each skill is a structured SKILL.md file that teaches Claude how to produce professional-grade outputs for your specific workflows.

-**🆕 Latest release (v10.0.0):** The library now includes 114 skills + 4 working agent templates. Two star milestones unlocked at once — 250 stars brought 4 Customer Success skills, 500 stars brought 4 more Engineering skills.
+**🆕 Latest release (v11.0.0):** The full 500-star milestone is now complete — 21 remaining engineering skills shipped. pm-engineering is now the largest bundle in the library with 35 skills. 135 skills across 16 professions.
 ---

 ## 🚀 Quick Install (2 minutes)
@@ -26,7 +27,8 @@ claude plugin install pm-essentials@pm-claude-skills     # Core PM + Word tracke

 claude plugin install pm-delivery@pm-claude-skills       # Delivery + PowerPoint auditor

-claude plugin install pm-engineering@pm-claude-skills    # Engineering (14 skills) 🆕
+claude plugin install pm-engineering@pm-claude-skills    # Engineering (35 skills) 🆕
+
 claude plugin install pm-cs@pm-claude-skills             # Customer Success 🆕

 claude plugin install pm-data@pm-claude-skills           # Data + chart data extractor
@@ -230,7 +232,7 @@ This repo was built alongside a published article series. Read the full story:

 ---

-## 🗂️ All 106 Skills
+## 🗂️ All 135 Skills

 ### 🛠️ Product Management (Skills 1–34)
 **Bundles:** `pm-essentials` · `pm-discovery` · `pm-planning` · `pm-delivery` · `pm-analytics` · `pm-strategy` · `pm-advanced` · `pm-rituals`
@@ -265,7 +267,7 @@ This repo was built alongside a published article series. Read the full story:

 ---

-### 👩‍💻 Engineering & Tech (Skills 41–54)
+### 👩‍💻 Engineering & Tech (Skills 41–75)
 **Bundle:** `pm-engineering`

 | # | Skill | Folder | What It Does |
@@ -280,14 +282,35 @@ This repo was built alongside a published article series. Read the full story:
 | 48 | **Changelog Generator** | `skills/changelog-generator/` | Convert git commits into a polished, user-facing changelog following Keep a Changelog format |
 | 49 | **Test Strategy Doc** | `skills/test-strategy-doc/` | Write a complete test strategy with risk assessment, test types, coverage targets, and P0/P1 test cases |
 | 50 | **Runbook Writer** | `skills/runbook-writer/` | Write operational runbooks for deployments, incidents, and maintenance with exact commands and rollback steps |
-| 51 | **CI/CD Playbook** 🆕 | `skills/cicd-playbook/` | Complete pipeline playbook covering every stage, rollback procedures, secrets management, and on-call responsibilities |
-| 52 | **SLO & Error Budget** 🆕 | `skills/slo-error-budget/` | SLI definitions, SLO targets, error budget calculation, burn rate alerts, and error budget policy |
-| 53 | **Developer Onboarding Doc** 🆕 | `skills/developer-onboarding-doc/` | Everything a new engineer needs in their first week — architecture, local setup, testing, deployment, and key contacts |
-| 54 | **On-Call Runbook** 🆕 | `skills/oncall-runbook/` | Per-alert response procedures, escalation matrix, diagnostic cheat sheet, and handoff template |
+| 51 | **CI/CD Playbook** | `skills/cicd-playbook/` | Complete pipeline playbook covering every stage, rollback procedures, secrets management, and on-call responsibilities |
+| 52 | **SLO & Error Budget** | `skills/slo-error-budget/` | SLI definitions, SLO targets, error budget calculation, burn rate alerts, and error budget policy |
+| 53 | **Developer Onboarding Doc** | `skills/developer-onboarding-doc/` | Everything a new engineer needs in their first week — architecture, local setup, testing, deployment, and key contacts |
+| 54 | **On-Call Runbook** | `skills/oncall-runbook/` | Per-alert response procedures, escalation matrix, diagnostic cheat sheet, and handoff template |
+| 55 | **Security Threat Model** 🆕 | `skills/security-threat-model/` | STRIDE-based threat model with asset register, trust boundaries, per-component threat enumeration, risk scores, and mitigations |
+| 56 | **Performance Budget** 🆕 | `skills/performance-budget/` | Performance budgets for Core Web Vitals and backend latency SLOs with CI enforcement and breach response policy |
+| 57 | **Database Schema Design** 🆕 | `skills/database-schema-design/` | Database schema documentation with ER diagram, DDL definitions, index strategy, and access pattern analysis |
+| 58 | **Database Migration Plan** 🆕 | `skills/database-migration-plan/` | Safe zero-downtime migration plan using expand-contract pattern with per-step rollback and data validation queries |
+| 59 | **Technical Debt Register** 🆕 | `skills/technical-debt-register/` | Debt inventory with business impact scoring, effort estimates, priority matrix, and quarterly resolution roadmap |
+| 60 | **RFC Writer** 🆕 | `skills/rfc-writer/` | Engineering Request for Comments covering problem, proposed solution, alternatives-with-rejection-reasons, and rollout plan |
+| 61 | **Capacity Planning** 🆕 | `skills/capacity-planning/` | Traffic forecasts, resource requirements per tier, scaling strategy, cost projections, and infrastructure action roadmap |
+| 62 | **Load Testing Plan** 🆕 | `skills/load-testing-plan/` | Load test plan with scenario definitions (baseline/stress/spike/soak), k6/Locust skeleton, thresholds, and CI gates |
+| 63 | **Disaster Recovery Plan** 🆕 | `skills/disaster-recovery-plan/` | DR plan with RPO/RTO targets, per-scenario runbooks, backup procedures, game day testing, and communication templates |
+| 64 | **Feature Flag Guide** 🆕 | `skills/feature-flag-guide/` | Feature flag lifecycle playbook — taxonomy, rollout strategy, monitoring requirements, cleanup policy, and governance |
+| 65 | **Dependency Audit** 🆕 | `skills/dependency-audit/` | Dependency audit for CVE vulnerabilities, license compliance, outdated packages, and 30-day remediation plan |
+| 66 | **Service Catalog Entry** 🆕 | `skills/service-catalog-entry/` | Microservice catalog entry with ownership, SLAs, API contract, data classification, and operational runbook links |
+| 67 | **Monitoring Setup Guide** 🆕 | `skills/monitoring-setup-guide/` | Four golden signals applied to a service, alert rules spec, structured log schema, tracing setup, and dashboard layout |
+| 68 | **Local Dev Setup** 🆕 | `skills/local-dev-setup/` | Local development setup guide — prerequisites, env vars, dependencies, test commands, and 5 common failure fixes |
+| 69 | **API Versioning Strategy** 🆕 | `skills/api-versioning-strategy/` | API versioning scheme, lifecycle policy, breaking change classification table, deprecation process, and migration guide template |
+| 70 | **Infra-as-Code Review** 🆕 | `skills/infra-as-code-review/` | IaC review for Terraform/CloudFormation/Pulumi — security, naming, state, cost, and drift risk with severity-classified findings |
+| 71 | **Engineering Weekly Report** 🆕 | `skills/engineering-weekly-report/` | Weekly engineering status in a consistent format — shipped/in-progress/blocked, metrics, decisions, risks, and next week |
+| 72 | **Tech Radar** 🆕 | `skills/tech-radar/` | ThoughtWorks-format technology radar with Adopt/Trial/Assess/Hold quadrants, per-blip rationale, and maintenance process |
+| 73 | **Sprint Velocity Analysis** 🆕 | `skills/sprint-velocity-analysis/` | Velocity trend analysis, completion rate patterns, blocker frequency, improvement recommendations, and capacity forecast |
+| 74 | **Microservices Decomposition** 🆕 | `skills/microservices-decomposition/` | Domain-driven service boundary design with bounded context map, communication patterns, data ownership, and strangler fig migration plan |
+| 75 | **Engineering Hiring Rubric** 🆕 | `skills/engineering-hiring-rubric/` | Technical interview rubric with level expectations, coding scorecard, system design guide, behavioural question bank, and debrief template |

 ---

-### 🤝 Customer Success (Skills 55–58)
+### 🤝 Customer Success (Skills 76–79)
 **Bundle:** `pm-cs`

 > 250 ⭐ milestone unlocked. Install:
@@ -297,183 +320,183 @@ claude plugin install pm-cs@pm-claude-skills

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 55 | **Customer Health Scorecard** 🆕 | `skills/cs-health-scorecard/` | Weighted health score across adoption, engagement, outcomes, support, and commercial — RAG status and renewal forecast |
-| 56 | **QBR Deck** 🆕 | `skills/qbr-deck/` | Slide-by-slide quarterly business review with talking points, value narrative, and mutual commitments |
-| 57 | **Escalation Brief** 🆕 | `skills/cs-escalation-brief/` | Structured brief for at-risk accounts — root cause, business impact, resolution plan, and decision required |
-| 58 | **Churn Analysis** 🆕 | `skills/churn-analysis/` | Churn breakdown by category and segment, early warning signals, and prioritised interventions |
+| 76 | **Customer Health Scorecard** | `skills/cs-health-scorecard/` | Weighted health score across adoption, engagement, outcomes, support, and commercial — RAG status and renewal forecast |
+| 77 | **QBR Deck** | `skills/qbr-deck/` | Slide-by-slide quarterly business review with talking points, value narrative, and mutual commitments |
+| 78 | **Escalation Brief** | `skills/cs-escalation-brief/` | Structured brief for at-risk accounts — root cause, business impact, resolution plan, and decision required |
+| 79 | **Churn Analysis** | `skills/churn-analysis/` | Churn breakdown by category and segment, early warning signals, and prioritised interventions |

 ---

-### 📊 Data & Analytics (Skills 59–62)
+### 📊 Data & Analytics (Skills 80–83)
 **Bundle:** `pm-data`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 59 | **Metrics Framework** | `skills/metrics-framework/` | North Star + metric tree, dashboard tiers, counter-metrics |
-| 60 | **SQL Query Explainer** | `skills/sql-query-explainer/` | Explain, optimise, write, and document SQL in plain English |
-| 61 | **Dashboard Brief** | `skills/dashboard-brief/` | Complete dashboard spec: KPIs, charts, filters, layout, data requirements |
-| 62 | **Chart Data Extractor** | `skills/chart-data-extractor/` | Extract pixel-level data from chart images into structured data tables |
+| 80 | **Metrics Framework** | `skills/metrics-framework/` | North Star + metric tree, dashboard tiers, counter-metrics |
+| 81 | **SQL Query Explainer** | `skills/sql-query-explainer/` | Explain, optimise, write, and document SQL in plain English |
+| 82 | **Dashboard Brief** | `skills/dashboard-brief/` | Complete dashboard spec: KPIs, charts, filters, layout, data requirements |
+| 83 | **Chart Data Extractor** | `skills/chart-data-extractor/` | Extract pixel-level data from chart images into structured data tables |

 ---

-### 🧑‍💼 Leadership & People (Skills 63–65)
+### 🧑‍💼 Leadership & People (Skills 84–86)
 **Bundle:** `pm-people`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 63 | **Performance Review** | `skills/performance-review/` | Structured reviews from bullet-point notes — self, manager, peer, and upward |
-| 64 | **Hiring Rubric** | `skills/hiring-rubric/` | Interview scorecards with competencies, behavioural questions, and panel guide |
-| 65 | **Team Offsite Planner** | `skills/team-offsite-planner/` | Full offsite agenda, session facilitation notes, and logistics checklist |
+| 84 | **Performance Review** | `skills/performance-review/` | Structured reviews from bullet-point notes — self, manager, peer, and upward |
+| 85 | **Hiring Rubric** | `skills/hiring-rubric/` | Interview scorecards with competencies, behavioural questions, and panel guide |
+| 86 | **Team Offsite Planner** | `skills/team-offsite-planner/` | Full offsite agenda, session facilitation notes, and logistics checklist |

 ---

-### 🎨 Design & UX (Skills 66–68)
+### 🎨 Design & UX (Skills 87–89)
 **Bundle:** `pm-design`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 66 | **UX Research Plan** | `skills/ux-research-plan/` | Research plans with screener, discussion guide, and synthesis framework |
-| 67 | **Design Critique** | `skills/design-critique/` | Structured feedback using JTBD, Gestalt principles, and Nielsen's heuristics |
-| 68 | **Accessibility Audit** | `skills/accessibility-audit/` | WCAG 2.2 audit with prioritised remediation and quick wins |
+| 87 | **UX Research Plan** | `skills/ux-research-plan/` | Research plans with screener, discussion guide, and synthesis framework |
+| 88 | **Design Critique** | `skills/design-critique/` | Structured feedback using JTBD, Gestalt principles, and Nielsen's heuristics |
+| 89 | **Accessibility Audit** | `skills/accessibility-audit/` | WCAG 2.2 audit with prioritised remediation and quick wins |

 ---

-### 🏢 Business & Strategy (Skills 69–71)
+### 🏢 Business & Strategy (Skills 90–92)
 **Bundle:** `pm-business`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 69 | **Investor Update** | `skills/investor-update/` | Monthly/quarterly investor updates: metrics, highlights, challenges, and asks |
-| 70 | **Board Deck Narrative** | `skills/board-deck-narrative/` | Slide-by-slide board presentation structure with narrative beats and talking points |
-| 71 | **Job Application** | `skills/job-application/` | Tailored CV summary, ATS keyword optimisation, and cover letter for any JD |
+| 90 | **Investor Update** | `skills/investor-update/` | Monthly/quarterly investor updates: metrics, highlights, challenges, and asks |
+| 91 | **Board Deck Narrative** | `skills/board-deck-narrative/` | Slide-by-slide board presentation structure with narrative beats and talking points |
+| 92 | **Job Application** | `skills/job-application/` | Tailored CV summary, ATS keyword optimisation, and cover letter for any JD |

 ---

-### ⚖️ Legal (Skills 72–75)
+### ⚖️ Legal (Skills 93–96)
 **Bundle:** `pm-legal`

 > ⚠️ All legal skills include a disclaimer. Not a substitute for qualified legal advice.

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 72 | **Contract Review** | `skills/contract-review/` | Structured review with key terms, flagged clauses, risk rating, and plain English summary |
-| 73 | **NDA Analyser** | `skills/nda-analyser/` | Clause-by-clause NDA analysis with risk flags and negotiation checklist |
-| 74 | **Legal Brief** | `skills/legal-brief/` | Legal memos and argument outlines in IRAC format (Issue, Rule, Application, Conclusion) |
-| 75 | **Compliance Checklist** | `skills/compliance-checklist/` | GDPR, SOC 2, ISO 27001, FCA, HIPAA compliance checklists with prioritised gap analysis |
+| 93 | **Contract Review** | `skills/contract-review/` | Structured review with key terms, flagged clauses, risk rating, and plain English summary |
+| 94 | **NDA Analyser** | `skills/nda-analyser/` | Clause-by-clause NDA analysis with risk flags and negotiation checklist |
+| 95 | **Legal Brief** | `skills/legal-brief/` | Legal memos and argument outlines in IRAC format (Issue, Rule, Application, Conclusion) |
+| 96 | **Compliance Checklist** | `skills/compliance-checklist/` | GDPR, SOC 2, ISO 27001, FCA, HIPAA compliance checklists with prioritised gap analysis |

 ---

-### 💰 Finance (Skills 76–80)
+### 💰 Finance (Skills 97–101)
 **Bundle:** `pm-finance`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 76 | **Financial Model Narrative** | `skills/financial-model-narrative/` | Turns P&L and model outputs into board-ready written narratives |
-| 77 | **Budget Variance Analysis** | `skills/budget-variance-analysis/` | Variance table with root cause commentary and management summary |
-| 78 | **Investor Pitch Deck** | `skills/investor-pitch-deck/` | Slide-by-slide pitch deck structure with what each slide must prove |
-| 79 | **Financial Due Diligence** | `skills/financial-due-diligence/` | DD document request list, analytical questions, and red flags checklist |
-| 80 | **Tax Planning Checklist** | `skills/tax-planning-checklist/` | Year-end tax planning framework across income, pension, CGT, business reliefs, and ISAs |
+| 97 | **Financial Model Narrative** | `skills/financial-model-narrative/` | Turns P&L and model outputs into board-ready written narratives |
+| 98 | **Budget Variance Analysis** | `skills/budget-variance-analysis/` | Variance table with root cause commentary and management summary |
+| 99 | **Investor Pitch Deck** | `skills/investor-pitch-deck/` | Slide-by-slide pitch deck structure with what each slide must prove |
+| 100 | **Financial Due Diligence** | `skills/financial-due-diligence/` | DD document request list, analytical questions, and red flags checklist |
+| 101 | **Tax Planning Checklist** | `skills/tax-planning-checklist/` | Year-end tax planning framework across income, pension, CGT, business reliefs, and ISAs |

 ---

-### 👥 HR (Skills 81–85)
+### 👥 HR (Skills 102–106)
 **Bundle:** `pm-hr`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 81 | **Job Description Writer** | `skills/job-description-writer/` | Inclusive, structured JDs with built-in language review and salary range nudge |
-| 82 | **Onboarding Plan** | `skills/onboarding-plan/` | 30/60/90-day plans with week-by-week structure, milestones, and manager checklist |
-| 83 | **Employee Engagement Survey** | `skills/employee-engagement-survey/` | Survey design + results analysis mode with eNPS and action planning template |
-| 84 | **Redundancy Consultation** | `skills/redundancy-consultation/` | Process timeline, at-risk letter, consultation script, and confirmation letter — UK law |
-| 85 | **Change Management Plan** | `skills/change-management-plan/` | Full change plan covering stakeholder analysis, communication strategy, training, and adoption metrics |
+| 102 | **Job Description Writer** | `skills/job-description-writer/` | Inclusive, structured JDs with built-in language review and salary range nudge |
+| 103 | **Onboarding Plan** | `skills/onboarding-plan/` | 30/60/90-day plans with week-by-week structure, milestones, and manager checklist |
+| 104 | **Employee Engagement Survey** | `skills/employee-engagement-survey/` | Survey design + results analysis mode with eNPS and action planning template |
+| 105 | **Redundancy Consultation** | `skills/redundancy-consultation/` | Process timeline, at-risk letter, consultation script, and confirmation letter — UK law |
+| 106 | **Change Management Plan** | `skills/change-management-plan/` | Full change plan covering stakeholder analysis, communication strategy, training, and adoption metrics |

 ---

-### 🤝 Sales (Skills 86–90)
+### 🤝 Sales (Skills 107–111)
 **Bundle:** `pm-sales`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 86 | **Sales Battlecard** | `skills/sales-battlecard/` | One-page competitive battlecard with objection responses and landmine questions |
-| 87 | **Discovery Call Prep** | `skills/discovery-call-prep/` | Call brief with research summary, hypothesis, structured questions, and success criteria |
-| 88 | **Proposal Writer** | `skills/proposal-writer/` | Commercial proposals structured around the prospect's problem, not the product |
-| 89 | **Account Plan** | `skills/account-plan/` | Strategic account plan with relationship map, whitespace analysis, risks, and 90-day actions |
-| 90 | **Sales Forecasting Model** | `skills/sales-forecasting-model/` | Pipeline-based forecast with stage model, scenario analysis, assumption log, and activity sanity check |
+| 107 | **Sales Battlecard** | `skills/sales-battlecard/` | One-page competitive battlecard with objection responses and landmine questions |
+| 108 | **Discovery Call Prep** | `skills/discovery-call-prep/` | Call brief with research summary, hypothesis, structured questions, and success criteria |
+| 109 | **Proposal Writer** | `skills/proposal-writer/` | Commercial proposals structured around the prospect's problem, not the product |
+| 110 | **Account Plan** | `skills/account-plan/` | Strategic account plan with relationship map, whitespace analysis, risks, and 90-day actions |
+| 111 | **Sales Forecasting Model** | `skills/sales-forecasting-model/` | Pipeline-based forecast with stage model, scenario analysis, assumption log, and activity sanity check |

 ---

-### ⚙️ Operations (Skills 91–95)
+### ⚙️ Operations (Skills 112–116)
 **Bundle:** `pm-operations`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 91 | **Process Documentation** | `skills/process-documentation/` | Clear process docs with steps, roles, edge cases — followable by a new starter |
-| 92 | **SOP Writer** | `skills/sop-writer/` | Formal, audit-ready SOPs with version control, quality checks, and non-conformance process |
-| 93 | **Vendor Evaluation** | `skills/vendor-evaluation/` | Weighted vendor scorecard, RFP questions, reference check template, and recommendation |
-| 94 | **Project Status Report** | `skills/project-status-report/` | RAG status reports with milestone progress, issues, risks, and decisions required |
-| 95 | **Workshop Facilitation Guide** | `skills/workshop-facilitation-guide/` | Complete facilitation guides with activity instructions, decision protocols, and facilitator moves |
+| 112 | **Process Documentation** | `skills/process-documentation/` | Clear process docs with steps, roles, edge cases — followable by a new starter |
+| 113 | **SOP Writer** | `skills/sop-writer/` | Formal, audit-ready SOPs with version control, quality checks, and non-conformance process |
+| 114 | **Vendor Evaluation** | `skills/vendor-evaluation/` | Weighted vendor scorecard, RFP questions, reference check template, and recommendation |
+| 115 | **Project Status Report** | `skills/project-status-report/` | RAG status reports with milestone progress, issues, risks, and decisions required |
+| 116 | **Workshop Facilitation Guide** | `skills/workshop-facilitation-guide/` | Complete facilitation guides with activity instructions, decision protocols, and facilitator moves |

 ---

-### 🏥 Research & Healthcare (Skills 96–99)
+### 🏥 Research & Healthcare (Skills 117–120)
 **Bundle:** `pm-research`

 > ⚠️ Healthcare skills are for documentation and educational purposes only. All clinical content must be reviewed by a qualified professional.

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 96 | **Clinical Case Summary** | `skills/clinical-case-summary/` | SBAR handovers, SOAP notes, and case reports for educational and documentation use |
-| 97 | **Research Protocol** | `skills/research-protocol/` | Complete study protocols with objectives, methodology, ethics, and analysis plan |
-| 98 | **Patient Communication** | `skills/patient-communication/` | Plain English patient letters, leaflets, and results communications at Grade 6 reading level |
-| 99 | **Literature Review** | `skills/literature-review/` | Thematically organised literature reviews with synthesis, critical analysis, and gap identification |
+| 117 | **Clinical Case Summary** | `skills/clinical-case-summary/` | SBAR handovers, SOAP notes, and case reports for educational and documentation use |
+| 118 | **Research Protocol** | `skills/research-protocol/` | Complete study protocols with objectives, methodology, ethics, and analysis plan |
+| 119 | **Patient Communication** | `skills/patient-communication/` | Plain English patient letters, leaflets, and results communications at Grade 6 reading level |
+| 120 | **Literature Review** | `skills/literature-review/` | Thematically organised literature reviews with synthesis, critical analysis, and gap identification |

 ---

-### 🌐 Cross-Profession (Skills 100–103)
+### 🌐 Cross-Profession (Skills 121–124)
 **Bundle:** `pm-cross`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 100 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
-| 101 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
-| 102 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
-| 103 | **Teaching Lesson Plan** | `skills/teaching-lesson-plan/` | Complete lesson plans for any subject, audience, or setting — with objectives, activities, and formative assessment |
+| 121 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
+| 122 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
+| 123 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
+| 124 | **Teaching Lesson Plan** | `skills/teaching-lesson-plan/` | Complete lesson plans for any subject, audience, or setting — with objectives, activities, and formative assessment |

 ---

-### 🖼️ Figma (Skills 104–113)
+### 🖼️ Figma (Skills 125–134)
 **Bundle:** `pm-figma`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 104 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
-| 105 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
-| 106 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
-| 107 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
-| 108 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
-| 109 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
-| 110 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
-| 111 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
-| 112 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
-| 113 | **Figma Design Critique (PM)** | `skills/figma-design-critique-pm/` | PM-perspective design critique focused on product outcomes, not aesthetics |
+| 125 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
+| 126 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
+| 127 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
+| 128 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
+| 129 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
+| 130 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
+| 131 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
+| 132 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
+| 133 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
+| 134 | **Figma Design Critique (PM)** | `skills/figma-design-critique-pm/` | PM-perspective design critique focused on product outcomes, not aesthetics |

 claude plugin install pm-figma@pm-claude-skills


 ---

-### 📅 PM Rituals (Skill 114)
+### 📅 PM Rituals (Skill 135)
 **Bundle:** `pm-rituals`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 114 | **PM Weekly Review** | `skills/pm-weekly-review/` | Weekly PM review and planning ritual — metrics, shipping progress, blockers, and next week's priorities |
+| 135 | **PM Weekly Review** | `skills/pm-weekly-review/` | Weekly PM review and planning ritual — metrics, shipping progress, blockers, and next week's priorities |

 ---

 ## ❤️ Sponsor This Work

-Building and maintaining 114 skills across 23 bundles takes real time — testing skills against new model releases, building new ones from community requests, writing the article series, and keeping documentation current.
+Building and maintaining 135 skills across 23 bundles takes real time — testing skills against new model releases, building new ones from community requests, writing the article series, and keeping documentation current.

 If these skills save you time at work, consider sponsoring:

@@ -545,29 +568,50 @@ Install the whole library or just the bundles you need:

 # Install by profession
 claude plugin install pm-essentials@pm-claude-skills
-claude plugin install pm-discovery@pm-claude-skills
-claude plugin install pm-planning@pm-claude-skills
-claude plugin install pm-delivery@pm-claude-skills
-claude plugin install pm-analytics@pm-claude-skills
-claude plugin install pm-strategy@pm-claude-skills
-claude plugin install pm-advanced@pm-claude-skills
-claude plugin install pm-rituals@pm-claude-skills
-claude plugin install pm-gtm@pm-claude-skills
-claude plugin install pm-engineering@pm-claude-skills    # 14 engineering skills 🆕
-claude plugin install pm-cs@pm-claude-skills             # Customer Success (4 skills) 🆕
-claude plugin install pm-data@pm-claude-skills
-claude plugin install pm-people@pm-claude-skills
-claude plugin install pm-design@pm-claude-skills
-claude plugin install pm-business@pm-claude-skills
-claude plugin install pm-legal@pm-claude-skills
-claude plugin install pm-finance@pm-claude-skills
-claude plugin install pm-hr@pm-claude-skills
-claude plugin install pm-sales@pm-claude-skills
-claude plugin install pm-operations@pm-claude-skills
-claude plugin install pm-research@pm-claude-skills
-claude plugin install pm-cross@pm-claude-skills
-claude plugin install pm-figma@pm-claude-skills

+claude plugin install pm-discovery@pm-claude-skills
+
+claude plugin install pm-planning@pm-claude-skills
+
+claude plugin install pm-delivery@pm-claude-skills
+
+claude plugin install pm-analytics@pm-claude-skills
+
+claude plugin install pm-strategy@pm-claude-skills
+
+claude plugin install pm-advanced@pm-claude-skills
+
+claude plugin install pm-rituals@pm-claude-skills
+
+claude plugin install pm-gtm@pm-claude-skills
+
+claude plugin install pm-engineering@pm-claude-skills    # Engineering (35 skills)
+
+claude plugin install pm-cs@pm-claude-skills             # Customer Success (4 skills) 🆕
+
+claude plugin install pm-data@pm-claude-skills
+
+claude plugin install pm-people@pm-claude-skills
+
+claude plugin install pm-design@pm-claude-skills
+
+claude plugin install pm-business@pm-claude-skills
+
+claude plugin install pm-legal@pm-claude-skills
+
+claude plugin install pm-finance@pm-claude-skills
+
+claude plugin install pm-hr@pm-claude-skills
+
+claude plugin install pm-sales@pm-claude-skills
+
+claude plugin install pm-operations@pm-claude-skills
+
+claude plugin install pm-research@pm-claude-skills
+
+claude plugin install pm-cross@pm-claude-skills
+
+claude plugin install pm-figma@pm-claude-skills

 ---

@@ -583,7 +627,7 @@ Read the full breakdown: [Part 12 — I Built the Same Skills Library for ChatGP

 ## 🛠️ Custom Skills for Your Team

-The 106 skills in this library are built for general professional workflows. But the most powerful version of Claude Skills is one built specifically for *your* team — your templates, your terminology, your processes, your quality standards.
+The 114 skills in this library are built for general professional workflows. But the most powerful version of Claude Skills is one built specifically for *your* team — your templates, your terminology, your processes, your quality standards.

 **What custom skills look like in practice:**

@@ -621,7 +665,7 @@ Stars unlock the next wave of skills. Here's the roadmap:
 |---|---|---|
 | 100 ⭐ | 10 Figma skills + quality rebuild across all 93 skills | ✅ Shipped (v6.0.0) |
 | 250 ⭐ | 10 Customer Success skills (health scorecard, QBR deck, escalation brief, churn analysis) | ✅ Unlocked — coming in next release |
-| 500 ⭐ | 25 more Engineering skills (CI/CD playbooks, SLO templates, onboarding docs, debugging patterns) | ✅ Unlocked — coming in next release |
+| 500 ⭐ | 25 Engineering skills (CI/CD playbooks, SLO templates, onboarding docs, debugging patterns, threat models, capacity planning, DR plans, and more) | ✅ Shipped — pm-engineering now 35 skills (v11.0.0) |
 | 1000 ⭐ | Full Startup Founder kit (fundraising memo, pitch critique, co-founder equity split) | 🔒 Locked |

 **[⭐ Star this repo to unlock the next milestone →](https://github.com/mohitagw15856/pm-claude-skills)**
@@ -1,13 +1,13 @@
 {
  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
  "name": "pm-engineering",
-  "version": "3.0.0",
-  "description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record, Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer, CI/CD Playbook, SLO & Error Budget, Developer Onboarding Doc, On-Call Runbook. 14 structured skills for engineering teams and technical PMs.",
+  "version": "4.0.0",
+  "description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record, Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer, CI/CD Playbook, SLO & Error Budget, Developer Onboarding Doc, On-Call Runbook, Security Threat Model, Performance Budget, Database Schema Design, Database Migration Plan, Technical Debt Register, RFC Writer, Capacity Planning, Load Testing Plan, Disaster Recovery Plan, Feature Flag Guide, Dependency Audit, Service Catalog Entry, Monitoring Setup Guide, Local Dev Setup, API Versioning Strategy, Infra-as-Code Review, Engineering Weekly Report, Tech Radar, Sprint Velocity Analysis, Microservices Decomposition, Engineering Hiring Rubric. 35 structured skills for engineering teams, SREs, and technical PMs.",
  "author": {
    "name": "Mohit Aggarwal",
    "email": "mohit15856@gmail.com"
  },
  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
  "license": "MIT",
-  "keywords": ["product-management", "engineering", "code-review", "incident-postmortem", "api-documentation", "adr", "architecture", "debugging", "pull-request", "system-design", "changelog", "test-strategy", "runbook", "devops", "cicd", "slo", "error-budget", "onboarding", "oncall", "sre", "reliability"]
+  "keywords": ["product-management", "engineering", "code-review", "incident-postmortem", "api-documentation", "adr", "architecture", "debugging", "pull-request", "system-design", "changelog", "test-strategy", "runbook", "devops", "cicd", "slo", "error-budget", "onboarding", "oncall", "sre", "reliability", "security", "threat-model", "performance", "database", "migration", "technical-debt", "rfc", "capacity-planning", "load-testing", "disaster-recovery", "feature-flags", "dependency-audit", "service-catalog", "monitoring", "observability", "tech-radar", "microservices", "hiring", "velocity"]
 }
@@ -0,0 +1,312 @@
+---
+name: api-versioning-strategy
+description: "Write an API versioning strategy document for a service or API platform. Use when asked to define versioning policy, plan API deprecation, classify breaking changes, or document version lifecycle. Produces a complete versioning strategy with breaking-change classification table, deprecation timeline, migration guide template, and client communication template."
+---
+
+# API Versioning Strategy
+
+Produce a complete API versioning strategy document that gives a service team durable, consistent rules for evolving their API without breaking consumers. This document covers the versioning scheme selection (with rationale), lifecycle policy from introduction through sunset, a precise breaking-change classification, and all the communication artifacts a team needs when deprecating a version. Engineers should be able to hand this document to a new team member or external consumer and have them understand exactly what to expect.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **API type** — REST, GraphQL, or gRPC (each has different versioning mechanics)
+- **Current versioning approach** — URL path (`/v1/`), request header, query parameter, or none; if none, document starts fresh
+- **Number of existing versions and active consumer count** — needed to size the lifecycle policy and migration scope
+- **Deprecation timeline constraints** — any hard deadlines (contract SLAs, compliance windows, annual release cycles)
+- **Consumer type** — internal teams only, external partners, public API, or mix (affects communication channel choices)
+
+If any input is missing, ask before producing the document. For GraphQL, note that the versioning approach differs substantially (schema evolution over versioning) and tailor the scheme section accordingly.
+
+## Output Format
+
+---
+
+# API Versioning Strategy: [Service Name]
+
+**Owner:** [Team Name]
+**API Type:** [REST / GraphQL / gRPC]
+**Document Version:** 1.0
+**Last Reviewed:** [Date]
+**Next Review:** [Date + 6 months]
+
+---
+
+## 1. Versioning Scheme
+
+### Selected Approach: [URL Path / Request Header / Query Parameter]
+
+| Scheme | Example | Pros | Cons | Verdict |
+|--------|---------|------|------|---------|
+| URL Path | `/v2/orders` | Visible in logs and bookmarks; trivial to route | Violates strict REST resource identity; clutters URL space | **Recommended for public-facing REST APIs** |
+| `Accept` Header | `Accept: application/vnd.[service].v2+json` | Keeps URLs clean; proper content negotiation | Harder to test in browser; less visible in logs | Recommended for internal APIs with controlled clients |
+| Query Parameter | `/orders?version=2` | Easy to retrofit without URL restructuring | Often missed in client code; cache-key complications | Acceptable only for read-heavy APIs already in production |
+| GraphQL Schema Evolution | Field deprecation + `@deprecated` directive | No versioning needed for additive changes | Requires disciplined schema design | **Recommended for GraphQL APIs** |
+
+**Rationale for [chosen scheme]:** [One paragraph explaining why this scheme fits the API type, consumer type, and operational context provided. Reference the specific inputs — e.g., "Because this API has external partners who integrate via generated clients, URL path versioning provides the most predictable routing behavior and eliminates header negotiation complexity."]
+
+### Version Format
+
+```
+[Base URL]/v{MAJOR}/{resource}
+
+Examples:
+  https://api.[company].com/v1/orders
+  https://api.[company].com/v2/orders/{id}/items
+
+Version identifier: integer only (v1, v2, v3)
+No minor versions in the URL — minor/patch changes are non-breaking and deployed continuously.
+```
+
+---
+
+## 2. Version Lifecycle Policy
+
+### Lifecycle Stages
+
+```
+  STABLE ──────────────────────────────────────────────────►
+      │
+      ├─ STABLE        Active development, full SLA, new consumers allowed
+      │
+      ├─ DEPRECATED    Announced, timeline posted, migration docs live.
+      │                New consumers blocked. Existing consumers receive warnings.
+      │
+      ├─ SUNSET        Requests return HTTP 410 Gone + migration pointer.
+      │                30-day window before routing is removed.
+      │
+      └─ RETIRED       Routing removed, docs archived, no traffic accepted.
+```
+
+| Stage | Duration | SLA Applies | New Consumers Allowed | Required Action |
+|-------|----------|-------------|----------------------|-----------------|
+| Stable | Until superseded | Yes — full | Yes | None |
+| Deprecated | [12 months / adjust per constraint] | Yes — degraded acceptable | No | Migrate before sunset date |
+| Sunset | 30-day window | Best-effort only | No | Migrate immediately |
+| Retired | Permanent | None | No | — |
+
+**Minimum Stable Period:** A version must remain Stable for at least [6 / 12] months before deprecation can be announced.
+
+**Maximum Simultaneous Versions:** No more than [2] versions in Stable or Deprecated status at any time. Releasing v3 requires committing to a sunset date for v1 in the same announcement.
+
+---
+
+## 3. Breaking vs. Non-Breaking Change Classification
+
+Apply this table before every API change. If a change is marked Breaking, it requires a new major version. When uncertain, default to Breaking.
+
+| Change Type | Specific Example | Classification | Rationale |
+|-------------|-----------------|----------------|-----------|
+| Remove a response field | Delete `order.legacy_id` from response | **Breaking** | Clients reading this field will null-pointer or fail |
+| Rename a field | `user_name` → `username` | **Breaking** | Clients referencing old name receive null |
+| Change field type | `"amount": "10.00"` → `"amount": 10.00` | **Breaking** | Type mismatch at deserialization |
+| Make optional field required | `email` required in POST body | **Breaking** | Existing callers omitting it receive 400 |
+| Remove an endpoint | `DELETE /v1/widgets/{id}` removed | **Breaking** | Existing callers receive 404 |
+| Change HTTP method | `GET /search` → `POST /search` | **Breaking** | Bookmarked or cached GET calls fail |
+| Change authentication scheme | API key → OAuth2 | **Breaking** | All clients must re-authenticate |
+| Restructure error response shape | Error JSON schema changed | **Breaking** | Error-handling code misparses responses |
+| Expand enum values (response) | New `status: "on_hold"` value returned | **Breaking** | Switch statements with no default fall through |
+| Change pagination defaults | `page_size` default 20 → 50 | **Breaking** | Response length changes unexpectedly |
+| Tighten input validation | Max length 100 → 50 | **Breaking** | Previously valid inputs now rejected |
+| Add new optional field to response | Add `order.tax_breakdown` | Non-Breaking | Clients ignore unknown fields per spec |
+| Add new optional request parameter | Add `?include_archived=true` | Non-Breaking | Ignored by existing clients |
+| Add a new endpoint | `GET /v1/orders/{id}/audit` | Non-Breaking | No existing client references it |
+| Relax input validation | Min length 10 → 5 | Non-Breaking | Existing valid inputs remain valid |
+| Performance or latency improvement | Response time reduced | Non-Breaking | — |
+| Add new enum value (request-only) | Accept new `type: "express"` | Non-Breaking | Existing values still accepted |
+
+---
+
+## 4. Deprecation Process
+
+### Step-by-Step Deprecation Checklist
+
+- [ ] **T-0 (Decision day):** Engineering lead approves deprecation. New version confirmed Stable. Sunset date set.
+- [ ] **T-0:** Update API docs — add deprecation banner to all v[N] endpoint pages.
+- [ ] **T-0:** Add `Deprecation` and `Sunset` response headers to all v[N] responses (see format below).
+- [ ] **T-0:** Block new consumer onboarding for v[N] in API gateway and developer portal.
+- [ ] **T-0:** Send initial deprecation notice to all registered consumers (see Section 5 template).
+- [ ] **T-0:** Open tracking issue in engineering backlog linking all known consumers to their migration status.
+- [ ] **T minus 30 days:** Send 30-day warning to all consumers still sending v[N] traffic.
+- [ ] **T minus 7 days:** Send final warning. If consumer traffic > 100 req/day, escalate directly to their engineering lead.
+- [ ] **Sunset date:** Switch v[N] routing to return `HTTP 410 Gone` with body pointing to migration guide.
+- [ ] **T plus 30 days:** Remove routing rules. Archive documentation. Close tracking issue.
+
+### Deprecation Response Headers
+
+```http
+HTTP/1.1 200 OK
+Deprecation: true
+Sunset: Sat, 01 Jan 2027 00:00:00 GMT
+Link: <https://docs.[company].com/api/migration/v1-to-v2>; rel="successor-version"
+```
+
+### Sunset Response Body
+
+```http
+HTTP/1.1 410 Gone
+Content-Type: application/json
+
+```
+
+---
+
+## 5. Client Communication Templates
+
+### Initial Deprecation Notice
+
+```
+Subject: [Action Required] [Service Name] API v[N] Deprecation — Sunset [Date]
+
+Hi [Team / Partner Name],
+
+We are deprecating [Service Name] API v[N], effective [Sunset Date].
+
+What this means for you:
+- v[N] continues to work normally until [Sunset Date]
+- After [Sunset Date], all v[N] requests return HTTP 410 Gone
+- v[N+1] is available today and fully stable
+
+Your current usage: approximately [X] requests/day as of [Date].
+Estimated migration effort: [Small: < 1 day | Medium: 1–3 days | Large: 3–10 days]
+
+Migration resources:
+  Migration guide:  [URL]
+  Changelog:        [URL]
+  Office hours:     [Date/Time/Link]
+  Support:          [Slack channel or email]
+
+Key dates:
+  [Date]          Deprecation announced (today)
+  [Date]          New consumer onboarding blocked for v[N]
+  [Date]          30-day warning sent to remaining consumers
+  [Sunset Date]   v[N] returns 410 Gone
+
+Reply to this message or contact us at [channel] with questions.
+
+[Your Name], [Team Name]
+```
+
+### 30-Day Warning
+
+```
+Subject: [30 Days Remaining] [Service Name] API v[N] sunsets [Date]
+
+Hi [Team / Partner Name],
+
+[Service Name] API v[N] sunsets in 30 days on [Date].
+
+Your current v[N] traffic: [X] requests/day — migration is not yet complete.
+
+If you have a technical blocker requiring an extension, contact us before
+[Date minus 14 days]. Extensions require a documented blocker and a committed
+migration completion date.
+
+Migration guide: [URL] | Support: [channel]
+```
+
+---
+
+## 6. Migration Guide Template
+
+Publish one migration guide per version transition at `docs.[company].com/api/migration/v[N]-to-v[N+1]`.
+
+```markdown
+# Migration Guide: v[N] → v[N+1]
+
+**Estimated effort:** [Small: < 1 day | Medium: 1–3 days | Large: 3–10 days]
+**Breaking changes in this guide:** [count]
+
+## Quick Start
+
+Update your base URL:
+  Before: https://api.[company].com/v[N]/
+  After:  https://api.[company].com/v[N+1]/
+
+## Breaking Changes
+
+### 1. [Field Rename: user_name → username]
+
+**Affected endpoints:** `GET /users/{id}`, `POST /users`
+
+Before (v[N]):
+{ "user_name": "alice" }
+
+After (v[N+1]):
+{ "username": "alice" }
+
+Migration: Replace all references to `user_name` with `username` in request
+builders and response parsers.
+
+### 2. [Next breaking change — repeat structure]
+
+## New Capabilities in v[N+1]
+
+| Feature | Description | Docs |
+|---------|-------------|------|
+| [Feature name] | [Brief description] | [Link] |
+
+## SDK Upgrade Reference
+
+| Language | Package | v[N+1] Version | Install Command |
+|----------|---------|----------------|-----------------|
+| Python | `[company]-sdk` | `2.0.0` | `pip install [company]-sdk==2.0.0` |
+| Node.js | `@[company]/sdk` | `2.0.0` | `npm install @[company]/sdk@2.0.0` |
+| Go | `github.com/[company]/sdk-go` | `v2.0.0` | `go get github.com/[company]/sdk-go/v2` |
+| Java | `com.[company]:sdk` | `2.0.0` | Update pom.xml / build.gradle |
+
+## Migration Validation Checklist
+
+- [ ] Base URL updated to v[N+1]
+- [ ] All renamed fields updated in request serializers
+- [ ] All renamed fields updated in response deserializers
+- [ ] Error-handling code updated for new error shape
+- [ ] Integration tests passing against v[N+1] in staging
+- [ ] Load test completed against v[N+1] — latency within acceptable range
+- [ ] Rollback plan documented if issues arise post-cutover
+```
+
+---
+
+## 7. Version-Specific Documentation
+
+- Maintain separate documentation pages for each Stable and Deprecated version.
+- Deprecated version docs carry a persistent banner: "This version is deprecated. Sunset date: [Date]. [Migrate to v[N+1]]."
+- OpenAPI specs, Protobuf definitions, or GraphQL schemas are tagged and archived per version in the repository under `/api/v[N]/`.
+- A root-level CHANGELOG.md records every breaking and non-breaking change by version — not buried in commit history.
+
+---
+
+## 8. SDK Versioning Alignment
+
+| API Version | SDK Major Version | SDK GA Date | SDK EOL Date |
+|-------------|------------------|-------------|--------------|
+| v[1] | 1.x | [Date] | [API Sunset + 90 days] |
+| v[2] | 2.x | [Date] | Active |
+
+- SDK major versions align 1:1 with API major versions.
+- SDK minor versions track non-breaking API additions.
+- SDK EOL dates trail API sunset dates by 90 days to give consumers extra runway.
+- SDKs emit a runtime deprecation warning log line when the underlying API version is Deprecated.
+
+---
+
+*Strategy authored by [Team Name] — questions to [Slack channel or email]*
+
+---
+
+## Quality Checks
+
+- [ ] Versioning scheme recommendation includes explicit rationale tied to the API type and consumer type provided — not a generic recommendation
+- [ ] Breaking-change table covers at minimum: field removal, field rename, type change, making optional field required, endpoint removal, enum expansion, and default value change
+- [ ] Deprecation timeline durations are filled in with concrete values, not left as abstract placeholders
+- [ ] All three communication artifacts are present: initial deprecation notice, 30-day warning, and migration guide template
+- [ ] Sunset response headers (`Deprecation`, `Sunset`, `Link`) use correct RFC date format and real URL structure
+- [ ] SDK versioning alignment table is present and ties SDK major versions explicitly to API major versions
+- [ ] Maximum simultaneous supported versions is stated with a concrete number
+- [ ] Breaking-change table covers at minimum: field removal, field rename, type change, making optional field required, endpoint removal, enum expansion, and default value change
+- [ ] Deprecation timeline durations are filled in with concrete values, not left as abstract placeholders
+- [ ] All three communication artifacts are present: initial deprecation notice, 30-day warning, and migration guide template
+- [ ] Sunset response headers (`Deprecation`, `Sunset`, `Link`) use correct RFC date format and real URL structure
+- [ ] SDK versioning alignment table is present and ties SDK major versions explicitly to API major versions
+- [ ] Maximum simultaneous supported versions is stated with a concrete number
@@ -0,0 +1,358 @@
+---
+name: capacity-planning
+description: "Produce a capacity planning document for a service covering traffic forecasts, resource requirements, and scaling strategy. Use when asked to plan infrastructure capacity, forecast resource needs, model traffic growth, define scaling strategy, or produce a capacity review for a service. Produces a structured capacity plan covering current baseline metrics, growth projections, resource requirements per tier, scaling strategy, cost projections, capacity triggers, and an infrastructure action roadmap."
+---
+
+# Capacity Planning Skill
+
+Produce a complete capacity planning document for a service. Capacity planning is not about predicting the future exactly — it is about understanding current headroom, modelling growth, and ensuring the team takes infrastructure action before a constraint becomes an incident.
+
+A good capacity plan answers: what is running out first, how long before it runs out, what does it cost to fix it, and who decides when to act.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name and description** — what the service does and who depends on it
+- **Current traffic and usage metrics** — requests per second (or per day), active users, data volume — whatever units are most natural for this service
+- **Current resource utilisation** — CPU %, memory %, disk usage, connection pool utilisation, DB query throughput
+- **Growth rate or projections** — historical growth rate, or known upcoming events (product launch, sales cycle, seasonal peak)
+- **Tech stack and infrastructure** — cloud provider, compute type (VMs, containers, serverless), database, caching layer, CDN
+- **Cost constraints** — current infrastructure spend, acceptable cost ceiling, or target cost per unit of traffic
+
+## Output Format
+
+---
+
+# Capacity Plan: [Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Author:** [Name] | **Last updated:** [Date]
+**Planning horizon:** [12 months — [Month Year] to [Month Year]]
+**Review cadence:** [Quarterly]
+
+---
+
+## 1. Executive Summary
+
+[3–5 sentences covering: current state, the most critical capacity constraint, the timeline before it becomes a risk, the recommended action, and the cost implication. Written for an engineering manager or VP who needs the key facts without reading the full document.]
+
+**Critical finding:** [e.g. "The database connection pool will reach 90% utilisation within 6 weeks at current growth. Without action, this will cause request queueing and latency spikes under normal traffic."]
+
+**Recommended immediate action:** [e.g. "Increase connection pool limit and add a read replica within the next 2 weeks."]
+
+**Estimated cost impact:** [e.g. "Recommended changes add ~$[X]/month to infrastructure spend."]
+
+---
+
+## 2. Current Baseline
+
+*All metrics are 30-day averages unless noted. Date captured: [Date]*
+
+### Traffic
+
+| Metric | Value | Peak (7-day) | Notes |
+|---|---|---|---|
+| Requests per second (avg) | [X req/s] | [X req/s] | [Peak time / day of week] |
+| Requests per day | [X M/day] | [X M/day] | — |
+| Active users (DAU/MAU) | [X] / [X] | — | — |
+| [Service-specific metric — e.g. jobs processed/hour] | [X] | [X] | — |
+| [Service-specific metric — e.g. GB ingested/day] | [X GB] | [X GB] | — |
+
+### Compute
+
+| Resource | Current utilisation | Instance type | Count | Notes |
+|---|---|---|---|---|
+| CPU (avg) | [X%] | [e.g. c5.2xlarge] | [X] | Peak: [X%] |
+| Memory (avg) | [X%] | — | — | Peak: [X%] |
+| Network egress | [X Mbps] | — | — | — |
+| Container / pod count | [X] | [e.g. 2 vCPU / 4 GB] | — | Auto-scaling range: [X–Y] |
+
+### Database
+
+| Resource | Current utilisation | Spec | Notes |
+|---|---|---|---|
+| CPU | [X%] | [e.g. db.r5.2xlarge] | Peak: [X%] |
+| Memory | [X%] | [X GB RAM] | — |
+| Storage used | [X GB] of [Y GB] ([Z%]) | [X GB provisioned] | Growth: [~X GB/month] |
+| IOPS (avg) | [X] of [Y provisioned] | [Y IOPS] | Peak: [X IOPS] |
+| Connection pool | [X] of [Y max] ([Z%]) | Max connections: [Y] | [ORM pool size: X] |
+| Query P99 latency | [X ms] | — | [Slowest query: X] |
+| Read/write ratio | [X%] reads / [Y%] writes | — | — |
+
+### Cache
+
+| Resource | Current utilisation | Spec | Notes |
+|---|---|---|---|
+| Memory used | [X GB] of [Y GB] ([Z%]) | [e.g. cache.r6g.large] | Eviction rate: [X%] |
+| Hit rate | [X%] | — | Miss rate: [Y%] |
+| Connections | [X] | Max: [Y] | — |
+
+### Storage / Object Store
+
+| Resource | Current usage | Growth rate | Notes |
+|---|---|---|---|
+| [S3 / GCS / Blob] | [X GB / TB] | [~X GB/month] | [Lifecycle policies in place? Y/N] |
+| Disk (if applicable) | [X GB] of [Y GB] | [~X GB/month] | [RAID / EBS type] |
+
+### Cost Baseline
+
+| Component | Current monthly cost | % of total |
+|---|---|---|
+| Compute (app servers) | $[X] | [X%] |
+| Database | $[X] | [X%] |
+| Cache | $[X] | [X%] |
+| Storage | $[X] | [X%] |
+| CDN / bandwidth | $[X] | [X%] |
+| Other ([describe]) | $[X] | [X%] |
+| **Total** | **$[X]** | 100% |
+
+**Unit economics:** $[X] per [1,000 requests / 1,000 users / GB processed]
+
+---
+
+## 3. Growth Projections
+
+### Assumptions
+
+| Assumption | Value | Source | Confidence |
+|---|---|---|---|
+| Monthly traffic growth rate | [X%] | [Historical trend / product forecast] | [High / Medium / Low] |
+| Seasonal peak factor | [+X% in [month(s)]] | [Last year's data / expected launch] | [High / Medium] |
+| Upcoming events | [e.g. Marketing campaign — [Month], expected +[X]% traffic spike] | [Marketing plan] | [Medium] |
+| User growth | [X new users/month] | [Sales pipeline / growth model] | [Medium] |
+| Data growth | [X GB/month] | [Current trend] | [High] |
+
+### Traffic Forecast
+
+| Timeframe | Req/s (avg) | Req/s (peak) | DAU | Data volume (cumulative) |
+|---|---|---|---|---|
+| **Now** (baseline) | [X] | [X] | [X] | [X GB/TB] |
+| **+3 months** | [X] | [X] | [X] | [X GB/TB] |
+| **+6 months** | [X] | [X] | [X] | [X GB/TB] |
+| **+12 months** | [X] | [X] | [X] | [X GB/TB] |
+
+*Growth formula: [Baseline] × (1 + [monthly rate])^[months] + seasonal adjustment*
+
+### Capacity Headroom Analysis
+
+**When does each resource run out at current utilisation and projected growth?**
+
+| Resource | Current utilisation | Safe ceiling | Headroom remaining | Months to ceiling |
+|---|---|---|---|---|
+| App CPU | [X%] | 70% | [X%] | [X months] |
+| App memory | [X%] | 80% | [X%] | [X months] |
+| DB CPU | [X%] | 70% | [X%] | [X months] |
+| DB storage | [X GB] of [Y GB] | 80% = [Z GB] | [X GB] | [X months] |
+| DB IOPS | [X] of [Y] | 80% = [Z] | [X IOPS] | [X months] |
+| DB connections | [X] of [Y] | 80% = [Z] | [X] | [X months] |
+| Cache memory | [X GB] of [Y GB] | 75% = [Z GB] | [X GB] | [X months] |
+| Storage (object) | [X TB] | No hard limit — cost trigger | — | [Cost trigger: $X/month] |
+
+**Red flags** (resources hitting ceiling within 3 months):
+- [Resource]: [current]% → ceiling in [X weeks] — **Action required**
+- [Resource]: [current]% → ceiling in [X weeks] — **Action required**
+
+---
+
+## 4. Resource Requirements
+
+### Compute Requirements
+
+| Timeframe | Required instances | Recommended instance type | Auto-scaling range | Notes |
+|---|---|---|---|---|
+| Now | [X] | [type] | [min: X, max: Y] | Current configuration |
+| +3 months | [X] | [type] | [min: X, max: Y] | [Any instance type change needed?] |
+| +6 months | [X] | [type or upgrade] | [min: X, max: Y] | [Consider [larger type / horizontal scale]] |
+| +12 months | [X] | [type or upgrade] | [min: X, max: Y] | [State of horizontal vs vertical decision] |
+
+**Memory headroom target:** Maintain ≥30% available memory at average load; ≥20% at peak.
+**CPU headroom target:** Maintain ≥30% available CPU at average load; ≥15% at peak.
+
+### Database Requirements
+
+| Timeframe | Instance type | Storage | IOPS | Read replica | Notes |
+|---|---|---|---|---|---|
+| Now | [type] | [X GB] | [X] | [Y/N] | Current |
+| +3 months | [type] | [X GB] | [X] | [Y/N] | [Upgrade storage / IOPS] |
+| +6 months | [type or upgrade] | [X GB] | [X] | **Yes** | [Read replica recommended by this point] |
+| +12 months | [type] | [X GB] | [X] | [X replicas] | [Consider sharding / partitioning at this scale] |
+
+**Storage growth management:**
+- Current growth: [~X GB/month]
+- Storage auto-scaling: [Enabled / Not enabled — enable by [date]]
+- Archiving policy: [Records older than X months moved to [cold storage / archive tier]]
+
+### Cache Requirements
+
+| Timeframe | Node type | Nodes | Memory | Notes |
+|---|---|---|---|---|
+| Now | [type] | [X] | [X GB] | Current |
+| +6 months | [type] | [X] | [X GB] | [Scale out or upgrade] |
+| +12 months | [type] | [X] | [X GB] | [Cluster mode if >Y GB required] |
+
+---
+
+## 5. Scaling Strategy
+
+### Compute — Horizontal Scaling
+
+**Decision: [Horizontal / Vertical / Both]**
+
+[State the scaling strategy and the reasoning. E.g. "The application is stateless and CPU-bound; horizontal scaling is preferred. Vertical scaling is a short-term fallback only."]
+
+**Auto-scaling configuration:**
+
+```
+Scale-out trigger:  CPU > [X%] for [Y minutes] OR memory > [X%] for [Y minutes]
+Scale-in trigger:   CPU < [X%] for [Y minutes] AND memory < [X%] for [Y minutes]
+Min instances:      [X] (ensures HA across [X] AZs)
+Max instances:      [Y] (cost ceiling)
+Cooldown period:    [X seconds]
+Warmup time:        [X seconds] (time for new instance to be healthy)
+```
+
+**Limits of horizontal scaling:**
+- [e.g. Database connection pool is the current bottleneck — adding more app instances without increasing DB connections will not help]
+- [e.g. Session affinity required for WebSocket connections — limits pure stateless scaling]
+
+### Database — Read Scaling
+
+**Strategy:** [Read replica / Connection pooling via PgBouncer / Query caching / None needed yet]
+
+**When to add a read replica:**
+- DB CPU sustained >60% for >30 minutes, OR
+- Read query P95 latency >50ms, OR
+- Connection pool utilisation >70%
+
+**Connection pooling:**
+- Pooler: [PgBouncer / RDS Proxy / application-level / not configured]
+- Pool size: [X connections per app instance × Y instances = Z total]
+- Max DB connections: [configured to Z + 20% headroom]
+
+### Caching Strategy
+
+**Cache policy:** [Cache-aside / Write-through / Write-behind]
+**TTL strategy:**
+
+| Data type | TTL | Invalidation method |
+|---|---|---|
+| [e.g. User profile] | [5 minutes] | [Explicit invalidation on update] |
+| [e.g. Product catalog] | [1 hour] | [TTL expiry — eventual consistency acceptable] |
+| [e.g. Session data] | [24 hours] | [Explicit invalidation on logout] |
+
+**Cache miss handling:** [Describe what happens on a cache miss — does it fall through gracefully or cause a thundering herd risk?]
+
+---
+
+## 6. Cost Projections
+
+### Infrastructure Cost Forecast
+
+| Component | Now (monthly) | +3 months | +6 months | +12 months |
+|---|---|---|---|---|
+| Compute | $[X] | $[X] | $[X] | $[X] |
+| Database | $[X] | $[X] | $[X] | $[X] |
+| Cache | $[X] | $[X] | $[X] | $[X] |
+| Storage | $[X] | $[X] | $[X] | $[X] |
+| CDN / bandwidth | $[X] | $[X] | $[X] | $[X] |
+| **Total** | **$[X]** | **$[X]** | **$[X]** | **$[X]** |
+| MoM growth % | — | [X%] | [X%] | [X%] |
+
+**Unit economics trend:**
+
+| Timeframe | Cost per 1k requests | Cost per user/month | Notes |
+|---|---|---|---|
+| Now | $[X] | $[X] | Baseline |
+| +6 months | $[X] | $[X] | [Improving / worsening — why] |
+| +12 months | $[X] | $[X] | [Target: $X per 1k requests] |
+
+**Cost optimisation opportunities:**
+
+| Opportunity | Estimated saving | Effort | Timeline |
+|---|---|---|---|
+| [e.g. Reserved instances for baseline compute] | $[X/month] | Low | Immediate |
+| [e.g. S3 lifecycle policy — move objects >90 days to Glacier] | $[X/month] | Low | This sprint |
+| [e.g. Right-size [instance] — current is overprovisioned] | $[X/month] | Low | This sprint |
+| [e.g. Optimise top-5 slow queries — reduce DB compute need] | $[X/month] | Medium | Next quarter |
+
+---
+
+## 7. Capacity Triggers and Actions
+
+Define the thresholds that require explicit action — not retrospective fixes after an incident.
+
+| Resource | Watch (amber) | Act (red — schedule work) | Emergency (incident risk) |
+|---|---|---|---|
+| App CPU (sustained avg) | >60% | >70% | >85% |
+| App memory | >70% | >80% | >90% |
+| DB CPU | >55% | >65% | >80% |
+| DB storage | >65% | >75% | >85% |
+| DB connections | >60% | >70% | >85% |
+| Cache memory / eviction | Hit rate <90% | Hit rate <85% | Hit rate <75% |
+| Error rate | >0.5% | >1% | >2% |
+| P99 latency | >2× baseline | >3× baseline | >5× baseline |
+
+**When a Watch threshold is crossed:**
+- Engineer who observes it creates a ticket with capacity label
+- Ticket reviewed in next sprint planning
+
+**When an Act threshold is crossed:**
+- On-call engineer creates a ticket marked P2
+- Tech lead reviews within 24 hours
+- Action plan documented and scheduled within 1 sprint
+
+**When an Emergency threshold is crossed:**
+- Treat as a potential incident — page on-call
+- Emergency scaling actions taken immediately (see runbook)
+- Root cause investigation starts within 2 hours
+
+**Emergency scaling runbook:** [Link to oncall-runbook for capacity incidents]
+
+---
+
+## 8. Infrastructure Action Roadmap
+
+### Immediate Actions (next 2 weeks)
+
+| Action | Owner | Effort | Justification |
+|---|---|---|---|
+| [e.g. Increase DB connection pool limit to X] | [Name] | [2 hours] | [DB connections at X% — hitting ceiling in X weeks] |
+| [e.g. Enable storage auto-scaling on RDS] | [Name] | [30 min] | [Storage at X% — prevents emergency at X months] |
+| [e.g. Add S3 lifecycle policy for [bucket]] | [Name] | [1 hour] | [Storage growing at $X/month unnecessarily] |
+
+### This Quarter (within 3 months)
+
+| Action | Owner | Effort | Justification |
+|---|---|---|---|
+| [e.g. Add read replica to production DB] | [Name] | [1 day] | [DB CPU projected to hit 65% in 2 months] |
+| [e.g. Increase max auto-scaling limit from X to Y] | [Name] | [2 hours] | [Current max is too close to expected peak] |
+| [e.g. Configure PgBouncer for connection pooling] | [Name] | [3 days] | [Reduce per-connection overhead; headroom for growth] |
+
+### Next Quarter (3–6 months)
+
+| Action | Owner | Effort | Justification |
+|---|---|---|---|
+| [e.g. Upgrade DB instance class — [current] → [next]] | [Name] | [2 hours — blue/green] | [DB CPU projected to hit 70% by Q[X]] |
+| [e.g. Implement caching for [high-read endpoint]] | [Name] | [1 week] | [Reduce DB read load by estimated [X%]] |
+| [e.g. Evaluate horizontal DB sharding] | [Name] | [2 weeks (spike)] | [At 12-month projections, single DB hits limits] |
+
+### Horizon (6–12 months)
+
+| Action | Description | Trigger condition |
+|---|---|---|
+| [e.g. Multi-region deployment] | [Active-passive setup in eu-west-2] | [DAU exceeds X or SLA requires 99.99%] |
+| [e.g. Database sharding or migration to distributed DB] | [Evaluate CockroachDB / Vitess] | [Single-node DB projected to hit ceiling] |
+| [e.g. CDN expansion] | [Add PoPs in [region]] | [Latency SLO breached for [geography]] |
+
+---
+
+## Quality Checks
+
+- [ ] Every resource has a quantified current utilisation and a projected months-to-ceiling — no hand-waving
+- [ ] The most critical constraint is called out in the executive summary with a specific timeline
+- [ ] Growth projections state their assumptions and confidence level — not presented as certainties
+- [ ] Capacity triggers define amber/red thresholds and name who acts at each level
+- [ ] Cost projections include unit economics, not just absolute totals
+- [ ] The infrastructure roadmap has named owners and effort estimates — not just a wish list
+- [ ] Auto-scaling configuration includes both scale-out AND scale-in triggers, and a min/max range
+- [ ] Actions are ordered by urgency — immediate items are genuinely immediate, not backlog filler
@@ -0,0 +1,454 @@
+---
+name: database-migration-plan
+description: "Write a safe, zero-downtime database migration plan for a schema change. Use when asked to plan a database migration, design a zero-downtime schema change, document an expand/contract migration, produce a rollback procedure for a database change, or coordinate a database schema update with a deployment. Produces a structured migration plan covering migration objectives, backward compatibility analysis, expand/contract phase breakdown, exact SQL, rollback steps per phase, data validation queries, and a deployment runbook."
+---
+
+# Database Migration Plan Skill
+
+Produce a complete, safe database migration plan for a schema change. A migration plan is not just the SQL — it is a coordinated sequence of steps that ensures the application stays available, data stays consistent, and every step can be rolled back independently.
+
+The expand/contract pattern is the default approach: expand the schema to support both old and new states, migrate the application, then contract to remove the old state. Never combine schema changes and data backfills in a single migration that runs during deployment.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Current schema state** — the DDL or description of the table(s) as they are now
+- **Target schema state** — the DDL or description of what the table(s) should look like after migration
+- **Migration reason** — why this change is being made (new feature, performance fix, normalization, compliance)
+- **Database engine** — PostgreSQL, MySQL, SQLite, CockroachDB, etc.
+- **Estimated data volume** — approximate number of rows in affected tables
+- **Deployment constraints** — is any downtime allowed? What is the expected traffic level during migration? Are there multiple app instances running?
+- **Rollback window** — how long after deploy can the team roll back before the migration becomes irreversible?
+
+## Output Format
+
+---
+
+# Database Migration Plan: [Migration Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Author:** [Name] | **Reviewed by:** [Name / DBA]
+**Date:** [Date] | **Target deploy date:** [Date]
+**Database engine:** [PostgreSQL X.X / MySQL X.X]
+**Ticket:** [JIRA-XXX]
+
+---
+
+## 1. Migration Overview
+
+**What is changing:**
+[1–2 sentences: the specific schema change — e.g. "Adding a non-nullable `organisation_id` column to the `users` table and backfilling it from the `accounts` table."]
+
+**Why:**
+[1–2 sentences: the business or technical reason driving the change.]
+
+**Migration type:** [Additive only / Additive + backfill / Column rename / Column type change / Table restructure / Index change]
+
+**Zero-downtime:** [Yes — using expand/contract / No — requires maintenance window — state duration]
+
+**Estimated migration duration:**
+- Expand phase: [~X minutes]
+- Data backfill: [~X minutes/hours — based on X rows at Y rows/second]
+- Contract phase: [~X minutes after app version deployed]
+
+---
+
+## 2. Backward Compatibility Analysis
+
+Before writing a single line of SQL, assess whether each change is backward compatible with the currently deployed application code.
+
+| Change | Backward compatible? | Risk | Notes |
+|---|---|---|---|
+| [e.g. Add nullable column `org_id`] | Yes | Low | Old app ignores new column |
+| [e.g. Backfill `org_id`] | Yes | Medium | Old app unaffected; new app reads backfilled values |
+| [e.g. Add NOT NULL constraint to `org_id`] | **No** | High | Old app that inserts without `org_id` will fail |
+| [e.g. Drop old column `account_id`] | **No** | High | Old app that reads `account_id` will fail |
+| [e.g. Add index on `org_id`] | Yes | Low | Additive; no breaking change |
+| [e.g. Rename column] | **No** | High | Never rename in one step; use expand/contract |
+
+**Summary:** [e.g. "This migration requires the expand/contract pattern across 3 deployment phases because steps 3 and 4 are not backward compatible."]
+
+---
+
+## 3. Expand/Contract Phases
+
+### Phase Overview
+
+```
+Phase 1 — EXPAND
+  Deploy migration: add new column (nullable), create new indexes
+  Old app: continues to work (ignores new column)
+  New app: not yet deployed
+  Duration: [~X min] | Rollback: trivial — drop new column
+
+       │
+       ▼
+
+Phase 2 — BACKFILL + DUAL-WRITE
+  Deploy app update: writes to both old and new columns
+  Run backfill: populate new column for existing rows
+  Validate: confirm 100% of rows have non-null new column
+  Duration: [~X hours depending on data volume]
+  Rollback: deploy previous app version; new column is still nullable
+
+       │
+       ▼
+
+Phase 3 — ENFORCE + SWITCH
+  Deploy migration: add NOT NULL constraint, drop old column/index
+  Deploy app update: reads only from new column
+  Duration: [~X min] | Rollback: requires forward-fix (constraint must be dropped first)
+
+       │
+       ▼
+
+Phase 4 — CONTRACT (optional cleanup)
+  Deploy migration: drop deprecated columns, rename if needed
+  Final state matches target schema
+  Rollback: not recommended — contract changes are destructive
+```
+
+---
+
+### Phase 1 — Expand Schema
+
+**Goal:** Add the new column and structures without breaking the existing application.
+**Deploy order:** Run migration first, then (optionally) deploy app.
+**Application state:** Old app running; no app changes required yet.
+
+```sql
+-- Migration: 001_add_org_id_to_users.sql
+BEGIN;
+
+-- Add nullable column (safe — old app ignores it)
+ALTER TABLE users
+    ADD COLUMN org_id UUID NULL
+        REFERENCES organisations(id) ON DELETE RESTRICT;
+
+-- Add index NOW, not in Phase 3 — building index on large table during Phase 3 is risky
+CREATE INDEX CONCURRENTLY users_org_id_idx ON users (org_id);
+
+-- Note: CONCURRENTLY does not lock the table; safe on live traffic
+-- Note: Cannot run CONCURRENTLY inside a transaction block; run separately if needed
+
+COMMIT;
+```
+
+**Validation after Phase 1:**
+```sql
+-- Confirm column exists and is nullable
+SELECT column_name, data_type, is_nullable
+FROM information_schema.columns
+WHERE table_name = 'users' AND column_name = 'org_id';
+-- Expected: is_nullable = 'YES'
+
+-- Confirm index exists
+SELECT indexname, indexdef
+FROM pg_indexes
+WHERE tablename = 'users' AND indexname = 'users_org_id_idx';
+```
+
+**Rollback (Phase 1 only):**
+```sql
+BEGIN;
+DROP INDEX CONCURRENTLY IF EXISTS users_org_id_idx;
+ALTER TABLE users DROP COLUMN IF EXISTS org_id;
+COMMIT;
+```
+
+---
+
+### Phase 2 — Backfill Existing Data
+
+**Goal:** Populate the new column for all existing rows before enforcing NOT NULL.
+**When to run:** After Phase 1 is live and stable. Can be run as a background job or a one-time script.
+**Application state:** Deploy app version that dual-writes to both old and new columns.
+
+**App code change required:**
+```
+// All INSERT and UPDATE operations must now set BOTH old_column and new_column
+// until Phase 3 is complete. This ensures new rows are populated during the backfill window.
+```
+
+**Backfill script — batch processing:**
+```sql
+-- Run in batches to avoid locking. Adjust batch size based on table size and DB load.
+-- Target: no single batch takes more than 5 seconds.
+
+DO $$
+DECLARE
+    batch_size  INT := 1000;
+    affected    INT;
+BEGIN
+    LOOP
+        UPDATE users
+        SET    org_id = accounts.organisation_id
+        FROM   accounts
+        WHERE  users.account_id = accounts.id
+          AND  users.org_id IS NULL
+        LIMIT  batch_size;
+
+        GET DIAGNOSTICS affected = ROW_COUNT;
+        EXIT WHEN affected = 0;
+
+        -- Pause between batches to avoid saturating I/O
+        PERFORM pg_sleep(0.1);
+    END LOOP;
+END $$;
+```
+
+**Monitoring during backfill:**
+```sql
+-- Check progress — run periodically during backfill
+SELECT
+    COUNT(*) FILTER (WHERE org_id IS NOT NULL) AS backfilled,
+    COUNT(*) FILTER (WHERE org_id IS NULL)     AS remaining,
+    COUNT(*)                                   AS total,
+    ROUND(
+        100.0 * COUNT(*) FILTER (WHERE org_id IS NOT NULL) / COUNT(*), 2
+    ) AS pct_complete
+FROM users;
+```
+
+**Backfill completion validation:**
+```sql
+-- Must return 0 before proceeding to Phase 3
+SELECT COUNT(*) AS unbackfilled_rows
+FROM users
+WHERE org_id IS NULL;
+
+-- Confirm no new rows written without org_id (dual-write working)
+SELECT COUNT(*) AS recent_missing
+FROM users
+WHERE org_id IS NULL
+  AND created_at > now() - INTERVAL '1 hour';
+```
+
+**Rollback (Phase 2 — app only):**
+- Deploy previous app version (single-write to old column)
+- `org_id` column remains nullable; no data is lost
+- Backfilled values remain; harmless
+
+---
+
+### Phase 3 — Enforce Constraints
+
+**Goal:** Add NOT NULL constraint and remove dependency on the old column.
+**Prerequisites:** Phase 2 backfill must be 100% complete (zero rows with `org_id IS NULL`).
+**Deploy order:** Run migration, then deploy app version that reads only from `org_id`.
+
+**PostgreSQL — use NOT VALID + VALIDATE for large tables:**
+```sql
+-- Step 1: Add constraint as NOT VALID (no full table scan — instant)
+ALTER TABLE users
+    ADD CONSTRAINT users_org_id_not_null
+    CHECK (org_id IS NOT NULL) NOT VALID;
+
+-- Step 2: VALIDATE CONSTRAINT (takes a SHARE UPDATE EXCLUSIVE lock — allows reads and writes)
+-- Run this separately, as it can take minutes on large tables
+ALTER TABLE users
+    VALIDATE CONSTRAINT users_org_id_not_null;
+
+-- Step 3: Once validated, convert to actual NOT NULL
+-- (PostgreSQL trusts the validated check constraint — this is instant)
+ALTER TABLE users
+    ALTER COLUMN org_id SET NOT NULL;
+
+-- Step 4: Drop the now-redundant check constraint
+ALTER TABLE users
+    DROP CONSTRAINT users_org_id_not_null;
+```
+
+**Validation after Phase 3:**
+```sql
+-- Confirm NOT NULL is enforced
+SELECT column_name, is_nullable
+FROM information_schema.columns
+WHERE table_name = 'users' AND column_name = 'org_id';
+-- Expected: is_nullable = 'NO'
+
+-- Test that insert without org_id fails (run in a transaction and roll back)
+BEGIN;
+INSERT INTO users (email) VALUES ('test@example.com');
+-- Expected: ERROR: null value in column "org_id" violates not-null constraint
+ROLLBACK;
+```
+
+**Rollback (Phase 3):**
+```sql
+-- Drop the NOT NULL constraint (restores nullable state)
+ALTER TABLE users ALTER COLUMN org_id DROP NOT NULL;
+-- Then deploy previous app version (dual-write)
+-- Note: Once app code reading the new column is live, rolling back the constraint
+-- without rolling back the app will cause issues — plan this carefully.
+```
+
+---
+
+### Phase 4 — Contract (Remove Old Column)
+
+**Goal:** Remove the old column once the app no longer references it.
+**Prerequisites:** Phase 3 fully deployed and stable for at least [X days/hours rollback window].
+**Warning:** This phase is destructive — the old column's data is permanently deleted.
+
+```sql
+BEGIN;
+
+-- Drop the old column
+ALTER TABLE users DROP COLUMN account_id;
+
+-- Drop any indexes that referenced the old column
+DROP INDEX IF EXISTS users_account_id_idx;
+
+COMMIT;
+```
+
+**Pre-drop validation:**
+```sql
+-- Confirm no application queries still reference the old column
+-- (Check this in code review and via a search of the codebase before running)
+-- grep -r "account_id" app/
+
+-- Confirm the column is safe to drop
+SELECT COUNT(*) FROM users WHERE account_id IS NOT NULL;
+-- Should be 0 (or irrelevant once new column is canonical)
+```
+
+**Rollback:** Not straightforward — dropped column data cannot be recovered. Only proceed to Phase 4 after the rollback window has passed and the change is confirmed stable.
+
+---
+
+## 4. Data Validation Plan
+
+Run these queries before and after the full migration to confirm data integrity.
+
+**Pre-migration baseline:**
+```sql
+-- Record these values before any migration step
+SELECT COUNT(*)   AS total_users FROM users;
+SELECT COUNT(*)   AS total_orgs  FROM organisations;
+SELECT MIN(created_at), MAX(created_at) FROM users;
+
+-- Check for any anomalies in the source data before backfill
+SELECT COUNT(*) AS users_without_account
+FROM users WHERE account_id IS NULL;
+```
+
+**Post-backfill integrity check:**
+```sql
+-- All users have an org that exists
+SELECT COUNT(*) AS orphaned_org_refs
+FROM users u
+WHERE u.org_id IS NOT NULL
+  AND NOT EXISTS (
+      SELECT 1 FROM organisations o WHERE o.id = u.org_id
+  );
+-- Expected: 0
+
+-- org_id matches expected value from source column
+SELECT COUNT(*) AS mismatched_backfill
+FROM users u
+JOIN accounts a ON u.account_id = a.id
+WHERE u.org_id != a.organisation_id;
+-- Expected: 0
+
+-- Row count unchanged (no rows created or deleted by migration)
+SELECT COUNT(*) AS total_users_after FROM users;
+-- Must match pre-migration baseline
+```
+
+**Post-contract final check:**
+```sql
+-- Old column is gone
+SELECT COUNT(*) FROM information_schema.columns
+WHERE table_name = 'users' AND column_name = 'account_id';
+-- Expected: 0
+
+-- New column is NOT NULL
+SELECT is_nullable FROM information_schema.columns
+WHERE table_name = 'users' AND column_name = 'org_id';
+-- Expected: NO
+```
+
+---
+
+## 5. Performance Impact Assessment
+
+| Step | Lock type | Lock duration | Traffic impact |
+|---|---|---|---|
+| Add nullable column | ACCESS EXCLUSIVE | Milliseconds | Negligible |
+| CREATE INDEX CONCURRENTLY | SHARE UPDATE EXCLUSIVE | Minutes (proportional to table size) | Reads and writes continue |
+| Batch backfill | Row-level locks only | <5s per batch | Low if batches are small |
+| ADD CONSTRAINT NOT VALID | ACCESS EXCLUSIVE | Milliseconds | Negligible |
+| VALIDATE CONSTRAINT | SHARE UPDATE EXCLUSIVE | Minutes | Reads and writes continue |
+| ALTER COLUMN SET NOT NULL | ACCESS EXCLUSIVE | Milliseconds (if check constraint validated) | Negligible |
+| DROP COLUMN | ACCESS EXCLUSIVE | Milliseconds | Negligible |
+
+**Expected load increase during backfill:**
+- DB CPU: [estimated % increase during batch writes]
+- DB I/O: [estimated increase]
+- Monitoring threshold to pause backfill: [e.g. DB CPU > 80% for >2 minutes]
+
+**Backfill rate estimate:**
+- Table size: [X million rows]
+- Batch size: [1000 rows]
+- Pause between batches: [100ms]
+- Estimated total duration: [X hours at Y rows/second]
+
+---
+
+## 6. Deployment Runbook
+
+Follow this checklist on the day of migration. Mark each step as done before proceeding.
+
+**Pre-migration (day before):**
+- [ ] DBA / tech lead has reviewed the migration plan
+- [ ] Performance impact assessed; monitoring dashboards ready
+- [ ] Backfill script tested on a staging DB with production-scale data
+- [ ] Rollback procedure tested on staging
+- [ ] On-call engineer briefed; Slack channel [#db-migrations] set up for coordination
+- [ ] Maintenance window scheduled (if required)
+
+**Phase 1 — Expand (T+0):**
+- [ ] Take a manual DB snapshot / verify automated backup is recent
+- [ ] Run `001_expand_add_org_id.sql` on production
+- [ ] Run Phase 1 validation queries — confirm pass
+- [ ] Deploy app version with dual-write
+- [ ] Monitor error rate for [10 minutes]
+
+**Phase 2 — Backfill (T+[X hours]):**
+- [ ] Confirm Phase 1 has been stable for [X hours]
+- [ ] Start backfill script in a screen/tmux session
+- [ ] Monitor progress via backfill progress query every [5 minutes]
+- [ ] Monitor DB CPU and I/O — pause if thresholds exceeded
+- [ ] Run completion validation — confirm 0 unbackfilled rows
+- [ ] Run integrity checks — confirm 0 orphaned refs, 0 mismatches
+
+**Phase 3 — Enforce (T+[X days]):**
+- [ ] Confirm backfill 100% complete and stable for [X hours]
+- [ ] Add NOT VALID constraint
+- [ ] Run VALIDATE CONSTRAINT (monitor duration and lock waits)
+- [ ] Alter column to NOT NULL
+- [ ] Run Phase 3 validation queries
+- [ ] Deploy app version reading only from new column
+- [ ] Monitor error rate for [30 minutes]
+
+**Phase 4 — Contract (T+[X days after rollback window]):**
+- [ ] Confirm rollback window has passed — no incidents, no rollback needed
+- [ ] Search codebase for references to old column — confirm zero
+- [ ] Run DROP COLUMN migration
+- [ ] Run final integrity checks
+- [ ] Close migration ticket; update schema documentation
+
+---
+
+## Quality Checks
+
+- [ ] Every migration phase has an independent rollback procedure — no phase assumes the next one has run
+- [ ] Batch backfill script includes a pause between batches to avoid saturating I/O
+- [ ] NOT NULL constraints use the NOT VALID + VALIDATE pattern on tables with >100k rows
+- [ ] The app dual-write period is explicitly defined — old column writes are not dropped until Phase 3 is deployed
+- [ ] Data validation queries include a row count check to confirm no data loss
+- [ ] Lock types are identified for every DDL statement — no "should be fine" assumptions
+- [ ] The deployment runbook names who runs each step, not just what to run
+- [ ] Phase 4 (contract) is explicitly gated on the rollback window passing — not run on the same day as Phase 3
@@ -0,0 +1,356 @@
+---
+name: database-schema-design
+description: "Document or design a database schema with entity relationships, table definitions, constraints, indexes, and access patterns. Use when asked to design a database, document an existing schema, model entities and relationships, define table structures, plan an index strategy, or produce a data model for review. Produces a structured schema document covering an ER diagram, table DDL definitions, index strategy, access pattern analysis, normalization decisions, and migration notes."
+---
+
+# Database Schema Design Skill
+
+Produce a complete database schema design document for a given domain. A schema document is not just a list of tables — it is a record of decisions: what was modelled, how entities relate, which queries the schema is optimised for, and what trade-offs were made.
+
+A good schema design document lets an engineer understand the data model, query it correctly, extend it safely, and write migrations without breaking things.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Domain description** — what the system does; what business objects are being modelled
+- **Entities and relationships** — the main things in the domain and how they relate (e.g. "a User has many Orders; an Order has many OrderItems; an OrderItem references a Product")
+- **Expected query patterns** — the most important read and write queries (e.g. "fetch all orders for a user, sorted by date"; "look up a product by SKU")
+- **Database engine** — PostgreSQL, MySQL, SQLite, CockroachDB, etc. — this affects DDL syntax and available types
+- **Expected data volume** — approximate row counts, growth rate, and any partitioning needs
+- **Constraints** — any existing conventions, naming standards, or migration constraints to respect
+
+## Output Format
+
+---
+
+# Database Schema Design: [Domain / Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Author:** [Name] | **Reviewed by:** [Name]
+**Date:** [Date] | **Database engine:** [PostgreSQL X.X / MySQL X.X / etc.]
+**Status:** [Draft / Reviewed / Approved]
+
+---
+
+## 1. Overview
+
+[2–3 sentences describing the domain being modelled, the scope of this schema, and any key design philosophy (e.g. "this schema prioritises read performance for the customer-facing API over write simplicity", or "designed for eventual migration to multi-tenancy")]
+
+**In scope:**
+- [Entity or subsystem]
+- [Entity or subsystem]
+
+**Out of scope:**
+- [e.g. Analytics / reporting tables — separate schema]
+- [e.g. Audit log tables — covered in separate design doc]
+
+---
+
+## 2. Entity Relationship Diagram
+
+```
+┌───────────────────┐         ┌───────────────────────┐
+│      users        │         │       organisations    │
+│─────────────────  │         │─────────────────────── │
+│ id (PK)           │    ┌───▶│ id (PK)                │
+│ org_id (FK)  ─────┼────┘    │ name                   │
+│ email             │         │ plan                   │
+│ display_name      │         │ created_at             │
+│ created_at        │         └───────────────────────┘
+│ updated_at        │
+└─────────┬─────────┘
+          │ 1
+          │
+          │ N
+┌─────────▼─────────┐         ┌───────────────────────┐
+│      [table_a]    │         │      [table_b]         │
+│─────────────────  │         │─────────────────────── │
+│ id (PK)           │    N    │ id (PK)                │
+│ user_id (FK) ─────┼────────▶│ [table_a]_id (FK)      │
+│ [field]           │    │    │ [field]                │
+│ [field]           │    │    │ [field]                │
+│ created_at        │         │ created_at             │
+└───────────────────┘         └───────────────────────┘
+```
+
+**Relationship summary:**
+
+| Entity A | Relationship | Entity B | Notes |
+|---|---|---|---|
+| organisations | has many | users | An org can have many users |
+| users | has many | [table_a] | Soft-deleted on user deletion |
+| [table_a] | has many | [table_b] | Cascade delete |
+| [table_b] | belongs to | [table_a] | Non-nullable FK |
+| [table_c] | many-to-many (via [join_table]) | [table_d] | Join table with metadata |
+
+---
+
+## 3. Table Definitions
+
+### `organisations`
+
+[1 sentence describing what this table stores and its role in the domain.]
+
+```sql
+CREATE TABLE organisations (
+    id          UUID            PRIMARY KEY DEFAULT gen_random_uuid(),
+    name        VARCHAR(255)    NOT NULL,
+    slug        VARCHAR(100)    NOT NULL UNIQUE,
+    plan        VARCHAR(50)     NOT NULL DEFAULT 'free'
+                                CHECK (plan IN ('free', 'pro', 'enterprise')),
+    settings    JSONB           NOT NULL DEFAULT '{}',
+    created_at  TIMESTAMPTZ     NOT NULL DEFAULT now(),
+    updated_at  TIMESTAMPTZ     NOT NULL DEFAULT now()
+);
+```
+
+| Column | Type | Nullable | Default | Notes |
+|---|---|---|---|---|
+| id | UUID | No | gen_random_uuid() | Surrogate PK — UUID preferred over serial for distributed use |
+| name | VARCHAR(255) | No | — | Display name; not unique |
+| slug | VARCHAR(100) | No | — | URL-safe identifier; unique across all orgs |
+| plan | VARCHAR(50) | No | 'free' | Constrained to known values via CHECK |
+| settings | JSONB | No | {} | Flexible config; avoid for queryable fields |
+| created_at | TIMESTAMPTZ | No | now() | Always use TIMESTAMPTZ, not TIMESTAMP |
+| updated_at | TIMESTAMPTZ | No | now() | Updated via trigger (see below) |
+
+---
+
+### `users`
+
+[1 sentence describing what this table stores.]
+
+```sql
+CREATE TABLE users (
+    id              UUID            PRIMARY KEY DEFAULT gen_random_uuid(),
+    org_id          UUID            NOT NULL REFERENCES organisations(id)
+                                    ON DELETE RESTRICT,
+    email           VARCHAR(254)    NOT NULL,
+    display_name    VARCHAR(255)    NOT NULL DEFAULT '',
+    role            VARCHAR(50)     NOT NULL DEFAULT 'member'
+                                    CHECK (role IN ('owner', 'admin', 'member', 'viewer')),
+    email_verified  BOOLEAN         NOT NULL DEFAULT false,
+    deleted_at      TIMESTAMPTZ     NULL,
+    created_at      TIMESTAMPTZ     NOT NULL DEFAULT now(),
+    updated_at      TIMESTAMPTZ     NOT NULL DEFAULT now(),
+
+    CONSTRAINT users_email_org_unique UNIQUE (email, org_id)
+);
+```
+
+| Column | Type | Nullable | Default | Notes |
+|---|---|---|---|---|
+| id | UUID | No | gen_random_uuid() | — |
+| org_id | UUID | No | — | FK to organisations; RESTRICT prevents orphaning |
+| email | VARCHAR(254) | No | — | RFC 5321 max length; unique per org (not globally) |
+| role | VARCHAR(50) | No | 'member' | Application-level RBAC |
+| deleted_at | TIMESTAMPTZ | Yes | NULL | Soft delete; NULL = active |
+
+**Soft delete policy:** Rows with `deleted_at IS NOT NULL` are considered deleted. All application queries MUST filter `WHERE deleted_at IS NULL` unless explicitly fetching deleted records. Use a view or ORM scope to enforce this.
+
+---
+
+### `[table_a]`
+
+[Description of what this table models.]
+
+```sql
+CREATE TABLE [table_a] (
+    id          UUID            PRIMARY KEY DEFAULT gen_random_uuid(),
+    user_id     UUID            NOT NULL REFERENCES users(id) ON DELETE CASCADE,
+    [field_1]   VARCHAR(255)    NOT NULL,
+    [field_2]   TEXT            NULL,
+    [field_3]   INTEGER         NOT NULL DEFAULT 0 CHECK ([field_3] >= 0),
+    status      VARCHAR(50)     NOT NULL DEFAULT 'pending'
+                                CHECK (status IN ('pending', 'active', 'archived')),
+    metadata    JSONB           NOT NULL DEFAULT '{}',
+    created_at  TIMESTAMPTZ     NOT NULL DEFAULT now(),
+    updated_at  TIMESTAMPTZ     NOT NULL DEFAULT now()
+);
+```
+
+| Column | Type | Nullable | Notes |
+|---|---|---|---|
+| user_id | UUID | No | CASCADE delete — when user is deleted, their [table_a] rows are too |
+| [field_1] | VARCHAR(255) | No | [Reason for length constraint] |
+| status | VARCHAR(50) | No | State machine: pending → active → archived (no other transitions) |
+| metadata | JSONB | No | [What is stored here and why it's not a typed column] |
+
+---
+
+### `[join_table]` *(Many-to-many)*
+
+[Description of the relationship this table represents.]
+
+```sql
+CREATE TABLE [join_table] (
+    [table_c]_id    UUID        NOT NULL REFERENCES [table_c](id) ON DELETE CASCADE,
+    [table_d]_id    UUID        NOT NULL REFERENCES [table_d](id) ON DELETE CASCADE,
+    granted_by      UUID        NOT NULL REFERENCES users(id) ON DELETE RESTRICT,
+    granted_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
+
+    PRIMARY KEY ([table_c]_id, [table_d]_id)
+);
+```
+
+**Why a composite PK:** The combination of `[table_c]_id + [table_d]_id` is the natural key — each association is unique and the primary key doubles as the uniqueness constraint without needing a separate index.
+
+---
+
+## 4. Index Strategy
+
+For each table, define which indexes are created and why. Include the query they are designed to serve.
+
+| Table | Index name | Columns | Type | Query served | Notes |
+|---|---|---|---|---|---|
+| users | `users_org_id_idx` | `(org_id)` | B-tree | `SELECT * FROM users WHERE org_id = $1` | FK lookup; required for join performance |
+| users | `users_email_lower_idx` | `(lower(email))` | B-tree (functional) | `WHERE lower(email) = lower($1)` | Case-insensitive email lookup |
+| users | `users_active_by_org_idx` | `(org_id, created_at DESC)` | B-tree | `WHERE org_id = $1 AND deleted_at IS NULL ORDER BY created_at DESC` | Partial index candidate (see below) |
+| [table_a] | `[table_a]_user_id_status_idx` | `(user_id, status)` | B-tree | `WHERE user_id = $1 AND status = 'active'` | Compound — order matters |
+| [table_a] | `[table_a]_metadata_gin_idx` | `metadata` | GIN | `WHERE metadata @> '{"key": "value"}'` | Only add if JSONB queried frequently |
+
+**Partial indexes (PostgreSQL):**
+
+```sql
+-- Index only active (non-deleted) users — dramatically smaller for soft-delete tables
+CREATE INDEX users_active_email_idx
+    ON users (email, org_id)
+    WHERE deleted_at IS NULL;
+
+-- Index only pending items — avoids indexing the majority of rows
+CREATE INDEX [table_a]_pending_idx
+    ON [table_a] (user_id, created_at)
+    WHERE status = 'pending';
+```
+
+**Index design principles applied:**
+- FKs that appear in JOIN conditions always have an index
+- Compound indexes follow selectivity order: most selective column first
+- Functional indexes for case-insensitive lookups
+- GIN indexes only where JSONB containment queries are frequent
+- Partial indexes for status-filtered queries on large tables
+
+---
+
+## 5. Access Pattern Analysis
+
+Document the primary queries this schema is designed to serve. For each, show the query, the indexes used, and any caveats.
+
+### AP-1: Fetch all active users for an organisation (paginated)
+
+**Frequency:** Very high — called on every dashboard load
+**Query:**
+```sql
+SELECT id, email, display_name, role, created_at
+FROM users
+WHERE org_id = $1
+  AND deleted_at IS NULL
+ORDER BY created_at DESC
+LIMIT 50 OFFSET $2;
+```
+**Index used:** `users_active_by_org_idx` (org_id, created_at DESC)
+**Notes:** Use keyset pagination (`WHERE created_at < $cursor`) at scale; OFFSET degrades past ~10k rows.
+
+---
+
+### AP-2: Look up a user by email (case-insensitive)
+
+**Frequency:** High — every authentication attempt
+**Query:**
+```sql
+SELECT id, org_id, role, email_verified
+FROM users
+WHERE lower(email) = lower($1)
+  AND deleted_at IS NULL;
+```
+**Index used:** `users_email_lower_idx`
+**Notes:** Returns multiple rows if same email exists across orgs. Application resolves by org context.
+
+---
+
+### AP-3: Fetch [table_a] items for a user by status
+
+**Frequency:** High
+**Query:**
+```sql
+SELECT *
+FROM [table_a]
+WHERE user_id = $1
+  AND status = $2
+ORDER BY created_at DESC
+LIMIT 25;
+```
+**Index used:** `[table_a]_user_id_status_idx`
+**Notes:** Compound index covers both filter columns. Status filter must come second in the index because user_id is more selective.
+
+---
+
+### AP-4: [Add further access patterns as needed]
+
+---
+
+## 6. Normalization Decisions
+
+Document deliberate choices to normalize or denormalize, with reasoning.
+
+| Decision | Approach | Reasoning |
+|---|---|---|
+| [e.g. Organisation name on users table?] | **Not denormalized** — always join to organisations | Avoid stale copies; org name changes are infrequent and joining is cheap |
+| [e.g. Status history] | **Not in this table** — separate `[table_a]_status_history` if needed | Current status is all that's needed for 99% of queries; history is auditing, not application data |
+| [e.g. JSONB `settings` column on organisations] | **Denormalized into JSONB** | Settings are read together; never queried by field; schema changes don't require migrations |
+| [e.g. Computed aggregate counts] | **Not stored** — computed at query time | Counts are small; maintaining a counter column requires careful locking; use `SELECT COUNT(*)` with the index |
+
+---
+
+## 7. Triggers and Automation
+
+```sql
+-- Automatically update updated_at on any row modification
+CREATE OR REPLACE FUNCTION set_updated_at()
+RETURNS TRIGGER AS $$
+BEGIN
+    NEW.updated_at = now();
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+
+-- Apply to all tables with updated_at
+CREATE TRIGGER users_updated_at
+    BEFORE UPDATE ON users
+    FOR EACH ROW EXECUTE FUNCTION set_updated_at();
+
+CREATE TRIGGER [table_a]_updated_at
+    BEFORE UPDATE ON [table_a]
+    FOR EACH ROW EXECUTE FUNCTION set_updated_at();
+```
+
+---
+
+## 8. Migration Notes
+
+If this schema is being introduced to an existing system, note the migration approach.
+
+| Step | Description | Backward compatible | Risk |
+|---|---|---|---|
+| 1 | Create `organisations` table | Yes — additive | Low |
+| 2 | Create `users` table | Yes — additive | Low |
+| 3 | Backfill `org_id` on existing users | **Requires dual-write period** | Medium |
+| 4 | Add NOT NULL constraint on `org_id` | Requires backfill to be 100% complete | Medium |
+| 5 | Remove deprecated columns | Requires app code updated first | Low once app deployed |
+
+**Backfill strategy:** [Describe how to handle existing data — batch size, rate limiting, validation queries]
+
+**Rollback:** Each migration step should be independently reversible. See [database-migration-plan skill] for the full rollback procedure template.
+
+---
+
+## Quality Checks
+
+- [ ] Every table has a primary key and a `created_at` column — no implicit ordering by row insertion
+- [ ] Every foreign key has a corresponding index — no missing FK indexes that would cause full table scans on joins
+- [ ] All TIMESTAMPTZ columns, not TIMESTAMP — timezone awareness is explicit
+- [ ] Soft-delete tables document the convention and where the filter is enforced (ORM scope, view, or query standard)
+- [ ] Every access pattern in the design has a supporting index or an explicit note that a full table scan is acceptable
+- [ ] JSONB columns are justified — not used as a substitute for proper schema design on queryable fields
+- [ ] Normalization decisions are documented with reasoning, not just stated
+- [ ] Migration notes address existing data if this is a schema change, not a greenfield schema
@@ -0,0 +1,332 @@
+---
+name: dependency-audit
+description: "Conduct a dependency audit for a project — checking for security vulnerabilities, license compliance issues, outdated packages, and transitive dependency risk. Use when asked to audit dependencies, review package security, check license compliance, assess dependency health, or produce a vulnerability report. Produces a vulnerability findings table, license compliance matrix, update priority matrix, dependency health score, and 30-day remediation plan."
+---
+
+# Dependency Audit Skill
+
+Produce a complete dependency audit report for a project — covering security vulnerabilities (with CVE references), license compliance against policy, outdated packages prioritised by risk, transitive dependency risk analysis, and a concrete remediation plan with timeline. A good dependency audit gives the team a clear, prioritised action list — not a raw dump of audit output that no one acts on.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Project language and ecosystem** — npm, pip/PyPI, Maven/Gradle, Go modules, Cargo, RubyGems, NuGet, or mixed
+- **Dependency list or package manifest** — paste the contents of `package.json`, `requirements.txt`, `go.mod`, `pom.xml`, etc., or provide the audit tool output
+- **License policy** — which licenses are allowed, which are restricted (e.g. "GPL is prohibited", "MIT/Apache/BSD only", or "no policy yet — recommend one")
+- **Current security tooling** — Dependabot, Snyk, OWASP Dependency-Check, npm audit, pip-audit, or none
+
+## Output Format
+
+---
+
+# Dependency Audit Report: [Project Name]
+
+**Ecosystem:** [npm / pip / Maven / Go / etc.]
+**Audit date:** [Date]
+**Auditor:** [Name]
+**Total direct dependencies:** [N]
+**Total transitive dependencies:** [N]
+**Audit tool(s) used:** [npm audit / pip-audit / Snyk / OWASP Dependency-Check / etc.]
+
+---
+
+## Executive Summary
+
+| Category | Finding | Risk level |
+|---|---|---|
+| Critical vulnerabilities | [N] CVEs requiring immediate action | [Critical / High / Low] |
+| High vulnerabilities | [N] CVEs — fix within 7 days | [High / Medium] |
+| License violations | [N] packages with non-compliant licenses | [High / Low] |
+| Severely outdated packages | [N] packages > 2 major versions behind | [Medium] |
+| Packages with no active maintenance | [N] packages — no commits in 12+ months | [Medium] |
+| **Overall dependency health score** | **[Score]/100** | **[Red / Amber / Green]** |
+
+**Scoring methodology:** Critical CVEs: −20 each. High CVEs: −10 each. License violations: −15 each. Abandoned packages: −5 each. Maximum deduction: 100. Score ≥80 = Green, 60–79 = Amber, <60 = Red.
+
+**Immediate actions required:**
+1. [Most critical action — e.g. "Upgrade lodash from 4.17.11 to 4.17.21 to fix CVE-2021-23337 (Critical — prototype pollution)"]
+2. [Second action]
+3. [Third action]
+
+---
+
+## 1. Security Vulnerability Findings
+
+### Critical and High Severity (Act within 24–72 hours)
+
+| Package | Installed version | Fix version | CVE | Severity | CVSS score | Description | Exploitability |
+|---|---|---|---|---|---|---|---|
+| [package-name] | [X.Y.Z] | [A.B.C] | [CVE-YYYY-NNNNN] | Critical | [9.x] | [e.g. Prototype pollution via `merge` function — remote code execution possible] | [Known exploit / PoC available / No known exploit] |
+| [package-name] | [X.Y.Z] | [A.B.C] | [CVE-YYYY-NNNNN] | High | [7.x] | [e.g. Path traversal in file serving utility] | [PoC available] |
+| [package-name] | [X.Y.Z] | [A.B.C] | [CVE-YYYY-NNNNN] | High | [7.x] | [e.g. Regular expression denial of service (ReDoS)] | [No known exploit] |
+
+### Medium Severity (Fix within 30 days)
+
+| Package | Installed version | Fix version | CVE | Severity | CVSS score | Description |
+|---|---|---|---|---|---|---|
+| [package-name] | [X.Y.Z] | [A.B.C] | [CVE-YYYY-NNNNN] | Medium | [5.x] | [Description] |
+| [package-name] | [X.Y.Z] | [A.B.C] | [CVE-YYYY-NNNNN] | Medium | [4.x] | [Description] |
+
+### Low Severity (Fix within 90 days or accept risk)
+
+| Package | Installed version | Fix version | CVE | Severity | Description |
+|---|---|---|---|---|---|
+| [package-name] | [X.Y.Z] | [A.B.C] | Low | [Description] |
+
+### Vulnerabilities With No Fix Available
+
+| Package | CVE | Severity | Recommended mitigation |
+|---|---|---|---|
+| [package-name] | [CVE-YYYY-NNNNN] | [High] | [e.g. "Remove this package — alternative: [replacement]"] |
+| [package-name] | [CVE-YYYY-NNNNN] | [Medium] | [e.g. "Vendor has a fix in progress — track issue [URL]. Mitigate by [X]"] |
+
+---
+
+## 2. License Compliance Matrix
+
+### License Policy Reference
+
+| License | Category | Policy | Notes |
+|---|---|---|---|
+| MIT | Permissive | Allowed | Attribution required in distributed products |
+| Apache 2.0 | Permissive | Allowed | Attribution + NOTICE file required |
+| BSD 2-Clause / 3-Clause | Permissive | Allowed | Attribution required |
+| ISC | Permissive | Allowed | |
+| MPL 2.0 | Weak copyleft | Allowed with review | Source disclosure required for modified MPL files only |
+| LGPL v2 / v3 | Weak copyleft | Allowed with review | Dynamic linking permitted; static linking may require disclosure |
+| GPL v2 / v3 | Strong copyleft | **Restricted** | May require open-sourcing the entire codebase — legal review required |
+| AGPL v3 | Strong copyleft | **Restricted** | Network use triggers copyleft — especially risky for SaaS |
+| SSPL | Source available | **Prohibited** | Not OSI-approved — treat as proprietary |
+| Proprietary / Commercial | Commercial | **Requires contract** | Verify license covers current use case and scale |
+| Unknown / Unlicensed | — | **Prohibited** | No license = all rights reserved — cannot use legally |
+
+### Findings: Packages With Compliance Issues
+
+| Package | License | Issue | Recommendation | Risk if unaddressed |
+|---|---|---|---|---|
+| [package-name] | GPL v3 | Copyleft — may require open-sourcing this project | Replace with [alternative] or get legal sign-off | Legal / IP risk |
+| [package-name] | AGPL v3 | Network copyleft — SaaS use triggers disclosure | Replace with [alternative] | Legal / IP risk |
+| [package-name] | Proprietary | License may not cover current usage tier | Verify license scope with vendor | Contract breach |
+| [package-name] | Unknown | No license declared in package metadata | Contact maintainer or replace | Cannot use legally |
+
+### All Licenses in Use (Full Inventory)
+
+| License | Package count | Compliance status |
+|---|---|---|
+| MIT | [N] | Compliant |
+| Apache 2.0 | [N] | Compliant |
+| BSD-3-Clause | [N] | Compliant |
+| ISC | [N] | Compliant |
+| MPL 2.0 | [N] | Review required |
+| GPL v3 | [N] | **Non-compliant** |
+| Unknown | [N] | **Non-compliant** |
+
+---
+
+## 3. Outdated Package Analysis
+
+### Severely Outdated (2+ major versions behind — high upgrade effort)
+
+| Package | Installed | Latest stable | Versions behind | Last updated | Breaking changes summary |
+|---|---|---|---|---|---|
+| [package-name] | [1.x.x] | [3.x.x] | 2 major | [Date] | [e.g. "API redesign in v2; async support added in v3"] |
+| [package-name] | [0.x.x] | [2.x.x] | 2 major | [Date] | [Summary] |
+
+### Moderately Outdated (1 major version behind)
+
+| Package | Installed | Latest stable | Versions behind | Security fix in newer version? |
+|---|---|---|---|---|
+| [package-name] | [2.x.x] | [3.x.x] | 1 major | [Yes — CVE-YYYY-NNNNN / No] |
+| [package-name] | [4.x.x] | [5.x.x] | 1 major | [No] |
+
+### Minor/Patch Updates Available (Low risk to update)
+
+| Package | Installed | Latest | Contains security fix? |
+|---|---|---|---|
+| [package-name] | [2.3.1] | [2.3.9] | [Yes / No] |
+| [package-name] | [1.0.0] | [1.2.1] | [No] |
+
+---
+
+## 4. Dependency Graph Risk Analysis
+
+### Transitive Dependency Risk
+
+Transitive (indirect) dependencies carry risk because they are not explicitly managed. These are the highest-risk transitive dependencies in this project:
+
+| Vulnerable transitive dep | Pulled in by | Installed version | Fix available | Action |
+|---|---|---|---|---|
+| [transitive-package] | [direct-parent] | [X.Y.Z] | [Yes — upgrade [parent] to [version]] | Upgrade direct dependency [parent] |
+| [transitive-package] | [direct-parent] | [X.Y.Z] | [No] | Remove [parent] or use [alternative] |
+
+### Dependency Concentration Risk
+
+These packages are depended on by many other packages in the project — a vulnerability or deprecation would have cascading effects:
+
+| Package | Depended on by (N packages) | Actively maintained? | Risk level |
+|---|---|---|---|
+| [package-name] | [N] | [Yes / No — last commit: date] | [High / Medium] |
+| [package-name] | [N] | [Yes] | [Medium] |
+
+### Abandoned / Unmaintained Packages
+
+| Package | Last release | Last commit | Weekly downloads | Recommended alternative |
+|---|---|---|---|---|
+| [package-name] | [Date] | [Date] | [N] | [alternative-package] |
+| [package-name] | [Date] | [Date] | [N] | [Maintained fork: URL] |
+
+---
+
+## 5. Remediation Plan
+
+### 30-Day Plan
+
+**Week 1 — Critical vulnerabilities (Days 1–7)**
+
+| Action | Owner | Package | Effort | Notes |
+|---|---|---|---|---|
+| Upgrade [package] [old] → [new] | [Name] | [package-name] | [30 min] | [No API changes / check breaking changes guide: URL] |
+| Replace [package] with [alternative] | [Name] | [package-name] | [2 hours] | [No fix available — must replace] |
+| Patch override for [transitive-dep] | [Name] | [transitive-dep] | [15 min] | [Add resolutions/overrides entry in manifest] |
+
+```bash
+# Commands for Week 1 upgrades:
+
+# npm
+npm install [package]@[target-version]
+npm audit fix --force  # use with caution — may introduce breaking changes
+
+# pip
+pip install --upgrade [package]==[target-version]
+pip-audit --fix  # if using pip-audit
+
+# Go
+go get [module]@[version]
+go mod tidy
+
+# Maven
+# Update pom.xml version property, then:
+mvn versions:use-latest-releases -DallowMajorUpdates=false
+mvn dependency:resolve
+```
+
+**Week 2 — High vulnerabilities and license violations (Days 8–14)**
+
+| Action | Owner | Package | Effort | Notes |
+|---|---|---|---|---|
+| Upgrade [package] | [Name] | [package-name] | [1 hour] | |
+| Replace GPL-licensed [package] | [Name] | [package-name] | [4 hours] | [Alternative: [package]] |
+| Legal review for [package] license | Legal team | [package-name] | [Legal team SLA] | [Submit via [process]] |
+
+**Week 3 — Medium vulnerabilities and abandoned packages (Days 15–21)**
+
+| Action | Owner | Package | Effort | Notes |
+|---|---|---|---|---|
+| Upgrade [package] | [Name] | [package-name] | [30 min] | |
+| Replace abandoned [package] | [Name] | [package-name] | [2 hours] | [Maintained fork or alternative: [URL]] |
+
+**Week 4 — Process improvements (Days 22–30)**
+
+| Action | Owner | Effort | Notes |
+|---|---|---|---|
+| Enable Dependabot / Renovate for automated PRs | [Name] | [2 hours] | [Config in Section 6] |
+| Add `npm audit` / `pip-audit` to CI — fail on Critical/High | [Name] | [1 hour] | [Config in Section 6] |
+| Document license policy in CONTRIBUTING.md | [Name] | [1 hour] | [Based on policy in Section 2] |
+| Schedule next quarterly audit | [Name] | [15 min] | [Add to team calendar] |
+
+---
+
+## 6. Policy Recommendations
+
+### Automated Vulnerability Scanning in CI
+
+Add the following to your CI pipeline to catch vulnerabilities before they merge:
+
+```yaml
+# GitHub Actions — adapt for your CI platform
+dependency-audit:
+  runs-on: ubuntu-latest
+  steps:
+    - uses: actions/checkout@v3
+
+    # npm
+    - name: npm audit
+      run: npm audit --audit-level=high
+      # Fails build on High or Critical vulnerabilities
+
+    # pip
+    - name: pip-audit
+      run: |
+        pip install pip-audit
+        pip-audit --requirement requirements.txt --severity high
+
+    # Go
+    - name: govulncheck
+      run: |
+        go install golang.org/x/vuln/cmd/govulncheck@latest
+        govulncheck ./...
+```
+
+### Dependabot / Renovate Configuration
+
+```yaml
+# .github/dependabot.yml — automated dependency update PRs
+version: 2
+updates:
+  - package-ecosystem: "[npm / pip / gomod / maven]"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+      day: "monday"
+    open-pull-requests-limit: 10
+    labels:
+      - "dependencies"
+      - "automated"
+    ignore:
+      # Ignore major version bumps — review these manually
+      - dependency-name: "*"
+        update-types: ["version-update:semver-major"]
+```
+
+### License Scanning
+
+```bash
+# npm — license checker
+npx license-checker --onlyAllow 'MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC' \
+  --failOn 'GPL;AGPL;LGPL'
+
+# Python — pip-licenses
+pip install pip-licenses
+pip-licenses --allow-only="MIT;Apache Software License;BSD License;ISC License" \
+  --fail-on="GNU General Public License"
+
+# Go — go-licenses
+go install github.com/google/go-licenses@latest
+go-licenses check ./... --allowed_licenses=MIT,Apache-2.0,BSD-2-Clause,BSD-3-Clause
+```
+
+---
+
+## 7. Dependency Health Score Detail
+
+| Category | Max points | Score | Notes |
+|---|---|---|---|
+| No critical vulnerabilities | 30 | [N]/30 | −20 per critical CVE |
+| No high vulnerabilities | 20 | [N]/20 | −10 per high CVE |
+| License compliance | 20 | [N]/20 | −15 per violation |
+| No abandoned packages | 15 | [N]/15 | −5 per abandoned package |
+| Up-to-date major versions | 10 | [N]/10 | −2 per major version behind |
+| Automated scanning enabled | 5 | [N]/5 | All-or-nothing |
+| **Total** | **100** | **[Score]/100** | **[Red / Amber / Green]** |
+
+---
+
+## Quality Checks
+
+- [ ] Every Critical and High CVE has a named owner and a resolution date in the 30-day plan
+- [ ] License findings have been reviewed by legal or a named engineer with authority to accept the risk
+- [ ] Transitive dependency vulnerabilities are included — not just direct dependencies
+- [ ] Abandoned packages have a concrete replacement recommendation, not just "consider replacing"
+- [ ] CI pipeline change is included — the audit findings should be the last time these are caught manually
+- [ ] The dependency health score is calculated from actual findings, not estimated
+- [ ] Remediation plan actions are specific commands or steps, not "upgrade package X" without version targets
@@ -0,0 +1,560 @@
+---
+name: disaster-recovery-plan
+description: "Write a disaster recovery plan for a service or system — covering RPO/RTO targets, failure scenario runbooks, backup and restore procedures, DR testing cadence, and communication templates. Use when asked to write a DR plan, document failover procedures, create recovery runbooks, define RTO/RPO targets, or prepare for a disaster recovery game day. Produces a full DR document with per-scenario recovery runbooks, backup validation procedures, testing schedule, and communication templates."
+---
+
+# Disaster Recovery Plan Skill
+
+Produce a complete disaster recovery plan for a service or system — giving engineers, SREs, and on-call responders everything they need to recover from a disaster scenario in the shortest possible time. A good DR plan is tested regularly, has exact commands (not vague instructions), and makes RTO/RPO targets measurable so the team knows whether recovery succeeded.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and what it does (business function and technical role)
+- **Criticality tier** — business impact of extended downtime (e.g. Tier 1 = revenue-critical, Tier 2 = ops impact, Tier 3 = internal only)
+- **Current infrastructure setup** — cloud provider, regions/zones, deployment model (Kubernetes, ECS, VMs, serverless)
+- **RPO/RTO requirements** — Recovery Point Objective (how much data loss is acceptable) and Recovery Time Objective (how long can it be down)
+- **Backup strategy** — what is backed up, how often, where backups are stored, retention policy
+- **On-call contacts** — names and contact details for the responder chain
+
+## Output Format
+
+---
+
+# Disaster Recovery Plan: [Service Name]
+
+**Team:** [Team name] | **Tech lead:** [Name]
+**Criticality tier:** [Tier 1 / Tier 2 / Tier 3] | **Last tested:** [Date]
+**Next DR test:** [Date] | **Document owner:** [Name]
+**Last updated:** [Date] | **Review cycle:** Quarterly
+
+> **Emergency? Skip to Section 3 — Failure Scenario Runbooks.** Find the scenario that matches your situation and follow the steps exactly.
+
+---
+
+## 1. Recovery Targets
+
+| Target | Value | Rationale |
+|---|---|---|
+| RPO (Recovery Point Objective) | [X minutes/hours] | [e.g. "Last committed transaction — database replication is synchronous"] |
+| RTO (Recovery Time Objective) | [Y minutes/hours] | [e.g. "Revenue impact begins at 30 min; target recovery in 15 min"] |
+| MTTR target (non-disaster) | [Z minutes] | [Operational incidents, not DR events] |
+| Data retention (backups) | [N days/weeks] | [Compliance requirement or operational policy] |
+| Backup frequency | [Every X hours] | [RPO-driven — backup interval must be ≤ RPO] |
+
+**What these mean in practice:**
+- If a database is corrupted, we can lose at most [X minutes] of transactions before the business impact is unacceptable.
+- The service must be operational again within [Y minutes/hours] of declaring a DR event.
+- If either target cannot be met, escalate to [Engineering Manager] immediately.
+
+---
+
+## 2. Failure Scenario Inventory
+
+| Scenario | Likelihood | Impact | RTO target | RPO target | Runbook |
+|---|---|---|---|---|---|
+| Single availability zone failure | Medium | [Partial / Full outage] | [15 min] | [0 — no data loss] | Section 3.1 |
+| Full region failure | Low | Full outage | [60 min] | [5 min] | Section 3.2 |
+| Database corruption / data loss | Low | Full outage | [90 min] | [RPO value] | Section 3.3 |
+| Critical dependency outage | High | [Partial degradation] | [30 min] | [N/A] | Section 3.4 |
+| Security breach / ransomware | Very low | Full outage + investigation | [4 hours] | [Last clean backup] | Section 3.5 |
+| Accidental bulk data deletion | Low | Partial or full data loss | [60 min] | [RPO value] | Section 3.6 |
+
+---
+
+## 3. Failure Scenario Runbooks
+
+### 3.1 Single Availability Zone Failure
+
+**Trigger:** One AZ becomes unreachable — pods/instances in that zone stop responding.
+**Detection:** PagerDuty alert `[AlertName]` fires, or cloud provider status page shows AZ degradation.
+**Expected RTO:** [15 minutes] | **Expected RPO:** Zero (no data loss if multi-AZ replication is working)
+
+**Step 1 — Confirm the failure**
+```bash
+# Check pod/instance health across zones
+kubectl get pods -o wide -n [namespace] | grep -v Running
+
+# Check which nodes are affected
+kubectl get nodes -o wide | grep -v Ready
+
+# Verify cloud provider AZ status
+# AWS: https://health.aws.amazon.com/health/status
+# GCP: https://status.cloud.google.com
+```
+
+**Step 2 — Assess whether auto-recovery has occurred**
+```bash
+# If using auto-scaling, check if replacement instances launched
+kubectl get pods -n [namespace] --watch
+
+# Check deployment replica count
+kubectl get deployment [service-name] -n [namespace]
+
+# Verify load balancer health checks are passing
+[cloud provider CLI command to check target group health]
+```
+
+**Step 3 — Force rescheduling if auto-recovery stalled**
+```bash
+# Cordon the affected node so no new pods schedule on it
+kubectl cordon [node-name]
+
+# Drain the node — moves all pods to healthy nodes
+kubectl drain [node-name] --ignore-daemonsets --delete-emptydir-data
+
+# Verify pods have rescheduled successfully
+kubectl get pods -o wide -n [namespace]
+```
+
+**Step 4 — Verify service health**
+```bash
+# Smoke test key endpoints
+curl -s -o /dev/null -w "%{http_code}" https://[service-url]/health
+curl -s -o /dev/null -w "%{http_code}" https://[service-url]/[critical-endpoint]
+
+# Check error rate in monitoring
+[dashboard link or query]
+```
+
+**Recovery confirmed when:** All pods are Running, health check returns 200, error rate is at baseline.
+
+---
+
+### 3.2 Full Region Failure
+
+**Trigger:** The primary region is entirely unavailable.
+**Detection:** All service health checks failing, cloud provider status page confirms region-wide event.
+**Expected RTO:** [60 minutes] | **Expected RPO:** [5 minutes — based on cross-region replication lag]
+
+**Step 1 — Confirm regional failure (5 minutes)**
+```bash
+# Confirm the primary region is unreachable
+ping [primary-region-endpoint] || echo "Primary region unreachable"
+
+# Check replication lag on standby region database
+[command to check replica lag — e.g. for RDS: aws rds describe-db-instances --region [dr-region]]
+```
+
+**Step 2 — Declare DR event and notify (2 minutes)**
+
+Post to `#incidents`:
+```
+🔴 DR EVENT — [Service Name] — Region Failure
+Primary region: [region] — UNREACHABLE
+Activating failover to: [dr-region]
+Incident commander: [Name]
+Next update: 15 minutes
+```
+
+Page [Engineering Manager] and [CTO/VP Eng] via PagerDuty.
+
+**Step 3 — Promote DR database (10 minutes)**
+```bash
+# AWS RDS — promote read replica to primary
+aws rds promote-read-replica \
+  --db-instance-identifier [dr-replica-identifier] \
+  --region [dr-region]
+
+# Wait for promotion to complete
+aws rds wait db-instance-available \
+  --db-instance-identifier [dr-replica-identifier] \
+  --region [dr-region]
+
+# Record the new database endpoint
+aws rds describe-db-instances \
+  --db-instance-identifier [dr-replica-identifier] \
+  --region [dr-region] \
+  --query 'DBInstances[0].Endpoint.Address'
+```
+
+**Step 4 — Deploy service in DR region (20 minutes)**
+```bash
+# Update service configuration to point at DR database
+kubectl set env deployment/[service-name] \
+  DATABASE_URL=[new-dr-database-url] \
+  -n [namespace] \
+  --context [dr-region-context]
+
+# Scale up the DR deployment
+kubectl scale deployment/[service-name] --replicas=[N] \
+  -n [namespace] \
+  --context [dr-region-context]
+
+# Verify all pods are running
+kubectl get pods -n [namespace] --context [dr-region-context]
+```
+
+**Step 5 — Cut over DNS / load balancer (5 minutes)**
+```bash
+# Update DNS to point to DR region load balancer
+# AWS Route 53:
+aws route53 change-resource-record-sets \
+  --hosted-zone-id [zone-id] \
+  --change-batch file://dr-failover-dns.json
+
+# Verify DNS propagation (may take up to [TTL] seconds)
+dig [service-domain] @8.8.8.8
+```
+
+**Step 6 — Verify end-to-end**
+```bash
+# Full smoke test against DR endpoint
+curl -s https://[service-url]/health
+[run automated smoke test suite if available]
+```
+
+**Recovery confirmed when:** DNS resolves to DR region, smoke tests pass, error rate is at baseline.
+
+**Post-failover actions (not urgent — after service is stable):**
+- Do not fail back to primary until root cause is confirmed resolved
+- Document data loss window (check replication lag at time of failure)
+- Begin post-incident review — see [incident-postmortem skill]
+
+---
+
+### 3.3 Database Corruption or Data Loss
+
+**Trigger:** Data in the database is corrupted, deleted, or otherwise incorrect due to a software bug, operator error, or hardware fault.
+**Detection:** Application errors referencing missing/invalid data, monitoring alerts on query error rate, user reports.
+**Expected RTO:** [90 minutes] | **Expected RPO:** [Backup interval — e.g. 1 hour]
+
+**Step 1 — Stop the bleeding immediately**
+```bash
+# Put the service into maintenance mode to prevent further writes to corrupted data
+[command to enable maintenance mode — e.g. kubectl set env deployment/[name] MAINTENANCE_MODE=true]
+
+# Or: scale down the service to zero to prevent writes
+kubectl scale deployment/[service-name] --replicas=0 -n [namespace]
+```
+
+**Step 2 — Assess scope of corruption**
+```bash
+# Identify which tables/records are affected
+[SQL query to check data integrity — e.g.]
+# psql $DATABASE_URL -c "SELECT COUNT(*) FROM [table] WHERE [integrity check condition]"
+
+# Determine when corruption started (cross-reference with deploy times and error logs)
+[log query to find earliest error — e.g. in Datadog:]
+# service:[service-name] status:error "[corruption error message]" | sort by timestamp asc
+```
+
+**Step 3 — Identify the correct restore point**
+```bash
+# List available backups
+[command to list backups — e.g. for RDS:]
+aws rds describe-db-snapshots \
+  --db-instance-identifier [db-identifier] \
+  --query 'DBSnapshots[*].[SnapshotCreateTime,DBSnapshotIdentifier]' \
+  --output table
+
+# Choose the most recent backup BEFORE corruption started
+# Record the chosen snapshot ID: [snapshot-id]
+```
+
+**Step 4 — Restore from backup**
+```bash
+# Restore to a NEW database instance (never overwrite production directly)
+aws rds restore-db-instance-from-db-snapshot \
+  --db-instance-identifier [service-name]-restored-[date] \
+  --db-snapshot-identifier [snapshot-id] \
+  --region [region]
+
+# Wait for restore to complete
+aws rds wait db-instance-available \
+  --db-instance-identifier [service-name]-restored-[date]
+
+# Get the restored instance endpoint
+aws rds describe-db-instances \
+  --db-instance-identifier [service-name]-restored-[date] \
+  --query 'DBInstances[0].Endpoint.Address'
+```
+
+**Step 5 — Validate restored data**
+```bash
+# Connect to restored database and verify integrity
+psql [restored-db-endpoint] -U [user] -d [database] -c "[data integrity query]"
+
+# Confirm record counts match expectations
+psql [restored-db-endpoint] -U [user] -d [database] -c "SELECT COUNT(*) FROM [critical-table]"
+```
+
+**Step 6 — Point service at restored database**
+```bash
+kubectl set env deployment/[service-name] \
+  DATABASE_URL=postgres://[user]:[pass]@[restored-endpoint]/[db] \
+  -n [namespace]
+
+kubectl scale deployment/[service-name] --replicas=[N] -n [namespace]
+```
+
+**Recovery confirmed when:** Service is running against restored database, data integrity checks pass, error rate is at baseline.
+
+---
+
+### 3.4 Critical Dependency Outage
+
+**Trigger:** A service that [service name] depends on is unavailable or degraded.
+**Detection:** Increased error rate or latency on endpoints that call [dependency], alerts from dependency owner.
+**Expected RTO:** Depends on dependency — [30 minutes for mitigation, resolution depends on dependency owner]
+
+**Dependency map:**
+
+| Dependency | Criticality | Degraded behaviour | Mitigation |
+|---|---|---|---|
+| [Database] | Critical — all writes fail | Full outage | Activate DR database (Section 3.3) |
+| [Cache — Redis] | High — latency increases | Performance degradation | Bypass cache, serve from DB |
+| [Auth service] | Critical — auth fails | All authenticated endpoints fail | Return cached tokens (if implemented) |
+| [Message queue] | Medium — async processing delays | Writes succeed, async jobs queue | Queue backlog — see on-call runbook |
+| [External API — name] | Low — feature X unavailable | Graceful degradation | Feature flag to disable feature X |
+
+**Mitigation steps:**
+```bash
+# Enable circuit breaker / fallback for [dependency] if implemented
+kubectl set env deployment/[service-name] [DEPENDENCY]_CIRCUIT_BREAKER=open -n [namespace]
+
+# Enable feature flag to disable [dependency-backed feature]
+[feature flag CLI command or dashboard link]
+
+# Check if dependency has a status page
+# [Dependency status URL]
+```
+
+**Escalation:** Contact [dependency] on-call via [PagerDuty / Slack `#[channel]`]. Share your service's error rate and the time dependency errors started.
+
+---
+
+### 3.5 Security Breach or Ransomware
+
+**Trigger:** Evidence of unauthorized access, data exfiltration, or encryption of service data.
+**Detection:** Security tooling alert, unusual access patterns, user reports of data exposure.
+**Expected RTO:** [4+ hours — prioritise containment over speed] | **Expected RPO:** [Last verified clean backup]
+
+**Step 1 — Isolate immediately**
+```bash
+# Take the service offline — do not attempt to recover while breach is active
+kubectl scale deployment/[service-name] --replicas=0 -n [namespace]
+
+# Revoke all API keys and service account credentials immediately
+[command to rotate secrets — e.g. via Vault or cloud provider]
+
+# Block all external access at network level
+[firewall/security group command to deny all inbound traffic]
+```
+
+**Step 2 — Notify security team immediately**
+Page [Security lead] via PagerDuty. Do NOT attempt to remediate without security team involvement.
+
+Post to `#security-incidents` (private channel, not `#incidents`):
+```
+🔴 SECURITY INCIDENT — [Service Name]
+Time detected: [Time]
+Evidence: [One sentence — what was observed]
+Actions taken: Service isolated, credentials revoked
+Awaiting: Security team guidance
+```
+
+**Step 3 — Preserve evidence**
+```bash
+# Export current logs before any remediation
+[log export command — preserve evidence for forensics]
+
+# Snapshot the current state of all infrastructure
+[snapshot/image command]
+```
+
+**Steps 4+ — Follow security team guidance.** Do not restore from backup until security team confirms the attack vector is closed.
+
+---
+
+### 3.6 Accidental Bulk Data Deletion
+
+**Trigger:** An operator, script, or application bug has deleted records in bulk.
+**Detection:** Sudden drop in record counts, user reports of missing data, application errors.
+**Expected RTO:** [60 minutes] | **Expected RPO:** [Backup interval]
+
+```bash
+# Step 1 — Stop further writes immediately
+kubectl scale deployment/[service-name] --replicas=0 -n [namespace]
+
+# Step 2 — Determine what was deleted and when
+psql $DATABASE_URL -c "
+  SELECT schemaname, tablename,
+         n_dead_tup, last_autovacuum
+  FROM pg_stat_user_tables
+  ORDER BY n_dead_tup DESC LIMIT 10;
+"
+
+# Step 3 — Check if deletion is recoverable via MVCC (PostgreSQL)
+# Records may still be recoverable if VACUUM has not run
+psql $DATABASE_URL -c "
+  SELECT * FROM [table]
+  WHERE xmax != 0  -- recently deleted rows
+  LIMIT 100;
+"
+
+# Step 4 — If not recoverable via MVCC, restore from backup
+# Follow Section 3.3 (Database Corruption runbook) from Step 3 onward
+```
+
+---
+
+## 4. Backup and Restore Procedures
+
+### Backup Configuration
+
+| Data store | Backup type | Frequency | Retention | Location |
+|---|---|---|---|---|
+| [Primary database] | Automated snapshots | Every [N] hours | [N] days | [S3 bucket / cloud storage path] |
+| [Primary database] | Transaction log backups | Continuous | [N] days | [Location] |
+| [Secondary store — e.g. Redis] | RDB dump | Daily | [N] days | [Location] |
+| [Blob/object storage] | Cross-region replication | Continuous | [N] days | [DR region bucket] |
+| [Config / secrets] | Terraform state + Vault backup | On change | Indefinite | [Location] |
+
+### Backup Validation (Run Weekly)
+
+```bash
+# Test restore of latest database backup to a throwaway instance
+aws rds restore-db-instance-from-db-snapshot \
+  --db-instance-identifier [service-name]-backup-test-$(date +%Y%m%d) \
+  --db-snapshot-identifier $(aws rds describe-db-snapshots \
+    --db-instance-identifier [db-id] \
+    --query 'sort_by(DBSnapshots, &SnapshotCreateTime)[-1].DBSnapshotIdentifier' \
+    --output text)
+
+# Wait for restore, then run integrity checks
+psql [test-instance-endpoint] -c "[integrity check query]"
+
+# Confirm row counts match recent production values (allow ≤ RPO difference)
+psql [test-instance-endpoint] -c "SELECT COUNT(*) FROM [critical-table]"
+
+# Destroy the test instance
+aws rds delete-db-instance \
+  --db-instance-identifier [service-name]-backup-test-$(date +%Y%m%d) \
+  --skip-final-snapshot
+```
+
+---
+
+## 5. DR Testing Cadence
+
+Regular testing is mandatory. An untested DR plan is not a DR plan.
+
+| Test type | Frequency | Who runs it | Pass criteria |
+|---|---|---|---|
+| Backup restore validation | Weekly (automated) | On-call rotation | Restore completes, integrity checks pass |
+| Zone failover drill | Monthly | Engineering team | RTO target met, zero data loss |
+| Region failover drill | Quarterly | Engineering + SRE | RTO/RPO targets met |
+| Full DR game day | Annually | Engineering + stakeholders | All scenarios exercised, gaps documented |
+| Chaos engineering (infra failures) | Weekly (automated) | Chaos engineering tooling | Service degrades gracefully, recovers automatically |
+
+### Game Day Procedure
+
+1. **Pre-game day (1 week before):** Notify all stakeholders, freeze production changes for the day, prepare DR environment.
+2. **Scope definition:** Choose 2–3 scenarios from Section 2. Document expected outcomes before the test.
+3. **Execute:** One person acts as incident commander, others execute runbook steps while another observes and times.
+4. **Measure:** Record actual RTO and RPO against targets for each scenario.
+5. **Debrief (same day):** Document gaps, runbook inaccuracies, and automation opportunities.
+6. **Action items:** File tickets for every gap found. Priority: P1 items must be fixed before next game day.
+
+---
+
+## 6. Communication Plan
+
+### Internal Communication During DR Event
+
+**Incident commander responsibilities:**
+- Declare the DR event and open the incident channel
+- Post updates every 15 minutes minimum
+- Make the call to fail over (do not let the team decide by committee)
+- Notify business stakeholders of expected recovery time
+
+**Notify these people at DR event start:**
+
+| Role | Name | Contact | When to notify |
+|---|---|---|---|
+| Engineering manager | [Name] | [Slack / Phone] | Immediately |
+| CTO / VP Engineering | [Name] | [Phone] | Tier 1 services: immediately |
+| Customer success lead | [Name] | [Slack] | If customer-facing impact |
+| Security lead | [Name] | [Slack / PagerDuty] | If breach suspected |
+| Legal / compliance | [Name] | [Email / Phone] | If data loss involves PII |
+
+### Communication Templates
+
+**DR event declared:**
+```
+🔴 DR EVENT — [Service Name]
+Time: [HH:MM UTC]
+Scenario: [Zone failure / Region failure / Data loss / etc.]
+Impact: [Who is affected and how]
+RTO target: [X minutes]
+Incident commander: [Name]
+War room: [Slack channel / call link]
+Next update: [Time + 15 min]
+```
+
+**Status update (every 15 minutes):**
+```
+🔴 DR UPDATE — [Service Name] — [HH:MM UTC]
+Status: [Investigating / Executing recovery / Verifying]
+Progress: [One sentence on current step]
+Blockers: [Any — or "None"]
+Updated RTO estimate: [Time]
+Next update: [Time + 15 min]
+```
+
+**Recovery confirmed:**
+```
+✅ DR RESOLVED — [Service Name] — [HH:MM UTC]
+Total downtime: [X minutes]
+Data loss: [None / X minutes of transactions]
+RTO target: [X min] — Actual: [Y min] — [MET / MISSED]
+RPO target: [X min] — Actual: [Y min] — [MET / MISSED]
+Root cause: [One sentence]
+Post-incident review: [Scheduled for / Link when created]
+```
+
+---
+
+## 7. DR Readiness Checklist
+
+Run this checklist quarterly and before any major infrastructure change:
+
+**Backups:**
+- [ ] Automated backups are running and alerts fire if they fail
+- [ ] Most recent backup restore was tested within the last 7 days
+- [ ] Backup retention meets RPO and compliance requirements
+- [ ] Backups are stored in a separate region / account from primary
+
+**Failover infrastructure:**
+- [ ] DR region / environment exists and is provisioned (not just documented)
+- [ ] DNS failover procedure is documented with exact commands
+- [ ] DR database replica is current (replication lag is within RPO)
+- [ ] Service can be deployed in DR region with a single command or automated pipeline
+
+**Runbooks:**
+- [ ] All runbooks in Section 3 have been tested within the last quarter
+- [ ] Runbook commands have been verified against current infrastructure (no stale references)
+- [ ] Contact list is current (no departed employees)
+
+**Access:**
+- [ ] On-call engineers have access to DR region console / CLI
+- [ ] Service account credentials for DR region are provisioned and tested
+- [ ] Break-glass accounts exist for emergency access if SSO is unavailable
+
+**Monitoring:**
+- [ ] Monitoring exists in DR region (not just primary)
+- [ ] Alerts fire correctly when DR environment has issues
+
+---
+
+## Quality Checks
+
+- [ ] RPO and RTO targets are specific numbers, not ranges, and are agreed with the business
+- [ ] Every command in every runbook has been run by a human in the last quarter — not copied from documentation untested
+- [ ] DR database exists in the DR region and replication lag is monitored
+- [ ] Backup restore has been tested end-to-end within the last 7 days
+- [ ] The game day schedule is on the team calendar — not just documented here
+- [ ] Contact list contains current phone numbers, not just Slack handles (Slack may be down during a DR event)
+- [ ] Security breach runbook (3.5) explicitly names the security team contact and does not attempt self-remediation
+- [ ] All thresholds (RTO/RPO) are visible in the monitoring dashboard so actual vs. target is measurable in real time
@@ -0,0 +1,338 @@
+---
+name: engineering-hiring-rubric
+description: "Build an engineering hiring rubric and technical interview scorecard for evaluating software engineers at a specific level. Use when asked to create an interview rubric, design a hiring process, build a technical scorecard, or standardize engineer evaluation. Produces a full interview scorecard, behavioral question bank, technical question set with evaluation criteria, system design rubric, and debrief agenda."
+---
+
+# Engineering Hiring Rubric
+
+Produce a complete hiring rubric and interview scorecard for evaluating software engineers at a specific role and level. The rubric must be specific enough that two interviewers who have never compared notes will score the same candidate within one level of each other. That requires: explicit behavioral anchors (what does "Strong Hire" look like vs. "Hire" for each competency), calibrated technical questions with written evaluation criteria, and a structured debrief format that surfaces signal rather than recency bias. Include calibration notes to help interviewers recognize and counter common evaluation biases.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Role** — backend, frontend, fullstack, SRE/platform, data, ML, or mobile engineer
+- **Level** — junior (L3/IC2), mid (L4/IC3), senior (L5/IC4), or staff (L6/IC5); clarify the company's level naming if different
+- **Team context** — what the team builds, team size, and what problems this hire will work on in the first year
+- **Tech stack** — primary languages and frameworks for the technical questions; list the stack explicitly
+- **Interview format** — which rounds are used (phone screen, coding, system design, behavioral, take-home); if not specified, produce a recommended format
+
+## Output Format
+
+---
+
+# Engineering Hiring Rubric: [Role] — [Level]
+
+**Role:** [e.g., Senior Backend Engineer]
+**Level equivalent:** [e.g., L5 / IC4 / Senior]
+**Team:** [Team name and one-sentence description of what they build]
+**Tech stack:** [Languages and frameworks]
+**Interview loop:** [List the rounds in order]
+
+---
+
+## 1. Role Definition and Level Expectations
+
+### What This Role Does
+
+[2–3 sentences describing the scope of work: what systems they'll own, what problems they'll solve, and who they'll work with. Make this specific to the team context provided.]
+
+### Level Bar
+
+Define the minimum bar for a Hire recommendation at this level. This is not the ideal candidate description — it is the floor.
+
+| Dimension | [Level] Floor | One Level Below (No Hire) | One Level Above (Stretch) |
+|-----------|--------------|---------------------------|---------------------------|
+| Technical scope | [e.g., "Owns a service or major feature area end-to-end with minimal guidance"] | [e.g., "Completes well-defined tasks; needs guidance on scope and approach"] | [e.g., "Leads cross-team technical initiatives; sets technical direction"] |
+| Problem solving | [e.g., "Breaks ambiguous problems into concrete sub-problems independently"] | [e.g., "Solves defined problems well; struggles with ambiguity"] | [e.g., "Identifies problems others miss; structures organization-level technical challenges"] |
+| Code quality | [e.g., "Writes production-ready code; anticipates edge cases; reviewable without significant rework"] | [e.g., "Writes working code that requires significant review feedback"] | [e.g., "Sets code quality standards; designs reusable abstractions adopted by others"] |
+| Communication | [e.g., "Communicates technical decisions clearly to peers and stakeholders"] | [e.g., "Communicates well with direct team; struggles with cross-team or stakeholder comms"] | [e.g., "Drives technical consensus across teams; writes documents others reference"] |
+| Ownership | [e.g., "Sees work to production; monitors after deploy; follows up on issues proactively"] | [e.g., "Delivers assigned work; escalates issues but doesn't drive them to resolution"] | [e.g., "Owns outcomes across teams; improves team processes and systems beyond their own work"] |
+
+---
+
+## 2. Interview Loop Structure
+
+| Round | Format | Duration | Interviewer | Competencies Assessed |
+|-------|--------|----------|-------------|----------------------|
+| Phone screen | Video call, technical questions | 45 min | [Hiring manager or senior engineer] | Problem solving, communication, basic technical depth |
+| Coding interview 1 | Live coding — [platform] | 60 min | [Engineer] | Coding, data structures, code quality |
+| Coding interview 2 | Live coding — [platform] | 60 min | [Engineer] | Algorithms, debugging, code quality |
+| System design | Whiteboard / shared doc | 60 min | [Senior/Staff engineer] | System design, scalability, technical communication |
+| Behavioral | Structured interview | 45 min | [Hiring manager] | Ownership, collaboration, growth mindset |
+| [Optional] Take-home | Asynchronous project | [X hours] | [Reviewer] | Code quality, thoroughness, real-world problem solving |
+
+**Interview coverage matrix:** Each competency dimension must be assessed by at least 2 independent interviewers.
+
+| Competency | Phone Screen | Coding 1 | Coding 2 | System Design | Behavioral |
+|-----------|-------------|---------|---------|--------------|-----------|
+| Coding | ○ | ● | ● | ○ | |
+| System design | ○ | | | ● | |
+| Problem solving | ● | ● | ● | ● | |
+| Code quality | | ● | ● | | |
+| Communication | ● | ● | ● | ● | ● |
+| Ownership | ○ | | | ○ | ● |
+| Debugging | | ● | ● | | |
+
+● = Primary signal  ○ = Secondary signal
+
+---
+
+## 3. Coding Interview Guide
+
+### Question Selection
+
+Choose 1–2 problems per coding round. Problems should be solvable in 30–40 minutes with the remaining time for discussion and follow-ups. Prefer problems with multiple solution tiers so you can see how far candidates take their thinking.
+
+### Problem Template
+
+**Problem: [Title]**
+
+*Prompt (read to candidate):*
+> [Problem statement — be specific. Include constraints (input size, value ranges). Avoid ambiguity that tests problem-reading rather than problem-solving.]
+
+*Example:*
+> Given a list of integers representing stock prices at each minute of a trading day, return the maximum profit you could achieve by making exactly one buy and one sell. You may not sell before you buy.
+
+**Clarifying questions a strong candidate will ask:**
+- [e.g., "Can the list be empty?" / "Are all values positive?" / "Can profit be negative — i.e., should we return 0 if no profit is possible?"]
+
+**Solution tiers:**
+
+| Tier | Approach | Time Complexity | Space Complexity | Signals |
+|------|----------|-----------------|-----------------|---------|
+| Baseline | [Brute force — O(n²) nested loop] | O(n²) | O(1) | Can solve the problem; understands correctness |
+| Expected | [Single pass, tracking min price seen so far] | O(n) | O(1) | Strong problem solver; explains tradeoff |
+| Strong | [Generalizes to k transactions, or extends to cooldown variant without prompting] | O(n) | O(1) | Staff-level generalization thinking |
+
+**Follow-up questions:**
+- [e.g., "What if you could make at most k trades?"]
+- [e.g., "How would you test this function? Write me 3 test cases."]
+- [e.g., "Walk me through your code as if you're explaining it in a code review."]
+
+**Evaluation rubric for this problem:**
+
+| Signal | Strong Hire | Hire | No Hire |
+|--------|------------|------|---------|
+| Problem comprehension | Asks 1–2 clarifying questions immediately; identifies edge cases before coding | Understands the problem after 1 prompt; misses 1–2 edge cases | Misunderstands the problem or requires repeated clarification |
+| Solution quality | O(n) solution; clean code; handles all edge cases | O(n) with hints; code is readable but has minor issues | O(n²) with hints, or correct solution with significant issues |
+| Code quality | Well-named variables; logical structure; would pass code review | Functional but verbose or inconsistently named | Hard to follow; would require significant review feedback |
+| Communication | Narrates thinking throughout; explains complexity; self-corrects | Explains solution when asked; answers follow-ups well | Silent during coding; unable to explain their approach |
+| Follow-ups | Extends solution confidently; identifies further improvements | Handles follow-ups with moderate prompting | Unable to extend or explain tradeoffs |
+
+---
+
+## 4. System Design Interview Guide
+
+### [Level]-Appropriate Design Scope
+
+At [Level], expect the candidate to:
+- [e.g., Senior: "Design a complete system with capacity estimates, component breakdown, and discussion of failure modes"]
+- [e.g., Mid: "Design the core components of a system; may need prompting on scalability and failure handling"]
+- [e.g., Junior: "Design a simple client-server system; focus on clarity of thinking over complete distributed systems knowledge"]
+
+### Sample Design Question
+
+**Question:** "Design [a URL shortener / a rate limiter / a notification service / a ride-matching system — choose one relevant to the team's domain]."
+
+**Evaluation dimensions:**
+
+| Dimension | What to assess | Strong Hire | Hire | No Hire |
+|-----------|---------------|------------|------|---------|
+| Requirements clarification | Does the candidate ask before designing? | Asks scope, scale, SLA, and key use cases before drawing anything | Asks some questions; may miss scale or SLA | Starts designing immediately without clarifying |
+| High-level design | Can they describe the major components? | Clear component breakdown with justified choices; covers data flow | Reasonable breakdown; may overcomplicate or undercomplicate | Missing key components or cannot explain data flow |
+| Data model | Can they design a schema or data structure for the system? | Models the core entities with normalization/denormalization tradeoffs discussed | Reasonable schema; may miss indexing or partitioning needs | Cannot model the data or produces clearly wrong schema |
+| Scalability | Can they identify and address bottlenecks? | Identifies bottlenecks proactively; proposes horizontal scaling, caching, or sharding as appropriate | Discusses scaling when prompted; reasonable solutions | Cannot identify bottlenecks or proposes solutions that don't match the scale |
+| Failure handling | Do they think about what happens when things break? | Proactively discusses failure modes: single points of failure, retry logic, idempotency | Discusses failure when prompted; identifies some failure modes | Does not think about failure; assumes happy path |
+| Communication | Is the design explained clearly? | Could run this meeting with a team of engineers at a real company | Clear enough to follow; some gaps in explanation | Difficult to follow; interviewer cannot understand the design |
+
+### Design Probing Questions
+
+Use these to probe depth after the candidate presents their design:
+- "Walk me through what happens when a write request comes in at peak load — 10,000 requests per second."
+- "Your primary database just failed. What happens to the system?"
+- "You estimated X QPS. How would your design change if it needed to handle 100× that?"
+- "Where is the first place this system would fall over under load?"
+- "How would you monitor this in production? What would your on-call runbook look like?"
+
+---
+
+## 5. Behavioral Interview Question Bank
+
+Map every question to a competency. Ask 4–6 questions per behavioral round using STAR format (Situation, Task, Action, Result). Do not ask leading questions.
+
+### Competency: Ownership and Delivery
+
+1. "Tell me about a time you owned something end-to-end — from design through production monitoring. What did you do when something went wrong after launch?"
+   - *Strong signal:* Describes proactive monitoring setup, a specific incident they caught themselves, and what they changed
+   - *Weak signal:* Describes writing the code and handing off; no discussion of production behavior
+
+2. "Describe a project that was significantly delayed or failed. What was your role, and what did you take responsibility for?"
+   - *Strong signal:* Direct ownership of their contribution to the failure; specific changes to how they work
+   - *Weak signal:* Attributes all delay to external factors; no reflection on their own actions
+
+### Competency: Technical Judgment
+
+3. "Tell me about a significant technical decision you made. What options did you consider, and how did you decide?"
+   - *Strong signal:* Named alternatives with clear tradeoffs; explains who they consulted; reflects on whether they'd decide the same way today
+   - *Weak signal:* "I knew X was the right answer" without describing the decision process
+
+4. "Describe a time you had to push back on a technical direction — either from management or from peers. What happened?"
+   - *Strong signal:* Evidence-based disagreement; constructive communication; willing to commit once decision was made even if they lost the argument
+   - *Weak signal:* Either never pushed back or pushed back emotionally without evidence
+
+### Competency: Collaboration and Communication
+
+5. "Tell me about a time you had to explain a complex technical concept to a non-technical stakeholder. How did you approach it?"
+   - *Strong signal:* Used analogy or simplified model; confirmed understanding; adapted to the audience
+   - *Weak signal:* "I explained it technically and told them to trust me"
+
+6. "Describe a situation where you and a peer strongly disagreed on an approach. How did it resolve?"
+   - *Strong signal:* Sought a third opinion or data; focused on the right outcome, not being right; maintained relationship
+   - *Weak signal:* Escalated immediately or capitulated without engaging
+
+### Competency: Growth and Learning
+
+7. "What is a significant technical mistake you made in the last two years? What did you learn from it?"
+   - *Strong signal:* Specific mistake, clear causal analysis, concrete behavioral change afterward
+   - *Weak signal:* Cannot name a specific mistake; describes a minor issue to avoid vulnerability
+
+8. "How do you stay current in [relevant technical area]? Give me a specific example of something you learned recently and applied."
+   - *Strong signal:* Named sources, applied learning in a specific project with a concrete outcome
+   - *Weak signal:* "I read blogs" with no specifics; no applied example
+
+---
+
+## 6. Full Interview Scorecard
+
+Complete one scorecard per interview round. Collect all scorecards before the debrief.
+
+```
+INTERVIEW SCORECARD
+===================
+Candidate:         ______________________
+Interviewer:       ______________________
+Round:             ______________________
+Date:              ______________________
+Interview format:  ______________________
+
+COMPETENCY RATINGS
+Rate each dimension independently. Do not average.
+Scale: 1 = Strong No Hire | 2 = No Hire | 3 = Hire | 4 = Strong Hire
+
+                          1    2    3    4    Notes
+Coding / Technical skill  [ ]  [ ]  [ ]  [ ]  ___________________________
+Problem solving           [ ]  [ ]  [ ]  [ ]  ___________________________
+System design             [ ]  [ ]  [ ]  [ ]  ___________________________  
+Code quality              [ ]  [ ]  [ ]  [ ]  ___________________________
+Debugging                 [ ]  [ ]  [ ]  [ ]  ___________________________
+Communication             [ ]  [ ]  [ ]  [ ]  ___________________________
+Ownership                 [ ]  [ ]  [ ]  [ ]  ___________________________
+Collaboration             [ ]  [ ]  [ ]  [ ]  ___________________________
+
+SPECIFIC EVIDENCE
+What did the candidate do or say that drove your rating?
+(Required — write observable behaviors, not impressions)
+
+Strongest signal (positive):
+___________________________________________________________________________
+
+Strongest concern or gap:
+___________________________________________________________________________
+
+OVERALL RECOMMENDATION
+[ ] Strong Hire    [ ] Hire    [ ] No Hire    [ ] Strong No Hire
+
+OVERALL RECOMMENDATION RATIONALE
+(Required — 3–5 sentences minimum. State your recommendation, the evidence
+that supports it, and the specific gap or risk if not a Strong Hire)
+___________________________________________________________________________
+___________________________________________________________________________
+___________________________________________________________________________
+
+Level signal: This candidate demonstrated [ L_ / L_ ] level behaviors.
+
+SHOULD INTERVIEWERS DISCUSS BEFORE DEBRIEF? 
+[ ] No — I have a clear independent signal
+[ ] Yes — I need context on [specific area] to complete my assessment
+```
+
+---
+
+## 7. Hiring Recommendation Framework
+
+| Recommendation | Meaning | When to use |
+|---------------|---------|-------------|
+| **Strong Hire** | Confident the candidate will exceed the level bar and be a high performer on the team | Evidence across 3+ competencies at above-bar level; no significant concerns |
+| **Hire** | Confident the candidate meets the level bar; will perform well | Meets bar on all must-have competencies; may have 1 area to develop |
+| **No Hire** | Does not meet the level bar | Below bar on 1+ must-have competency, or gap too large to close quickly |
+| **Strong No Hire** | Clear mismatch — well below the bar, or a specific disqualifying signal | Significant gaps across multiple competencies, or a values/behavior concern |
+
+**Must-hire competencies for [Role] at [Level]:** [List 3–4 competencies where a No Hire score on any one of them means the overall recommendation must be No Hire, regardless of performance elsewhere. Example: "Coding and System Design are must-hire competencies for a Senior Backend Engineer. Strong performance on Behavioral dimensions cannot compensate for a No Hire on Coding."]
+
+**Debrief rule:** A Strong Hire can override one No Hire only if: (a) the No Hire is not on a must-hire competency, and (b) the Strong Hire interviewer can articulate why the concern is not disqualifying. A Strong No Hire cannot be overridden — escalate to hiring manager.
+
+---
+
+## 8. Debrief Agenda
+
+Run the debrief before scorecards are shared verbally. Everyone submits a written scorecard first.
+
+```
+DEBRIEF AGENDA — [Candidate Name]
+Duration: 45 minutes
+Facilitator: [Hiring Manager]
+
+0:00 – 0:05  SCORECARD REVIEW
+  Each interviewer states their overall recommendation only (no rationale yet).
+  Facilitator notes alignment and disagreements on whiteboard/doc.
+
+0:05 – 0:15  EVIDENCE ROUND
+  Go around the table. Each interviewer shares:
+    - Their strongest positive signal (observable behavior, not impression)
+    - Their biggest concern (observable behavior, not impression)
+  No discussion yet — just evidence gathering.
+
+0:15 – 0:30  DISCUSS DISAGREEMENTS
+  Address only the competency dimensions where interviewers disagree.
+  Anchor discussion on: "What did you observe?" not "What do you think?"
+  If interviewers assessed different competencies, disagreement may reflect
+  insufficient signal — note this.
+
+0:30 – 0:40  DECISION
+  Reach a decision on overall recommendation.
+  If consensus: state the recommendation and rationale.
+  If not consensus: hiring manager makes the call and states why.
+
+0:40 – 0:45  PROCESS NOTES
+  - Were any questions unclear or hard to compare across candidates?
+  - Any bias signals observed during the debrief? (see Section 9)
+  - Feedback to improve the process for next time.
+```
+
+---
+
+## 9. Calibration and Bias Reduction Notes
+
+Brief every interviewer on these before they conduct their first interview for this role.
+
+| Bias | How it manifests | Counter-measure |
+|------|-----------------|-----------------|
+| Halo effect | Strong performance in round 1 colors ratings in round 2 | Submit scorecard before reading others; rate each competency independently |
+| Similarity bias | "I liked them" correlates with "they think like me" | Require observable evidence for every rating; check: "Is this a signal about their ability or their similarity to me?" |
+| Recency bias | Final impression dominates overall rating | Take notes during the interview; write evidence immediately after; debrief uses written evidence, not memory |
+| Expectation anchoring | First interviewer's opinion anchors all others | No verbal discussion between interviewers before debrief; written scorecards submitted before debrief starts |
+| Culture fit as cover | "Not a culture fit" without specific behavioral evidence | "Culture fit" is not a valid dimension on this scorecard; use Collaboration and Communication with evidence |
+| Credential bias | Degree or previous employer overweights rating | Do not list educational background in pre-interview briefing documents; focus on demonstrated behaviors |
+| Confidence ≠ Competence | Articulate candidates rated higher regardless of correctness | Grade the answer quality, not the delivery style; use written rubrics per question |
+
+---
+
+## Quality Checks
+
+- [ ] Level bar table defines a concrete floor for the level — not aspirational traits — with a comparison to one level below and above
+- [ ] Every behavioral question includes explicit Strong Hire and Weak/No Hire signal descriptions — not just the question text
+- [ ] Coding problem(s) include solution tiers with time and space complexity, plus a per-question rubric with behavioral anchors
+- [ ] System design rubric evaluates at minimum: requirements clarification, component design, data model, scalability, and failure handling
+- [ ] Scorecard uses observable behavior fields ("What did the candidate do or say") — not impression fields
+- [ ] Must-hire competencies are explicitly named for the role and level
+- [ ] Debrief agenda enforces written scorecard submission before verbal discussion to prevent anchoring
@@ -0,0 +1,164 @@
+---
+name: engineering-weekly-report
+description: "Write a weekly engineering status report for a team, service, or initiative. Use when asked to write a team update, weekly engineering report, sprint status email, or standing team communication to stakeholders. Produces a concise, scannable weekly report covering shipping progress, metrics, decisions, blockers, and next-week priorities."
+---
+
+# Engineering Weekly Report
+
+Produce a weekly engineering status report that a team can send to stakeholders, their engineering manager, and the team itself. The format is fixed week-over-week so readers know exactly where to look — shipping progress at the top, decisions in the middle, risks and next steps at the bottom. The report must be readable in under 2 minutes. Avoid prose walls: use bullet points, status tags, and short tables. If metrics are not provided, leave the metrics section with [data needed] markers rather than fabricating numbers.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Team name and report period** — team name plus week number or date range (e.g., "Platform Team, Week 21, May 12–16")
+- **Work items shipped this week** — what was completed and released or merged
+- **Work items in progress** — what is actively being worked on, with rough percent-complete if known
+- **Blocked items** — what is blocked, who owns the block, and what is needed to unblock
+- **Key decisions made** — any architecture, process, or priority decisions made this week
+- **Decisions needed next week** — any decisions that need to be made soon and who needs to make them
+- **Risks and escalations** — anything that threatens next week's commitments or needs leadership visibility
+- **Next week's top priorities** — the 3–5 things the team plans to accomplish next week
+
+Optional but useful:
+- **Key metrics** — reliability (error rate, p99 latency), velocity (story points completed), or other health indicators
+- **Team health notes** — PTO, new joins, attrition, morale signals worth noting
+- **Sprint or iteration number** — if the team runs sprints
+
+## Output Format
+
+---
+
+# Engineering Weekly Report — [Team Name]
+**Week:** [Week Number] | [Date Range, e.g., May 12–16, 2025]
+**Author:** [Name or Team Lead]
+**Distribution:** [e.g., Eng leadership, Product, Team]
+
+---
+
+## Shipping Progress
+
+### Shipped This Week
+
+| Item | Description | Impact |
+|------|-------------|--------|
+| [Feature / Fix / Infra change] | [One-line description] | [Who benefits / what it unblocks] |
+| [Feature / Fix / Infra change] | [One-line description] | [Who benefits / what it unblocks] |
+| [Feature / Fix / Infra change] | [One-line description] | [Who benefits / what it unblocks] |
+
+### In Progress
+
+| Item | Owner | Status | Target Ship |
+|------|-------|--------|-------------|
+| [Work item] | [Name] | [~40% / On Track / At Risk] | [Date or Sprint] |
+| [Work item] | [Name] | [~70% / On Track / At Risk] | [Date or Sprint] |
+| [Work item] | [Name] | [~20% / On Track / At Risk] | [Date or Sprint] |
+
+### Blocked
+
+| Item | Blocked Since | Blocker Description | Owner | Needed To Unblock |
+|------|--------------|--------------------|----|-------------------|
+| [Work item] | [Date] | [What is blocking progress] | [Name] | [Specific ask — decision, resource, dependency] |
+
+If no items are blocked: *No active blockers.*
+
+---
+
+## Key Metrics
+
+*Metrics reported as of [Date]. Prior week in parentheses.*
+
+| Metric | This Week | Last Week | Trend | Target |
+|--------|-----------|-----------|-------|--------|
+| Error rate (5xx) | [X%] | [X%] | [↑ / ↓ / →] | < [threshold] |
+| p99 latency | [Xms] | [Xms] | [↑ / ↓ / →] | < [threshold] |
+| Deployment frequency | [X deploys] | [X deploys] | [↑ / ↓ / →] | [target] |
+| Story points completed | [X] | [X] | [↑ / ↓ / →] | [sprint target] |
+| On-call page volume | [X pages] | [X pages] | [↑ / ↓ / →] | < [threshold] |
+
+**Metrics notes:** [Any context that makes the numbers meaningful — e.g., "Error rate spike on Tuesday tied to downstream dependency outage, resolved by EOD."]
+
+If metrics are not provided: replace table rows with `[data needed — provide metric values for this section]`.
+
+---
+
+## Decisions
+
+### Made This Week
+
+| Decision | Rationale | Owner | Stakeholders Informed |
+|----------|-----------|-------|----------------------|
+| [Decision description] | [Why — 1 sentence] | [Name] | [Yes / No — who] |
+| [Decision description] | [Why — 1 sentence] | [Name] | [Yes / No — who] |
+
+If no decisions were made: *No major decisions this week.*
+
+### Needed Next Week
+
+| Decision | Context | Deadline | Decision Owner |
+|----------|---------|----------|----------------|
+| [What needs to be decided] | [Why it matters, what happens if delayed] | [Date] | [Name or role] |
+
+If no decisions are pending: *No decisions pending.*
+
+---
+
+## Risks and Escalations
+
+| Risk | Likelihood | Impact | Mitigation | Escalate To |
+|------|-----------|--------|-----------|-------------|
+| [Risk description] | [High/Med/Low] | [High/Med/Low] | [What we're doing about it] | [Name/role if escalation needed] |
+
+**Escalations this week:** [Any item that needs immediate leadership attention — call it out explicitly here, do not bury it in a table row. If none: "None."]
+
+---
+
+## Team Health
+
+| Item | Status |
+|------|--------|
+| Team capacity this week | [X of Y people at full capacity] |
+| PTO / out of office | [Names and dates, or "None"] |
+| New joins / departures | [Name, role, and date, or "None"] |
+| On-call this week | [Name] |
+| On-call next week | [Name] |
+
+**Team notes:** [Any morale, workload, or team dynamic signals worth surfacing — keep this factual and constructive. If nothing to note: omit this line.]
+
+---
+
+## Next Week's Priorities
+
+*The [3–5] things this team will ship or meaningfully advance next week.*
+
+1. **[Priority item]** — [One sentence: what done looks like and who owns it]
+2. **[Priority item]** — [One sentence: what done looks like and who owns it]
+3. **[Priority item]** — [One sentence: what done looks like and who owns it]
+4. **[Priority item]** — [One sentence: what done looks like and who owns it]
+5. **[Priority item]** — [One sentence: what done looks like and who owns it]
+
+**Capacity risk:** [If the team is at reduced capacity next week (PTO, incidents, etc.), note it here so stakeholders calibrate expectations.]
+
+---
+
+## Appendix: Sprint Scorecard (if applicable)
+
+| Sprint | Committed | Completed | Completion Rate | Carried Over |
+|--------|-----------|-----------|----------------|--------------|
+| Sprint [N-1] | [X pts] | [X pts] | [X%] | [X pts] |
+| Sprint [N] (current) | [X pts] | [X pts — partial] | [X% at midpoint] | TBD |
+
+---
+
+*Questions or corrections: [Slack channel or email] | Next report: [Date]*
+
+---
+
+## Quality Checks
+
+- [ ] Every blocked item names a specific owner and states what is concretely needed to unblock it — not just "waiting on X"
+- [ ] Decisions-needed table includes a deadline and a named decision owner, not a vague "TBD"
+- [ ] Metrics table is either populated with real numbers or explicitly marked `[data needed]` — no fabricated metrics
+- [ ] Next week's priorities are written as outcomes ("ship X", "complete Y migration") not as activities ("work on X")
+- [ ] Escalations that need leadership attention are called out explicitly in the Risks section — not just buried in a table row
+- [ ] The entire report is readable in under 2 minutes — if it is longer than one printed page, trim it
+- [ ] Report period (week number and date range) is clearly stated in the header
@@ -0,0 +1,369 @@
+---
+name: feature-flag-guide
+description: "Write a feature flag management guide and lifecycle playbook for a service or team — covering flag taxonomy, creation checklist, rollout strategy, monitoring requirements, cleanup policy, and governance. Use when asked to document feature flag practices, create a flag rollout plan, write a feature flag policy, or guide a team on flag lifecycle management. Produces a flag lifecycle playbook, taxonomy reference, per-flag creation template, rollout decision tree, and cleanup checklist."
+---
+
+# Feature Flag Guide Skill
+
+Produce a complete feature flag management guide for a service or team — covering how flags are named and categorised, how to create and roll out a flag safely, what to monitor during rollout, when and how to clean up flags, and who is responsible for each stage. Feature flags without discipline become permanent technical debt. This guide gives the team a repeatable process so flags are created intentionally, rolled out safely, and removed when done.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service or team name** — scope of the guide
+- **Feature flag platform** — LaunchDarkly, Split, Unleash, Flagsmith, Flipt, or a custom/in-house solution
+- **Flag being documented** (if writing a per-flag guide) or "general guide" (if writing team-wide policy)
+- **Rollout constraints** — any compliance, data privacy, or contractual constraints on who can see a feature (e.g. HIPAA, EU-only, enterprise customers only)
+
+## Output Format
+
+---
+
+# Feature Flag Management Guide: [Service / Team Name]
+
+**Team:** [Team name] | **Platform:** [LaunchDarkly / Split / Unleash / Custom]
+**Document owner:** [Name] | **Last updated:** [Date]
+**Review cycle:** Quarterly, and whenever the flag platform changes
+
+---
+
+## 1. Flag Taxonomy
+
+Every flag belongs to exactly one category. The category determines default behaviour, who can enable it in production, and when it must be cleaned up.
+
+| Type | Purpose | Default state | Production gate | Max lifetime |
+|---|---|---|---|---|
+| **Release flag** | Controls rollout of a new feature — decouples deploy from release | Off | Tech lead approval | 90 days from feature launch |
+| **Experiment flag** | A/B or multivariate test — measures impact of a change | Off (control group) | Product + tech lead | Duration of experiment + 30 days |
+| **Ops flag** | Operational control — circuit breaker, kill switch, throttle | On (normal behaviour) | On-call engineer can toggle | Indefinite (review annually) |
+| **Permission flag** | Gates access by user segment, tier, or region | Off (restricted) | Product + Account owner | Indefinite (review annually) |
+
+**When in doubt:** If the flag is temporary (tied to a specific feature launch), it is a Release flag. If it will exist forever as a control knob, it is an Ops flag.
+
+---
+
+## 2. Flag Naming Convention
+
+All flags must follow this naming scheme:
+
+```
+[type]-[service]-[feature-description]
+```
+
+| Segment | Values | Example |
+|---|---|---|
+| type | `release`, `exp`, `ops`, `perm` | `release` |
+| service | Short service identifier, lowercase, hyphenated | `payments` |
+| feature-description | Kebab-case description, max 5 words | `new-checkout-flow` |
+
+**Full examples:**
+- `release-payments-new-checkout-flow` — release flag for a new checkout feature in the payments service
+- `exp-search-personalized-ranking` — experiment on personalized search ranking
+- `ops-api-rate-limit-override` — operational flag to override API rate limits
+- `perm-dashboard-beta-users-only` — permission flag gating dashboard for beta users
+
+**Do not:**
+- Use ticket numbers in flag names (`release-JIRA-1234` → not searchable or self-describing)
+- Use dates in flag names (`release-dark-mode-jan-2024` → flags outlive their dates)
+- Use vague names (`release-new-thing` → not useful when you have 50 flags)
+
+---
+
+## 3. Flag Creation Checklist
+
+Complete every item before creating a flag in the production environment.
+
+**Before creating the flag:**
+- [ ] Flag type determined from taxonomy (Section 1)
+- [ ] Flag name follows naming convention (Section 2)
+- [ ] Flag owner assigned — one named engineer responsible for cleanup
+- [ ] Cleanup date set in the flag description field (for Release and Experiment flags)
+- [ ] Rollout strategy defined — see Section 4
+- [ ] Monitoring plan defined — see Section 5
+- [ ] Code review approved with flag guard in place
+
+**Flag description field (required):**
+```
+Type: [Release / Experiment / Ops / Permission]
+Owner: [Name]
+Linked ticket: [JIRA-XXXX or GitHub issue URL]
+Purpose: [One sentence — what this flag controls]
+Cleanup by: [Date — required for Release and Experiment flags; "Annual review" for Ops/Permission]
+Rollout plan: [Link to this document or inline summary]
+```
+
+**Code requirements:**
+```python
+# Good — behaviour is clear when flag is off, and cleanup is obvious
+if flag_client.is_enabled("release-[service]-[feature]", user_context):
+    return new_feature_handler(request)
+else:
+    return existing_handler(request)
+
+# Bad — nested flags, ternaries, and implicit defaults make cleanup error-prone
+result = new_handler() if (f1 and not f2) or f3 else old_handler()
+```
+
+---
+
+## 4. Rollout Strategy
+
+### Decision Tree
+
+Use this decision tree to pick the right rollout strategy for a Release or Experiment flag:
+
+```
+Is the change reversible without a deploy?
+├── No → Use an Ops flag with manual enable, not a percentage rollout
+└── Yes → Continue
+
+Is there a user-level identifier available (user ID, session ID)?
+├── No → Use server-side percentage (stateless, but inconsistent per user)
+└── Yes → Use user-based percentage (consistent experience per user) ← preferred
+
+Is the change risky (touches payments, auth, or data writes)?
+├── Yes → Start at 1% → 5% → 25% → 50% → 100%, with 24-hour holds
+└── No → Start at 10% → 50% → 100%, with 4-hour holds
+
+Does the change affect specific customer tiers or geographies?
+├── Yes → Use segment-based targeting, not percentage rollout
+└── No → Use percentage rollout
+```
+
+### Rollout Stages
+
+| Stage | Percentage | Hold duration | Pass criteria before advancing |
+|---|---|---|---|
+| Canary | 1% | 24 hours | Error rate within SLO, no P1 incidents |
+| Early rollout | 5–10% | 24 hours | Error rate and latency match control group |
+| Partial rollout | 25–50% | 24–48 hours | Business metrics not degraded vs. control |
+| Majority | 75% | 24 hours | Final check — no regressions |
+| Full rollout | 100% | 48 hours | Stable — schedule cleanup |
+
+**Do not skip stages for Release flags on production.** Speed of rollout is not worth a production incident.
+
+### Segment-Based Targeting
+
+Use segment targeting when the rollout must be restricted:
+
+```yaml
+# LaunchDarkly segment example — adapt for your platform
+targeting_rules:
+  - clause:
+      attribute: "subscription_tier"
+      operator: "in"
+      values: ["enterprise", "team"]
+    serve: "on"
+  - clause:
+      attribute: "country"
+      operator: "in"
+      values: ["US", "CA", "GB"]
+    serve: "on"
+  default: "off"
+```
+
+---
+
+## 5. Monitoring Requirements
+
+Every flag that is not at 0% or 100% rollout requires active monitoring. Do not roll out a flag and walk away.
+
+### Required Metrics Per Flag
+
+| Metric | What to compare | Alert threshold |
+|---|---|---|
+| Error rate | Flag-on cohort vs. flag-off cohort | >2× baseline error rate in flag-on group |
+| p99 latency | Flag-on vs. flag-off | >20% higher latency in flag-on group |
+| [Primary business metric] | Flag-on vs. flag-off | >5% degradation in flag-on group |
+| [Conversion / completion rate] | Flag-on vs. flag-off | >2% drop in flag-on group |
+
+**Setting up split metric monitoring in [LaunchDarkly / Split / Datadog]:**
+```
+1. Navigate to the flag → Metrics tab
+2. Add metric: [primary business metric]
+3. Add metric: error_rate (service-level)
+4. Add metric: p99_latency (endpoint-level)
+5. Set alert: notify [flag owner] in Slack #[team-channel] if metric degrades by [threshold]
+6. Set experiment duration: [N days] if this is an Experiment flag
+```
+
+### Guardrail Metrics
+
+These metrics must never degrade, regardless of what the primary metric shows. If a guardrail is breached, roll back immediately — do not wait for investigation.
+
+- Error rate exceeds SLO threshold ([X]%)
+- p99 latency exceeds SLO threshold ([Y] ms)
+- [Service-specific guardrail — e.g. payment failure rate, auth failure rate]
+
+**Immediate rollback command if guardrail is breached:**
+```bash
+# [LaunchDarkly CLI]
+ld-cli flag update [project-key] [flag-key] --default-variation off
+
+# [Split CLI]
+split-cli update-treatment [flag-name] --treatment "off" --percentage 100
+
+# [Unleash CLI / API]
+curl -X POST https://[unleash-host]/api/admin/features/[flag-name]/disable \
+  -H "Authorization: [admin-token]"
+
+# [Custom — adapt to your implementation]
+[command or dashboard step]
+```
+
+---
+
+## 6. Per-Flag Creation Template
+
+Copy this template into your flag's description field and the linked ticket when creating a new flag:
+
+```markdown
+## Flag: [flag-name]
+
+**Type:** [Release / Experiment / Ops / Permission]
+**Owner:** [Name] ([Slack handle])
+**Created:** [Date]
+**Cleanup by:** [Date]
+**Linked ticket:** [URL]
+
+### Purpose
+[One paragraph: what this flag controls, why it exists, what "on" and "off" mean]
+
+### Rollout Plan
+| Stage | Target | Date | Approved by |
+|---|---|---|---|
+| Canary | 1% | [Date] | [Name] |
+| Early | 10% | [Date] | [Name] |
+| Partial | 50% | [Date] | [Name] |
+| Full | 100% | [Date] | [Name] |
+
+### Monitoring
+- Primary metric: [metric name and dashboard link]
+- Guardrail metrics: error rate < [X]%, p99 < [Y] ms
+- Alert channel: #[team-channel]
+
+### Rollback Procedure
+[Exact steps to turn the flag off in an emergency — should take < 2 minutes]
+
+### Cleanup Checklist
+- [ ] Flag at 100% for 48+ hours with no incidents
+- [ ] Code path for flag-off branch removed from codebase
+- [ ] Flag deleted from [platform]
+- [ ] Ticket closed
+```
+
+---
+
+## 7. Emergency Kill-Switch Procedure
+
+When a flag needs to be disabled immediately due to a production incident:
+
+**Time target: flag disabled within 2 minutes of decision.**
+
+```
+1. Go to [platform URL] — bookmark this: [URL]
+2. Search for the flag by name: [flag-name]
+3. Set to 0% / "off" for ALL users
+4. Verify the service error rate drops within 60 seconds
+5. Post to #incidents:
+   "🟡 Feature flag [flag-name] disabled — rolling back [feature description].
+    Owner: [name]. Error rate before: [X]%. Monitoring for recovery."
+6. Page the flag owner if not already aware
+```
+
+**For ops flags (kill switches that must turn OFF normally-on behaviour):**
+```bash
+# These flags are "on" by default and turned "off" to disable a feature
+# Confirm the flag polarity before toggling — "off" may mean "disabled" or "enabled" depending on naming
+# Flag [flag-name]: OFF = [feature behaviour when off]
+[kill switch command for your platform]
+```
+
+---
+
+## 8. Stale Flag Policy and Cleanup
+
+Stale flags are flags that are at 100% rollout, have been at 100% for >48 hours, or are past their cleanup date. Stale flags are technical debt.
+
+### Stale Flag Definition
+
+A flag is stale if ANY of the following are true:
+- It is a Release flag past its cleanup date
+- It has been at 100% (or 0%) rollout for more than 30 days
+- Its linked ticket is closed and code cleanup has not happened
+- Its owner has left the team
+
+### Cleanup Checklist
+
+```
+[ ] Flag is at 100% rollout and has been stable for 48+ hours
+[ ] Monitoring shows no issues for the flag-on cohort
+[ ] Code changes:
+    [ ] Remove the flag check from application code
+    [ ] Remove the "off" code path entirely — do not leave dead code
+    [ ] Remove any flag-related tests that test the off behaviour
+    [ ] Update any documentation that references the flag
+[ ] PR merged and deployed to production
+[ ] Flag deleted from [platform] (do not just disable — delete)
+[ ] Cleanup ticket closed
+[ ] Flag owner confirms cleanup in Slack: "Flag [name] has been cleaned up — [commit link]"
+```
+
+**Automated stale flag detection:**
+```bash
+# Run weekly — flags past cleanup date or at 100% for > 30 days
+# [Platform-specific query — adapt:]
+
+# LaunchDarkly API
+curl -s "https://app.launchdarkly.com/api/v2/flags/[project-key]" \
+  -H "Authorization: [api-key]" | \
+  jq '.items[] | select(.creationDate < (now - 2592000) * 1000) | {key: .key, created: .creationDate}'
+
+# Notify #engineering-housekeeping with list of stale flags
+```
+
+### Stale Flag Escalation
+
+| Age past cleanup date | Action |
+|---|---|
+| 0–14 days | Slack reminder to flag owner |
+| 14–30 days | Slack reminder to flag owner + tech lead |
+| 30+ days | Tech lead assigns cleanup, creates ticket with P2 priority |
+| 60+ days | Engineering manager reviews — flag may be force-deleted |
+
+---
+
+## 9. Governance
+
+### Who Can Do What
+
+| Action | Who | Approval required |
+|---|---|---|
+| Create a flag (any environment) | Any engineer | None — but must complete creation checklist |
+| Enable a flag in development | Any engineer | None |
+| Enable a flag in staging | Any engineer | None |
+| Enable a flag in production (0–10%) | Flag owner | Tech lead awareness |
+| Advance rollout in production (10–100%) | Flag owner | Tech lead sign-off per stage |
+| Enable an Ops flag in production | On-call engineer | None — these are break-glass controls |
+| Delete a flag | Flag owner | Tech lead confirmation that code cleanup is done |
+| Create a Permission flag | Flag owner | Product manager approval |
+
+### Audit Logging
+
+All flag changes in production must be traceable. Ensure the following are configured in [platform]:
+
+- **Change log:** Every production flag change logs: who changed it, what they changed, and when.
+- **Slack notifications:** Production flag changes post to `#[team]-flag-changes` automatically.
+- **Quarterly review:** Every quarter, the tech lead reviews the full flag inventory, confirms owners are current, and removes flags with no owner.
+
+---
+
+## Quality Checks
+
+- [ ] Every flag has an owner named in its description — no orphan flags
+- [ ] Release and Experiment flags have a cleanup date set — not open-ended
+- [ ] Monitoring is configured for every flag currently between 1–99% rollout
+- [ ] The emergency kill-switch procedure has been tested — on-call engineers have bookmarked the platform URL and know the steps
+- [ ] Stale flag detection runs automatically and results are reviewed weekly
+- [ ] Code review checklist includes: "Does this PR introduce a flag? If yes, is the creation checklist complete?"
+- [ ] At least one person other than the flag owner knows how to disable any given flag in an emergency
@@ -0,0 +1,292 @@
+---
+name: infra-as-code-review
+description: "Write an infrastructure-as-code review checklist and conduct a structured review of Terraform, CloudFormation, Pulumi, or Ansible code. Use when asked to review IaC code, audit infrastructure configurations, check cloud security posture, or produce a reusable IaC review checklist. Produces a structured review report with severity-categorized findings, remediation guidance, and a reusable checklist."
+---
+
+# Infrastructure-as-Code Review
+
+Produce a structured infrastructure-as-code review that applies security, reliability, and operational quality standards to a specific body of IaC code. The output serves two purposes: an actionable review report for the code at hand (with findings by severity and specific remediation steps), and a reusable checklist the team can apply to every future IaC change. If the user provides actual code, analyze it and populate the findings table with real issues. If no code is provided, produce the checklist and a template findings report.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **IaC tool** — Terraform, CloudFormation, Pulumi, Ansible, or CDK
+- **Cloud provider** — AWS, GCP, Azure, or multi-cloud
+- **What the code provisions** — a brief description (e.g., "VPC, EKS cluster, and RDS instance for the payments service")
+- **Security policies or naming standards in use** — any existing org standards to check against; if none, use sensible defaults
+- **The IaC code itself** — paste or describe it; if not provided, produce the checklist template only and note findings require code
+
+## Output Format
+
+---
+
+# IaC Review Report: [What Is Being Provisioned]
+
+**Reviewer:** [Name / Claude]
+**IaC Tool:** [Terraform / CloudFormation / Pulumi / Ansible / CDK]
+**Cloud Provider:** [AWS / GCP / Azure]
+**Code Location:** [Repo path or PR link]
+**Review Date:** [Date]
+**Overall Risk:** [Critical / High / Medium / Low]
+
+---
+
+## Executive Summary
+
+| Severity | Finding Count | Resolved in This Review | Carry-Over Risk |
+|----------|---------------|------------------------|-----------------|
+| Critical | [n] | [n] | [Yes/No — explain] |
+| High | [n] | [n] | [Yes/No — explain] |
+| Medium | [n] | [n] | [Yes/No — explain] |
+| Low | [n] | [n] | [Yes/No — explain] |
+| **Total** | **[n]** | **[n]** | |
+
+**Recommendation:** [Approve / Approve with Required Changes / Block — one sentence rationale]
+
+---
+
+## Findings
+
+### Critical Findings
+
+#### CRIT-01: [Finding Title]
+
+| Field | Detail |
+|-------|--------|
+| **Severity** | Critical |
+| **Category** | [IAM / Secrets / Encryption / Network / State / Naming / Cost] |
+| **Resource** | `[resource_type.resource_name]` |
+| **File / Line** | `[path/to/file.tf:42]` |
+| **Risk** | [What can go wrong — be specific about the attack vector or failure mode] |
+
+**Current code:**
+```hcl
+# [paste the problematic snippet]
+resource "aws_s3_bucket" "data" {
+  bucket = "my-bucket"
+  acl    = "public-read"   # PROBLEM: public read access
+}
+```
+
+**Remediation:**
+```hcl
+resource "aws_s3_bucket" "data" {
+  bucket = "my-bucket"
+}
+
+resource "aws_s3_bucket_public_access_block" "data" {
+  bucket                  = aws_s3_bucket.data.id
+  block_public_acls       = true
+  block_public_policy     = true
+  ignore_public_acls      = true
+  restrict_public_buckets = true
+}
+```
+
+**Why this matters:** [One sentence linking the specific risk to business impact — data exposure, compliance violation, etc.]
+
+---
+
+#### CRIT-02: [Next Critical Finding — repeat structure]
+
+---
+
+### High Findings
+
+#### HIGH-01: [Finding Title]
+
+| Field | Detail |
+|-------|--------|
+| **Severity** | High |
+| **Category** | [Category] |
+| **Resource** | `[resource_type.resource_name]` |
+| **File / Line** | `[path/to/file.tf:line]` |
+| **Risk** | [Specific risk description] |
+
+**Current code:**
+```hcl
+# [problematic snippet]
+```
+
+**Remediation:**
+```hcl
+# [fixed snippet]
+```
+
+---
+
+### Medium Findings
+
+#### MED-01: [Finding Title]
+
+| Field | Detail |
+|-------|--------|
+| **Severity** | Medium |
+| **Category** | [Category] |
+| **Resource** | `[resource_type.resource_name]` |
+| **File / Line** | `[path/to/file.tf:line]` |
+| **Risk** | [Specific risk description] |
+
+**Remediation:** [Prose or code snippet — choose whichever is clearer for this finding]
+
+---
+
+### Low Findings
+
+#### LOW-01: [Finding Title]
+
+| Field | Detail |
+|-------|--------|
+| **Severity** | Low |
+| **Category** | [Category] |
+| **Resource** | `[resource_type.resource_name]` |
+| **File / Line** | `[path/to/file.tf:line]` |
+| **Suggestion** | [What to improve and why] |
+
+---
+
+## Reusable IaC Review Checklist
+
+Use this checklist on every IaC pull request. Check every item; mark N/A only when the item genuinely does not apply to the resources being provisioned.
+
+### 1. IAM and Access Control
+
+- [ ] No wildcard actions (`"*"`) in IAM policies — policies follow least-privilege
+- [ ] No wildcard resource (`"*"`) in IAM policies unless explicitly justified with a comment
+- [ ] IAM roles use condition keys to restrict scope (e.g., `aws:RequestedRegion`, `sts:ExternalId`)
+- [ ] No IAM access keys or credentials hardcoded or in plaintext variables
+- [ ] EC2 / compute instances use instance profiles, not hardcoded credentials
+- [ ] S3 bucket policies do not allow public access unless the bucket is explicitly a public asset bucket
+- [ ] Cross-account trust policies name specific account IDs, not `"*"`
+- [ ] Service accounts (GCP) / managed identities (Azure) follow naming conventions and have documented purpose
+
+### 2. Secrets Management
+
+- [ ] No secrets, passwords, tokens, or API keys in plaintext in any `.tf`, `.yaml`, or `.json` file
+- [ ] No secrets in variable default values
+- [ ] Secrets sourced from Secrets Manager / Parameter Store / Vault — not from environment variables passed at plan time
+- [ ] `sensitive = true` is set on all output values and variables that contain secrets (Terraform)
+- [ ] State backend is encrypted — no unencrypted state files contain sensitive data
+- [ ] `.gitignore` or equivalent excludes `*.tfvars`, `terraform.tfstate`, and any file that may contain resolved secrets
+
+### 3. Encryption at Rest
+
+- [ ] Storage resources (S3, EBS, RDS, DynamoDB, GCS, Azure Blob) have encryption at rest enabled
+- [ ] Customer-managed keys (CMK/KMS) are used where required by policy — not solely AWS/GCP/Azure managed keys
+- [ ] KMS key rotation is enabled for all CMKs
+- [ ] Database snapshots have encryption enabled
+- [ ] Encryption is not disabled via `encrypted = false` or equivalent
+
+### 4. Encryption in Transit
+
+- [ ] Load balancers terminate TLS — HTTP-only listeners redirect to HTTPS or are absent
+- [ ] Minimum TLS version is 1.2; TLS 1.0 and 1.1 are explicitly disabled
+- [ ] RDS / database connections require SSL (`require_ssl = true` or equivalent parameter)
+- [ ] Internal service-to-service calls use TLS where the network is not fully private
+- [ ] S3 bucket policies include a `Deny` on non-TLS requests (`aws:SecureTransport: false`)
+
+### 5. Network and Public Access
+
+- [ ] Security groups / firewall rules do not permit `0.0.0.0/0` ingress except on ports 80/443 for public-facing services
+- [ ] SSH (port 22) and RDP (port 3389) are not open to `0.0.0.0/0`
+- [ ] Databases are in private subnets — not directly internet-routable
+- [ ] `publicly_accessible = false` on RDS instances unless explicitly required and documented
+- [ ] VPC has flow logs enabled
+- [ ] Network ACLs and security groups are layered (defense in depth)
+- [ ] S3 bucket public access block is enabled at the account and bucket level
+
+### 6. Logging, Monitoring, and Audit
+
+- [ ] CloudTrail / Cloud Audit Logs / Azure Monitor is enabled across all regions
+- [ ] S3 access logging is enabled on buckets containing sensitive or regulated data
+- [ ] RDS enhanced monitoring or equivalent is enabled
+- [ ] CloudWatch alarms or equivalent are defined for critical metrics (CPU, disk, error rate)
+- [ ] Log retention periods are defined — logs not retained indefinitely or deleted within 7 days
+
+### 7. Naming and Tagging Standards
+
+- [ ] All resources follow the team's naming convention: `[env]-[team]-[resource-type]-[identifier]`
+- [ ] Required tags are present on all taggable resources:
+  - [ ] `Environment` (e.g., prod / staging / dev)
+  - [ ] `Team` or `Owner`
+  - [ ] `Service` or `Application`
+  - [ ] `CostCenter` (if required by finance policy)
+  - [ ] `ManagedBy: terraform` (or equivalent IaC tool tag)
+- [ ] No resources with default names (e.g., `default-vpc`, `launch-wizard-1`)
+
+### 8. State Management and Backend
+
+- [ ] Remote state backend is configured — no local state in repository
+- [ ] State backend uses locking (DynamoDB for S3 backend, etc.)
+- [ ] State backend bucket/storage has versioning enabled
+- [ ] State backend bucket/storage has access logging enabled
+- [ ] Workspaces or separate state files are used per environment — no shared state between prod and non-prod
+- [ ] `terraform.tfstate` and `*.tfstate.backup` are in `.gitignore`
+
+### 9. Module and Resource Structure
+
+- [ ] Modules are versioned with explicit version pins — no floating `source = "git::...?ref=main"`
+- [ ] Provider versions are pinned in `required_providers` — no unconstrained `>= x.y`
+- [ ] Terraform version is pinned in `required_version`
+- [ ] Modules have a clear single responsibility — not one module that provisions everything
+- [ ] No copy-paste duplication — repeated patterns use modules or loops (`for_each`, `count`)
+- [ ] Outputs expose only what downstream consumers need — no unnecessary output sprawl
+
+### 10. Environment Parity
+
+- [ ] Prod and non-prod environments use the same module code, parameterized by environment variable
+- [ ] Instance sizes and replica counts differ by environment via variables — not by separate code branches
+- [ ] Non-prod does not have security controls disabled "to save money" (encryption off, logging off)
+
+### 11. Cost Impact
+
+- [ ] Large instance types (e.g., `r5.16xlarge`) or storage allocations are justified in a comment
+- [ ] Data transfer costs are considered for cross-region or cross-AZ architectures
+- [ ] Reserved instance or committed use discount eligibility is noted for long-lived resources
+- [ ] Auto-scaling is configured for variable workloads — no fixed oversized fleets for spiky traffic
+- [ ] Lifecycle policies are set on S3 buckets storing time-bounded data (logs, backups)
+
+### 12. Drift Risk
+
+- [ ] No resources that are commonly mutated in the console are managed by IaC without import documentation
+- [ ] `lifecycle { prevent_destroy = true }` is set on stateful resources in production (databases, state buckets)
+- [ ] `ignore_changes` is used sparingly and each instance is documented with a rationale comment
+- [ ] A plan is run against the live environment as part of the PR process — no unreviewed drift
+
+---
+
+## Findings Summary Table
+
+| ID | Title | Severity | Category | File | Status |
+|----|-------|----------|----------|------|--------|
+| CRIT-01 | [Title] | Critical | [Category] | [file:line] | Open |
+| HIGH-01 | [Title] | High | [Category] | [file:line] | Open |
+| MED-01 | [Title] | Medium | [Category] | [file:line] | Open |
+| LOW-01 | [Title] | Low | [Category] | [file:line] | Open |
+
+---
+
+## Required Actions Before Merge
+
+List only Critical and High findings that must be resolved before this code is merged:
+
+1. **CRIT-01 [Title]** — [One-line remediation instruction]
+2. **HIGH-01 [Title]** — [One-line remediation instruction]
+
+Medium and Low findings should be tracked as follow-up issues with a committed resolution date.
+
+---
+
+*Review conducted by [Reviewer] on [Date] — checklist version [1.0]*
+
+---
+
+## Quality Checks
+
+- [ ] Every finding includes: severity, category, specific resource name, file and line number, current code, and fixed code
+- [ ] Checklist covers all 12 categories: IAM, Secrets, Encryption at Rest, Encryption in Transit, Network, Logging, Naming/Tagging, State, Module Structure, Environment Parity, Cost, and Drift
+- [ ] Executive summary table is filled with real counts — not all zeros or all placeholders
+- [ ] "Required Actions Before Merge" section lists only Critical and High items
+- [ ] Code snippets in findings show both the problematic code AND the corrected version
+- [ ] Overall risk rating is justified by the highest-severity open finding
+- [ ] Checklist items are binary (checkable) — not narrative observations
@@ -0,0 +1,432 @@
+---
+name: load-testing-plan
+description: "Write a load and performance testing plan for a service. Use when asked to create a performance test plan, write load testing documentation, define stress or soak test scenarios, or set performance regression gates for CI. Produces a complete test plan document with scenario definitions, k6/Locust script skeleton, threshold table, result interpretation guide, and CI integration steps."
+---
+
+# Load Testing Plan Skill
+
+Produce a complete load and performance testing plan for a service — covering test objectives, scenario definitions, tooling configuration, success thresholds, and CI integration. A good load testing plan eliminates ambiguity about what "performance is acceptable" means, so engineers can run tests and get a pass/fail answer without having to interpret raw numbers themselves.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name and key endpoints** — which endpoints are under test (path, method, typical request/response shape)
+- **Current traffic baseline** — current requests/sec, p50/p99 latency, error rate under normal load
+- **Peak traffic expectations** — expected peak RPS (e.g. 10× baseline for flash sales, or seasonality peak)
+- **SLO targets** — latency SLOs (p99 < X ms), error rate SLO (< Y%), availability target
+- **Preferred testing tool** — k6, Locust, JMeter, Gatling, or no preference
+- **Test environment availability** — dedicated load test environment, staging, or production (with traffic shaping)
+
+## Output Format
+
+---
+
+# Load Testing Plan: [Service Name]
+
+**Author:** [Name] | **Team:** [Team name]
+**Date:** [Date] | **Review cycle:** Before each major release and quarterly
+**Testing tool:** [k6 / Locust / JMeter / Gatling]
+**Test environment:** [Environment name and URL]
+
+---
+
+## 1. Objectives and Scope
+
+**What we are testing:** [Service name] handles [describe function — e.g. "user authentication requests from the mobile and web clients"]. This plan validates that the service meets its SLOs under expected and elevated traffic conditions.
+
+**In scope:**
+- [Endpoint 1: METHOD /path — description]
+- [Endpoint 2: METHOD /path — description]
+- [Endpoint 3: METHOD /path — description]
+
+**Out of scope:**
+- [Any endpoints explicitly excluded and why — e.g. "admin APIs — low traffic, excluded from load test"]
+- [Third-party integrations that cannot be load-tested — mock them instead]
+
+---
+
+## 2. Performance Targets (Success Criteria)
+
+Every scenario has explicit pass/fail thresholds. A test run FAILS if any threshold is breached.
+
+| Metric | Baseline scenario | Stress scenario | Spike scenario | Soak scenario |
+|---|---|---|---|---|
+| p50 latency | < [X] ms | < [X × 1.5] ms | < [X × 2] ms | < [X] ms |
+| p95 latency | < [Y] ms | < [Y × 1.5] ms | < [Y × 2] ms | < [Y] ms |
+| p99 latency | < [Z] ms | < [Z × 2] ms | < [Z × 3] ms | < [Z] ms |
+| Error rate | < [0.1]% | < [1]% | < [2]% | < [0.1]% |
+| Throughput | ≥ [N] RPS | ≥ [N × 3] RPS | N/A | ≥ [N] RPS |
+| Failed requests | 0 (5xx) | < [threshold] | < [threshold] | 0 (5xx) |
+
+**SLO reference:** These thresholds are derived from the service SLOs — p99 < [Z ms], error rate < [0.1]%, availability [99.9]%.
+
+---
+
+## 3. Traffic Model
+
+**Baseline traffic (current production):**
+- Average RPS: [N] req/sec
+- Peak RPS (observed): [N] req/sec
+- Request distribution by endpoint:
+  - [Endpoint 1]: [X]% of traffic
+  - [Endpoint 2]: [Y]% of traffic
+  - [Endpoint 3]: [Z]% of traffic
+
+**Simulated user behaviour:**
+- Think time between requests: [X–Y] seconds (randomised)
+- Session duration: [N] minutes average
+- Authenticated vs anonymous ratio: [X]%/[Y]%
+- Geographic distribution: [Region 1 X]%, [Region 2 Y]%
+
+---
+
+## 4. Test Scenarios
+
+### Scenario 1: Baseline (Steady-State)
+
+**Purpose:** Confirm the service performs acceptably under normal production load.
+**Duration:** 10 minutes
+**Load profile:** Ramp to [N] RPS over 2 minutes, hold for 8 minutes.
+**Concurrency:** [N] virtual users
+
+**Pass criteria:** All thresholds in the Baseline column of the targets table above.
+
+---
+
+### Scenario 2: Stress Test
+
+**Purpose:** Find the breaking point — how much load can the service handle before SLOs are breached?
+**Duration:** 20–30 minutes
+**Load profile:** Ramp from [N] RPS (baseline) to [N × 5] RPS in 5-minute steps. Hold each step for 5 minutes. Stop at first SLO breach.
+**Concurrency:** Scales with RPS target
+
+**What to record:**
+- RPS at which p99 latency first exceeds SLO
+- RPS at which error rate first exceeds SLO
+- Whether the service recovers when load drops back to baseline
+
+---
+
+### Scenario 3: Spike Test
+
+**Purpose:** Simulate a sudden traffic surge (flash sale, viral event, bot attack).
+**Duration:** 15 minutes
+**Load profile:** Hold at [N] RPS (baseline) for 3 minutes, spike to [N × 10] RPS instantly, hold for 5 minutes, drop back to baseline for 7 minutes.
+
+**What to record:**
+- Latency during spike and recovery
+- Whether the service sheds load gracefully (rate limiting, queue depth)
+- Time to recover to baseline latency after spike ends
+
+---
+
+### Scenario 4: Soak / Endurance Test
+
+**Purpose:** Detect memory leaks, connection pool exhaustion, and slow degradation over time.
+**Duration:** 4–8 hours (run overnight)
+**Load profile:** Steady [N × 1.5] RPS (50% above baseline) for entire duration.
+
+**What to watch:**
+- Memory usage trend over time (should not grow unboundedly)
+- Error rate trend (should be flat, not creeping up)
+- GC pause frequency (JVM/Go services)
+- Database connection pool utilisation
+- p99 latency trend (should not creep up over hours)
+
+---
+
+## 5. Test Environment Requirements
+
+### Infrastructure
+
+| Component | Requirement | Notes |
+|---|---|---|
+| Service under test | Isolated from production | [N] replicas, matching prod resource limits |
+| Database | Separate instance with production-scale data | Seed script in section 7 |
+| Cache (Redis/Memcached) | Empty at test start | Ensures cold-start conditions are tested |
+| Load generator | Separate from service under test | [N] vCPUs, [N] GB RAM minimum |
+| Network | Low-latency path to service | Do not run generator on same host |
+
+### Data Seeding
+
+Before every test run, ensure the environment has:
+```bash
+# Seed test users (needed for authenticated endpoint tests)
+[seed command or script path — e.g. python scripts/seed_load_test_users.py --count 10000]
+
+# Seed test data for read endpoints
+[seed command — e.g. ./scripts/seed_products.sh --count 50000]
+
+# Verify seed completed
+[verification command — e.g. psql $DB_URL -c "SELECT COUNT(*) FROM users WHERE load_test=true"]
+```
+
+**Test data rules:**
+- Never use real production user data in load tests
+- Tag all test-generated records with `load_test=true` for easy cleanup
+- Run cleanup after each test: `[cleanup command]`
+
+---
+
+## 6. Tooling Setup
+
+### k6 Script Skeleton
+
+```javascript
+import http from 'k6/http';
+import { check, sleep } from 'k6';
+import { Rate, Trend } from 'k6/metrics';
+
+// Custom metrics
+const errorRate = new Rate('error_rate');
+const endpointLatency = new Trend('endpoint_latency', true);
+
+// Test configuration — override per scenario
+export const options = {
+  scenarios: {
+    baseline: {
+      executor: 'ramping-vus',
+      startVUs: 0,
+      stages: [
+        { duration: '2m', target: [BASELINE_VUS] },
+        { duration: '8m', target: [BASELINE_VUS] },
+        { duration: '1m', target: 0 },
+      ],
+    },
+  },
+  thresholds: {
+    http_req_duration: [
+      'p(95)<[Y_MS]',
+      'p(99)<[Z_MS]',
+    ],
+    error_rate: ['rate<0.01'],
+    http_req_failed: ['rate<0.01'],
+  },
+};
+
+// Auth helper — get token once per VU
+export function setup() {
+  const loginRes = http.post('[BASE_URL]/auth/login', JSON.stringify({
+    username: `load_test_user_${Math.floor(Math.random() * 10000)}@example.com`,
+    password: '[LOAD_TEST_PASSWORD]',
+  }), { headers: { 'Content-Type': 'application/json' } });
+
+  check(loginRes, { 'login ok': (r) => r.status === 200 });
+  return { token: loginRes.json('access_token') };
+}
+
+export default function (data) {
+  const headers = {
+    Authorization: `Bearer ${data.token}`,
+    'Content-Type': 'application/json',
+  };
+
+  // Endpoint 1: [Description]
+  const res1 = http.get('[BASE_URL]/[endpoint-1]', { headers });
+  check(res1, {
+    '[endpoint-1] status 200': (r) => r.status === 200,
+    '[endpoint-1] latency < [X]ms': (r) => r.timings.duration < [X],
+  });
+  errorRate.add(res1.status >= 400);
+  endpointLatency.add(res1.timings.duration, { endpoint: '[endpoint-1]' });
+
+  sleep(Math.random() * [THINK_TIME_MAX] + [THINK_TIME_MIN]);
+
+  // Endpoint 2: [Description]
+  const res2 = http.post('[BASE_URL]/[endpoint-2]',
+    JSON.stringify({ [key]: '[value]' }),
+    { headers }
+  );
+  check(res2, {
+    '[endpoint-2] status 201': (r) => r.status === 201,
+  });
+  errorRate.add(res2.status >= 400);
+}
+```
+
+### Locust Script Skeleton (alternative)
+
+```python
+from locust import HttpUser, task, between
+import random
+
+class [ServiceName]User(HttpUser):
+    wait_time = between([THINK_TIME_MIN], [THINK_TIME_MAX])
+    token = None
+
+    def on_start(self):
+        """Called once per simulated user — authenticate."""
+        user_id = random.randint(1, 10000)
+        response = self.client.post("/auth/login", json={
+            "username": f"load_test_user_{user_id}@example.com",
+            "password": "[LOAD_TEST_PASSWORD]",
+        })
+        self.token = response.json()["access_token"]
+        self.headers = {"Authorization": f"Bearer {self.token}"}
+
+    @task([WEIGHT_1])  # Weight = relative frequency
+    def [endpoint_1_task](self):
+        """[Endpoint 1 description]"""
+        with self.client.get(
+            "/[endpoint-1]",
+            headers=self.headers,
+            catch_response=True
+        ) as response:
+            if response.elapsed.total_seconds() > [LATENCY_THRESHOLD]:
+                response.failure(f"Too slow: {response.elapsed.total_seconds()}s")
+
+    @task([WEIGHT_2])
+    def [endpoint_2_task](self):
+        """[Endpoint 2 description]"""
+        self.client.post(
+            "/[endpoint-2]",
+            json={"[key]": "[value]"},
+            headers=self.headers,
+        )
+```
+
+### Running Tests
+
+```bash
+# k6 — run baseline scenario
+k6 run --env BASE_URL=https://[test-env-url] scripts/load_test.js
+
+# k6 — run stress scenario with output to InfluxDB
+k6 run --out influxdb=http://[influxdb-host]:8086/k6 \
+  --env SCENARIO=stress \
+  scripts/load_test.js
+
+# Locust — headless run
+locust -f locustfile.py \
+  --headless \
+  --users [N] \
+  --spawn-rate [N] \
+  --run-time 10m \
+  --host https://[test-env-url] \
+  --csv=results/[run-id]
+
+# Locust — web UI (interactive)
+locust -f locustfile.py --host https://[test-env-url]
+```
+
+---
+
+## 7. Metrics to Capture
+
+Capture all of the following during every test run. Missing any of these makes result comparison unreliable.
+
+| Metric | Source | Why it matters |
+|---|---|---|
+| p50, p95, p99, p999 latency per endpoint | Load tool | SLO validation |
+| Error rate (4xx, 5xx) per endpoint | Load tool | SLO validation |
+| Requests/sec (throughput) | Load tool | Capacity baseline |
+| CPU utilisation (%) | Infra monitoring | Saturation signal |
+| Memory utilisation (%) | Infra monitoring | Leak detection |
+| GC pause time / frequency | JVM/Go metrics | Latency spike root cause |
+| DB connection pool: active/idle/waiting | DB metrics | Pool exhaustion detection |
+| DB query latency (p99) | DB metrics | Downstream bottleneck |
+| Cache hit rate | Cache metrics | Miss storm detection |
+| Pod/instance count (if autoscaling) | Infra | Scaling behaviour |
+| Network in/out bytes | Infra | Bandwidth saturation |
+
+---
+
+## 8. Result Analysis Framework
+
+After each test run, work through this analysis in order:
+
+**Step 1 — Pass/fail check**
+Compare all captured metrics against the thresholds in Section 2. Record pass/fail per scenario.
+
+**Step 2 — Latency distribution**
+Plot the full latency histogram, not just percentiles. A bimodal distribution (two humps) indicates two distinct code paths — investigate the slow hump.
+
+**Step 3 — Error correlation**
+If errors occurred, correlate them with:
+- Time of occurrence (was it during ramp-up, steady state, or spike?)
+- Specific endpoint (is it one endpoint or all?)
+- Infrastructure events (CPU spike, OOM, DB connection exhaustion?)
+
+**Step 4 — Saturation analysis**
+Graph CPU, memory, and connection pool over time. If any resource reached 80%+ of capacity, it is a candidate bottleneck — even if SLOs passed this run.
+
+**Step 5 — Compare to baseline run**
+Every run should be compared to the previous run. A 10% regression in p99 latency warrants investigation even if it is still within SLO.
+
+**Regression classification:**
+
+| Change | Classification | Action |
+|---|---|---|
+| p99 within 5% of previous run | Green — no regression | No action |
+| p99 5–15% worse than previous | Yellow — watch | Investigate before next release |
+| p99 >15% worse than previous | Red — regression | Block release, file ticket |
+| Error rate increased vs previous | Red — regression | Block release |
+| SLO threshold breached | Critical | Block release, page on-call |
+
+---
+
+## 9. CI Integration
+
+Add load tests as a gated step in the release pipeline. Run the baseline scenario on every release candidate; run all scenarios weekly.
+
+```yaml
+# Example: GitHub Actions step (adapt for your CI platform)
+load-test:
+  runs-on: ubuntu-latest
+  needs: [deploy-staging]
+  if: github.ref == 'refs/heads/main'
+  steps:
+    - uses: actions/checkout@v3
+
+    - name: Install k6
+      run: |
+        curl -s https://dl.k6.io/key.gpg | sudo apt-key add -
+        echo "deb https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
+        sudo apt-get update && sudo apt-get install k6
+
+    - name: Seed test data
+      run: [seed command]
+
+    - name: Run baseline load test
+      run: |
+        k6 run \
+          --env BASE_URL=${{ secrets.LOAD_TEST_ENV_URL }} \
+          --out json=results.json \
+          scripts/load_test.js
+      env:
+        LOAD_TEST_ENV_URL: ${{ secrets.LOAD_TEST_ENV_URL }}
+
+    - name: Check thresholds
+      run: |
+        # k6 exits with non-zero if any threshold fails — this step fails the build
+        echo "k6 threshold check complete"
+
+    - name: Upload results
+      uses: actions/upload-artifact@v3
+      if: always()
+      with:
+        name: load-test-results-${{ github.run_id }}
+        path: results.json
+
+    - name: Cleanup test data
+      if: always()
+      run: [cleanup command]
+```
+
+**CI gates summary:**
+- Baseline scenario runs on every release to staging
+- Full scenario suite (stress, spike, soak) runs weekly on a schedule
+- Any threshold failure blocks promotion to production
+- Results are archived for trend analysis
+
+---
+
+## Quality Checks
+
+- [ ] All key endpoints are covered by at least one test scenario — no production endpoint is untested
+- [ ] Thresholds are derived from actual SLO targets, not guesses
+- [ ] Test data seeding is scripted and reproducible — tests do not rely on pre-existing environment state
+- [ ] The load generator runs on separate infrastructure from the service under test
+- [ ] CI integration blocks promotion on threshold failure — not just records results
+- [ ] Soak test has been run at least once to establish a memory and connection pool baseline
+- [ ] Results comparison to previous run is part of the analysis — not just absolute pass/fail
@@ -0,0 +1,484 @@
+---
+name: local-dev-setup
+description: "Write a local development environment setup guide for a service or project — covering prerequisites, repository setup, environment variables, local service dependencies, database seeding, running the service, running tests, common gotchas, IDE recommendations, and first-contribution checklist. Use when asked to write a dev setup guide, create onboarding documentation for engineers, document local environment setup, or write a getting-started guide for a codebase. Produces a complete setup guide that a new engineer can follow from zero to running tests in under 30 minutes, with a troubleshooting section for the most common setup failures."
+---
+
+# Local Dev Setup Skill
+
+Produce a complete local development environment setup guide for a service or project — walking a new engineer from zero (a clean laptop) to a working local environment with passing tests in under 30 minutes. A good setup guide reduces onboarding time, prevents the "it works on my machine" problem, and lets engineers make their first contribution with confidence. Write every step as a concrete command or action — not a description of what needs to happen.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and what it does
+- **Tech stack** — language, framework, database, cache, message queue, and any external services
+- **Dependencies** — databases, caches, message queues, and external services (mocked or real)
+- **Test framework** — how tests are run and what the test suite covers
+- **CI/CD platform** — GitHub Actions, CircleCI, Jenkins, etc. (for context on what "passing CI" means locally)
+
+## Output Format
+
+---
+
+# Local Development Setup: [Service Name]
+
+**Tech stack:** [Language + version] | [Framework] | [Database] | [Cache]
+**Estimated setup time:** [20–30 minutes] on a clean machine
+**Last verified:** [Date] on [macOS Ventura 13.x / Ubuntu 22.04]
+**Questions?** Ask in [Slack: #[team-channel]] or ping [@tech-lead-handle]
+
+> **First contribution?** Complete setup first (this doc), then read [CONTRIBUTING.md] for code standards and PR process.
+
+---
+
+## Prerequisites
+
+Install these tools before starting. The versions listed are the minimum required — newer patch versions are fine, newer major versions may have compatibility issues.
+
+### Required Tools
+
+| Tool | Required version | Install |
+|---|---|---|
+| [Git] | 2.x+ | Pre-installed on most systems; or `brew install git` |
+| [Language runtime — e.g. Go] | [1.22+] | [https://go.dev/dl/ or `brew install go`] |
+| [Docker] | 24.x+ | [https://docs.docker.com/get-docker/] |
+| [Docker Compose] | 2.x+ | Included with Docker Desktop; or `brew install docker-compose` |
+| [Make] | Any | Pre-installed on macOS/Linux |
+| [Tool — e.g. Node.js] | [20.x+] | [`brew install node` or https://nodejs.org] |
+| [Tool — e.g. psql client] | [15+] | `brew install postgresql@15` (client only) |
+
+### Optional but Recommended
+
+| Tool | Purpose | Install |
+|---|---|---|
+| [direnv] | Auto-load `.envrc` environment variables | `brew install direnv` + [setup instructions](https://direnv.net) |
+| [jq] | Pretty-print JSON in terminal | `brew install jq` |
+| [k9s] | Kubernetes cluster UI (if using K8s locally) | `brew install k9s` |
+| [mkcert] | Local HTTPS certificates | `brew install mkcert` |
+
+### Required Accounts and Access
+
+Before starting, make sure you have:
+- [ ] GitHub access to [org/repo] — request via [access request process / Slack: #it-help]
+- [ ] [AWS / GCP / Azure] account with [dev environment] access — request via [process]
+- [ ] [Internal tool — e.g. 1Password] for retrieving development secrets — request via [process]
+- [ ] [VPN access] if required to reach internal services — request via [process]
+
+---
+
+## 1. Repository Setup
+
+```bash
+# Clone the repository
+git clone git@github.com:[org]/[repo-name].git
+cd [repo-name]
+
+# Install git hooks (required — enforces commit message format and runs pre-commit checks)
+make install-hooks
+# Or manually:
+# cp scripts/hooks/pre-commit .git/hooks/pre-commit && chmod +x .git/hooks/pre-commit
+
+# Verify your git setup
+git config user.name   # should be your name
+git config user.email  # should be your work email
+```
+
+**If you see a permission denied error on clone:** Your SSH key is not added to GitHub. Follow [GitHub's SSH key guide](https://docs.github.com/en/authentication/connecting-to-github-with-ssh) or use HTTPS with a personal access token instead.
+
+---
+
+## 2. Environment Variables
+
+The service requires environment variables for configuration. **Never commit actual secrets to the repository.**
+
+### Step 1 — Copy the example file
+
+```bash
+cp .env.example .env.local
+```
+
+### Step 2 — Fill in the values
+
+Open `.env.local` in your editor. Below is a description of every variable and where to get its value:
+
+| Variable | Description | Where to get it | Example (not real) |
+|---|---|---|---|
+| `APP_ENV` | Environment name | Set to `development` | `development` |
+| `APP_PORT` | Port the service listens on | Set to `8080` for local | `8080` |
+| `DATABASE_URL` | PostgreSQL connection string | Use value from Docker Compose (Section 3) | `postgres://app:password@localhost:5432/[service]_dev` |
+| `REDIS_URL` | Redis connection string | Use value from Docker Compose | `redis://localhost:6379` |
+| `SECRET_KEY` | Application secret key | Generate with: `openssl rand -hex 32` | `[random 64-char hex]` |
+| `[EXTERNAL_SERVICE]_API_KEY` | API key for [External Service] | Retrieve from [1Password vault: "Dev API Keys"] or ask [name] | — |
+| `[EXTERNAL_SERVICE]_BASE_URL` | Base URL for [External Service] | Use sandbox URL: `https://sandbox.[external-service].com` | `https://sandbox.stripe.com` |
+| `LOG_LEVEL` | Logging verbosity | Set to `debug` for local development | `debug` |
+| `[FEATURE_FLAG_SDK_KEY]` | Feature flag platform SDK key | Retrieve from [LaunchDarkly/Split dev project] | — |
+
+**Using direnv (recommended):** Rename `.env.local` to `.envrc`, add `dotenv` at the top, and run `direnv allow`. Variables will load automatically when you `cd` into the project.
+
+---
+
+## 3. Local Service Dependencies
+
+All infrastructure dependencies run in Docker Compose. You do not need to install PostgreSQL, Redis, or Kafka locally.
+
+```bash
+# Start all dependencies (PostgreSQL, Redis, and any other services)
+docker compose up -d
+
+# Verify all containers are healthy
+docker compose ps
+# Expected output: all services show "healthy" status
+
+# View logs if something is not healthy
+docker compose logs [service-name]
+```
+
+### What Docker Compose Starts
+
+| Service | Port | Purpose | Health check |
+|---|---|---|---|
+| PostgreSQL [version] | `5432` | Primary database | `pg_isready -U app` |
+| Redis [version] | `6379` | Cache and session store | `redis-cli ping` |
+| [Kafka + Zookeeper] | `9092` / `2181` | Message queue | `kafka-topics.sh --list` |
+| [Mock server — e.g. WireMock] | `8089` | Mocks for external APIs in tests | `curl localhost:8089/__admin` |
+| [LocalStack] | `4566` | AWS service emulation (S3, SQS, etc.) | `aws --endpoint-url=http://localhost:4566 s3 ls` |
+
+**If a container exits immediately:** See Troubleshooting section — common causes are port conflicts and Docker memory limits.
+
+### Stopping Dependencies
+
+```bash
+# Stop containers (preserves data volumes)
+docker compose stop
+
+# Stop and remove containers (clears data — use when you want a fresh start)
+docker compose down -v
+```
+
+---
+
+## 4. Install Dependencies and Build
+
+```bash
+# Install language dependencies
+# Go:
+go mod download
+
+# Node.js:
+npm install   # or: yarn install / pnpm install
+
+# Python:
+python -m venv .venv
+source .venv/bin/activate   # On Windows: .venv\Scripts\activate
+pip install -r requirements-dev.txt
+
+# Verify build compiles cleanly
+make build
+# Expected: no errors; binary or compiled output in [./bin/ or ./dist/]
+```
+
+---
+
+## 5. Database Setup and Seeding
+
+```bash
+# Run database migrations (creates tables and schema)
+make db-migrate
+# Or directly:
+# [Migration command — e.g. "go run ./cmd/migrate up" or "alembic upgrade head" or "npm run db:migrate"]
+
+# Verify migrations applied
+# psql $DATABASE_URL -c "\dt"  # should list all tables
+
+# Seed the database with development data
+make db-seed
+# Or directly:
+# [Seed command — e.g. "go run ./cmd/seed" or "python scripts/seed.py" or "npm run db:seed"]
+
+# Verify seed data is present
+# psql $DATABASE_URL -c "SELECT COUNT(*) FROM [primary-table]"
+# Expected: [N] rows
+```
+
+**What the seed creates:**
+- [N] test user accounts (credentials in [scripts/seed/README.md or .env.example])
+- [N] sample [resources] for development and testing
+- Admin account: `[admin@example.com]` / password: see `.env.example` for dev password variable
+
+**To reset to a clean state:**
+```bash
+docker compose down -v   # wipe database volume
+docker compose up -d     # start fresh
+make db-migrate
+make db-seed
+```
+
+---
+
+## 6. Running the Service
+
+```bash
+# Run the service locally
+make run
+# Or directly:
+# [Run command — e.g. "go run ./cmd/server" or "python app.py" or "npm run dev"]
+
+# Expected output:
+# [Example of healthy startup log lines — e.g.:]
+# {"level":"info","message":"Database connected","host":"localhost","port":5432}
+# {"level":"info","message":"Redis connected","host":"localhost","port":6379}
+# {"level":"info","message":"Server listening","port":8080}
+```
+
+### Verify It's Working
+
+```bash
+# Health check
+curl http://localhost:8080/health
+# Expected: {"status":"ok","version":"[git-sha]"}
+
+# Test a key endpoint (authenticated)
+# First, get a dev token:
+curl -X POST http://localhost:8080/api/v1/auth/login \
+  -H "Content-Type: application/json" \
+  -d '{"email":"[dev-user-from-seed]@example.com","password":"[dev-password-from-env]"}'
+# Copy the token from the response, then:
+
+curl http://localhost:8080/api/v1/[resource] \
+  -H "Authorization: Bearer [token-from-above]"
+# Expected: 200 with JSON response
+```
+
+### Hot Reload (for Development)
+
+```bash
+# Run with hot reload — service restarts automatically on file changes
+make run-dev
+# Or:
+# [Hot reload command — e.g. "air" for Go / "uvicorn --reload" for Python / "npm run dev" for Node]
+```
+
+---
+
+## 7. Running Tests
+
+```bash
+# Run the full test suite
+make test
+# Or:
+# [Test command — e.g. "go test ./..." or "pytest" or "npm test"]
+
+# Run tests with coverage report
+make test-coverage
+# Coverage report: [./coverage.html or stdout]
+
+# Run a specific test file or test case
+# Go: go test ./pkg/[package]/... -run TestFunctionName
+# Python: pytest tests/test_[module].py::TestClass::test_method -v
+# Node: npm test -- --testPathPattern=[filename]
+
+# Run only unit tests (fast — no external dependencies)
+make test-unit
+
+# Run only integration tests (requires Docker Compose dependencies running)
+make test-integration
+```
+
+**Expected test results:**
+- Unit tests: [N] tests, all pass, [<30] seconds
+- Integration tests: [N] tests, all pass, [<2] minutes
+- Coverage: [≥80]% (enforced in CI — tests fail below this threshold)
+
+**Before pushing a PR, always run:**
+```bash
+make lint      # code linting — must pass
+make test      # full test suite — must pass
+make build     # verify compilation — must pass
+```
+
+---
+
+## 8. IDE Setup
+
+### VS Code (Recommended)
+
+Install the recommended extensions (VS Code will prompt you automatically):
+
+```json
+// .vscode/extensions.json — already in the repository
+{
+  "recommendations": [
+    "[language-extension — e.g. golang.go]",
+    "dbaeumer.vscode-eslint",
+    "esbenp.prettier-vscode",
+    "ms-azuretools.vscode-docker",
+    "eamodio.gitlens"
+  ]
+}
+```
+
+Workspace settings are in `.vscode/settings.json` — format on save is enabled, linter is configured automatically.
+
+**[Language]-specific setup:**
+```
+[e.g. Go: The gopls language server is installed automatically by the Go extension.
+ Run "Go: Install/Update Tools" from the command palette after installing the extension.]
+```
+
+### JetBrains (IntelliJ / GoLand / PyCharm / WebStorm)
+
+- Open the project root as the project directory
+- [Language SDK]: set to [version] — File → Project Structure → SDKs
+- Run configurations are checked into `.idea/runConfigurations/` — they appear automatically
+- Enable "Run formatters on save" in Settings → Tools → Actions on Save
+
+---
+
+## 9. Common Gotchas and Troubleshooting
+
+### Docker container exits immediately on startup
+
+**Symptom:** `docker compose ps` shows a container as `Exited (1)` seconds after starting.
+
+```bash
+# Check the container logs for the error
+docker compose logs [container-name]
+
+# Common causes:
+# 1. Port already in use — find and kill the conflicting process:
+lsof -ti tcp:[port] | xargs kill -9
+
+# 2. Docker doesn't have enough memory — allocate at least 4GB in Docker Desktop:
+# Docker Desktop → Settings → Resources → Memory → 4GB
+
+# 3. M1/M2 Mac architecture mismatch — add platform directive to docker-compose.yml:
+# platform: linux/amd64
+```
+
+### Database connection refused
+
+**Symptom:** Service fails to start with "connection refused" or "dial tcp localhost:5432: connect: connection refused"
+
+```bash
+# Is PostgreSQL actually running?
+docker compose ps postgres
+# If not running: docker compose up -d postgres
+
+# Is it on the right port?
+lsof -i :5432
+
+# Can you connect manually?
+psql postgres://app:password@localhost:5432/[service]_dev -c "SELECT 1"
+
+# If using a custom DATABASE_URL, verify it matches the docker-compose.yml settings exactly
+```
+
+### Migrations fail with "relation already exists"
+
+**Symptom:** `make db-migrate` errors with "ERROR: relation [table] already exists"
+
+```bash
+# Check current migration state
+[migration status command — e.g. "go run ./cmd/migrate status" or "alembic current"]
+
+# The database may be in a partial state — reset it:
+docker compose down -v
+docker compose up -d
+make db-migrate  # should now succeed on a clean database
+```
+
+### Tests fail with "connection refused" or dependency errors
+
+**Symptom:** Integration tests fail because they cannot connect to PostgreSQL or Redis.
+
+```bash
+# Integration tests need Docker Compose running
+docker compose up -d
+
+# Verify all containers are healthy before running tests
+docker compose ps   # all should show "healthy"
+
+# If containers are running but tests still fail, check environment variables:
+make test-integration  # should pick up .env.local automatically
+# If not: source .env.local && make test-integration
+```
+
+### `make lint` fails on a fresh checkout
+
+**Symptom:** Lint errors on files you have not modified.
+
+```bash
+# Formatting issue — auto-fix with:
+# Go:
+gofmt -w .
+goimports -w .
+
+# Python:
+black .
+isort .
+
+# Node/TypeScript:
+npm run lint:fix
+# Or: npx eslint --fix . && npx prettier --write .
+
+# Re-run lint to confirm
+make lint
+```
+
+### Environment variables not loading
+
+**Symptom:** Service starts but immediately fails with "missing required environment variable: [VAR]"
+
+```bash
+# Verify .env.local exists and has all required variables
+cat .env.local | grep "^[A-Z]" | awk -F= '{print $1}'
+
+# Compare against required variables in .env.example
+diff <(grep "^[A-Z_]*=" .env.example | cut -d= -f1 | sort) \
+     <(grep "^[A-Z_]*=" .env.local | cut -d= -f1 | sort)
+
+# Missing variables are shown in left column only (< prefix)
+```
+
+---
+
+## 10. First Contribution Checklist
+
+Before opening your first pull request, verify:
+
+**Setup complete:**
+- [ ] `make build` passes with no errors
+- [ ] `make test` passes — all tests green
+- [ ] `make lint` passes — no lint errors
+- [ ] Service starts and health check returns 200
+- [ ] You can authenticate and call at least one API endpoint
+
+**Git and GitHub:**
+- [ ] You have read [CONTRIBUTING.md] — code standards, commit message format, PR process
+- [ ] Your git user.name and user.email are set correctly
+- [ ] Pre-commit hooks are installed (`ls .git/hooks/pre-commit` should exist)
+- [ ] You have branched from `main` (not committing directly to main)
+
+**Development workflow:**
+- [ ] You know how to run a specific test: `[test command for single test]`
+- [ ] You know how to reset the database: `docker compose down -v && docker compose up -d && make db-migrate && make db-seed`
+- [ ] You have joined [Slack: #[team-channel]] and [#[service-consumers-channel] if applicable]
+- [ ] You have read the [architecture overview doc / README] — you understand what this service does
+
+**First PR:**
+- [ ] Changes are small and focused — one logical change per PR
+- [ ] Tests are added or updated for your change
+- [ ] `make test && make lint && make build` all pass locally before requesting review
+- [ ] PR description explains what changed and why (use the [pr-description-writer skill] if needed)
+
+---
+
+## Quality Checks
+
+- [ ] A new engineer with no prior knowledge of the project can follow this guide from start to finish without asking anyone for help
+- [ ] Every command is tested on a clean environment — not written from memory and assumed to work
+- [ ] Environment variables table covers every variable in `.env.example` — no undocumented variables
+- [ ] The troubleshooting section covers the 5 most common real failures observed during onboarding — not theoretical issues
+- [ ] Docker Compose version and Docker Desktop memory requirements are stated explicitly
+- [ ] "Expected output" is shown for key commands so engineers know whether a step succeeded
+- [ ] Setup time estimate is honest — verified by timing a real onboarding session, not estimated
@@ -0,0 +1,290 @@
+---
+name: microservices-decomposition
+description: "Design a microservices decomposition for a monolith or new system, defining service boundaries, ownership, communication patterns, and migration plan. Use when asked to decompose a monolith, define service boundaries, design a microservices architecture, or plan a strangler-fig migration. Produces a bounded context map, service inventory table, communication pattern decisions, data ownership matrix, migration roadmap, and risk register."
+---
+
+# Microservices Decomposition
+
+Produce a complete microservices decomposition design for a system — whether decomposing an existing monolith or designing service boundaries for a new system. Ground the decomposition in Domain-Driven Design (DDD) concepts: identify bounded contexts first, then derive service boundaries from them. Include communication pattern decisions (sync vs. async, event vs. RPC), data ownership rules, and a pragmatic migration plan if decomposing a monolith. Conway's Law is real — include an organizational alignment section. The deliverable should be specific enough that a team can begin implementation, not an abstract architectural diagram.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **System or domain description** — what the system does, its core domain, and the key business processes it supports
+- **Current architecture** — monolith (describe the tech stack and rough module structure), partial services (list existing services), or greenfield
+- **Team structure** — number of teams, team names if known, and approximate team sizes; this drives service ownership
+- **Performance and scalability requirements** — any specific SLAs, load characteristics, or scaling constraints per domain area
+- **Migration constraints** — what cannot be rewritten all at once, hard deadlines, zero-downtime requirements, budget constraints
+- **Integration points** — external systems, third-party APIs, or legacy systems that cannot be changed
+
+If decomposing a monolith, also ask for: approximate codebase size, what is most painful to change today, and where the team experiences the most coupling-related friction.
+
+## Output Format
+
+---
+
+# Microservices Decomposition: [System Name]
+
+**Author:** [Name / Team]
+**Date:** [Date]
+**Architecture type:** [Monolith decomposition / New system design]
+**Current state:** [One sentence describing what exists today]
+**Target state:** [One sentence describing the desired end state]
+
+---
+
+## 1. Domain Analysis
+
+### Core Domain
+
+[One paragraph: what is the core domain of this system? What does the business fundamentally do? What gives it competitive differentiation? The core domain gets the most investment and the cleanest service boundaries.]
+
+### Domain Map
+
+List every significant subdomain before assigning service boundaries. Classify each subdomain:
+
+| Subdomain | Type | Description | Current Location in Monolith |
+|-----------|------|-------------|------------------------------|
+| [Subdomain, e.g., Order Management] | Core | [What it does and why it matters] | [Module/package name or "new"] |
+| [Subdomain, e.g., Inventory] | Core | [Description] | [Location] |
+| [Subdomain, e.g., Notifications] | Supporting | [Description] | [Location] |
+| [Subdomain, e.g., Billing] | Supporting | [Description] | [Location] |
+| [Subdomain, e.g., Reporting] | Generic | [Description — candidates for off-the-shelf solutions] | [Location] |
+| [Subdomain, e.g., User Auth] | Generic | [Description] | [Location] |
+
+**Subdomain types:** Core = competitive differentiation, build with care; Supporting = necessary but not differentiating, build pragmatically; Generic = commodity, buy or use open source.
+
+---
+
+## 2. Bounded Context Map (ASCII)
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                        [System Name]                            │
+│                                                                 │
+│  ┌──────────────────┐    ┌──────────────────┐                  │
+│  │  [Context A]     │    │  [Context B]      │                  │
+│  │                  │─ ─►│                  │                  │
+│  │  [key concepts]  │    │  [key concepts]  │                  │
+│  └──────────────────┘    └──────────────────┘                  │
+│           │                       │                             │
+│           │ event                 │ sync                        │
+│           ▼                       ▼                             │
+│  ┌──────────────────┐    ┌──────────────────┐                  │
+│  │  [Context C]     │    │  [Context D]      │                  │
+│  │                  │    │                  │                  │
+│  │  [key concepts]  │    │  [key concepts]  │                  │
+│  └──────────────────┘    └──────────────────┘                  │
+│                                   │                             │
+│                          ┌────────┘                             │
+│                          ▼                                      │
+│                 ┌──────────────────┐                            │
+│                 │  [Context E]     │                            │
+│                 │  [key concepts]  │                            │
+│                 └──────────────────┘                            │
+│                                                                 │
+│  External: [Third-party system] ──► [Context that owns it]      │
+└─────────────────────────────────────────────────────────────────┘
+
+Legend:  ──► sync call   - -► async event   ═══ shared kernel
+```
+
+Render this map using the actual bounded contexts derived from the domain analysis. Place contexts that communicate frequently closer together. Label relationship types on arrows.
+
+### Context Relationships
+
+| Upstream Context | Downstream Context | Relationship Type | Integration Pattern |
+|-----------------|-------------------|------------------|---------------------|
+| [Context A] | [Context B] | Customer-Supplier | REST API call |
+| [Context B] | [Context C] | Published Language | Domain events via message bus |
+| [Context X] | [Context Y] | Conformist | [Downstream conforms to upstream's model] |
+| [Context X] | [Context Y] | Anti-Corruption Layer | [ACL translates upstream model to local model] |
+
+---
+
+## 3. Proposed Service Inventory
+
+| Service Name | Bounded Context | Core Responsibility | Team Owner | Tech Stack | Priority |
+|-------------|----------------|--------------------|-----------|-----------|---------| 
+| [service-name] | [Context] | [One sentence: what this service owns and does] | [Team] | [Language/framework] | [P1/P2/P3] |
+| [service-name] | [Context] | [Responsibility] | [Team] | [Stack] | [Priority] |
+| [service-name] | [Context] | [Responsibility] | [Team] | [Stack] | [Priority] |
+| [service-name] | [Context] | [Responsibility] | [Team] | [Stack] | [Priority] |
+| [service-name] | [Context] | [Responsibility] | [Team] | [Stack] | [Priority] |
+
+**Service count:** [N proposed services] for [M bounded contexts]. [Note if any context maps to multiple services and why — e.g., "the Orders context splits into order-intake and order-fulfillment because they have different scalability requirements."]
+
+### Service Responsibility Rules (applied to every service above)
+
+- Single bounded context ownership — a service does not straddle two bounded contexts
+- Owns its own data — no direct database access by other services
+- Independently deployable — no coordinated deploys required with other services
+- Has a named team owner — no shared ownership of a single service across teams
+- Exposes a defined API contract — not internal implementation
+
+---
+
+## 4. Inter-Service Communication Patterns
+
+### Pattern Decision Matrix
+
+| Communication Need | Recommended Pattern | Rationale |
+|-------------------|--------------------|-----------| 
+| Query another service's current state | Synchronous REST / gRPC | Low latency required; caller needs immediate response |
+| Notify other services of a state change | Async domain event | Decouples services; multiple consumers; sender doesn't care when it's processed |
+| Long-running workflow spanning services | Async saga (choreography or orchestration) | No single service owns the full workflow; rollback needed if steps fail |
+| Read-heavy cross-service aggregation | CQRS read model / materialized view | Avoid chatty sync calls at read time; build purpose-fit read models |
+| Real-time push to clients | WebSocket gateway service | Centralizes connection management; services emit events, gateway pushes |
+
+### Per-Service Communication Decisions
+
+| Service | Calls (sync) | Publishes (events) | Subscribes to (events) |
+|---------|-------------|-------------------|----------------------|
+| [service-name] | [service-name (endpoint)] | [EventName] | [EventName] |
+| [service-name] | — | [EventName], [EventName] | [EventName] |
+| [service-name] | [service-name (endpoint)] | — | [EventName] |
+
+### Event Catalog
+
+| Event Name | Producer | Consumers | Payload (key fields) | Trigger |
+|-----------|---------|---------|---------------------|---------|
+| [OrderPlaced] | [order-service] | [inventory-service, notification-service] | `orderId, customerId, lineItems, totalAmount` | Customer submits order |
+| [InventoryReserved] | [inventory-service] | [order-service] | `orderId, reservationId, items` | Inventory successfully reserved |
+| [PaymentProcessed] | [payment-service] | [order-service, notification-service] | `orderId, paymentId, amount, status` | Payment confirmed |
+
+---
+
+## 5. Data Ownership Matrix
+
+Each piece of data has exactly one owning service. Other services may cache or project a read model, but they do not write to the owner's database.
+
+| Data Entity | Owner Service | Authoritative Store | Consumers | Access Pattern |
+|-------------|--------------|--------------------|-----------| ---------------|
+| [Order] | [order-service] | [PostgreSQL] | [fulfillment-service, reporting-service] | Event subscription + read API |
+| [Customer] | [customer-service] | [PostgreSQL] | [order-service, notification-service] | Sync API call |
+| [Product Catalog] | [catalog-service] | [PostgreSQL] | [order-service, inventory-service] | Sync API + cached local copy |
+| [Inventory Level] | [inventory-service] | [Redis + PostgreSQL] | [catalog-service (read only)] | Event subscription |
+| [Payment Record] | [payment-service] | [PostgreSQL] | [order-service] | Event subscription |
+
+### Data Migration (if decomposing a monolith)
+
+| Data Entity | Current Location | Target Service | Migration Approach | Data Volume | Risk |
+|-------------|-----------------|---------------|-------------------|-------------|------|
+| [Entity] | [monolith.orders table] | [order-service] | Dual-write then cut over | [X rows] | [High/Med/Low] |
+| [Entity] | [monolith.users table] | [customer-service] | Extract and sync via CDC | [X rows] | [High/Med/Low] |
+
+---
+
+## 6. API Contract Definitions
+
+Define the surface area for each service. Full OpenAPI specs are written separately; this section establishes the contract boundaries.
+
+### [service-name] API
+
+**Base path:** `/api/v1/[resource]`
+**Owner team:** [Team]
+**SLA:** [p99 latency target, availability target]
+
+| Endpoint | Method | Description | Auth Required | Rate Limit |
+|----------|--------|-------------|--------------|------------|
+| `/[resources]` | GET | List [resources] with pagination | Yes | [X req/min] |
+| `/[resources]/{id}` | GET | Get single [resource] by ID | Yes | [X req/min] |
+| `/[resources]` | POST | Create new [resource] | Yes | [X req/min] |
+| `/[resources]/{id}` | PUT | Update [resource] | Yes | [X req/min] |
+| `/[resources]/{id}` | DELETE | Soft-delete [resource] | Yes — elevated | [X req/min] |
+
+[Repeat for each service.]
+
+---
+
+## 7. Strangler Fig Migration Plan (for monolith decomposition)
+
+Use the strangler fig pattern: extract services incrementally, route traffic through a facade, and retire monolith modules one at a time.
+
+### Migration Phases
+
+```
+Phase 1: Foundation (Weeks 1–[N])
+  - Deploy service infrastructure (CI/CD, observability, service mesh)
+  - Extract lowest-risk, highest-value service first
+  - Monolith continues to serve all traffic
+
+Phase 2: First Extractions (Weeks [N]–[M])
+  - Extract P1 services
+  - API gateway routes selected traffic to new services
+  - Monolith handles remaining traffic via facade pattern
+  - Both paths write to shared DB during transition (dual-write)
+
+Phase 3: Core Domain Services (Weeks [M]–[P])
+  - Extract P1 core domain services
+  - Data migration for extracted services
+  - Remove dual-write paths for completed migrations
+
+Phase 4: Monolith Retirement (Weeks [P]–[Q])
+  - Extract remaining services
+  - Monolith serves no production traffic
+  - Decommission monolith infrastructure
+```
+
+### Phase-by-Phase Roadmap
+
+| Phase | Service to Extract | Migration Approach | Team | Duration | Dependencies | Success Criteria |
+|-------|------------------|--------------------|------|----------|-------------|-----------------|
+| 1 | [service-name] | [Strangler facade / Branch by abstraction / Event interception] | [Team] | [X weeks] | [Infra ready, CI/CD pipeline] | [Traffic fully on new service, zero errors for 2 weeks] |
+| 2 | [service-name] | [Approach] | [Team] | [X weeks] | [Phase 1 complete] | [Success metric] |
+| 3 | [service-name] | [Approach] | [Team] | [X weeks] | [Phase 2 complete] | [Success metric] |
+
+### Rollback Plan
+
+For each migration phase, define the rollback trigger and mechanism:
+- **Rollback trigger:** Error rate on new service > [X%] sustained for [Y minutes], or p99 latency > [threshold]
+- **Rollback mechanism:** API gateway feature flag reverts all traffic to monolith path in < 5 minutes
+- **Data rollback:** Dual-write maintained for [X weeks] after cutover to allow replay if needed
+
+---
+
+## 8. Organizational Alignment (Conway's Law)
+
+Conway's Law: the architecture of a system mirrors the communication structure of the organization that builds it. Design service ownership to match team boundaries — or change the team boundaries.
+
+| Service | Proposed Owner Team | Current Team Assignment | Change Required |
+|---------|--------------------|-----------------------|-----------------|
+| [service-name] | [Team A] | [Same / Different] | [No change / Transfer to Team A / New team needed] |
+| [service-name] | [Team B] | [Team A currently] | [Transfer ownership] |
+
+**Misalignments identified:**
+- [Misalignment 1: e.g., "The notification service spans two teams today. Assign it entirely to Team B which already owns the messaging domain."]
+- [Misalignment 2: e.g., "The reporting service is owned by Data Eng but consumers are Product teams — establish a clear API contract and SLA."]
+
+**Team topology recommendation:** [Describe the recommended team structure — stream-aligned teams, platform team, enabling team — and how it maps to the proposed services.]
+
+---
+
+## 9. Risk Register
+
+| Risk | Likelihood | Impact | Mitigation | Owner |
+|------|-----------|--------|-----------|-------|
+| Data consistency across services during migration | High | High | Dual-write with reconciliation job; event sourcing for critical domains | [Name] |
+| Distributed transaction complexity (sagas) | Medium | High | Start with choreography; add orchestration only when choreography becomes unmanageable | [Name] |
+| Service mesh operational overhead | Medium | Medium | Start without a mesh; add after 5+ services deployed | [Name] |
+| Network latency replacing in-process calls | Medium | Medium | Cache aggressively; design read models to avoid chatty sync calls | [Name] |
+| Conway's Law friction during transition | High | Medium | Align team structure before starting extraction, not after | [Name] |
+| Over-decomposition (nanoservices) | Medium | High | Enforce minimum service size rule: a service must justify its own team/deployment overhead | [Name] |
+| Observability gaps during migration | High | High | Deploy distributed tracing before first extraction; establish correlation IDs | [Name] |
+| [Context-specific risk] | [Level] | [Level] | [Mitigation] | [Owner] |
+
+---
+
+*Questions about this design: [Slack channel or contact]*
+
+---
+
+## Quality Checks
+
+- [ ] Bounded context map is an ASCII diagram with labeled relationships — not a prose description of the contexts
+- [ ] Every service in the inventory table has a named team owner and a clear single-sentence responsibility statement
+- [ ] Data ownership matrix assigns every key entity to exactly one owning service — no shared ownership
+- [ ] Communication pattern decisions explain WHY sync vs. async was chosen for each interaction type
+- [ ] If decomposing a monolith, the strangler fig migration plan has phases with durations, dependencies, and success criteria
+- [ ] Risk register addresses at minimum: data consistency, distributed transactions, and Conway's Law alignment
+- [ ] Organizational alignment section maps services to teams and identifies misalignments that need to be resolved
@@ -0,0 +1,436 @@
+---
+name: monitoring-setup-guide
+description: "Write a monitoring setup guide for a service — defining what to measure, how to alert on it, and how to build the observability stack covering the four golden signals, business metrics, log strategy, distributed tracing, alerting rules, dashboard layout, and observability debt. Use when asked to set up monitoring for a service, define alerting strategy, write an observability plan, create a dashboard specification, or document logging standards for a team. Produces a metric definitions table, alert rules specification, dashboard layout wireframe, log schema, tracing setup checklist, and monitoring gap analysis."
+---
+
+# Monitoring Setup Guide Skill
+
+Produce a complete monitoring setup guide for a service — defining exactly what to measure, how to structure logs, how to configure alerts with actionable thresholds, and how to build dashboards that answer real operational questions. A good monitoring guide eliminates "we don't know what's happening in production" as a root cause category, and gives on-call engineers a single source of truth for what healthy looks like.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name and description** — what the service does and its role in the system
+- **Tech stack** — language, framework, and infrastructure (e.g. Go/gRPC on Kubernetes, Python/FastAPI on ECS)
+- **Current monitoring tooling** — Datadog, Prometheus + Grafana, CloudWatch, New Relic, Honeycomb, or none yet
+- **Key user journeys** — the 2–4 most important things a user or consumer does with the service (these drive what to alert on)
+- **Existing alerts** — paste any existing alert configurations or describe what's currently monitored
+
+## Output Format
+
+---
+
+# Monitoring Setup Guide: [Service Name]
+
+**Team:** [Team name] | **Tech lead:** [Name]
+**Stack:** [Language/Framework] on [Infrastructure]
+**Monitoring platform:** [Datadog / Prometheus+Grafana / CloudWatch / etc.]
+**Date:** [Date] | **Review cycle:** Quarterly
+
+---
+
+## 1. Monitoring Philosophy
+
+Good monitoring answers three questions:
+1. **Is the service healthy right now?** (alerting)
+2. **Was it healthy in the past, and is it trending worse?** (dashboards + SLO tracking)
+3. **Why did something fail?** (logs + traces)
+
+This guide defines the answers for [Service Name]. Every alert must be actionable — if an on-call engineer cannot take a specific action in response to the alert, the alert should not exist.
+
+**Key user journeys monitored:**
+- Journey 1: [e.g. "User submits a payment — POST /charges, receives confirmation"]
+- Journey 2: [e.g. "User views transaction history — GET /transactions"]
+- Journey 3: [e.g. "Subscription renewal job runs — background worker processes billing events"]
+
+---
+
+## 2. The Four Golden Signals
+
+Apply the four golden signals specifically to [Service Name]:
+
+### Latency
+
+Latency measures how long requests take to complete. Track it separately for successful and failed requests — slow failures hide behind fast errors if you only measure aggregate latency.
+
+| Metric | Description | Source | Dimensions |
+|---|---|---|---|
+| `[service].request.duration_ms` | End-to-end request latency | Application instrumentation | `endpoint`, `method`, `status_code` |
+| `[service].db.query_duration_ms` | Database query latency | ORM / query instrumentation | `query_name`, `table` |
+| `[service].external.request_duration_ms` | Outbound call latency to dependencies | HTTP client instrumentation | `target_service`, `endpoint` |
+| `[service].queue.processing_duration_ms` | Time to process one message (if applicable) | Consumer instrumentation | `queue_name`, `message_type` |
+
+**Latency SLO targets:**
+
+| Endpoint / operation | p50 target | p95 target | p99 target |
+|---|---|---|---|
+| `GET /api/v1/[resource]` | < [50] ms | < [200] ms | < [500] ms |
+| `POST /api/v1/[resource]` | < [100] ms | < [400] ms | < [1000] ms |
+| `GET /health` | < [10] ms | < [20] ms | < [50] ms |
+| [Background job name] | < [5] sec | < [15] sec | < [60] sec |
+
+### Traffic
+
+Traffic measures demand on the system. Use it to detect unexpected spikes, traffic drops (which can indicate upstream failures), and to capacity-plan.
+
+| Metric | Description | Source |
+|---|---|---|
+| `[service].request.count` | Requests per second | Application / load balancer |
+| `[service].request.count_by_endpoint` | RPS broken down by endpoint | Application |
+| `[service].queue.messages_consumed_per_second` | Consumer throughput | Queue consumer |
+| `[service].queue.depth` | Messages waiting in queue | Queue metrics |
+
+**Traffic baselines (update after observing production for 2+ weeks):**
+
+| Time period | Expected RPS | Low-traffic floor | Spike ceiling |
+|---|---|---|---|
+| Peak (weekday business hours) | [N] RPS | [N × 0.5] RPS | [N × 5] RPS |
+| Off-peak (nights/weekends) | [N × 0.2] RPS | [N × 0.05] RPS | [N] RPS |
+
+### Errors
+
+Errors measure the fraction of requests that fail. Distinguish between client errors (4xx — caller is doing something wrong) and server errors (5xx — the service is broken).
+
+| Metric | Description | Alert on? |
+|---|---|---|
+| `[service].request.error_rate` | 5xx errors / total requests | Yes — see alert rules |
+| `[service].request.client_error_rate` | 4xx errors / total requests | Threshold alert — sudden spike may indicate API misuse |
+| `[service].dependency.error_rate` | Errors calling downstream dependencies | Yes — upstream health signal |
+| `[service].queue.dlq_depth` | Messages in dead-letter queue | Yes — indicates processing failures |
+
+### Saturation
+
+Saturation measures how "full" the service is — how close to maximum capacity are the constrained resources.
+
+| Resource | Metric | Alert threshold | Source |
+|---|---|---|---|
+| CPU | `[service].cpu.utilisation_pct` | >80% sustained 5 min | Container / VM metrics |
+| Memory | `[service].memory.utilisation_pct` | >85% sustained 5 min | Container / VM metrics |
+| DB connections | `[service].db.connection_pool.utilisation_pct` | >75% | Application / DB metrics |
+| Thread pool / goroutines | `[service].runtime.goroutine_count` / `thread_count` | >N (establish baseline) | Runtime metrics |
+| Disk (if applicable) | `[service].disk.utilisation_pct` | >75% | Infrastructure |
+| Queue depth (if applicable) | `[service].queue.depth` | >[backlog threshold] | Queue metrics |
+
+---
+
+## 3. Business Metrics
+
+Beyond the golden signals, track metrics that measure whether the service is delivering business value. These matter for SLO reporting and product dashboards.
+
+| Metric | Description | Source | Alert? |
+|---|---|---|---|
+| `[service].[primary_action].success_rate` | [e.g. "Payment success rate"] | Application | Yes — if drops >5% vs 1h average |
+| `[service].[primary_action].count` | [e.g. "Payments processed per minute"] | Application | Yes — sudden drop (traffic anomaly) |
+| `[service].[resource].created_per_hour` | [e.g. "New accounts created"] | Application / DB | No — informational |
+| `[service].cache.hit_rate` | Fraction of requests served from cache | Cache instrumentation | Yes — if drops below [60]% |
+| `[service].job.[name].success_rate` | [Background job success rate] | Job framework | Yes — if drops below [99]% |
+
+---
+
+## 4. Log Strategy
+
+### Structured Logging Schema
+
+All logs must be structured JSON. Do not emit unstructured text logs in production. Every log line must include the mandatory fields.
+
+**Mandatory fields (every log line):**
+
+```json
+{
+  "timestamp": "2024-01-15T10:23:45.123Z",
+  "level": "info",
+  "service": "[service-name]",
+  "version": "[git-sha-short]",
+  "trace_id": "[uuid-from-request-context]",
+  "span_id": "[span-uuid]",
+  "request_id": "[uuid-per-request]",
+  "message": "[human readable description]"
+}
+```
+
+**Request log (emit for every HTTP request):**
+
+```json
+{
+  "timestamp": "...",
+  "level": "info",
+  "service": "[service-name]",
+  "event": "http_request",
+  "method": "POST",
+  "path": "/api/v1/[resource]",
+  "status_code": 201,
+  "duration_ms": 45,
+  "user_id": "[uuid — DO NOT log PII directly]",
+  "request_id": "[uuid]",
+  "trace_id": "[uuid]"
+}
+```
+
+**Error log (emit for every error with context):**
+
+```json
+{
+  "timestamp": "...",
+  "level": "error",
+  "service": "[service-name]",
+  "event": "error",
+  "error_code": "[application-error-code]",
+  "error_message": "[description — no sensitive data]",
+  "stack_trace": "[stack trace]",
+  "request_id": "[uuid]",
+  "trace_id": "[uuid]",
+  "context": {
+    "[key]": "[relevant context without PII]"
+  }
+}
+```
+
+### Log Levels — When to Use Each
+
+| Level | Use when | Example |
+|---|---|---|
+| `error` | Something failed that requires attention — this should page on-call eventually | Database query failed, external API returned 5xx, required config missing |
+| `warn` | Something unexpected happened but service is still functioning | Retry succeeded after failure, cache miss on expected hit, rate limit approaching |
+| `info` | Significant business events and request lifecycle | Request received, payment processed, user authenticated, job started/completed |
+| `debug` | Detailed diagnostic information — off in production by default | Query parameters, intermediate computation results, cache key lookups |
+
+### What NOT to Log
+
+**Never log:**
+- Passwords, tokens, API keys, or secrets (even hashed)
+- Full credit card numbers or PAN data
+- Social security numbers or government IDs
+- Full names + dates of birth + contact info in the same log line (PII aggregation)
+- Request/response bodies in full (use field-level extraction instead)
+- Health check requests (too noisy — exclude `GET /health` from access logs)
+
+---
+
+## 5. Distributed Tracing Setup
+
+Distributed tracing is mandatory for any service that calls other services. It enables root-cause analysis across service boundaries.
+
+### Instrumentation Checklist
+
+```
+[ ] Tracing library installed:
+    - Go: go.opentelemetry.io/otel
+    - Python: opentelemetry-sdk, opentelemetry-instrumentation
+    - Node: @opentelemetry/sdk-node
+    - Java: opentelemetry-java-instrumentation
+
+[ ] Tracer initialized at service startup with service name and version
+
+[ ] Trace context propagated via W3C Trace Context headers:
+    traceparent: 00-[trace-id]-[span-id]-01
+    tracestate: [optional vendor-specific]
+
+[ ] Automatic instrumentation enabled for:
+    [ ] Inbound HTTP/gRPC requests (creates root span)
+    [ ] Outbound HTTP/gRPC calls (creates child spans)
+    [ ] Database queries (creates child spans with sanitized query)
+    [ ] Cache operations (Redis, Memcached)
+    [ ] Message queue produce/consume
+
+[ ] Custom spans added for:
+    [ ] Key business operations ([e.g. payment processing, user lookup])
+    [ ] Background jobs (each job execution = root span)
+    [ ] Third-party API calls with custom attributes
+
+[ ] Span attributes to capture on all spans:
+    - user.id (if authenticated — no PII)
+    - deployment.environment (production/staging)
+    - service.version (git SHA)
+    - [service-specific key attributes]
+
+[ ] Trace exporter configured to: [Datadog / Jaeger / Tempo / OTLP endpoint]
+
+[ ] Sampling rate configured:
+    - Production: [1–10]% of requests (adjust based on volume and cost)
+    - Always sample: errors, slow requests (>p99 threshold), and 100% of [critical endpoint]
+```
+
+### Trace Instrumentation Examples
+
+```python
+# Python — OpenTelemetry example
+from opentelemetry import trace
+
+tracer = trace.get_tracer("[service-name]")
+
+def process_payment(payment_data):
+    with tracer.start_as_current_span("process_payment") as span:
+        span.set_attribute("payment.amount_cents", payment_data["amount"])
+        span.set_attribute("payment.currency", payment_data["currency"])
+        # Never: span.set_attribute("payment.card_number", ...)
+        try:
+            result = _do_process(payment_data)
+            span.set_status(trace.StatusCode.OK)
+            return result
+        except PaymentError as e:
+            span.set_status(trace.StatusCode.ERROR, str(e))
+            span.record_exception(e)
+            raise
+```
+
+---
+
+## 6. Alert Rules Specification
+
+Every alert must have: a name, a condition, a threshold, a severity, and a clear on-call action. Alerts without a clear action should not exist.
+
+### Alert Definitions
+
+| Alert name | Condition | Threshold | Severity | On-call action |
+|---|---|---|---|---|
+| `[Service]HighErrorRate` | 5xx error rate, 5-min rolling window | >1% for 2 consecutive windows | P1 | Check recent deploys; inspect error logs; see runbook [link] |
+| `[Service]CriticalErrorRate` | 5xx error rate, 2-min rolling window | >5% | P1 — immediate | Same as above — page immediately, do not wait |
+| `[Service]HighP99Latency` | p99 latency on key endpoints | >2× SLO target for 3 min | P2 | Check DB latency, cache hit rate, and upstream dependencies |
+| `[Service]LatencySLOBreach` | p99 latency | >SLO target for 5 consecutive minutes | P1 | SLO burn — page on-call, escalate if not resolved in 20 min |
+| `[Service]HighCPU` | CPU utilisation | >80% sustained for 5 min | P2 | Check for traffic spike; scale up if needed; check for runaway processes |
+| `[Service]HighMemory` | Memory utilisation | >85% sustained for 5 min | P2 | Check for memory leak (especially after deploys); restart pod if OOM imminent |
+| `[Service]DBConnectionPoolHigh` | DB connection pool utilisation | >75% | P2 | Check for long-running queries; consider scaling service or increasing pool size |
+| `[Service]DLQDepthHigh` | Dead-letter queue depth | >10 messages | P2 | Inspect DLQ messages for error pattern; fix bug and replay if safe |
+| `[Service]TrafficDropAnomaly` | RPS, compared to same hour yesterday | >50% drop sustained 5 min | P1 | Upstream may be down; check caller health; check load balancer |
+| `[Service]PrimaryActionSuccessRateDrop` | [Business metric success rate] | <[95]% over 10 min | P1 | [Service-specific action — e.g. "Check payment provider status"] |
+| `[Service]DownstreamDependencyErrors` | Error rate calling [dependency] | >5% over 5 min | P2 | Check [dependency] status page; enable fallback if available |
+
+### Alert Configuration Examples
+
+```yaml
+# Prometheus / Grafana alerting rules (adapt for your platform)
+groups:
+  - name: [service-name]-alerts
+    rules:
+
+      - alert: [Service]HighErrorRate
+        expr: |
+          (
+            sum(rate([service]_http_requests_total{status=~"5.."}[5m]))
+            /
+            sum(rate([service]_http_requests_total[5m]))
+          ) > 0.01
+        for: 2m
+        labels:
+          severity: critical
+          team: [team-name]
+        annotations:
+          summary: "High error rate on [Service Name]"
+          description: "Error rate is {{ $value | humanizePercentage }} (threshold: 1%)"
+          runbook_url: "[runbook link]"
+
+      - alert: [Service]HighP99Latency
+        expr: |
+          histogram_quantile(0.99,
+            sum(rate([service]_http_request_duration_seconds_bucket[5m])) by (le, endpoint)
+          ) > [0.5]
+        for: 3m
+        labels:
+          severity: warning
+          team: [team-name]
+        annotations:
+          summary: "p99 latency elevated on [Service Name]"
+          description: "p99 latency on {{ $labels.endpoint }} is {{ $value | humanizeDuration }}"
+          runbook_url: "[runbook link]"
+```
+
+```python
+# Datadog monitor configuration (Python SDK or Terraform)
+import datadog
+
+datadog.initialize(api_key="[key]", app_key="[key]")
+
+datadog.api.Monitor.create(
+    type="metric alert",
+    query=f"sum(last_5m):sum:{{service}}.http.errors{{service:[service-name]}} / sum:{{service}}.http.requests{{service:[service-name]}} > 0.01",
+    name="[Service] High Error Rate",
+    message="Error rate exceeded 1%. @pagerduty-[service-oncall]\n\nRunbook: [link]",
+    tags=["service:[service-name]", "team:[team-name]"],
+    options={
+        "thresholds": {"critical": 0.01, "warning": 0.005},
+        "notify_no_data": False,
+        "evaluation_delay": 60,
+    }
+)
+```
+
+---
+
+## 7. Dashboard Layout Specification
+
+The primary service dashboard must answer "is the service healthy right now?" at a glance. Use this layout:
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│  [SERVICE NAME] — Service Health Dashboard           [Time range ▼] │
+├───────────────┬───────────────┬───────────────┬─────────────────────┤
+│  Error rate   │  p99 Latency  │  RPS (current)│  SLO budget remaining│
+│  [BIG NUMBER] │  [BIG NUMBER] │  [BIG NUMBER] │  [BIG NUMBER / days] │
+│  vs SLO: 0.1% │  vs SLO: 500ms│  vs avg: [N]  │  [Error budget gauge]│
+├───────────────┴───────────────┴───────────────┴─────────────────────┤
+│                   Error rate over time (24h)                        │
+│  [Time series: 5xx rate line, SLO threshold line]                   │
+├─────────────────────────────────┬───────────────────────────────────┤
+│  Latency percentiles over time  │  Request throughput over time     │
+│  [Lines: p50, p95, p99, p999]   │  [Bars: RPS by endpoint]          │
+│  [SLO threshold horizontal line]│                                   │
+├─────────────────────────────────┴───────────────────────────────────┤
+│  Latency heatmap (all requests — shows distribution shape)          │
+├─────────────────────────────────┬───────────────────────────────────┤
+│  CPU utilisation over time      │  Memory utilisation over time     │
+│  [All instances/pods — lines]   │  [All instances/pods — lines]     │
+│  [Alert threshold: 80%]         │  [Alert threshold: 85%]           │
+├─────────────────────────────────┴───────────────────────────────────┤
+│  DB: connection pool utilisation│  DB: query latency (p99 per query)│
+├─────────────────────────────────┴───────────────────────────────────┤
+│  [Business metric 1 over time]  │  [Business metric 2 over time]    │
+│  e.g. Payment success rate      │  e.g. Orders created/min          │
+└─────────────────────────────────┴───────────────────────────────────┘
+```
+
+**Second dashboard — Dependency Health:**
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│  [SERVICE NAME] — Dependency Health                                 │
+├─────────────────────────────────────────────────────────────────────┤
+│  For each dependency: error rate | latency | current status         │
+│  [Database]    [N]% errors | [N]ms p99 | ● Healthy / ⚠ Degraded    │
+│  [Redis]       [N]% errors | [N]ms p99 | ● Healthy                 │
+│  [External API][N]% errors | [N]ms p99 | ● Healthy                 │
+├─────────────────────────────────────────────────────────────────────┤
+│  Outbound call latency over time (one line per dependency)          │
+├─────────────────────────────────────────────────────────────────────┤
+│  Circuit breaker / fallback state (if implemented)                  │
+└─────────────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## 8. Observability Debt Analysis
+
+Honest assessment of what is missing today and what the priority to add it is:
+
+| Gap | Impact | Priority | Effort | Owner | Target date |
+|---|---|---|---|---|---|
+| [e.g. No distributed tracing — can't see cross-service latency] | High — blind to dependency issues | P1 | [2 days] | [Name] | [Date] |
+| [e.g. No business metric alerts — only infra alerts] | High — silent business failures | P1 | [1 day] | [Name] | [Date] |
+| [e.g. Logs are unstructured text — not searchable] | Medium — slow incident investigation | P2 | [3 days] | [Name] | [Date] |
+| [e.g. No dead-letter queue monitoring] | Medium — failed messages go unnoticed | P2 | [4 hours] | [Name] | [Date] |
+| [e.g. Alert thresholds not calibrated to production baseline] | Medium — alert fatigue or missed alerts | P2 | [1 day] | [Name] | [Date] |
+| [e.g. No latency heatmap — outliers invisible in averages] | Low — harder to spot tail latency issues | P3 | [2 hours] | [Name] | [Date] |
+
+**Total observability debt: [N] items | Estimated effort: [N days]**
+
+---
+
+## Quality Checks
+
+- [ ] Every alert has a named on-call action — no alert says "investigate" without specifying what to investigate first
+- [ ] Alert thresholds are calibrated against production baselines, not set to default values from a template
+- [ ] Structured logging is implemented — no unstructured text log lines in production
+- [ ] PII is explicitly excluded from logs — a named engineer has verified this
+- [ ] Distributed tracing is propagating trace IDs across all service boundaries (verify with a test request)
+- [ ] The primary dashboard answers "is the service healthy?" in under 10 seconds — no hunting for the right panel
+- [ ] Business metrics are tracked alongside infrastructure metrics — not just four golden signals
+- [ ] Observability debt items have owners and dates — not just "would be nice to have"
@@ -0,0 +1,277 @@
+---
+name: performance-budget
+description: "Define and document performance budgets for a web service or application. Use when asked to set performance targets, define SLOs for latency or throughput, establish Core Web Vitals targets, create a performance baseline, or document performance regression policy. Produces a structured performance budget covering key user journeys, Core Web Vitals, backend latency SLOs, measurement tooling, CI enforcement, and breach response process."
+---
+
+# Performance Budget Skill
+
+Produce a complete, actionable performance budget document for a web service or application. A performance budget is not a wishlist — it is a set of measurable, enforced constraints that define what "acceptable performance" means and who is responsible when those constraints are violated.
+
+A good performance budget answers: what are the targets, how are they measured, what triggers an investigation, and what happens when a budget is breached.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name and type** — web app, API service, mobile app, or combination
+- **Key user journeys** — the 3–5 most important flows users take (e.g. "search → product page → checkout")
+- **Current baseline metrics** — P50/P95/P99 latency, LCP, CLS, INP if available (state "no baseline" if not collected yet)
+- **Tech stack** — frontend framework, backend language/framework, CDN, database
+- **Deployment environment** — cloud provider, region(s), edge/CDN configuration
+- **Cost constraints** — any budget or infrastructure limits that affect headroom
+
+## Output Format
+
+---
+
+# Performance Budget: [Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Last updated:** [Date] | **Owner:** [Name / role]
+**Environment:** [Production / Staging baseline] | **Review cadence:** [Quarterly / per-sprint]
+
+---
+
+## Overview
+
+[2–3 sentences describing the service, its user-facing performance requirements, and why performance is a priority. Reference the business impact of latency — e.g. conversion rate, user retention, SLA obligations.]
+
+**Performance philosophy:** [e.g. "Performance is a feature. Every engineer is responsible for keeping the service within budget. Regressions must be caught in CI before they reach production."]
+
+---
+
+## Key User Journeys
+
+Define the critical paths that the performance budget is designed to protect.
+
+| Journey ID | Journey name | Entry point | Exit point | Criticality |
+|---|---|---|---|---|
+| UJ-1 | [e.g. New user sign-up] | [Landing page] | [Dashboard] | Critical |
+| UJ-2 | [e.g. Core workflow task] | [e.g. /app/tasks] | [e.g. Task complete] | High |
+| UJ-3 | [e.g. Search and select] | [e.g. /search] | [e.g. Detail page] | High |
+| UJ-4 | [e.g. API data fetch] | [e.g. GET /api/items] | [e.g. 200 response] | Medium |
+
+---
+
+## Frontend Performance Budget
+
+*Complete this section for web and mobile applications. Skip for API-only services.*
+
+### Core Web Vitals Targets
+
+Targets apply to the 75th percentile of real user sessions (field data), measured on a mid-range Android device on a 4G connection unless otherwise stated.
+
+| Metric | Description | Good | Needs Improvement | Poor | **Our Target** | Current baseline |
+|---|---|---|---|---|---|---|
+| **LCP** | Largest Contentful Paint — perceived load speed | ≤2.5s | 2.5–4.0s | >4.0s | **[≤X.Xs]** | [Xs / not measured] |
+| **INP** | Interaction to Next Paint — responsiveness | ≤200ms | 200–500ms | >500ms | **[≤Xms]** | [Xms / not measured] |
+| **CLS** | Cumulative Layout Shift — visual stability | ≤0.1 | 0.1–0.25 | >0.25 | **[≤0.X]** | [X.XX / not measured] |
+| **FCP** | First Contentful Paint | ≤1.8s | 1.8–3.0s | >3.0s | **[≤X.Xs]** | [Xs / not measured] |
+| **TTFB** | Time to First Byte | ≤800ms | 800ms–1.8s | >1.8s | **[≤Xms]** | [Xms / not measured] |
+
+### Page Weight Budget
+
+| Asset type | Max size (compressed) | Current | Status |
+|---|---|---|---|
+| Total page weight | [e.g. 500KB] | [XKB / unknown] | [Within / Over / Unknown] |
+| JavaScript (initial load) | [e.g. 200KB] | [XKB / unknown] | [Within / Over / Unknown] |
+| CSS | [e.g. 50KB] | [XKB / unknown] | [Within / Over / Unknown] |
+| Images (above fold) | [e.g. 150KB] | [XKB / unknown] | [Within / Over / Unknown] |
+| Web fonts | [e.g. 50KB] | [XKB / unknown] | [Within / Over / Unknown] |
+| Third-party scripts | [e.g. 100KB] | [XKB / unknown] | [Within / Over / Unknown] |
+
+### Per-Journey Frontend Targets
+
+| Journey | LCP | INP | CLS | FCP | TTFB |
+|---|---|---|---|---|---|
+| UJ-1: [Journey name] | [≤Xs] | [≤Xms] | [≤0.X] | [≤Xs] | [≤Xms] |
+| UJ-2: [Journey name] | [≤Xs] | [≤Xms] | [≤0.X] | [≤Xs] | [≤Xms] |
+| UJ-3: [Journey name] | [≤Xs] | [≤Xms] | [≤0.X] | [≤Xs] | [≤Xms] |
+
+---
+
+## Backend Performance Budget
+
+### API Latency SLOs
+
+Targets measured at the service boundary (not including client-side network latency).
+
+| Endpoint / operation | Method | P50 | P95 | P99 | Max (hard limit) | Error rate |
+|---|---|---|---|---|---|---|
+| [e.g. /api/auth/login] | POST | [≤Xms] | [≤Xms] | [≤Xms] | [≤Xms] | [<X%] |
+| [e.g. /api/items] | GET | [≤Xms] | [≤Xms] | [≤Xms] | [≤Xms] | [<X%] |
+| [e.g. /api/items/:id] | GET | [≤Xms] | [≤Xms] | [≤Xms] | [≤Xms] | [<X%] |
+| [e.g. /api/items] | POST | [≤Xms] | [≤Xms] | [≤Xms] | [≤Xms] | [<X%] |
+| [e.g. Background job: sync] | — | [≤Xs] | [≤Xs] | [≤Xs] | [≤Xs] | [<X%] |
+
+**Overall service SLOs:**
+
+| SLO | Target | Measurement window |
+|---|---|---|
+| Availability | [99.X%] | 30-day rolling |
+| P95 latency (all endpoints) | [≤Xms] | 30-day rolling |
+| Error rate (5xx) | [<X%] | 30-day rolling |
+| Throughput (sustained) | [≥X req/s] | Peak hour |
+
+### Database Query Budget
+
+| Query / operation | P50 | P95 | Max | Notes |
+|---|---|---|---|---|
+| [e.g. User lookup by ID] | [≤Xms] | [≤Xms] | [≤Xms] | Index on `user_id` |
+| [e.g. List items for user] | [≤Xms] | [≤Xms] | [≤Xms] | Paginated, max 100 rows |
+| [e.g. Full-text search] | [≤Xms] | [≤Xms] | [≤Xms] | Elasticsearch / pg_trgm |
+
+---
+
+## Measurement Methodology
+
+### Real User Monitoring (RUM)
+
+**Tool:** [e.g. Google CrUX, SpeedCurve, Datadog RUM, Sentry Performance, custom]
+**Data source:** [Field data from real users / Lab data from synthetic tests / Both]
+**Sample rate:** [X% of sessions]
+**How to access:** [Dashboard URL or tool access instructions]
+
+**What is measured:**
+- [ ] Core Web Vitals (LCP, INP, CLS) per page and journey
+- [ ] Custom performance marks for business-critical interactions
+- [ ] Resource timing for key assets
+- [ ] Long tasks (>50ms on main thread)
+
+### Synthetic Monitoring
+
+**Tool:** [e.g. Lighthouse CI, WebPageTest, k6, Artillery, Playwright with performance assertions]
+**Frequency:** [Every X minutes / on every deploy / nightly]
+**Test location(s):** [e.g. eu-west-1, us-east-1]
+**Device profile:** [Desktop 10Mbps / Mobile 4G Moto G4 / both]
+
+**Synthetic test suite location:** [Link to test files]
+
+### Backend Observability
+
+**APM tool:** [e.g. Datadog, Grafana + Prometheus, New Relic, AWS X-Ray]
+**Metrics collected:**
+- Request rate, error rate, duration (RED metrics) per endpoint
+- Database query duration and connection pool utilisation
+- Cache hit/miss rates
+- Background job queue depth and processing latency
+
+**Dashboard:** [Link to primary performance dashboard]
+
+---
+
+## CI/CD Performance Enforcement
+
+Performance budgets are enforced at two gates:
+
+### Gate 1 — Build-time Bundle Analysis
+
+**Tool:** [e.g. bundlesize, size-limit, webpack-bundle-analyzer with CI assertion]
+**Config file:** [`[.bundlesizerc / .size-limit.js / etc.]`]
+**Trigger:** Every PR targeting `main`
+**Blocking:** Yes — PR cannot merge if bundle size budget is exceeded
+
+```json
+// Example .size-limit.js
+[
+  {
+    "path": "dist/js/*.js",
+    "limit": "200 KB"
+  },
+  {
+    "path": "dist/css/*.css",
+    "limit": "50 KB"
+  }
+]
+```
+
+### Gate 2 — Synthetic Performance Tests in CI
+
+**Tool:** [e.g. Lighthouse CI, k6, Artillery]
+**Trigger:** On deploy to staging
+**Blocking:** Yes — production deploy is blocked if thresholds fail
+**Thresholds checked:**
+- LCP ≤ [Xs]
+- CLS ≤ [0.X]
+- P95 API latency ≤ [Xms]
+- Error rate < [X%]
+
+**CI config location:** [`[.github/workflows/perf.yml / ci/performance.yaml]`]
+
+**How to run locally:**
+```bash
+# Run Lighthouse CI against local build
+[command — e.g. lhci autorun --config=lighthouserc.js]
+
+# Run load test locally
+[command — e.g. k6 run load-tests/api-smoke.js]
+```
+
+---
+
+## Budget Breach Response Process
+
+A budget breach is when a measured metric exceeds its target for [X consecutive measurements / X minutes sustained / a single deploy].
+
+### Breach Severity Levels
+
+| Severity | Condition | Response time | Who acts |
+|---|---|---|---|
+| P1 — Critical | >2× budget threshold in production | Immediate | On-call engineer + team lead |
+| P2 — High | >1.5× budget threshold in production | Within 4 hours | On-call engineer |
+| P3 — Medium | Threshold exceeded in production | Within 1 sprint | PR author + team |
+| P4 — Low | Threshold exceeded in staging only | Before merge | PR author |
+
+### Breach Investigation Checklist
+
+When a breach is detected, work through this checklist in order:
+
+**1. Identify the regression commit**
+```bash
+# Compare performance across recent deploys
+[command — e.g. datadog metrics query, lighthouse-ci compare, git bisect]
+```
+
+**2. Classify the breach**
+- [ ] Is this a code change? (new feature, refactor, dependency bump)
+- [ ] Is this an infrastructure change? (new instance type, config change)
+- [ ] Is this an external factor? (CDN issue, DNS, upstream dependency)
+- [ ] Is this a measurement anomaly? (test environment issue, sample size)
+
+**3. Immediate actions**
+- If P1/P2 in production and a code cause is confirmed: roll back or disable the feature flag
+- If cause is unknown: do not roll back immediately — gather more data first
+- Notify [#performance / #incidents Slack channel] with: metric name, current value, budget target, suspected cause
+
+**4. Resolution**
+- Fix the root cause — do not just adjust the budget threshold
+- Budget thresholds should only change after a team discussion and explicit approval from [tech lead / EM]
+- Document the breach in the [performance log / incident record]
+
+**Budget change policy:** Budget thresholds may only be relaxed if: (a) the feature delivering the regression has measurable business value that outweighs the performance cost, and (b) the change is reviewed and approved by [tech lead].
+
+---
+
+## Performance Review Cadence
+
+| Trigger | Action |
+|---|---|
+| Every sprint | Review P95/P99 latency trends; flag any creeping degradation |
+| Every quarter | Full performance budget review — update baselines, adjust targets, audit tooling |
+| After major feature launch | Re-measure all Core Web Vitals and API SLOs; update baselines |
+| After infrastructure change | Re-run full synthetic test suite; confirm no regression |
+| After dependency upgrade | Run bundle size diff; confirm no unexpected size increase |
+
+**Next scheduled review:** [Date]
+**Review owner:** [Name / role]
+
+---
+
+## Quality Checks
+
+- [ ] Every budget threshold is a specific number — not a range or "TBD"
+- [ ] Both frontend (if applicable) and backend targets are defined — not just one or the other
+- [ ] Measurement tooling is named with a link to the dashboard or config file
+- [ ] CI enforcement is configured for at least one gate (build-time or deploy-time)
+- [ ] Budget breach response process names specific Slack channels and owners
+- [ ] Budget thresholds are anchored to baseline measurements or a justified target — not pulled from thin air
+- [ ] Per-journey targets are defined for critical user journeys, not just global averages
@@ -0,0 +1,399 @@
+---
+name: rfc-writer
+description: "Write an engineering RFC (Request for Comments) for a technical decision, architectural change, or significant implementation approach. Use when asked to write an RFC, document a technical proposal, create a design doc, write an architecture decision for review, or produce a technical specification for team feedback. Produces a complete RFC document covering problem statement, motivation, proposed solution, alternatives rejected, implementation plan, migration plan, security and performance implications, observability changes, rollout plan, and open questions."
+---
+
+# RFC Writer Skill
+
+Produce a complete engineering RFC (Request for Comments) for a technical decision or architectural change. An RFC is a structured proposal document — not a persuasion document. Its purpose is to expose a decision to scrutiny, surface trade-offs, document alternatives considered, and create a permanent record of why a choice was made.
+
+A good RFC makes it possible for someone who wasn't in the room to understand years later why the team built something the way they did.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **RFC title and author** — what this RFC is about and who is proposing it
+- **Problem being solved** — what is broken, missing, or inadequate today; why action is needed now
+- **Proposed solution** — the approach the author is recommending, at least at a high level
+- **Context and constraints** — team size, existing architecture, timeline pressures, budget limits, compliance requirements
+- **Alternatives considered** — at least 2 alternative approaches the author has thought about
+- **Current status** — is this pre-decision (seeking feedback) or post-decision (documenting a made decision)?
+
+## Output Format
+
+---
+
+# RFC [Number]: [Title]
+
+**Author:** [Name] | **Team:** [Team name]
+**Created:** [Date] | **Last updated:** [Date]
+**Status:** Draft | In Review | Approved | Rejected | Superseded by RFC-[X]
+**Ticket:** [JIRA-XXX] | **Slack thread:** [#channel link]
+**Review deadline:** [Date — when comments should be submitted by]
+
+---
+
+## Abstract
+
+[2–4 sentences summarising the entire RFC. Should stand alone — someone reading only this should understand what is being proposed, why, and what the main trade-off is. Write this last.]
+
+---
+
+## 1. Problem Statement
+
+[Describe the problem being solved. Focus on the *problem*, not the solution. Be specific and quantified where possible.]
+
+**Current state:**
+[Describe how things work today — the existing system, process, or architecture. Include any relevant constraints or limitations.]
+
+**Why this is a problem now:**
+[Why is this being addressed now rather than earlier or later? Reference metrics, incidents, product requirements, or scaling thresholds that make this urgent or timely.]
+
+**Example of the problem in practice:**
+[A concrete scenario or incident that illustrates the problem. This helps reviewers understand the real-world impact, not just the abstract description.]
+
+```
+// Example: current behaviour that illustrates the problem
+[code snippet, log output, or sequence description showing the problem]
+```
+
+**Impact of not solving this:**
+- [Impact 1 — e.g. "New tenant onboarding requires 3 hours of manual configuration per account"]
+- [Impact 2 — e.g. "Auth service handles 400 req/s; projected to hit capacity within 8 weeks at current growth"]
+- [Impact 3 — e.g. "Current approach is incompatible with the upcoming multi-region requirement"]
+
+---
+
+## 2. Goals and Non-Goals
+
+**Goals:**
+- [ ] [Specific, measurable outcome — e.g. "Reduce tenant onboarding time from 3 hours to <5 minutes"]
+- [ ] [e.g. "Support 2,000 req/s on the auth service with P99 latency ≤50ms"]
+- [ ] [e.g. "Enable multi-region deployment without changes to the application layer"]
+
+**Non-goals:** *(what this RFC explicitly does not address)*
+- [e.g. "This RFC does not address authentication for internal service-to-service calls — see RFC-042"]
+- [e.g. "Performance improvements to the existing system — this RFC replaces it"]
+- [e.g. "Migration of historical data — covered in a follow-on RFC"]
+
+**Success metrics:**
+| Metric | Current | Target | Measurement method |
+|---|---|---|---|
+| [e.g. Onboarding time] | [3 hours] | [<5 minutes] | [Prometheus histogram on onboarding job duration] |
+| [e.g. Auth latency P99] | [120ms] | [≤50ms] | [Datadog APM] |
+| [e.g. Engineer setup time] | [4 hours] | [<30 minutes] | [Onboarding survey] |
+
+---
+
+## 3. Background and Motivation
+
+[Provide the context a reviewer needs to evaluate the proposal. This is not a repeat of the problem statement — it is the surrounding technical and business context.]
+
+**Existing system overview:**
+[Describe the relevant parts of the current architecture. Include an ASCII diagram if the relationships between components help understanding.]
+
+```
+[ASCII diagram of current architecture — optional but strongly recommended for architectural RFCs]
+
+  ┌──────────┐     ┌──────────────┐     ┌──────────────┐
+  │  Client  │────▶│  [Service A] │────▶│  [Service B] │
+  └──────────┘     └──────────────┘     └──────────────┘
+                           │
+                           ▼
+                   ┌──────────────┐
+                   │  [Database]  │
+                   └──────────────┘
+```
+
+**Prior work and related decisions:**
+- [RFC-XXX: Title — relevant previous decision; link]
+- [ADR-XXX: Title — architectural decision record]
+- [Any external standards, blog posts, or vendor documentation that informs this proposal]
+
+**Constraints:**
+- [e.g. Must remain backward compatible with v1 API clients for 12 months]
+- [e.g. Team has no Rust expertise — solution must be in Python or Go]
+- [e.g. Must be deployable without a maintenance window]
+
+---
+
+## 4. Proposed Solution
+
+[Describe the proposed approach clearly and specifically. Include enough detail that an engineer could begin implementing from this document, but don't write the code — that is for the PR.]
+
+### 4.1 High-Level Approach
+
+[1–3 paragraphs describing the overall solution. Explain the key idea and why it solves the problem.]
+
+### 4.2 Architecture
+
+```
+[ASCII diagram of the proposed architecture — what the system looks like after this RFC is implemented]
+
+  ┌──────────┐     ┌──────────────────┐     ┌──────────────┐
+  │  Client  │────▶│  [New Component] │────▶│  [Service B] │
+  └──────────┘     └──────────────────┘     └──────────────┘
+                           │                       │
+                           ▼                       ▼
+                   ┌──────────────┐       ┌──────────────┐
+                   │  [Store A]   │       │  [Store B]   │
+                   └──────────────┘       └──────────────┘
+```
+
+### 4.3 Detailed Design
+
+[Break the solution into its key components or decisions. For each, explain what it does and why it was designed this way.]
+
+**Component / Decision 1: [Name]**
+
+[Description of this component — what it does, how it works, why this approach was chosen.]
+
+```
+// Example interface, API contract, or pseudocode (not implementation code)
+[Relevant schema, API definition, data flow, or pseudocode]
+```
+
+**Component / Decision 2: [Name]**
+
+[Description]
+
+**Component / Decision 3: [Name]**
+
+[Description]
+
+### 4.4 API Changes
+
+*Complete this section if the RFC introduces or modifies any API endpoints, events, or interfaces.*
+
+**New endpoints / events:**
+```
+[HTTP method + path or event name]
+Request: { ... }
+Response: { ... }
+```
+
+**Modified endpoints:**
+- `[endpoint]`: [what changes and why; backward compatibility note]
+
+**Deprecated endpoints:**
+- `[endpoint]`: deprecated in favour of `[new endpoint]` — removal timeline: [date/version]
+
+### 4.5 Data Model Changes
+
+*Complete this section if any database schema or data structure changes are required.*
+
+[Describe schema changes at a high level. Reference the database-migration-plan skill for detailed migration steps.]
+
+```sql
+-- Key schema changes (abbreviated — full migration in [link])
+[DDL statements for key additions/changes]
+```
+
+---
+
+## 5. Alternatives Considered
+
+*Every alternative must include an explicit reason why it was rejected. "We went with the proposed solution" is not a reason.*
+
+### Alternative 1: [Name]
+
+**Description:**
+[What this alternative would involve.]
+
+**Pros:**
+- [Pro 1]
+- [Pro 2]
+
+**Cons:**
+- [Con 1]
+- [Con 2]
+
+**Why rejected:**
+[Specific reason — e.g. "Requires 3× the infrastructure cost", "Incompatible with multi-region requirement", "Team has no expertise in this technology and the ramp-up would miss the Q3 deadline"]
+
+---
+
+### Alternative 2: [Name]
+
+**Description:**
+[What this alternative would involve.]
+
+**Pros:**
+- [Pro 1]
+- [Pro 2]
+
+**Cons:**
+- [Con 1]
+- [Con 2]
+
+**Why rejected:**
+[Specific reason]
+
+---
+
+### Alternative 3: Do nothing / defer
+
+**Description:**
+Accept the current state and revisit the problem in [timeframe].
+
+**Why rejected:**
+[Why deferring is not acceptable — reference the impact of not solving this from Section 1.]
+
+---
+
+## 6. Implementation Plan
+
+**Estimated effort:** [X engineer-weeks] | **Target completion:** [Date / Quarter]
+**Team:** [Who is building this — names or roles]
+
+| Phase | Description | Duration | Dependencies | Owner |
+|---|---|---|---|---|
+| 1 | [e.g. Core implementation — new component built and tested] | [X weeks] | [None] | [Name] |
+| 2 | [e.g. Integration — connect new component to existing services] | [X weeks] | [Phase 1 complete] | [Name] |
+| 3 | [e.g. Rollout — canary deploy, then full rollout] | [X weeks] | [Phase 2 + staging validated] | [Name] |
+| 4 | [e.g. Cleanup — deprecate old system, remove feature flags] | [X weeks] | [Phase 3 stable for X weeks] | [Name] |
+
+**Key milestones:**
+- [ ] [Date]: [Milestone — e.g. "Core implementation complete and code-reviewed"]
+- [ ] [Date]: [Milestone — e.g. "Staging environment validation complete"]
+- [ ] [Date]: [Milestone — e.g. "10% canary traffic without regression"]
+- [ ] [Date]: [Milestone — e.g. "Full rollout complete"]
+- [ ] [Date]: [Milestone — e.g. "Old system decommissioned"]
+
+---
+
+## 7. Migration Plan
+
+*Complete this section if the RFC requires migrating existing users, data, or API consumers.*
+
+**Migration strategy:** [Big-bang / Phased / Parallel-run / Opt-in]
+
+**Who is affected:**
+- [e.g. All existing API v1 consumers — requires updated client libraries]
+- [e.g. X million rows in the `orders` table require backfilling]
+
+**Migration steps:**
+1. [Step 1 — describe action, who does it, estimated duration]
+2. [Step 2]
+3. [Step 3]
+
+**Backward compatibility window:** [How long will the old system/API remain available?]
+
+**Communication plan:**
+- [Who needs to be notified, when, and how — e.g. "API consumers will receive a deprecation notice 3 months before the old endpoint is removed"]
+
+---
+
+## 8. Security Implications
+
+[Describe the security impact of this change. If there are no security implications, state that explicitly with reasoning — do not leave this section blank.]
+
+| Concern | Impact | Mitigation |
+|---|---|---|
+| [e.g. New API endpoint exposed to internet] | [e.g. New attack surface] | [e.g. Rate limiting, auth required, WAF rules] |
+| [e.g. New data stored — user PII] | [e.g. GDPR scope expanded] | [e.g. Encrypted at rest, access log, data retention policy] |
+| [e.g. Service-to-service communication] | [e.g. Token forgery risk] | [e.g. mTLS between services] |
+
+**Has a threat model been produced or updated?** [Yes — link / No — required before implementation / Not required — reason]
+
+---
+
+## 9. Performance Implications
+
+[Describe the expected performance impact. Include projections for the new system and how it was estimated.]
+
+| Metric | Current | Projected | Measurement method |
+|---|---|---|---|
+| [e.g. P99 latency — /api/auth] | [120ms] | [≤50ms] | [Load test results — link] |
+| [e.g. Database query count per request] | [12] | [3] | [Query logging in staging] |
+| [e.g. Memory per instance] | [512MB] | [768MB] | [Profiling — link] |
+| [e.g. Infrastructure cost] | [$X/month] | [$Y/month] | [AWS cost calculator estimate] |
+
+**Load testing:** [Has load testing been done? Link to results. If not, when will it be done?]
+
+**Performance risks:**
+- [Risk 1 — e.g. "New component adds a network hop that may increase tail latency under congestion — needs validation at 2× peak load"]
+
+---
+
+## 10. Observability Changes
+
+*Describe what new or changed metrics, logs, traces, and alerts this RFC introduces.*
+
+**New metrics:**
+| Metric name | Type | Description | Alert threshold |
+|---|---|---|---|
+| `[service].[component].[metric]` | [counter/gauge/histogram] | [What it measures] | [e.g. P99 > 100ms for 5 min] |
+
+**New log events:**
+| Event | Level | When emitted | Key fields |
+|---|---|---|---|
+| `[event.name]` | INFO | [When] | `user_id`, `duration_ms`, `result` |
+
+**Distributed tracing:** [Are spans added for new components? Which operations are instrumented?]
+
+**Dashboard changes:** [New dashboard / updated existing dashboard — link]
+
+---
+
+## 11. Rollout Plan
+
+**Rollout strategy:** [Feature flag / Canary / Blue-green / Gradual traffic shift / Full deploy]
+
+| Stage | Traffic % | Duration | Success criteria | Rollback trigger |
+|---|---|---|---|---|
+| Internal testing | 0% (dogfood) | [X days] | [No errors in internal usage] | Any error |
+| Canary | 1% | [X hours] | [Error rate <0.1%; P99 latency within budget] | Error rate >0.5% |
+| Limited rollout | 10% | [X days] | [As above + business metrics stable] | Error rate >0.2% |
+| Full rollout | 100% | — | [All success metrics from Section 2 met] | Any SLO breach |
+
+**Feature flag:** [Name of feature flag, if applicable] — managed in [LaunchDarkly / Unleash / config]
+
+**Rollback procedure:**
+```
+// How to roll back if the rollout needs to be reversed
+1. [Step 1 — e.g. Toggle feature flag to off]
+2. [Step 2 — e.g. Deploy previous version]
+3. [Step 3 — e.g. Notify stakeholders]
+```
+
+---
+
+## 12. Open Questions
+
+[List any unresolved questions, design decisions not yet made, or areas where the author is specifically seeking feedback. Assign an owner and a resolution deadline for each.]
+
+| # | Question | Owner | Deadline | Resolution |
+|---|---|---|---|---|
+| 1 | [e.g. Should we use optimistic or pessimistic locking for concurrent updates to [resource]?] | [Name] | [Date] | [Pending / [Answer]] |
+| 2 | [e.g. What is the retention policy for [new data type]?] | [Name] | [Date] | [Pending / [Answer]] |
+| 3 | [e.g. Do we need a read replica for this query pattern at launch, or can we defer it?] | [Name] | [Date] | [Pending / [Answer]] |
+
+---
+
+## 13. Decision
+
+*To be filled in after the review period closes.*
+
+**Decision:** [Approved / Rejected / Approved with modifications]
+**Decision date:** [Date]
+**Decision makers:** [Names]
+
+**Summary of key feedback addressed:**
+- [Feedback item and how it was resolved]
+
+**Conditions of approval (if any):**
+- [e.g. Must complete load testing before Phase 2 begins]
+
+---
+
+## Quality Checks
+
+- [ ] The problem statement is specific and quantified — not "the current system is slow" but "P99 latency is 800ms; budget is 200ms"
+- [ ] Goals section includes measurable success metrics, not aspirational statements
+- [ ] Every alternative has an explicit rejection reason — not just a list of cons
+- [ ] Security implications section is completed, not left blank
+- [ ] Performance implications include projected numbers, not just "should be better"
+- [ ] Open questions are assigned to named owners with deadlines — not floating
+- [ ] The RFC is written to be read by someone who was not in the planning conversations
+- [ ] Migration plan addresses all affected parties — users, API consumers, data — not just the technical steps
@@ -0,0 +1,253 @@
+---
+name: security-threat-model
+description: "Write a STRIDE-based threat model for a service or feature. Use when asked to produce a threat model, document security risks, identify attack vectors, assess a service's security posture, or prepare for a security design review. Produces a structured threat model covering assets, trust boundaries, STRIDE threat enumeration per component, risk scores, mitigation controls, and residual risk sign-off."
+---
+
+# Security Threat Model Skill
+
+Produce a complete STRIDE-based threat model for a service or feature. A threat model is not a list of things that could go wrong — it is a structured analysis of attackers, assets, boundaries, and controls that lets an engineering team make informed, documented security decisions.
+
+A good threat model is specific enough that a new engineer can understand what is being protected, why each control exists, and what risk the team has accepted.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name and description** — what the service does, who uses it
+- **Architecture overview** — components, dependencies, data flows (a diagram description or ASCII diagram is fine)
+- **Deployment environment** — cloud provider, VPC/network topology, where it runs (Kubernetes, ECS, VMs, serverless)
+- **Data sensitivity** — what data does this service handle? PII, payment data, credentials, internal-only?
+- **Existing controls** — authentication method, encryption in transit/at rest, current WAF/firewall, existing security scanning
+- **Trust levels** — who are the principals? (anonymous public, authenticated users, internal services, admins)
+
+## Output Format
+
+---
+
+# Security Threat Model: [Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Author:** [Name] | **Reviewed by:** [Security lead / peer]
+**Date:** [Date] | **Next review:** [Date — recommend 6 months or after major architecture change]
+**Classification:** [Internal / Confidential]
+
+---
+
+## 1. Overview
+
+[2–3 sentences describing the service, its role in the system, and the scope of this threat model. State what is in scope and what is explicitly out of scope.]
+
+**In scope:**
+- [Component or data flow]
+- [Component or data flow]
+
+**Out of scope:**
+- [e.g. Third-party payment processor internals]
+- [e.g. Corporate network / end-user devices]
+
+---
+
+## 2. Asset Register
+
+Assets are the things worth protecting — data, capabilities, and reputational value.
+
+| Asset | Description | Sensitivity | Owner |
+|---|---|---|---|
+| [e.g. User PII] | Names, email addresses, profile data | High — GDPR-regulated | [Team] |
+| [e.g. API credentials] | Service-to-service auth tokens | Critical | [Team] |
+| [e.g. Session tokens] | User authentication state | High | [Team] |
+| [e.g. Audit logs] | Record of user and admin actions | Medium | [Team] |
+| [e.g. Service availability] | Uptime of the [X] endpoint | Medium | [Team] |
+
+**Data classification key:**
+- **Critical** — Credential material; exposure enables direct system compromise
+- **High** — PII, financial data, health data; regulated or high reputational impact
+- **Medium** — Internal configuration, non-sensitive business data
+- **Low** — Public information, anonymised data
+
+---
+
+## 3. Trust Boundaries and Architecture
+
+Trust boundaries are the lines that separate zones with different trust levels. Threats often occur when data or requests cross a boundary.
+
+```
+  ┌─────────────────────────────────────────────────────────────────┐
+  │  INTERNET (Untrusted)                                           │
+  │                                                                 │
+  │   [Public User]          [Bot / Attacker]                       │
+  └──────────────────────────────┬──────────────────────────────────┘
+                                 │ HTTPS
+                    ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
+                    Trust Boundary: Public → DMZ
+                    ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
+                                 ▼
+  ┌──────────────────────────────────────────────────────────────────┐
+  │  DMZ / Edge Layer                                                │
+  │   ┌────────────┐     ┌──────────────┐                           │
+  │   │  WAF / CDN │────▶│  API Gateway │                           │
+  │   └────────────┘     └──────┬───────┘                           │
+  └──────────────────────────────┼───────────────────────────────────┘
+                    ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
+                    Trust Boundary: Edge → Application VPC
+                    ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
+                                 ▼
+  ┌──────────────────────────────────────────────────────────────────┐
+  │  Application VPC (Private)                                       │
+  │   ┌──────────────┐     ┌────────────┐     ┌──────────────────┐  │
+  │   │  [Service A] │────▶│ [Service B]│────▶│  [Database]      │  │
+  │   └──────────────┘     └────────────┘     └──────────────────┘  │
+  │                                ▲                                  │
+  │                                │                                  │
+  │   ┌──────────────┐             │                                  │
+  │   │  Admin (IAM) │─────────────┘                                 │
+  └──────────────────────────────────────────────────────────────────┘
+```
+
+**Trust Boundaries identified:**
+
+| Boundary | From | To | Auth mechanism | Encrypted |
+|---|---|---|---|---|
+| TB-1 | Public internet | API Gateway | [JWT / OAuth / API key] | TLS 1.2+ |
+| TB-2 | API Gateway | Service A | [mTLS / internal JWT / IAM role] | [Yes/No] |
+| TB-3 | Service A | Database | [Connection string + IAM / username+password] | [Yes/No] |
+| TB-4 | Admin | Service B | [IAM role / VPN + MFA] | TLS |
+
+---
+
+## 4. STRIDE Threat Analysis
+
+STRIDE is a threat classification framework. For each significant component, enumerate threats in each category.
+
+**STRIDE key:**
+- **S** — Spoofing: Impersonating another user, service, or system
+- **T** — Tampering: Modifying data or code without authorisation
+- **R** — Repudiation: Denying an action occurred; insufficient audit trail
+- **I** — Information Disclosure: Exposing data to unauthorised parties
+- **D** — Denial of Service: Making the service unavailable
+- **E** — Elevation of Privilege: Gaining capabilities beyond what is authorised
+
+### Component: [API Gateway / Auth Layer]
+
+| ID | Category | Threat | Attack vector | Existing control |
+|---|---|---|---|---|
+| T-001 | S | Attacker forges a JWT token to authenticate as another user | Weak signing key or algorithm confusion (alg:none) | [e.g. RS256 with key rotation / none] |
+| T-002 | S | Attacker replays a stolen session token | Theft via XSS or network sniff | [e.g. Token expiry + refresh rotation] |
+| T-003 | T | Attacker modifies request headers to bypass tenant isolation | Missing validation of tenant ID header | [e.g. Server-side tenant resolution / none] |
+| T-004 | R | No audit trail for admin authentication events | Logging not configured for auth failures | [e.g. CloudTrail enabled / none] |
+| T-005 | I | Auth error messages reveal whether an email exists | Verbose error responses | [e.g. Normalised error responses / none] |
+| T-006 | D | Credential stuffing exhausts rate limits and blocks legitimate users | Automated login attempts | [e.g. Rate limiting per IP + CAPTCHA / none] |
+| T-007 | E | Compromised low-privilege token used to call admin endpoint | Missing role check on admin routes | [e.g. RBAC middleware on all routes / none] |
+
+### Component: [Application Service / Business Logic]
+
+| ID | Category | Threat | Attack vector | Existing control |
+|---|---|---|---|---|
+| T-008 | T | SQL/NoSQL injection via unsanitised user input | Unparameterised queries | [e.g. ORM with parameterised queries / none] |
+| T-009 | T | Mass assignment — attacker sets fields they should not (e.g. `isAdmin: true`) | API accepts extra fields without allowlist | [e.g. Input validation / none] |
+| T-010 | I | Insecure direct object reference — user accesses another user's resource | Missing ownership check on resource ID | [e.g. Ownership middleware / none] |
+| T-011 | I | Sensitive data in application logs (PII, tokens) | Over-logging in debug mode | [e.g. Log scrubbing / none] |
+| T-012 | D | Unprotected expensive endpoint triggers large DB scan | No pagination or query cost limit | [e.g. Pagination enforced / none] |
+| T-013 | R | Business-critical state changes not logged | No audit event on [operation] | [e.g. Audit log table / none] |
+
+### Component: [Database]
+
+| ID | Category | Threat | Attack vector | Existing control |
+|---|---|---|---|---|
+| T-014 | I | Database exposed to internet (misconfigured security group) | Direct connection from outside VPC | [e.g. No public IP, security group restricts to app subnet] |
+| T-015 | I | Backup snapshots not encrypted or accessible to wrong accounts | Unencrypted snapshot, public S3 | [e.g. Encrypted snapshots, private S3 bucket] |
+| T-016 | T | Privilege escalation via DB account with excessive permissions | App uses a superuser DB account | [e.g. Least-privilege DB role per service / none] |
+| T-017 | D | Runaway query or bulk delete causes data loss or outage | No query timeout or soft-delete | [e.g. Statement timeout, soft-delete on critical tables / none] |
+
+### Component: [Internal Service-to-Service Communication]
+
+| ID | Category | Threat | Attack vector | Existing control |
+|---|---|---|---|---|
+| T-018 | S | Rogue internal service impersonates a trusted service | No mutual authentication between services | [e.g. mTLS / service mesh / none] |
+| T-019 | I | Internal traffic sniffed on shared network | Unencrypted service-to-service calls | [e.g. Service mesh with TLS / none] |
+| T-020 | E | Compromised internal service calls privileged endpoints | No scoping on internal tokens | [e.g. Scoped service tokens / none] |
+
+---
+
+## 5. Risk Register
+
+Score each threat: **Likelihood (1–5)** × **Impact (1–5)** = **Risk Score (1–25)**
+
+Priority bands: Critical (20–25) | High (12–19) | Medium (6–11) | Low (1–5)
+
+| ID | Threat summary | Likelihood | Impact | Score | Priority | Status |
+|---|---|---|---|---|---|---|
+| T-001 | JWT forgery — auth bypass | 2 | 5 | 10 | Medium | [Open / Mitigated / Accepted] |
+| T-002 | Session token replay | 3 | 4 | 12 | High | [Open / Mitigated / Accepted] |
+| T-007 | Privilege escalation via missing role check | 3 | 5 | 15 | High | [Open / Mitigated / Accepted] |
+| T-008 | SQL injection | 2 | 5 | 10 | Medium | [Open / Mitigated / Accepted] |
+| T-010 | IDOR — cross-user data access | 3 | 4 | 12 | High | [Open / Mitigated / Accepted] |
+| T-014 | Database exposed to internet | 1 | 5 | 5 | Low | [Open / Mitigated / Accepted] |
+| T-018 | Rogue internal service impersonation | 2 | 4 | 8 | Medium | [Open / Mitigated / Accepted] |
+
+---
+
+## 6. Mitigations Table
+
+For every Open threat with priority Medium or above, define a specific mitigation.
+
+| ID | Threat | Mitigation | Owner | Target date | Ticket |
+|---|---|---|---|---|---|
+| T-002 | Session token replay | Implement token rotation on refresh — invalidate old token server-side immediately | [Engineer name] | [Date] | [JIRA-123] |
+| T-007 | Privilege escalation | Add RBAC middleware to all `/admin/*` routes; write integration test for role boundary | [Engineer name] | [Date] | [JIRA-124] |
+| T-010 | IDOR | Add ownership assertion to all resource-fetching service methods; add to code review checklist | [Engineer name] | [Date] | [JIRA-125] |
+| T-011 | PII in logs | Audit logging calls for PII fields; add scrubbing to logger middleware | [Engineer name] | [Date] | [JIRA-126] |
+| T-018 | Rogue service impersonation | Enable mTLS via service mesh or issue scoped service tokens per service | [Engineer name] | [Date] | [JIRA-127] |
+
+---
+
+## 7. Accepted Risks
+
+Accepted risks are threats the team has decided not to mitigate right now. Every accepted risk must have a named owner and a review date.
+
+| ID | Threat | Reason for acceptance | Risk owner | Review date |
+|---|---|---|---|---|
+| T-014 | Database public exposure | Database has no public IP assigned; control already in place — accepted as low likelihood | [Name] | [Date] |
+| [ID] | [Threat] | [Reason — e.g. "Effort exceeds risk at current scale; re-evaluate at 10× traffic"] | [Name] | [Date] |
+
+---
+
+## 8. Security Controls Summary
+
+| Control | Type | Covers threats | Implemented |
+|---|---|---|---|
+| JWT RS256 with 15-min expiry | Preventive | T-001, T-002 | [Yes / Partial / No] |
+| RBAC middleware on all routes | Preventive | T-007, T-020 | [Yes / Partial / No] |
+| Parameterised queries (ORM) | Preventive | T-008 | [Yes / Partial / No] |
+| Rate limiting (100 req/min per IP) | Preventive | T-006, T-012 | [Yes / Partial / No] |
+| CloudTrail / audit logging | Detective | T-004, T-013 | [Yes / Partial / No] |
+| Automated SAST in CI pipeline | Detective | T-008, T-009 | [Yes / Partial / No] |
+| Encrypted backups + private S3 | Preventive | T-015 | [Yes / Partial / No] |
+| Least-privilege DB role | Preventive | T-016 | [Yes / Partial / No] |
+| Incident response runbook | Corrective | All | [Yes / Partial / No] |
+
+---
+
+## 9. Review Cadence
+
+| Trigger | Action |
+|---|---|
+| Every 6 months | Full threat model review — update risk scores, close mitigated items |
+| Major architecture change | Update trust boundary diagram and re-run STRIDE for new components |
+| Security incident | Review relevant threats; add any newly discovered vectors |
+| New data classification | Add assets to register; assess whether new STRIDE categories apply |
+| Third-party dependency added | Assess supply chain threats for the new dependency |
+
+**Next scheduled review:** [Date]
+**Review owner:** [Name / Security lead]
+
+---
+
+## Quality Checks
+
+- [ ] Every trust boundary is named and its authentication mechanism is specified — not left as "TBD"
+- [ ] Every Critical and High risk in the risk register has a mitigation with a named owner and a target date
+- [ ] Every accepted risk has a named risk owner and a review date — no unowned accepted risks
+- [ ] The asset register includes data sensitivity levels and at least one entry for credential material
+- [ ] STRIDE analysis covers all major components — not just the API layer
+- [ ] Mitigation actions are specific enough to become a ticket (not "improve security")
+- [ ] The ASCII trust boundary diagram matches the architecture description provided
@@ -0,0 +1,292 @@
+---
+name: service-catalog-entry
+description: "Write a service catalog entry for a microservice or internal platform service — covering service identity, purpose, architecture context, SLAs, API contract summary, data classification, dependencies, operational runbooks, and known limitations. Use when asked to document a service for an internal developer portal, write a service README for a platform catalog, create a service overview page, or onboard a new service to a service registry. Produces a complete service catalog entry suitable for an internal developer portal or wiki."
+---
+
+# Service Catalog Entry Skill
+
+Produce a complete service catalog entry for a microservice or internal platform service — giving any engineer at the company the context they need to understand what the service does, how to depend on it, what its reliability characteristics are, and where to go when something goes wrong. A well-written catalog entry eliminates "who owns this?" and "is this safe to use?" questions that slow down teams depending on shared services.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** — the canonical identifier used in code, monitoring, and deployments
+- **Team and owner** — team name, tech lead name, and on-call contact
+- **Architecture overview** — what the service does, what calls it, and what it calls
+- **SLA requirements** — availability target, latency SLO, support tier, and maintenance window
+- **Key APIs** — the most important endpoints other teams use (method, path, brief description)
+- **Data handled** — what data the service stores or processes, sensitivity classification, retention
+
+## Output Format
+
+---
+
+# Service Catalog: [Service Name]
+
+> **[One sentence — what this service does for consumers, in plain language]**
+>
+> *e.g. "The Payments Service processes charge, refund, and subscription billing events for all Acme products."*
+
+---
+
+## Identity
+
+| Field | Value |
+|---|---|
+| **Service name** | `[service-name]` |
+| **Canonical repository** | [https://github.com/[org]/[repo]] |
+| **Owner team** | [Team name] |
+| **Tech lead** | [Name] ([Slack: @handle]) |
+| **On-call rotation** | [PagerDuty service link] |
+| **Slack channel** | `#[team-channel]` |
+| **Support tier** | [Tier 1 — 24/7 / Tier 2 — business hours / Tier 3 — best effort] |
+| **Status** | [Active / Deprecated / Sunset date: YYYY-MM-DD] |
+| **Language / runtime** | [e.g. Go 1.22 / Python 3.12 / Node 20] |
+| **Deployment platform** | [Kubernetes / ECS / Lambda / etc.] |
+| **Environments** | [Production: URL] | [Staging: URL] | [Dev: URL] |
+
+---
+
+## What It Does
+
+[Two to three paragraphs in plain language — no jargon or acronyms without explanation.]
+
+[Paragraph 1: The business problem this service solves. What would break or be missing if this service did not exist?]
+
+[Paragraph 2: How it works at a high level — the main processing model (e.g. request/response API, event-driven consumer, batch processor), what triggers it, and what it produces.]
+
+[Paragraph 3: What this service is NOT responsible for — the explicit boundaries. This prevents other teams from building incorrect assumptions about scope.]
+
+---
+
+## Architecture Context
+
+### System Diagram
+
+```
+[Upstream callers]          [This Service]             [Downstream dependencies]
+                                                        
+  [Web App]  ──────────→                          ──→  [Primary Database — PostgreSQL]
+  [Mobile API]  ────────→  [Service Name]         ──→  [Cache — Redis]
+  [Partner API] ────────→  (Port 8080/gRPC)       ──→  [Message Queue — Kafka/SQS]
+                                                   ──→  [External Service / API]
+                           ↓ emits events to
+                        [Event Bus / SNS]
+                           ↓ consumed by
+                  [Downstream Service A]
+                  [Downstream Service B]
+```
+
+### Who Depends on This Service
+
+| Caller | How they use it | Contact |
+|---|---|---|
+| [Service / Team A] | [e.g. "Calls POST /charges to initiate payments"] | [Slack: #team-a] |
+| [Service / Team B] | [e.g. "Subscribes to payment.completed events via Kafka topic"] | [Slack: #team-b] |
+| [Service / Team C] | [e.g. "Calls GET /subscriptions for billing status"] | [Slack: #team-c] |
+
+### What This Service Depends On
+
+| Dependency | Type | Criticality | Their on-call |
+|---|---|---|---|
+| [PostgreSQL instance] | Database | Critical — all writes fail without it | [DBA team: #db-oncall] |
+| [Redis cluster] | Cache | High — latency degrades without it | [Infra team: #infra-oncall] |
+| [Kafka cluster] | Message queue | High — async events queue | [Infra team: #infra-oncall] |
+| [Stripe API] | External API | Critical — payment processing fails | [vendor status: status.stripe.com] |
+| [Auth Service] | Internal service | Critical — all auth fails | [Auth team: #auth-oncall] |
+
+---
+
+## Service Level Agreement
+
+### Availability and Latency
+
+| SLO | Target | Measurement window | Error budget |
+|---|---|---|---|
+| Availability | [99.9%] | Rolling 30 days | [43 min/month] |
+| p50 latency (key endpoints) | < [50] ms | Rolling 24 hours | — |
+| p99 latency (key endpoints) | < [500] ms | Rolling 24 hours | — |
+| p99.9 latency (key endpoints) | < [2000] ms | Rolling 24 hours | — |
+| Error rate | < [0.1]% | Rolling 1 hour | — |
+
+**SLO dashboard:** [Link to monitoring dashboard]
+**Current error budget remaining:** [Link to SLO dashboard or inline value]
+
+### Support Tiers
+
+| Tier | Scope | Response time | Resolution time |
+|---|---|---|---|
+| P1 — Service down | All authenticated requests failing | 15 minutes | 1 hour |
+| P2 — Significant degradation | Error rate >1% or p99 >2× SLO | 30 minutes | 4 hours |
+| P3 — Minor issues | Non-critical endpoints degraded | Next business day | 3 business days |
+| Feature requests / bugs | Via standard ticket process | [Ticket SLA] | Per roadmap |
+
+**To raise an incident:** Page via [PagerDuty service link] or post in `#incidents`.
+**To raise a feature request or bug:** File a ticket in [JIRA project / GitHub repo Issues].
+
+### Maintenance Windows
+
+- **Planned downtime:** [e.g. "Sundays 02:00–04:00 UTC — advance notice posted to #[team-channel] 48h before"]
+- **Deployment window:** [e.g. "Weekdays 10:00–16:00 UTC — no deploys on Fridays or the day before a public holiday"]
+- **Breaking changes notice:** [e.g. "Minimum 30 days notice for breaking API changes — see versioning policy below"]
+
+---
+
+## API Contract
+
+### Authentication
+
+All API calls require: [e.g. "Bearer token via Authorization header. Tokens are issued by the Auth Service (`/api/v1/token`)"]
+
+```
+Authorization: Bearer [jwt-token]
+Content-Type: application/json
+```
+
+### Base URL
+
+| Environment | Base URL |
+|---|---|
+| Production | `https://[service-name].internal.[company].com` |
+| Staging | `https://[service-name].staging.[company].com` |
+| Local development | `http://localhost:[port]` |
+
+### Key Endpoints
+
+| Method | Path | Description | Auth required | Rate limit |
+|---|---|---|---|---|
+| `GET` | `/health` | Liveness and readiness check | No | None |
+| `GET` | `/api/v1/[resource]` | [Description — e.g. "List resources for the authenticated user"] | Yes | [100 req/min] |
+| `GET` | `/api/v1/[resource]/:id` | [Description — e.g. "Get a single resource by ID"] | Yes | [500 req/min] |
+| `POST` | `/api/v1/[resource]` | [Description — e.g. "Create a new resource"] | Yes | [50 req/min] |
+| `PUT` | `/api/v1/[resource]/:id` | [Description — e.g. "Update an existing resource"] | Yes | [50 req/min] |
+| `DELETE` | `/api/v1/[resource]/:id` | [Description] | Yes | [20 req/min] |
+
+**Full API documentation:** [OpenAPI/Swagger spec URL] | [Postman collection URL]
+
+### Versioning Policy
+
+- API version is in the URL path (`/api/v1/`, `/api/v2/`)
+- Minor additions (new optional fields, new endpoints) are non-breaking — no version bump
+- Breaking changes (removed fields, changed types, authentication changes) require a new major version
+- Deprecated versions are supported for [90 days] after the successor reaches GA
+- Deprecation notices are posted to `#[team-channel]` and emailed to registered consumers
+
+### Error Response Format
+
+```json
+{
+  "error": {
+    "code": "[ERROR_CODE]",
+    "message": "[Human-readable description]",
+    "request_id": "[UUID — include in support tickets]",
+    "details": {}
+  }
+}
+```
+
+Common error codes:
+
+| HTTP status | Error code | Meaning |
+|---|---|---|
+| 400 | `INVALID_REQUEST` | Request body or parameters fail validation |
+| 401 | `UNAUTHENTICATED` | Missing or invalid auth token |
+| 403 | `FORBIDDEN` | Token valid but lacks permission for this resource |
+| 404 | `NOT_FOUND` | Resource does not exist |
+| 409 | `CONFLICT` | Duplicate resource or state conflict |
+| 422 | `UNPROCESSABLE_ENTITY` | Request is valid but violates business rules |
+| 429 | `RATE_LIMITED` | Too many requests — back off and retry |
+| 500 | `INTERNAL_ERROR` | Unexpected server error — include request_id in support ticket |
+| 503 | `SERVICE_UNAVAILABLE` | Downstream dependency unavailable — retry with backoff |
+
+### Events Published (if event-driven)
+
+| Event | Topic / Queue | Schema | Published when |
+|---|---|---|---|
+| `[resource].created` | `[kafka-topic / sns-arn]` | [Schema URL] | [When a new resource is created] |
+| `[resource].updated` | `[kafka-topic / sns-arn]` | [Schema URL] | [When a resource is modified] |
+| `[resource].deleted` | `[kafka-topic / sns-arn]` | [Schema URL] | [When a resource is deleted] |
+
+---
+
+## Data Classification
+
+| Data element | Sensitivity | Stored in | Retention | Encrypted at rest |
+|---|---|---|---|---|
+| [User PII — e.g. email, name] | [PII / Restricted] | [PostgreSQL `users` table] | [Until account deletion] | Yes |
+| [Financial data — e.g. card last 4] | [PCI / Highly restricted] | [PostgreSQL `payment_methods` table] | [7 years per regulations] | Yes — field-level encryption |
+| [Operational logs] | [Internal] | [CloudWatch / Datadog] | [90 days] | Yes (at rest, not searched) |
+| [Anonymised analytics] | [Public] | [Data warehouse] | [Indefinite] | Yes |
+
+**Data residency:** [e.g. "All data stored in us-east-1. EU customer data stored in eu-west-1 per GDPR requirements."]
+**Compliance scope:** [e.g. SOC 2 Type II / PCI DSS Level 2 / HIPAA / GDPR]
+**Data access policy:** [e.g. "Production database access requires [approval process]. Access logged and reviewed quarterly."]
+
+---
+
+## Operational Runbooks
+
+| Runbook | Location | Use when |
+|---|---|---|
+| On-call runbook | [Wiki / GitHub link] | Responding to PagerDuty alerts |
+| Deployment runbook | [Wiki / GitHub link] | Deploying a new version to production |
+| Database migration runbook | [Wiki / GitHub link] | Running schema migrations |
+| Rollback runbook | [Wiki / GitHub link] | Rolling back a bad deploy |
+| Incident response runbook | [Wiki / GitHub link] | Declaring and managing incidents |
+| Disaster recovery plan | [Wiki / GitHub link] | Zone/region failure or data loss |
+
+**Monitoring dashboards:**
+
+| Dashboard | Link | Use it for |
+|---|---|---|
+| Service overview | [Datadog / Grafana link] | Error rate, latency, throughput |
+| Infrastructure | [Link] | CPU, memory, pod health |
+| Database | [Link] | Query performance, connection pool |
+| SLO / error budget | [Link] | Budget burn rate, availability |
+| Dependency health | [Link] | Upstream dependency status |
+
+---
+
+## Known Limitations
+
+Document limitations honestly — this section prevents other teams from building on incorrect assumptions.
+
+| Limitation | Impact | Workaround | Planned fix |
+|---|---|---|---|
+| [e.g. No bulk write API — items must be created one at a time] | [Slow for large imports — N HTTP calls required] | [Use the batch import CLI tool for >100 items] | [Bulk API in Q3 — ticket: [URL]] |
+| [e.g. List endpoints have a maximum page size of 100] | [Cannot retrieve more than 100 items in a single call] | [Paginate using `cursor` parameter] | [No current plan to increase — by design] |
+| [e.g. Rate limits are per-token, not per-service] | [High-traffic consumers may hit limits for other consumers on the same token] | [Request dedicated service-account token] | [Per-service rate limits in roadmap] |
+| [e.g. Eventual consistency on read-after-write for list endpoints] | [Record may not appear in list immediately after creation (<500ms lag)] | [Use GET /:id to confirm creation; do not rely on list for immediate consistency] | [Read-your-writes consistency available via `?consistent=true` — in progress] |
+
+---
+
+## Getting Started
+
+**To start using this service:**
+
+1. Request access: [Link to access request form or instructions]
+2. Get your service account credentials: [Link to process]
+3. Read the API docs: [OpenAPI spec URL]
+4. Try the sandbox environment: `https://[service-name].sandbox.[company].com`
+5. Join the consumer Slack channel: `#[service-name]-consumers`
+
+**Client libraries (if available):**
+
+| Language | Package | Installation |
+|---|---|---|
+| [Python] | [`[package-name]`] | `pip install [package-name]` |
+| [Go] | [`github.com/[org]/[package]`] | `go get github.com/[org]/[package]` |
+| [TypeScript/JS] | [`@[org]/[package]`] | `npm install @[org]/[package]` |
+
+---
+
+## Quality Checks
+
+- [ ] "What It Does" is written without jargon — a new engineer from another team can understand it in under 2 minutes
+- [ ] SLO targets are specific numbers agreed with stakeholders — not aspirational or copied from a template
+- [ ] All direct upstream consumers are listed in the "Who Depends on This" table — no omissions
+- [ ] API error codes are accurate and tested — not aspirational documentation
+- [ ] Known limitations are honest — nothing is glossed over to make the service look better than it is
+- [ ] All runbook links are live — not broken references or TODO placeholders
+- [ ] Data classification includes retention period and encryption status — not just sensitivity level
+- [ ] The entry has been reviewed by at least one consumer team to confirm it matches their experience of the service
@@ -0,0 +1,263 @@
+---
+name: sprint-velocity-analysis
+description: "Analyze sprint velocity data and produce an engineering team health report covering delivery trends, capacity utilization, and improvement recommendations. Use when asked to analyze sprint velocity, review team delivery health, identify delivery risks, or produce a retrospective data analysis. Produces a velocity trend analysis, health diagnosis table, top improvement recommendations with implementation steps, and a next-sprint capacity forecast."
+---
+
+# Sprint Velocity Analysis
+
+Analyze sprint velocity data to produce an honest engineering team health report. The goal is not to generate optimistic-looking charts — it is to surface delivery patterns, identify dysfunction early, and give the team and their manager actionable recommendations. Look for: velocity trends (improving, declining, flat, erratic), story point calibration consistency, carry-over patterns that indicate chronic over-commitment, and capacity-related signals. Produce text-based trend visualizations, a health diagnosis, and specific improvement recommendations with measurable targets.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Sprint history** — for each sprint: sprint name/number, committed story points, completed story points, and number of items carried over to next sprint; ideally 6–8 sprints minimum
+- **Team size and any changes** — current team size and any additions or departures during the data window
+- **Known disruptions** — holidays, company all-hands, on-call incidents, or other events that affected specific sprints
+- **Cycle time data (optional)** — if available, p50 and p90 cycle time per sprint (time from start to done)
+- **Definition of Done** — what "completed" means for this team (merged to main? deployed to prod? accepted by PO?)
+
+If cycle time data is not provided, omit that section and note it as a recommended data source to add.
+
+## Output Format
+
+---
+
+# Sprint Velocity Analysis: [Team Name]
+
+**Analysis period:** Sprint [N] through Sprint [N+7] ([Date range])
+**Team size:** [X engineers] ([note any changes during period])
+**Report date:** [Date]
+**Data source:** [Where this data came from — Jira, Linear, spreadsheet, etc.]
+
+---
+
+## Velocity Trend
+
+### Raw Data
+
+| Sprint | Committed | Completed | Completion Rate | Carried Over | Notes |
+|--------|-----------|-----------|----------------|--------------|-------|
+| [Sprint N] | [X pts] | [X pts] | [X%] | [X pts / X items] | [disruption or context] |
+| [Sprint N+1] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| [Sprint N+2] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| [Sprint N+3] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| [Sprint N+4] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| [Sprint N+5] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| [Sprint N+6] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| [Sprint N+7] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| **Average** | **[X pts]** | **[X pts]** | **[X%]** | **[X pts]** | |
+
+### Velocity Chart (Completed Points per Sprint)
+
+```
+Points
+  60 |
+  55 |          ●
+  50 |    ●           ●
+  45 | ●        ●          ●
+  40 |               ●          ●
+  35 |
+  30 |
+     +--+--+--+--+--+--+--+--
+      N N+1 N+2 N+3 N+4 N+5 N+6 N+7
+      Sprint
+
+  ● = Completed points   — = Average ([X pts])
+```
+
+Generate this chart using ASCII characters based on the actual data provided. Scale the Y-axis to the data range. Plot completed (not committed) points. Mark the average as a dashed line.
+
+### Trend Diagnosis
+
+| Metric | Value | Interpretation |
+|--------|-------|----------------|
+| Average velocity | [X pts/sprint] | [Baseline for planning] |
+| Velocity std deviation | [±X pts] | [Low < 15% of avg = stable; High > 25% = erratic] |
+| Trend direction | [Improving / Flat / Declining / Erratic] | [3-sprint trailing average vs. 3-sprint leading average] |
+| Average completion rate | [X%] | [Healthy: 80–95%; < 75% = chronic over-commitment] |
+| Carry-over rate | [X% of committed points carried over per sprint] | [Healthy: < 15%; > 25% = systemic issue] |
+| Sprints with completion rate < 75% | [X of 8 sprints] | [> 3 of 8 = structural problem, not noise] |
+
+---
+
+## Story Point Calibration
+
+Story points are only useful if they are applied consistently. Look for these calibration signals in the data:
+
+| Signal | Observed | Interpretation |
+|--------|----------|----------------|
+| High variance in velocity despite stable team size | [Yes / No] | Suggests inconsistent estimation — same effort scored differently week to week |
+| Consistent over-commitment (committed >> completed) | [Yes / No — by avg X pts per sprint] | Team is sandbagging estimates or ignoring historical capacity |
+| Consistent under-commitment (completed >> committed by > 20%) | [Yes / No] | Team is over-padding estimates or pulling in unplanned work frequently |
+| Frequent large items (> 13 pts) in carry-over | [Yes / No] | Items are too large to estimate reliably — need better decomposition |
+| Velocity cliff after team change | [Yes / No — Sprint N+X] | Team did not re-baseline capacity after composition changed |
+
+**Calibration verdict:** [Well-calibrated / Needs recalibration / Severely uncalibrated — one sentence explanation tied to the signals above]
+
+**If recalibration is needed:** [Specific recommendation — e.g., "Run a calibration session using the last 20 completed items, re-score them as a team, and use the resulting relative sizes to anchor future estimates."]
+
+---
+
+## Carry-Over Pattern Analysis
+
+Carry-over is the most reliable leading indicator of commitment reliability problems.
+
+| Sprint | Carried-Over Items | Common Themes in Carry-Over |
+|--------|-------------------|----------------------------|
+| [Sprint N] | [X items / X pts] | [Technical debt, dependency blocked, scoped wrong, etc.] |
+| [Sprint N+1] | [X items / X pts] | [Theme] |
+| [Sprint N+2] | [X items / X pts] | [Theme] |
+
+**Carry-over root causes identified:**
+- [Root cause 1: e.g., "5 of 12 carry-overs were blocked on a third-party API integration — external dependency, not estimation failure"]
+- [Root cause 2: e.g., "4 of 12 carry-overs were items estimated at 8+ points that were later found to be 2–3x larger than expected"]
+- [Root cause 3: e.g., "3 of 12 carry-overs were interruptions from on-call incidents consuming unplanned capacity"]
+
+---
+
+## Capacity Utilization
+
+| Sprint | Team Size | Available Capacity (pts) | Committed | Utilization % | Disruptions |
+|--------|-----------|--------------------------|-----------|--------------|-------------|
+| [Sprint N] | [X engineers] | [X pts] | [X pts] | [X%] | [Holiday / incident / none] |
+| [Sprint N+1] | [X engineers] | [X pts] | [X pts] | [X%] | |
+
+**Capacity calculation used:** [X engineers × Y pts/person/sprint = Z pts available. Adjust: if team capacity changed during the window, note which sprints used which team size.]
+
+**Average utilization:** [X%]
+**Utilization interpretation:** [< 70% = team is under-loaded or over-padding | 70–90% = healthy range | > 90% = no slack for unplanned work — fragile]
+
+---
+
+## Health Diagnosis
+
+| Dimension | Score | Evidence | Priority |
+|-----------|-------|----------|----------|
+| Delivery predictability | [Green / Yellow / Red] | [Average completion rate X%, std dev Y pts] | [High / Med / Low] |
+| Commitment accuracy | [Green / Yellow / Red] | [Team over-commits by avg X pts/sprint] | |
+| Estimation consistency | [Green / Yellow / Red] | [Velocity std dev ±X pts, calibration verdict] | |
+| Carry-over hygiene | [Green / Yellow / Red] | [X% carry-over rate, root causes] | |
+| Capacity management | [Green / Yellow / Red] | [Avg utilization X%, disruption handling] | |
+| Trend direction | [Green / Yellow / Red] | [Trailing 3-sprint avg vs. leading 3-sprint avg] | |
+
+**Scoring guide:** Green = operating within healthy range; Yellow = marginal — watch closely or single-sprint anomaly; Red = chronic issue requiring active intervention.
+
+**Overall health:** [Green / Yellow / Red] — [One sentence summary: "The team delivers consistently at X pts/sprint but chronic over-commitment is eroding morale and creating a misleading picture for stakeholders."]
+
+---
+
+## Blocker Frequency Analysis
+
+If blocker data was provided, complete this section. If not, note it as a recommended tracking addition.
+
+| Blocker Category | Frequency (last 8 sprints) | Avg Days Blocked | Impact (pts delayed) |
+|-----------------|--------------------------|------------------|---------------------|
+| External dependency | [X occurrences] | [X days] | [X pts] |
+| Technical debt / rework | [X occurrences] | [X days] | [X pts] |
+| Unclear requirements | [X occurrences] | [X days] | [X pts] |
+| On-call interruptions | [X occurrences] | [X days] | [X pts] |
+| Environment / tooling | [X occurrences] | [X days] | [X pts] |
+
+**Top blocker to address:** [Name the single highest-impact blocker category and what addressing it would mean for velocity.]
+
+---
+
+## Improvement Recommendations
+
+Provide 3 specific recommendations ordered by expected impact. Each recommendation must include a measurable success target and implementation steps.
+
+### Recommendation 1: [Title]
+
+**Problem it addresses:** [Which health dimension is Red or Yellow, and what the data shows]
+
+**What to do:**
+1. [Specific action step — concrete enough that a tech lead can assign it]
+2. [Next step]
+3. [Next step]
+
+**Who owns it:** [Tech lead / Engineering manager / Whole team]
+**When to start:** [This sprint / Next sprint / Within 2 weeks]
+
+**Measurable target:** [e.g., "Carry-over rate drops below 15% within 3 sprints" or "Completion rate above 80% for 4 consecutive sprints"]
+
+**How to know it's working:** [Leading indicator to watch before the outcome metric improves — e.g., "Carry-over items decreasing sprint-over-sprint even before the target is hit"]
+
+---
+
+### Recommendation 2: [Title]
+
+**Problem it addresses:** [Health dimension and evidence]
+
+**What to do:**
+1. [Step]
+2. [Step]
+3. [Step]
+
+**Who owns it:** [Role]
+**When to start:** [Timing]
+
+**Measurable target:** [Specific metric and timeframe]
+
+**How to know it's working:** [Leading indicator]
+
+---
+
+### Recommendation 3: [Title]
+
+**Problem it addresses:** [Health dimension and evidence]
+
+**What to do:**
+1. [Step]
+2. [Step]
+
+**Who owns it:** [Role]
+**When to start:** [Timing]
+
+**Measurable target:** [Specific metric and timeframe]
+
+**How to know it's working:** [Leading indicator]
+
+---
+
+## Next-Sprint Capacity Forecast
+
+**Next sprint:** [Sprint N+8]
+**Known team size:** [X engineers]
+**Known capacity reducers:** [PTO: X days total, on-call rotation: ~Y pts of unplanned capacity, etc.]
+
+| Factor | Impact |
+|--------|--------|
+| Base capacity (historical average) | [X pts] |
+| PTO / planned absences | −[X pts] |
+| On-call overhead (estimate) | −[X pts] |
+| Carry-over from Sprint [N+7] | +[X pts committed capacity already spoken for] |
+| **Recommended commitment ceiling** | **[X pts]** |
+
+**Confidence:** [High — stable team and known capacity | Medium — some uncertainty in disruption level | Low — team composition uncertain]
+
+**Recommendation for planning:** [One sentence — e.g., "Plan to Sprint [N+8] ceiling of X pts. Given the carry-over items, prioritize completing those before pulling in new scope."]
+
+---
+
+## Cycle Time Distribution (if data provided)
+
+| Sprint | p50 Cycle Time | p90 Cycle Time | Items Completed |
+|--------|---------------|---------------|-----------------|
+| [Sprint N] | [X days] | [X days] | [X items] |
+| [Average] | [X days] | [X days] | |
+
+**Cycle time interpretation:** [p90 > 2× p50 indicates a long-tail of stuck items that deserve investigation. p50 increasing over time indicates slowing throughput independent of story point changes.]
+
+If cycle time data was not provided: *Cycle time data was not included in this analysis. Recommend adding p50 and p90 cycle time per sprint to your tracking to detect throughput issues that story points alone cannot reveal.*
+
+---
+
+## Quality Checks
+
+- [ ] Velocity chart is generated from the actual data provided — not a generic placeholder chart
+- [ ] Trend diagnosis states a direction (Improving / Flat / Declining / Erratic) with a quantitative basis (trailing vs. leading average)
+- [ ] Carry-over root causes are specific categories with counts — not a generic observation that carry-over exists
+- [ ] Each of the 3 recommendations includes a named owner, a start date, and a measurable target with a timeframe
+- [ ] Next-sprint capacity forecast uses historical average as the baseline and deducts specific known reducers
+- [ ] Health diagnosis table uses Red/Yellow/Green with evidence cited in the Evidence column — no unsupported scores
+- [ ] If metrics are missing (cycle time, blocker log), the report explicitly calls them out as recommended additions
@@ -0,0 +1,290 @@
+---
+name: tech-radar
+description: "Build a technology radar for an engineering team, categorizing technologies into Adopt/Trial/Assess/Hold quadrants following the ThoughtWorks Tech Radar format. Use when asked to create a tech radar, evaluate the team's technology landscape, categorize tools and frameworks, or establish a technology strategy. Produces a full tech radar with quadrant tables, individual blip rationales, a decision trail, and a maintenance process guide."
+---
+
+# Tech Radar
+
+Produce a complete technology radar document for an engineering team. The radar gives the team a shared, explicit position on every significant technology in their stack — what to standardize on, what to experiment with, what to evaluate, and what to actively stop using. Follow the ThoughtWorks Tech Radar format: four quadrants (Techniques, Tools, Platforms, Languages & Frameworks) each with four rings (Adopt, Trial, Assess, Hold). Each technology entry ("blip") gets a ring assignment, a one-paragraph rationale, and a date. Include a decision trail showing what moved and why, and a maintenance process the team can run to keep the radar current.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Team or company name** — for the document header
+- **Current tech stack** — list every significant technology, tool, language, and platform the team currently uses
+- **Technologies under active evaluation** — tools or frameworks the team is currently trying or considering
+- **Technologies to deprecate or move off** — anything the team wants to stop using or is actively migrating away from
+- **Strategic technology bets** — any technologies the company has made a deliberate bet on (e.g., "we're all-in on Kubernetes" or "migrating to event-driven architecture")
+- **Team context** — team size, product domain, and any constraints (regulatory, compliance, vendor lock-in concerns)
+
+If a technology is mentioned without a ring placement, use the rationale inputs to determine the appropriate ring. When uncertain between two rings, ask.
+
+## Output Format
+
+---
+
+# Technology Radar: [Team / Company Name]
+
+**Edition:** [Month Year]
+**Maintained by:** [Team Name / Architecture Guild / CTO Office]
+**Review cadence:** Bi-annual (every 6 months)
+**Next review:** [Month Year + 6 months]
+
+---
+
+## How to Read This Radar
+
+This radar reflects [Team / Company Name]'s current thinking on technologies we use, evaluate, and retire. Use it to make consistent technology choices, onboard new engineers, and have structured conversations about the stack.
+
+**Quadrants** categorize the type of technology:
+
+| Quadrant | What belongs here |
+|----------|------------------|
+| **Techniques** | Methods, patterns, and practices (e.g., trunk-based development, event sourcing) |
+| **Tools** | Software tools used in the development and delivery process (e.g., linters, CI systems, observability platforms) |
+| **Platforms** | Infrastructure and hosting environments (e.g., AWS, Kubernetes, Snowflake) |
+| **Languages & Frameworks** | Programming languages and application frameworks (e.g., Go, React, FastAPI) |
+
+**Rings** express our recommendation:
+
+| Ring | Meaning | What to do |
+|------|---------|-----------|
+| **Adopt** | Industry-proven, working well for us — our standard choice | Use by default for new work; no special justification needed |
+| **Trial** | Worth pursuing — we are experimenting with it in limited production use | Use in a bounded context with architectural oversight; share learnings |
+| **Assess** | Worth exploring — we have not used it in production yet | Spike, prototype, or research; do not use in production without a review |
+| **Hold** | Do not start new work with this technology | Complete existing commitments; do not expand use; plan migration |
+
+---
+
+## Quadrant 1: Techniques
+
+### Adopt
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Technique name, e.g., Trunk-based development] | [Month Year] | [One sentence: why we adopted it and what it replaced] |
+| [Technique name] | [Month Year] | [One sentence rationale] |
+| [Technique name] | [Month Year] | [One sentence rationale] |
+
+**[Technique name] — Adopt**
+[One paragraph rationale. Explain what problem this technique solves, why it works well in your context, and what the team should know before applying it. Reference any internal experience — e.g., "We rolled this out across 8 services in 2024 and saw a 40% reduction in merge conflicts."]
+
+[Repeat for each Adopt-ring technique.]
+
+### Trial
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Technique name] | [Month Year] | [One sentence: what we're testing and where] |
+
+**[Technique name] — Trial**
+[One paragraph. What are we trialing? In which teams or services? What hypothesis are we testing? What would cause us to move it to Adopt vs. Hold?]
+
+### Assess
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Technique name] | [Month Year] | [One sentence: why we're interested] |
+
+**[Technique name] — Assess**
+[One paragraph. Why is this interesting to us? What would we need to see to move it to Trial? Who is responsible for the assessment?]
+
+### Hold
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Technique name] | [Month Year] | [One sentence: why we're stopping and what replaces it] |
+
+**[Technique name] — Hold**
+[One paragraph. Why are we putting this on hold? What is the migration path? What is the target end-state for teams still using it?]
+
+---
+
+## Quadrant 2: Tools
+
+### Adopt
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Tool name, e.g., GitHub Actions] | [Month Year] | [One sentence rationale] |
+| [Tool name] | [Month Year] | [One sentence rationale] |
+
+**[Tool name] — Adopt**
+[One paragraph rationale. Why is this our standard tool? What does it do well in our context? Any configuration or usage patterns the team should follow?]
+
+[Repeat for each Adopt-ring tool.]
+
+### Trial
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Tool name] | [Month Year] | [One sentence: what we're testing] |
+
+**[Tool name] — Trial**
+[One paragraph rationale and trial scope.]
+
+### Assess
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Tool name] | [Month Year] | [One sentence: why we're evaluating it] |
+
+**[Tool name] — Assess**
+[One paragraph: what sparked interest, who is evaluating, and timeline.]
+
+### Hold
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Tool name] | [Month Year] | [One sentence: what replaces it] |
+
+**[Tool name] — Hold**
+[One paragraph: deprecation rationale and migration path.]
+
+---
+
+## Quadrant 3: Platforms
+
+### Adopt
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Platform name, e.g., AWS EKS] | [Month Year] | [One sentence rationale] |
+| [Platform name] | [Month Year] | [One sentence rationale] |
+
+**[Platform name] — Adopt**
+[One paragraph. What does this platform provide? What are the boundaries of its use? Any internal golden-path setup the team should follow?]
+
+[Repeat for each Adopt-ring platform.]
+
+### Trial
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Platform name] | [Month Year] | [One sentence: scope of trial] |
+
+**[Platform name] — Trial**
+[One paragraph rationale and trial boundaries.]
+
+### Assess
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Platform name] | [Month Year] | [One sentence: why we're exploring it] |
+
+**[Platform name] — Assess**
+[One paragraph assessment plan.]
+
+### Hold
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Platform name] | [Month Year] | [One sentence: migration target and timeline] |
+
+**[Platform name] — Hold**
+[One paragraph: what triggered the hold decision, migration target, and timeline.]
+
+---
+
+## Quadrant 4: Languages & Frameworks
+
+### Adopt
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Language/Framework, e.g., Go] | [Month Year] | [One sentence rationale] |
+| [Language/Framework] | [Month Year] | [One sentence rationale] |
+
+**[Language/Framework] — Adopt**
+[One paragraph. What is this language or framework used for? What are the team's proficiency expectations? Any frameworks or libraries that go alongside it as part of the standard choice?]
+
+[Repeat for each Adopt-ring language or framework.]
+
+### Trial
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Language/Framework] | [Month Year] | [One sentence: bounded use case] |
+
+**[Language/Framework] — Trial**
+[One paragraph rationale.]
+
+### Assess
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Language/Framework] | [Month Year] | [One sentence: interest driver] |
+
+**[Language/Framework] — Assess**
+[One paragraph assessment plan.]
+
+### Hold
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Language/Framework] | [Month Year] | [One sentence: reason and migration path] |
+
+**[Language/Framework] — Hold**
+[One paragraph: deprecation rationale, existing system obligations, and timeline to retire.]
+
+---
+
+## Decision Trail
+
+This log records every ring movement since the radar's first edition. Use it to understand the evolution of our technology choices.
+
+| Technology | Quadrant | Previous Ring | New Ring | Edition | Reason |
+|------------|----------|--------------|----------|---------|--------|
+| [Name] | [Quadrant] | — | Adopt | [Month Year] | First placement — [one sentence why] |
+| [Name] | [Quadrant] | Assess | Trial | [Month Year] | [What prompted the move — evidence, team feedback, production trial results] |
+| [Name] | [Quadrant] | Trial | Adopt | [Month Year] | [Adoption rationale — usage results, team satisfaction, scale proven] |
+| [Name] | [Quadrant] | Adopt | Hold | [Month Year] | [Why moved to Hold — better alternative, security concern, cost, vendor issue] |
+| [Name] | [Quadrant] | — | Hold | [Month Year] | First placement — added directly to Hold because [reason] |
+
+---
+
+## Radar Maintenance Process
+
+### Who Contributes
+
+- **Architecture review group / CTO office** — final ring placement decisions
+- **All engineers** — submit blip nominations via [channel or form]
+- **Tech leads** — triage nominations and prepare proposals for review sessions
+
+### Update Cadence
+
+| Activity | Frequency | Owner |
+|----------|-----------|-------|
+| New blip nominations accepted | Ongoing — any engineer via [channel] | Anyone |
+| Nomination triage | Monthly | Tech leads |
+| Full radar review session | Every 6 months | Architecture group |
+| Published radar update | Every 6 months | [Owner name or role] |
+
+### How to Nominate a Blip
+
+1. Submit to [Slack channel / form URL] with: technology name, quadrant, proposed ring, and one-paragraph rationale.
+2. A tech lead reviews within 2 weeks and either schedules it for the next review session or requests more information.
+3. At the review session, the architecture group discusses and votes. Simple majority wins; ties go to Hold pending further evidence.
+4. Approved blips are added to the radar doc and the decision trail within 1 week of the session.
+
+### Ring Change Criteria
+
+| To move TO Adopt | To move TO Trial | To move TO Assess | To move TO Hold |
+|-----------------|-----------------|-------------------|-----------------|
+| Proven in multiple production systems; team broadly trained; clear operational runbook exists | At least one production use case running; architectural oversight in place; learnings documented | Concrete use case identified; spike completed or in progress; interest from at least 2 engineers | Better alternative exists; known security/compliance risk; strategic direction change; unacceptable maintenance burden |
+
+---
+
+*Questions about this radar: [Slack channel] | Submit a nomination: [URL or channel]*
+
+---
+
+## Quality Checks
+
+- [ ] Every blip has a written rationale paragraph — not just a table row entry
+- [ ] The decision trail is populated with at least the initial placement date for every blip
+- [ ] Hold-ring entries include a concrete migration path or target technology, not just "stop using it"
+- [ ] Ring definitions are present and include both what each ring means AND what engineers should do in response
+- [ ] Maintenance process includes: nomination channel, review cadence, who decides, and ring-change criteria
+- [ ] Technologies identified as "strategic bets" in the inputs are placed in Adopt (if proven) or Trial (if being rolled out)
+- [ ] Technologies identified for deprecation are in Hold with a rationale that references the replacement
@@ -0,0 +1,260 @@
+---
+name: technical-debt-register
+description: "Document and prioritize a technical debt backlog with business impact, effort estimates, and resolution strategy. Use when asked to audit technical debt, create a debt register, prioritize tech debt for a quarter, document architectural shortcuts, or build a debt reduction roadmap. Produces a structured technical debt register covering debt inventory by category, business impact per item, effort and priority scores, top-item resolution plans, and a quarterly debt reduction roadmap."
+---
+
+# Technical Debt Register Skill
+
+Produce a complete technical debt register for a team or service. A debt register is not a complaint list — it is a prioritized, business-impact-aware inventory that lets an engineering team make deliberate choices about which debt to pay down, in what order, and with what expected return.
+
+Good debt management is not eliminating all debt. It is ensuring debt is visible, owned, and resolved when the interest cost exceeds the cost of fixing it.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Team or service name** — what team and/or service this register covers
+- **Known debt items** — list of known technical debt, or ask Claude to elicit them by asking about: legacy code, missing tests, outdated dependencies, architectural shortcuts, manual processes, observability gaps, security backlogs
+- **Tech stack** — language, frameworks, infrastructure (helps Claude categorise and score items correctly)
+- **Team size and velocity** — number of engineers and approximate story points or days per sprint (needed for effort estimates)
+- **Current quarter / planning period** — so the roadmap targets the right timeframe
+
+## Output Format
+
+---
+
+# Technical Debt Register: [Team / Service Name]
+
+**Team:** [Name] | **Service(s):** [Name(s)]
+**Author:** [Name] | **Last updated:** [Date]
+**Planning period:** [Q[X] [Year]] | **Review cadence:** [Monthly / Quarterly]
+
+---
+
+## Overview
+
+[2–3 sentences describing the team's current debt situation, the main categories of debt, and the business context — e.g. are they in a growth phase where velocity matters, or approaching a compliance deadline where security debt is critical?]
+
+**Total items in register:** [X]
+**Unresolved items:** [X]
+**Critical/High priority items:** [X]
+**Estimated total resolution effort:** [X story points / X engineer-weeks]
+
+---
+
+## Debt Category Definitions
+
+| Category | Description | Examples |
+|---|---|---|
+| **Code quality** | Code that works but is hard to change safely | Duplicated logic, deeply nested conditionals, inconsistent error handling, missing abstraction |
+| **Architecture** | Structural decisions that limit scalability or increase coupling | Monolith that should be decomposed, sync calls that should be async, missing domain boundaries |
+| **Testing** | Gaps in test coverage that increase regression risk | Missing unit tests, no integration tests, flaky test suite, no test data management |
+| **Security** | Known vulnerabilities or missing security controls | Outdated dependencies with CVEs, missing rate limiting, hard-coded secrets, insufficient auth |
+| **Dependencies** | Outdated or risky external dependencies | End-of-life libraries, major version lag, abandoned packages |
+| **Infrastructure** | Infrastructure that limits reliability or developer productivity | Manual deployment steps, no IaC, single-AZ, missing autoscaling |
+| **Observability** | Gaps in visibility that slow incident response | Missing metrics, no distributed tracing, poor log structure, no alerting on key SLIs |
+| **Process** | Manual or error-prone operational processes | Manual DB migrations, no runbooks, tribal knowledge not documented |
+
+---
+
+## Debt Register
+
+### Scoring Method
+
+**Business impact (1–5):**
+- 5 — Blocking growth, causing production incidents, or creating compliance risk
+- 4 — Significantly slowing delivery or increasing incident likelihood
+- 3 — Noticeable slowdown; manageable but accumulating
+- 2 — Minor friction; low immediate risk
+- 1 — Cosmetic or aspirational; no current business impact
+
+**Effort to resolve (1–5, lower = easier):**
+- 1 — <0.5 day; single engineer
+- 2 — 0.5–2 days; single engineer
+- 3 — 3–5 days; single engineer or small pair
+- 4 — 1–2 weeks; team collaboration required
+- 5 — >2 weeks; significant planning and coordination
+
+**Priority score = Business impact × (6 − Effort)** *(rewards high-impact, low-effort items)*
+
+---
+
+| ID | Item | Category | Business impact (1–5) | Effort (1–5) | Priority score | Status | Owner |
+|---|---|---|---|---|---|---|---|
+| TD-001 | [e.g. No integration tests for payment flow] | Testing | 5 | 3 | 15 | Open | [Name] |
+| TD-002 | [e.g. Authentication library 3 major versions behind] | Security | 5 | 2 | 20 | Open | [Name] |
+| TD-003 | [e.g. Database queries not using connection pooling] | Architecture | 4 | 2 | 16 | Open | [Name] |
+| TD-004 | [e.g. Manual deployment process for [service]] | Infrastructure | 4 | 3 | 12 | In progress | [Name] |
+| TD-005 | [e.g. 200-line God function in order processing] | Code quality | 3 | 3 | 9 | Open | [Name] |
+| TD-006 | [e.g. No structured logging — plain text only] | Observability | 3 | 2 | 12 | Open | [Name] |
+| TD-007 | [e.g. ORM version has known N+1 query issue] | Dependencies | 3 | 3 | 9 | Open | [Name] |
+| TD-008 | [e.g. No runbook for [critical operation]] | Process | 3 | 1 | 15 | Open | [Name] |
+| TD-009 | [e.g. Test coverage at 34% — no meaningful safety net] | Testing | 4 | 4 | 8 | Open | [Name] |
+| TD-010 | [e.g. Hard-coded config values in application code] | Code quality | 2 | 1 | 10 | Open | [Name] |
+| TD-011 | [e.g. Service deployed single-AZ with no failover] | Infrastructure | 5 | 4 | 10 | Open | [Name] |
+| TD-012 | [e.g. No alerting on P95 latency for [endpoint]] | Observability | 4 | 1 | 20 | Open | [Name] |
+
+---
+
+## Category Breakdown
+
+```
+Category distribution (by item count):
+─────────────────────────────────────────────
+Code quality     ████████░░  [X items]  ([X]%)
+Architecture     ██████░░░░  [X items]  ([X]%)
+Testing          █████████░  [X items]  ([X]%)
+Security         ████░░░░░░  [X items]  ([X]%)
+Dependencies     ███░░░░░░░  [X items]  ([X]%)
+Infrastructure   ████░░░░░░  [X items]  ([X]%)
+Observability    ████░░░░░░  [X items]  ([X]%)
+Process          ██░░░░░░░░  [X items]  ([X]%)
+─────────────────────────────────────────────
+
+Priority distribution:
+Critical (score 20–25): [X items]
+High     (score 12–19): [X items]
+Medium   (score  6–11): [X items]
+Low      (score   1–5): [X items]
+```
+
+---
+
+## Top 5 Priority Items — Resolution Plans
+
+### TD-XXX: [Highest priority item name]
+
+**Priority score:** [Score] | **Category:** [Category] | **Owner:** [Name]
+
+**Problem:**
+[2–3 sentences describing what the debt is, how it manifests, and what pain it currently causes. Be specific — reference actual incidents, slowdowns, or risks.]
+
+**Business impact:**
+[What happens if this is not resolved? Reference any incidents, near-misses, or growth blockers. E.g. "This caused 2 production incidents in the last quarter and adds ~30 minutes of debugging time to any change in this area."]
+
+**Resolution approach:**
+[Clear description of the fix. Not "improve the code" — describe the actual work: "Extract the payment processing logic into a dedicated `PaymentService` class, write unit tests to 80% coverage, and update the 3 call sites."]
+
+**Steps:**
+1. [Specific, ticketable step]
+2. [Specific, ticketable step]
+3. [Specific, ticketable step]
+
+**Acceptance criteria:**
+- [ ] [Measurable criterion — e.g. "Zero hard-coded config values remain in application code"]
+- [ ] [Measurable criterion — e.g. "CI pipeline passes with new tests"]
+- [ ] [Measurable criterion]
+
+**Effort estimate:** [X story points / X days]
+**Suggested sprint:** [Q[X] Sprint [Y] / When [dependency] is complete]
+
+---
+
+### TD-XXX: [Second priority item name]
+
+**Priority score:** [Score] | **Category:** [Category] | **Owner:** [Name]
+
+**Problem:**
+[Description]
+
+**Business impact:**
+[Impact description]
+
+**Resolution approach:**
+[Approach description]
+
+**Steps:**
+1. [Step]
+2. [Step]
+3. [Step]
+
+**Acceptance criteria:**
+- [ ] [Criterion]
+- [ ] [Criterion]
+
+**Effort estimate:** [X story points / X days]
+**Suggested sprint:** [Sprint or timeframe]
+
+---
+
+### TD-XXX: [Third priority item]
+
+*(Follow same format as above)*
+
+---
+
+### TD-XXX: [Fourth priority item]
+
+*(Follow same format as above)*
+
+---
+
+### TD-XXX: [Fifth priority item]
+
+*(Follow same format as above)*
+
+---
+
+## Debt Reduction Roadmap
+
+### Guiding principles
+
+- Allocate [X%] of each sprint's capacity to debt resolution — recommended 15–20% for healthy teams
+- Security and dependency debt is addressed on a fixed cadence regardless of priority score
+- No new feature work in modules with Critical debt unless the debt is scheduled for the current sprint
+- Debt items closed without a resolution (accepted/deferred) must have a named owner and a review date
+
+### Quarterly plan
+
+| Quarter | Focus area | Items targeted | Estimated capacity | Expected outcome |
+|---|---|---|---|---|
+| **[Q1 Year]** (current) | Security + observability | TD-002, TD-012, TD-006 | [X] points / [Y] eng-days | Auth library current; latency alerting live; structured logging shipped |
+| **[Q2 Year]** | Architecture + reliability | TD-003, TD-011, TD-004 | [X] points / [Y] eng-days | Connection pooling fixed; multi-AZ deployed; deploy automation complete |
+| **[Q3 Year]** | Testing coverage | TD-001, TD-009 | [X] points / [Y] eng-days | Payment flow integration tests live; overall coverage ≥60% |
+| **[Q4 Year]** | Code quality + process | TD-005, TD-008, TD-010 | [X] points / [Y] eng-days | God functions refactored; runbooks complete; zero hard-coded config |
+
+### Sprint allocation model
+
+```
+Sprint capacity: [X] story points
+
+Allocation:
+  ├── Feature work:        [X * 0.75 = ~Y] points  (75%)
+  ├── Debt resolution:     [X * 0.15 = ~Y] points  (15%)
+  └── Unplanned/bugs:      [X * 0.10 = ~Y] points  (10%)
+
+Debt items that fit in one sprint ([≤Y] points each):
+  ✓ TD-002 ([X] points)
+  ✓ TD-012 ([X] points)
+  ✓ TD-006 ([X] points)
+  ✓ TD-008 ([X] points)
+
+Multi-sprint debt items (break into phases):
+  ~ TD-001: Phase 1 ([X] pts) → Phase 2 ([X] pts)
+  ~ TD-009: Requires dedicated debt sprint or pairing
+```
+
+---
+
+## Accepted / Deferred Debt
+
+Items where the cost of remediation currently exceeds the business value, accepted with explicit review dates.
+
+| ID | Item | Reason for deferral | Review date | Owner |
+|---|---|---|---|---|
+| TD-XXX | [Item] | [e.g. "Rewrite would require 3 weeks with no user-facing value at current scale; revisit at 10× traffic"] | [Date] | [Name] |
+| TD-XXX | [Item] | [e.g. "Dependency has a CVE but no upgrade path exists until Q3; mitigated by WAF rule"] | [Date] | [Name] |
+
+**Policy:** No item may be deferred more than twice without escalation to the engineering manager.
+
+---
+
+## Quality Checks
+
+- [ ] Every item has a named owner — no unowned debt
+- [ ] Priority scores are calculated using the formula, not assigned arbitrarily
+- [ ] Security and dependency items are not scored below their actual business impact because they feel "technical"
+- [ ] Top-5 resolution plans include specific, ticketable steps — not vague descriptions like "improve test coverage"
+- [ ] The quarterly roadmap allocates realistic capacity — debt allocation does not exceed actual sprint budget
+- [ ] Accepted/deferred items have a review date and a named owner — no permanently deferred items
+- [ ] The register distinguishes between debt (deliberate or accumulated shortcuts) and bugs (unintended defects)
+- [ ] Items are closed as resolved only when acceptance criteria are met — not when the PR is merged
@@ -0,0 +1,312 @@
+---
+name: api-versioning-strategy
+description: "Write an API versioning strategy document for a service or API platform. Use when asked to define versioning policy, plan API deprecation, classify breaking changes, or document version lifecycle. Produces a complete versioning strategy with breaking-change classification table, deprecation timeline, migration guide template, and client communication template."
+---
+
+# API Versioning Strategy
+
+Produce a complete API versioning strategy document that gives a service team durable, consistent rules for evolving their API without breaking consumers. This document covers the versioning scheme selection (with rationale), lifecycle policy from introduction through sunset, a precise breaking-change classification, and all the communication artifacts a team needs when deprecating a version. Engineers should be able to hand this document to a new team member or external consumer and have them understand exactly what to expect.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **API type** — REST, GraphQL, or gRPC (each has different versioning mechanics)
+- **Current versioning approach** — URL path (`/v1/`), request header, query parameter, or none; if none, document starts fresh
+- **Number of existing versions and active consumer count** — needed to size the lifecycle policy and migration scope
+- **Deprecation timeline constraints** — any hard deadlines (contract SLAs, compliance windows, annual release cycles)
+- **Consumer type** — internal teams only, external partners, public API, or mix (affects communication channel choices)
+
+If any input is missing, ask before producing the document. For GraphQL, note that the versioning approach differs substantially (schema evolution over versioning) and tailor the scheme section accordingly.
+
+## Output Format
+
+---
+
+# API Versioning Strategy: [Service Name]
+
+**Owner:** [Team Name]
+**API Type:** [REST / GraphQL / gRPC]
+**Document Version:** 1.0
+**Last Reviewed:** [Date]
+**Next Review:** [Date + 6 months]
+
+---
+
+## 1. Versioning Scheme
+
+### Selected Approach: [URL Path / Request Header / Query Parameter]
+
+| Scheme | Example | Pros | Cons | Verdict |
+|--------|---------|------|------|---------|
+| URL Path | `/v2/orders` | Visible in logs and bookmarks; trivial to route | Violates strict REST resource identity; clutters URL space | **Recommended for public-facing REST APIs** |
+| `Accept` Header | `Accept: application/vnd.[service].v2+json` | Keeps URLs clean; proper content negotiation | Harder to test in browser; less visible in logs | Recommended for internal APIs with controlled clients |
+| Query Parameter | `/orders?version=2` | Easy to retrofit without URL restructuring | Often missed in client code; cache-key complications | Acceptable only for read-heavy APIs already in production |
+| GraphQL Schema Evolution | Field deprecation + `@deprecated` directive | No versioning needed for additive changes | Requires disciplined schema design | **Recommended for GraphQL APIs** |
+
+**Rationale for [chosen scheme]:** [One paragraph explaining why this scheme fits the API type, consumer type, and operational context provided. Reference the specific inputs — e.g., "Because this API has external partners who integrate via generated clients, URL path versioning provides the most predictable routing behavior and eliminates header negotiation complexity."]
+
+### Version Format
+
+```
+[Base URL]/v{MAJOR}/{resource}
+
+Examples:
+  https://api.[company].com/v1/orders
+  https://api.[company].com/v2/orders/{id}/items
+
+Version identifier: integer only (v1, v2, v3)
+No minor versions in the URL — minor/patch changes are non-breaking and deployed continuously.
+```
+
+---
+
+## 2. Version Lifecycle Policy
+
+### Lifecycle Stages
+
+```
+  STABLE ──────────────────────────────────────────────────►
+      │
+      ├─ STABLE        Active development, full SLA, new consumers allowed
+      │
+      ├─ DEPRECATED    Announced, timeline posted, migration docs live.
+      │                New consumers blocked. Existing consumers receive warnings.
+      │
+      ├─ SUNSET        Requests return HTTP 410 Gone + migration pointer.
+      │                30-day window before routing is removed.
+      │
+      └─ RETIRED       Routing removed, docs archived, no traffic accepted.
+```
+
+| Stage | Duration | SLA Applies | New Consumers Allowed | Required Action |
+|-------|----------|-------------|----------------------|-----------------|
+| Stable | Until superseded | Yes — full | Yes | None |
+| Deprecated | [12 months / adjust per constraint] | Yes — degraded acceptable | No | Migrate before sunset date |
+| Sunset | 30-day window | Best-effort only | No | Migrate immediately |
+| Retired | Permanent | None | No | — |
+
+**Minimum Stable Period:** A version must remain Stable for at least [6 / 12] months before deprecation can be announced.
+
+**Maximum Simultaneous Versions:** No more than [2] versions in Stable or Deprecated status at any time. Releasing v3 requires committing to a sunset date for v1 in the same announcement.
+
+---
+
+## 3. Breaking vs. Non-Breaking Change Classification
+
+Apply this table before every API change. If a change is marked Breaking, it requires a new major version. When uncertain, default to Breaking.
+
+| Change Type | Specific Example | Classification | Rationale |
+|-------------|-----------------|----------------|-----------|
+| Remove a response field | Delete `order.legacy_id` from response | **Breaking** | Clients reading this field will null-pointer or fail |
+| Rename a field | `user_name` → `username` | **Breaking** | Clients referencing old name receive null |
+| Change field type | `"amount": "10.00"` → `"amount": 10.00` | **Breaking** | Type mismatch at deserialization |
+| Make optional field required | `email` required in POST body | **Breaking** | Existing callers omitting it receive 400 |
+| Remove an endpoint | `DELETE /v1/widgets/{id}` removed | **Breaking** | Existing callers receive 404 |
+| Change HTTP method | `GET /search` → `POST /search` | **Breaking** | Bookmarked or cached GET calls fail |
+| Change authentication scheme | API key → OAuth2 | **Breaking** | All clients must re-authenticate |
+| Restructure error response shape | Error JSON schema changed | **Breaking** | Error-handling code misparses responses |
+| Expand enum values (response) | New `status: "on_hold"` value returned | **Breaking** | Switch statements with no default fall through |
+| Change pagination defaults | `page_size` default 20 → 50 | **Breaking** | Response length changes unexpectedly |
+| Tighten input validation | Max length 100 → 50 | **Breaking** | Previously valid inputs now rejected |
+| Add new optional field to response | Add `order.tax_breakdown` | Non-Breaking | Clients ignore unknown fields per spec |
+| Add new optional request parameter | Add `?include_archived=true` | Non-Breaking | Ignored by existing clients |
+| Add a new endpoint | `GET /v1/orders/{id}/audit` | Non-Breaking | No existing client references it |
+| Relax input validation | Min length 10 → 5 | Non-Breaking | Existing valid inputs remain valid |
+| Performance or latency improvement | Response time reduced | Non-Breaking | — |
+| Add new enum value (request-only) | Accept new `type: "express"` | Non-Breaking | Existing values still accepted |
+
+---
+
+## 4. Deprecation Process
+
+### Step-by-Step Deprecation Checklist
+
+- [ ] **T-0 (Decision day):** Engineering lead approves deprecation. New version confirmed Stable. Sunset date set.
+- [ ] **T-0:** Update API docs — add deprecation banner to all v[N] endpoint pages.
+- [ ] **T-0:** Add `Deprecation` and `Sunset` response headers to all v[N] responses (see format below).
+- [ ] **T-0:** Block new consumer onboarding for v[N] in API gateway and developer portal.
+- [ ] **T-0:** Send initial deprecation notice to all registered consumers (see Section 5 template).
+- [ ] **T-0:** Open tracking issue in engineering backlog linking all known consumers to their migration status.
+- [ ] **T minus 30 days:** Send 30-day warning to all consumers still sending v[N] traffic.
+- [ ] **T minus 7 days:** Send final warning. If consumer traffic > 100 req/day, escalate directly to their engineering lead.
+- [ ] **Sunset date:** Switch v[N] routing to return `HTTP 410 Gone` with body pointing to migration guide.
+- [ ] **T plus 30 days:** Remove routing rules. Archive documentation. Close tracking issue.
+
+### Deprecation Response Headers
+
+```http
+HTTP/1.1 200 OK
+Deprecation: true
+Sunset: Sat, 01 Jan 2027 00:00:00 GMT
+Link: <https://docs.[company].com/api/migration/v1-to-v2>; rel="successor-version"
+```
+
+### Sunset Response Body
+
+```http
+HTTP/1.1 410 Gone
+Content-Type: application/json
+
+{
+  "error": "api_version_sunset",
+  "message": "API v1 was sunset on 2027-01-01. Please migrate to v2.",
+  "migration_guide": "https://docs.[company].com/api/migration/v1-to-v2",
+  "support": "api-support@[company].com"
+}
+```
+
+---
+
+## 5. Client Communication Templates
+
+### Initial Deprecation Notice
+
+```
+Subject: [Action Required] [Service Name] API v[N] Deprecation — Sunset [Date]
+
+Hi [Team / Partner Name],
+
+We are deprecating [Service Name] API v[N], effective [Sunset Date].
+
+What this means for you:
+- v[N] continues to work normally until [Sunset Date]
+- After [Sunset Date], all v[N] requests return HTTP 410 Gone
+- v[N+1] is available today and fully stable
+
+Your current usage: approximately [X] requests/day as of [Date].
+Estimated migration effort: [Small: < 1 day | Medium: 1–3 days | Large: 3–10 days]
+
+Migration resources:
+  Migration guide:  [URL]
+  Changelog:        [URL]
+  Office hours:     [Date/Time/Link]
+  Support:          [Slack channel or email]
+
+Key dates:
+  [Date]          Deprecation announced (today)
+  [Date]          New consumer onboarding blocked for v[N]
+  [Date]          30-day warning sent to remaining consumers
+  [Sunset Date]   v[N] returns 410 Gone
+
+Reply to this message or contact us at [channel] with questions.
+
+[Your Name], [Team Name]
+```
+
+### 30-Day Warning
+
+```
+Subject: [30 Days Remaining] [Service Name] API v[N] sunsets [Date]
+
+Hi [Team / Partner Name],
+
+[Service Name] API v[N] sunsets in 30 days on [Date].
+
+Your current v[N] traffic: [X] requests/day — migration is not yet complete.
+
+If you have a technical blocker requiring an extension, contact us before
+[Date minus 14 days]. Extensions require a documented blocker and a committed
+migration completion date.
+
+Migration guide: [URL] | Support: [channel]
+```
+
+---
+
+## 6. Migration Guide Template
+
+Publish one migration guide per version transition at `docs.[company].com/api/migration/v[N]-to-v[N+1]`.
+
+```markdown
+# Migration Guide: v[N] → v[N+1]
+
+**Estimated effort:** [Small: < 1 day | Medium: 1–3 days | Large: 3–10 days]
+**Breaking changes in this guide:** [count]
+
+## Quick Start
+
+Update your base URL:
+  Before: https://api.[company].com/v[N]/
+  After:  https://api.[company].com/v[N+1]/
+
+## Breaking Changes
+
+### 1. [Field Rename: user_name → username]
+
+**Affected endpoints:** `GET /users/{id}`, `POST /users`
+
+Before (v[N]):
+{ "user_name": "alice" }
+
+After (v[N+1]):
+{ "username": "alice" }
+
+Migration: Replace all references to `user_name` with `username` in request
+builders and response parsers.
+
+### 2. [Next breaking change — repeat structure]
+
+## New Capabilities in v[N+1]
+
+| Feature | Description | Docs |
+|---------|-------------|------|
+| [Feature name] | [Brief description] | [Link] |
+
+## SDK Upgrade Reference
+
+| Language | Package | v[N+1] Version | Install Command |
+|----------|---------|----------------|-----------------|
+| Python | `[company]-sdk` | `2.0.0` | `pip install [company]-sdk==2.0.0` |
+| Node.js | `@[company]/sdk` | `2.0.0` | `npm install @[company]/sdk@2.0.0` |
+| Go | `github.com/[company]/sdk-go` | `v2.0.0` | `go get github.com/[company]/sdk-go/v2` |
+| Java | `com.[company]:sdk` | `2.0.0` | Update pom.xml / build.gradle |
+
+## Migration Validation Checklist
+
+- [ ] Base URL updated to v[N+1]
+- [ ] All renamed fields updated in request serializers
+- [ ] All renamed fields updated in response deserializers
+- [ ] Error-handling code updated for new error shape
+- [ ] Integration tests passing against v[N+1] in staging
+- [ ] Load test completed against v[N+1] — latency within acceptable range
+- [ ] Rollback plan documented if issues arise post-cutover
+```
+
+---
+
+## 7. Version-Specific Documentation
+
+- Maintain separate documentation pages for each Stable and Deprecated version.
+- Deprecated version docs carry a persistent banner: "This version is deprecated. Sunset date: [Date]. [Migrate to v[N+1]]."
+- OpenAPI specs, Protobuf definitions, or GraphQL schemas are tagged and archived per version in the repository under `/api/v[N]/`.
+- A root-level CHANGELOG.md records every breaking and non-breaking change by version — not buried in commit history.
+
+---
+
+## 8. SDK Versioning Alignment
+
+| API Version | SDK Major Version | SDK GA Date | SDK EOL Date |
+|-------------|------------------|-------------|--------------|
+| v[1] | 1.x | [Date] | [API Sunset + 90 days] |
+| v[2] | 2.x | [Date] | Active |
+
+- SDK major versions align 1:1 with API major versions.
+- SDK minor versions track non-breaking API additions.
+- SDK EOL dates trail API sunset dates by 90 days to give consumers extra runway.
+- SDKs emit a runtime deprecation warning log line when the underlying API version is Deprecated.
+
+---
+
+*Strategy authored by [Team Name] — questions to [Slack channel or email]*
+
+---
+
+## Quality Checks
+
+- [ ] Versioning scheme recommendation includes explicit rationale tied to the API type and consumer type provided — not a generic recommendation
+- [ ] Breaking-change table covers at minimum: field removal, field rename, type change, making optional field required, endpoint removal, enum expansion, and default value change
+- [ ] Deprecation timeline durations are filled in with concrete values, not left as abstract placeholders
+- [ ] All three communication artifacts are present: initial deprecation notice, 30-day warning, and migration guide template
+- [ ] Sunset response headers (`Deprecation`, `Sunset`, `Link`) use correct RFC date format and real URL structure
+- [ ] SDK versioning alignment table is present and ties SDK major versions explicitly to API major versions
+- [ ] Maximum simultaneous supported versions is stated with a concrete number
@@ -0,0 +1,358 @@
+---
+name: capacity-planning
+description: "Produce a capacity planning document for a service covering traffic forecasts, resource requirements, and scaling strategy. Use when asked to plan infrastructure capacity, forecast resource needs, model traffic growth, define scaling strategy, or produce a capacity review for a service. Produces a structured capacity plan covering current baseline metrics, growth projections, resource requirements per tier, scaling strategy, cost projections, capacity triggers, and an infrastructure action roadmap."
+---
+
+# Capacity Planning Skill
+
+Produce a complete capacity planning document for a service. Capacity planning is not about predicting the future exactly — it is about understanding current headroom, modelling growth, and ensuring the team takes infrastructure action before a constraint becomes an incident.
+
+A good capacity plan answers: what is running out first, how long before it runs out, what does it cost to fix it, and who decides when to act.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name and description** — what the service does and who depends on it
+- **Current traffic and usage metrics** — requests per second (or per day), active users, data volume — whatever units are most natural for this service
+- **Current resource utilisation** — CPU %, memory %, disk usage, connection pool utilisation, DB query throughput
+- **Growth rate or projections** — historical growth rate, or known upcoming events (product launch, sales cycle, seasonal peak)
+- **Tech stack and infrastructure** — cloud provider, compute type (VMs, containers, serverless), database, caching layer, CDN
+- **Cost constraints** — current infrastructure spend, acceptable cost ceiling, or target cost per unit of traffic
+
+## Output Format
+
+---
+
+# Capacity Plan: [Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Author:** [Name] | **Last updated:** [Date]
+**Planning horizon:** [12 months — [Month Year] to [Month Year]]
+**Review cadence:** [Quarterly]
+
+---
+
+## 1. Executive Summary
+
+[3–5 sentences covering: current state, the most critical capacity constraint, the timeline before it becomes a risk, the recommended action, and the cost implication. Written for an engineering manager or VP who needs the key facts without reading the full document.]
+
+**Critical finding:** [e.g. "The database connection pool will reach 90% utilisation within 6 weeks at current growth. Without action, this will cause request queueing and latency spikes under normal traffic."]
+
+**Recommended immediate action:** [e.g. "Increase connection pool limit and add a read replica within the next 2 weeks."]
+
+**Estimated cost impact:** [e.g. "Recommended changes add ~$[X]/month to infrastructure spend."]
+
+---
+
+## 2. Current Baseline
+
+*All metrics are 30-day averages unless noted. Date captured: [Date]*
+
+### Traffic
+
+| Metric | Value | Peak (7-day) | Notes |
+|---|---|---|---|
+| Requests per second (avg) | [X req/s] | [X req/s] | [Peak time / day of week] |
+| Requests per day | [X M/day] | [X M/day] | — |
+| Active users (DAU/MAU) | [X] / [X] | — | — |
+| [Service-specific metric — e.g. jobs processed/hour] | [X] | [X] | — |
+| [Service-specific metric — e.g. GB ingested/day] | [X GB] | [X GB] | — |
+
+### Compute
+
+| Resource | Current utilisation | Instance type | Count | Notes |
+|---|---|---|---|---|
+| CPU (avg) | [X%] | [e.g. c5.2xlarge] | [X] | Peak: [X%] |
+| Memory (avg) | [X%] | — | — | Peak: [X%] |
+| Network egress | [X Mbps] | — | — | — |
+| Container / pod count | [X] | [e.g. 2 vCPU / 4 GB] | — | Auto-scaling range: [X–Y] |
+
+### Database
+
+| Resource | Current utilisation | Spec | Notes |
+|---|---|---|---|
+| CPU | [X%] | [e.g. db.r5.2xlarge] | Peak: [X%] |
+| Memory | [X%] | [X GB RAM] | — |
+| Storage used | [X GB] of [Y GB] ([Z%]) | [X GB provisioned] | Growth: [~X GB/month] |
+| IOPS (avg) | [X] of [Y provisioned] | [Y IOPS] | Peak: [X IOPS] |
+| Connection pool | [X] of [Y max] ([Z%]) | Max connections: [Y] | [ORM pool size: X] |
+| Query P99 latency | [X ms] | — | [Slowest query: X] |
+| Read/write ratio | [X%] reads / [Y%] writes | — | — |
+
+### Cache
+
+| Resource | Current utilisation | Spec | Notes |
+|---|---|---|---|
+| Memory used | [X GB] of [Y GB] ([Z%]) | [e.g. cache.r6g.large] | Eviction rate: [X%] |
+| Hit rate | [X%] | — | Miss rate: [Y%] |
+| Connections | [X] | Max: [Y] | — |
+
+### Storage / Object Store
+
+| Resource | Current usage | Growth rate | Notes |
+|---|---|---|---|
+| [S3 / GCS / Blob] | [X GB / TB] | [~X GB/month] | [Lifecycle policies in place? Y/N] |
+| Disk (if applicable) | [X GB] of [Y GB] | [~X GB/month] | [RAID / EBS type] |
+
+### Cost Baseline
+
+| Component | Current monthly cost | % of total |
+|---|---|---|
+| Compute (app servers) | $[X] | [X%] |
+| Database | $[X] | [X%] |
+| Cache | $[X] | [X%] |
+| Storage | $[X] | [X%] |
+| CDN / bandwidth | $[X] | [X%] |
+| Other ([describe]) | $[X] | [X%] |
+| **Total** | **$[X]** | 100% |
+
+**Unit economics:** $[X] per [1,000 requests / 1,000 users / GB processed]
+
+---
+
+## 3. Growth Projections
+
+### Assumptions
+
+| Assumption | Value | Source | Confidence |
+|---|---|---|---|
+| Monthly traffic growth rate | [X%] | [Historical trend / product forecast] | [High / Medium / Low] |
+| Seasonal peak factor | [+X% in [month(s)]] | [Last year's data / expected launch] | [High / Medium] |
+| Upcoming events | [e.g. Marketing campaign — [Month], expected +[X]% traffic spike] | [Marketing plan] | [Medium] |
+| User growth | [X new users/month] | [Sales pipeline / growth model] | [Medium] |
+| Data growth | [X GB/month] | [Current trend] | [High] |
+
+### Traffic Forecast
+
+| Timeframe | Req/s (avg) | Req/s (peak) | DAU | Data volume (cumulative) |
+|---|---|---|---|---|
+| **Now** (baseline) | [X] | [X] | [X] | [X GB/TB] |
+| **+3 months** | [X] | [X] | [X] | [X GB/TB] |
+| **+6 months** | [X] | [X] | [X] | [X GB/TB] |
+| **+12 months** | [X] | [X] | [X] | [X GB/TB] |
+
+*Growth formula: [Baseline] × (1 + [monthly rate])^[months] + seasonal adjustment*
+
+### Capacity Headroom Analysis
+
+**When does each resource run out at current utilisation and projected growth?**
+
+| Resource | Current utilisation | Safe ceiling | Headroom remaining | Months to ceiling |
+|---|---|---|---|---|
+| App CPU | [X%] | 70% | [X%] | [X months] |
+| App memory | [X%] | 80% | [X%] | [X months] |
+| DB CPU | [X%] | 70% | [X%] | [X months] |
+| DB storage | [X GB] of [Y GB] | 80% = [Z GB] | [X GB] | [X months] |
+| DB IOPS | [X] of [Y] | 80% = [Z] | [X IOPS] | [X months] |
+| DB connections | [X] of [Y] | 80% = [Z] | [X] | [X months] |
+| Cache memory | [X GB] of [Y GB] | 75% = [Z GB] | [X GB] | [X months] |
+| Storage (object) | [X TB] | No hard limit — cost trigger | — | [Cost trigger: $X/month] |
+
+**Red flags** (resources hitting ceiling within 3 months):
+- [Resource]: [current]% → ceiling in [X weeks] — **Action required**
+- [Resource]: [current]% → ceiling in [X weeks] — **Action required**
+
+---
+
+## 4. Resource Requirements
+
+### Compute Requirements
+
+| Timeframe | Required instances | Recommended instance type | Auto-scaling range | Notes |
+|---|---|---|---|---|
+| Now | [X] | [type] | [min: X, max: Y] | Current configuration |
+| +3 months | [X] | [type] | [min: X, max: Y] | [Any instance type change needed?] |
+| +6 months | [X] | [type or upgrade] | [min: X, max: Y] | [Consider [larger type / horizontal scale]] |
+| +12 months | [X] | [type or upgrade] | [min: X, max: Y] | [State of horizontal vs vertical decision] |
+
+**Memory headroom target:** Maintain ≥30% available memory at average load; ≥20% at peak.
+**CPU headroom target:** Maintain ≥30% available CPU at average load; ≥15% at peak.
+
+### Database Requirements
+
+| Timeframe | Instance type | Storage | IOPS | Read replica | Notes |
+|---|---|---|---|---|---|
+| Now | [type] | [X GB] | [X] | [Y/N] | Current |
+| +3 months | [type] | [X GB] | [X] | [Y/N] | [Upgrade storage / IOPS] |
+| +6 months | [type or upgrade] | [X GB] | [X] | **Yes** | [Read replica recommended by this point] |
+| +12 months | [type] | [X GB] | [X] | [X replicas] | [Consider sharding / partitioning at this scale] |
+
+**Storage growth management:**
+- Current growth: [~X GB/month]
+- Storage auto-scaling: [Enabled / Not enabled — enable by [date]]
+- Archiving policy: [Records older than X months moved to [cold storage / archive tier]]
+
+### Cache Requirements
+
+| Timeframe | Node type | Nodes | Memory | Notes |
+|---|---|---|---|---|
+| Now | [type] | [X] | [X GB] | Current |
+| +6 months | [type] | [X] | [X GB] | [Scale out or upgrade] |
+| +12 months | [type] | [X] | [X GB] | [Cluster mode if >Y GB required] |
+
+---
+
+## 5. Scaling Strategy
+
+### Compute — Horizontal Scaling
+
+**Decision: [Horizontal / Vertical / Both]**
+
+[State the scaling strategy and the reasoning. E.g. "The application is stateless and CPU-bound; horizontal scaling is preferred. Vertical scaling is a short-term fallback only."]
+
+**Auto-scaling configuration:**
+
+```
+Scale-out trigger:  CPU > [X%] for [Y minutes] OR memory > [X%] for [Y minutes]
+Scale-in trigger:   CPU < [X%] for [Y minutes] AND memory < [X%] for [Y minutes]
+Min instances:      [X] (ensures HA across [X] AZs)
+Max instances:      [Y] (cost ceiling)
+Cooldown period:    [X seconds]
+Warmup time:        [X seconds] (time for new instance to be healthy)
+```
+
+**Limits of horizontal scaling:**
+- [e.g. Database connection pool is the current bottleneck — adding more app instances without increasing DB connections will not help]
+- [e.g. Session affinity required for WebSocket connections — limits pure stateless scaling]
+
+### Database — Read Scaling
+
+**Strategy:** [Read replica / Connection pooling via PgBouncer / Query caching / None needed yet]
+
+**When to add a read replica:**
+- DB CPU sustained >60% for >30 minutes, OR
+- Read query P95 latency >50ms, OR
+- Connection pool utilisation >70%
+
+**Connection pooling:**
+- Pooler: [PgBouncer / RDS Proxy / application-level / not configured]
+- Pool size: [X connections per app instance × Y instances = Z total]
+- Max DB connections: [configured to Z + 20% headroom]
+
+### Caching Strategy
+
+**Cache policy:** [Cache-aside / Write-through / Write-behind]
+**TTL strategy:**
+
+| Data type | TTL | Invalidation method |
+|---|---|---|
+| [e.g. User profile] | [5 minutes] | [Explicit invalidation on update] |
+| [e.g. Product catalog] | [1 hour] | [TTL expiry — eventual consistency acceptable] |
+| [e.g. Session data] | [24 hours] | [Explicit invalidation on logout] |
+
+**Cache miss handling:** [Describe what happens on a cache miss — does it fall through gracefully or cause a thundering herd risk?]
+
+---
+
+## 6. Cost Projections
+
+### Infrastructure Cost Forecast
+
+| Component | Now (monthly) | +3 months | +6 months | +12 months |
+|---|---|---|---|---|
+| Compute | $[X] | $[X] | $[X] | $[X] |
+| Database | $[X] | $[X] | $[X] | $[X] |
+| Cache | $[X] | $[X] | $[X] | $[X] |
+| Storage | $[X] | $[X] | $[X] | $[X] |
+| CDN / bandwidth | $[X] | $[X] | $[X] | $[X] |
+| **Total** | **$[X]** | **$[X]** | **$[X]** | **$[X]** |
+| MoM growth % | — | [X%] | [X%] | [X%] |
+
+**Unit economics trend:**
+
+| Timeframe | Cost per 1k requests | Cost per user/month | Notes |
+|---|---|---|---|
+| Now | $[X] | $[X] | Baseline |
+| +6 months | $[X] | $[X] | [Improving / worsening — why] |
+| +12 months | $[X] | $[X] | [Target: $X per 1k requests] |
+
+**Cost optimisation opportunities:**
+
+| Opportunity | Estimated saving | Effort | Timeline |
+|---|---|---|---|
+| [e.g. Reserved instances for baseline compute] | $[X/month] | Low | Immediate |
+| [e.g. S3 lifecycle policy — move objects >90 days to Glacier] | $[X/month] | Low | This sprint |
+| [e.g. Right-size [instance] — current is overprovisioned] | $[X/month] | Low | This sprint |
+| [e.g. Optimise top-5 slow queries — reduce DB compute need] | $[X/month] | Medium | Next quarter |
+
+---
+
+## 7. Capacity Triggers and Actions
+
+Define the thresholds that require explicit action — not retrospective fixes after an incident.
+
+| Resource | Watch (amber) | Act (red — schedule work) | Emergency (incident risk) |
+|---|---|---|---|
+| App CPU (sustained avg) | >60% | >70% | >85% |
+| App memory | >70% | >80% | >90% |
+| DB CPU | >55% | >65% | >80% |
+| DB storage | >65% | >75% | >85% |
+| DB connections | >60% | >70% | >85% |
+| Cache memory / eviction | Hit rate <90% | Hit rate <85% | Hit rate <75% |
+| Error rate | >0.5% | >1% | >2% |
+| P99 latency | >2× baseline | >3× baseline | >5× baseline |
+
+**When a Watch threshold is crossed:**
+- Engineer who observes it creates a ticket with capacity label
+- Ticket reviewed in next sprint planning
+
+**When an Act threshold is crossed:**
+- On-call engineer creates a ticket marked P2
+- Tech lead reviews within 24 hours
+- Action plan documented and scheduled within 1 sprint
+
+**When an Emergency threshold is crossed:**
+- Treat as a potential incident — page on-call
+- Emergency scaling actions taken immediately (see runbook)
+- Root cause investigation starts within 2 hours
+
+**Emergency scaling runbook:** [Link to oncall-runbook for capacity incidents]
+
+---
+
+## 8. Infrastructure Action Roadmap
+
+### Immediate Actions (next 2 weeks)
+
+| Action | Owner | Effort | Justification |
+|---|---|---|---|
+| [e.g. Increase DB connection pool limit to X] | [Name] | [2 hours] | [DB connections at X% — hitting ceiling in X weeks] |
+| [e.g. Enable storage auto-scaling on RDS] | [Name] | [30 min] | [Storage at X% — prevents emergency at X months] |
+| [e.g. Add S3 lifecycle policy for [bucket]] | [Name] | [1 hour] | [Storage growing at $X/month unnecessarily] |
+
+### This Quarter (within 3 months)
+
+| Action | Owner | Effort | Justification |
+|---|---|---|---|
+| [e.g. Add read replica to production DB] | [Name] | [1 day] | [DB CPU projected to hit 65% in 2 months] |
+| [e.g. Increase max auto-scaling limit from X to Y] | [Name] | [2 hours] | [Current max is too close to expected peak] |
+| [e.g. Configure PgBouncer for connection pooling] | [Name] | [3 days] | [Reduce per-connection overhead; headroom for growth] |
+
+### Next Quarter (3–6 months)
+
+| Action | Owner | Effort | Justification |
+|---|---|---|---|
+| [e.g. Upgrade DB instance class — [current] → [next]] | [Name] | [2 hours — blue/green] | [DB CPU projected to hit 70% by Q[X]] |
+| [e.g. Implement caching for [high-read endpoint]] | [Name] | [1 week] | [Reduce DB read load by estimated [X%]] |
+| [e.g. Evaluate horizontal DB sharding] | [Name] | [2 weeks (spike)] | [At 12-month projections, single DB hits limits] |
+
+### Horizon (6–12 months)
+
+| Action | Description | Trigger condition |
+|---|---|---|
+| [e.g. Multi-region deployment] | [Active-passive setup in eu-west-2] | [DAU exceeds X or SLA requires 99.99%] |
+| [e.g. Database sharding or migration to distributed DB] | [Evaluate CockroachDB / Vitess] | [Single-node DB projected to hit ceiling] |
+| [e.g. CDN expansion] | [Add PoPs in [region]] | [Latency SLO breached for [geography]] |
+
+---
+
+## Quality Checks
+
+- [ ] Every resource has a quantified current utilisation and a projected months-to-ceiling — no hand-waving
+- [ ] The most critical constraint is called out in the executive summary with a specific timeline
+- [ ] Growth projections state their assumptions and confidence level — not presented as certainties
+- [ ] Capacity triggers define amber/red thresholds and name who acts at each level
+- [ ] Cost projections include unit economics, not just absolute totals
+- [ ] The infrastructure roadmap has named owners and effort estimates — not just a wish list
+- [ ] Auto-scaling configuration includes both scale-out AND scale-in triggers, and a min/max range
+- [ ] Actions are ordered by urgency — immediate items are genuinely immediate, not backlog filler
@@ -0,0 +1,454 @@
+---
+name: database-migration-plan
+description: "Write a safe, zero-downtime database migration plan for a schema change. Use when asked to plan a database migration, design a zero-downtime schema change, document an expand/contract migration, produce a rollback procedure for a database change, or coordinate a database schema update with a deployment. Produces a structured migration plan covering migration objectives, backward compatibility analysis, expand/contract phase breakdown, exact SQL, rollback steps per phase, data validation queries, and a deployment runbook."
+---
+
+# Database Migration Plan Skill
+
+Produce a complete, safe database migration plan for a schema change. A migration plan is not just the SQL — it is a coordinated sequence of steps that ensures the application stays available, data stays consistent, and every step can be rolled back independently.
+
+The expand/contract pattern is the default approach: expand the schema to support both old and new states, migrate the application, then contract to remove the old state. Never combine schema changes and data backfills in a single migration that runs during deployment.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Current schema state** — the DDL or description of the table(s) as they are now
+- **Target schema state** — the DDL or description of what the table(s) should look like after migration
+- **Migration reason** — why this change is being made (new feature, performance fix, normalization, compliance)
+- **Database engine** — PostgreSQL, MySQL, SQLite, CockroachDB, etc.
+- **Estimated data volume** — approximate number of rows in affected tables
+- **Deployment constraints** — is any downtime allowed? What is the expected traffic level during migration? Are there multiple app instances running?
+- **Rollback window** — how long after deploy can the team roll back before the migration becomes irreversible?
+
+## Output Format
+
+---
+
+# Database Migration Plan: [Migration Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Author:** [Name] | **Reviewed by:** [Name / DBA]
+**Date:** [Date] | **Target deploy date:** [Date]
+**Database engine:** [PostgreSQL X.X / MySQL X.X]
+**Ticket:** [JIRA-XXX]
+
+---
+
+## 1. Migration Overview
+
+**What is changing:**
+[1–2 sentences: the specific schema change — e.g. "Adding a non-nullable `organisation_id` column to the `users` table and backfilling it from the `accounts` table."]
+
+**Why:**
+[1–2 sentences: the business or technical reason driving the change.]
+
+**Migration type:** [Additive only / Additive + backfill / Column rename / Column type change / Table restructure / Index change]
+
+**Zero-downtime:** [Yes — using expand/contract / No — requires maintenance window — state duration]
+
+**Estimated migration duration:**
+- Expand phase: [~X minutes]
+- Data backfill: [~X minutes/hours — based on X rows at Y rows/second]
+- Contract phase: [~X minutes after app version deployed]
+
+---
+
+## 2. Backward Compatibility Analysis
+
+Before writing a single line of SQL, assess whether each change is backward compatible with the currently deployed application code.
+
+| Change | Backward compatible? | Risk | Notes |
+|---|---|---|---|
+| [e.g. Add nullable column `org_id`] | Yes | Low | Old app ignores new column |
+| [e.g. Backfill `org_id`] | Yes | Medium | Old app unaffected; new app reads backfilled values |
+| [e.g. Add NOT NULL constraint to `org_id`] | **No** | High | Old app that inserts without `org_id` will fail |
+| [e.g. Drop old column `account_id`] | **No** | High | Old app that reads `account_id` will fail |
+| [e.g. Add index on `org_id`] | Yes | Low | Additive; no breaking change |
+| [e.g. Rename column] | **No** | High | Never rename in one step; use expand/contract |
+
+**Summary:** [e.g. "This migration requires the expand/contract pattern across 3 deployment phases because steps 3 and 4 are not backward compatible."]
+
+---
+
+## 3. Expand/Contract Phases
+
+### Phase Overview
+
+```
+Phase 1 — EXPAND
+  Deploy migration: add new column (nullable), create new indexes
+  Old app: continues to work (ignores new column)
+  New app: not yet deployed
+  Duration: [~X min] | Rollback: trivial — drop new column
+
+       │
+       ▼
+
+Phase 2 — BACKFILL + DUAL-WRITE
+  Deploy app update: writes to both old and new columns
+  Run backfill: populate new column for existing rows
+  Validate: confirm 100% of rows have non-null new column
+  Duration: [~X hours depending on data volume]
+  Rollback: deploy previous app version; new column is still nullable
+
+       │
+       ▼
+
+Phase 3 — ENFORCE + SWITCH
+  Deploy migration: add NOT NULL constraint, drop old column/index
+  Deploy app update: reads only from new column
+  Duration: [~X min] | Rollback: requires forward-fix (constraint must be dropped first)
+
+       │
+       ▼
+
+Phase 4 — CONTRACT (optional cleanup)
+  Deploy migration: drop deprecated columns, rename if needed
+  Final state matches target schema
+  Rollback: not recommended — contract changes are destructive
+```
+
+---
+
+### Phase 1 — Expand Schema
+
+**Goal:** Add the new column and structures without breaking the existing application.
+**Deploy order:** Run migration first, then (optionally) deploy app.
+**Application state:** Old app running; no app changes required yet.
+
+```sql
+-- Migration: 001_add_org_id_to_users.sql
+BEGIN;
+
+-- Add nullable column (safe — old app ignores it)
+ALTER TABLE users
+    ADD COLUMN org_id UUID NULL
+        REFERENCES organisations(id) ON DELETE RESTRICT;
+
+-- Add index NOW, not in Phase 3 — building index on large table during Phase 3 is risky
+CREATE INDEX CONCURRENTLY users_org_id_idx ON users (org_id);
+
+-- Note: CONCURRENTLY does not lock the table; safe on live traffic
+-- Note: Cannot run CONCURRENTLY inside a transaction block; run separately if needed
+
+COMMIT;
+```
+
+**Validation after Phase 1:**
+```sql
+-- Confirm column exists and is nullable
+SELECT column_name, data_type, is_nullable
+FROM information_schema.columns
+WHERE table_name = 'users' AND column_name = 'org_id';
+-- Expected: is_nullable = 'YES'
+
+-- Confirm index exists
+SELECT indexname, indexdef
+FROM pg_indexes
+WHERE tablename = 'users' AND indexname = 'users_org_id_idx';
+```
+
+**Rollback (Phase 1 only):**
+```sql
+BEGIN;
+DROP INDEX CONCURRENTLY IF EXISTS users_org_id_idx;
+ALTER TABLE users DROP COLUMN IF EXISTS org_id;
+COMMIT;
+```
+
+---
+
+### Phase 2 — Backfill Existing Data
+
+**Goal:** Populate the new column for all existing rows before enforcing NOT NULL.
+**When to run:** After Phase 1 is live and stable. Can be run as a background job or a one-time script.
+**Application state:** Deploy app version that dual-writes to both old and new columns.
+
+**App code change required:**
+```
+// All INSERT and UPDATE operations must now set BOTH old_column and new_column
+// until Phase 3 is complete. This ensures new rows are populated during the backfill window.
+```
+
+**Backfill script — batch processing:**
+```sql
+-- Run in batches to avoid locking. Adjust batch size based on table size and DB load.
+-- Target: no single batch takes more than 5 seconds.
+
+DO $$
+DECLARE
+    batch_size  INT := 1000;
+    affected    INT;
+BEGIN
+    LOOP
+        UPDATE users
+        SET    org_id = accounts.organisation_id
+        FROM   accounts
+        WHERE  users.account_id = accounts.id
+          AND  users.org_id IS NULL
+        LIMIT  batch_size;
+
+        GET DIAGNOSTICS affected = ROW_COUNT;
+        EXIT WHEN affected = 0;
+
+        -- Pause between batches to avoid saturating I/O
+        PERFORM pg_sleep(0.1);
+    END LOOP;
+END $$;
+```
+
+**Monitoring during backfill:**
+```sql
+-- Check progress — run periodically during backfill
+SELECT
+    COUNT(*) FILTER (WHERE org_id IS NOT NULL) AS backfilled,
+    COUNT(*) FILTER (WHERE org_id IS NULL)     AS remaining,
+    COUNT(*)                                   AS total,
+    ROUND(
+        100.0 * COUNT(*) FILTER (WHERE org_id IS NOT NULL) / COUNT(*), 2
+    ) AS pct_complete
+FROM users;
+```
+
+**Backfill completion validation:**
+```sql
+-- Must return 0 before proceeding to Phase 3
+SELECT COUNT(*) AS unbackfilled_rows
+FROM users
+WHERE org_id IS NULL;
+
+-- Confirm no new rows written without org_id (dual-write working)
+SELECT COUNT(*) AS recent_missing
+FROM users
+WHERE org_id IS NULL
+  AND created_at > now() - INTERVAL '1 hour';
+```
+
+**Rollback (Phase 2 — app only):**
+- Deploy previous app version (single-write to old column)
+- `org_id` column remains nullable; no data is lost
+- Backfilled values remain; harmless
+
+---
+
+### Phase 3 — Enforce Constraints
+
+**Goal:** Add NOT NULL constraint and remove dependency on the old column.
+**Prerequisites:** Phase 2 backfill must be 100% complete (zero rows with `org_id IS NULL`).
+**Deploy order:** Run migration, then deploy app version that reads only from `org_id`.
+
+**PostgreSQL — use NOT VALID + VALIDATE for large tables:**
+```sql
+-- Step 1: Add constraint as NOT VALID (no full table scan — instant)
+ALTER TABLE users
+    ADD CONSTRAINT users_org_id_not_null
+    CHECK (org_id IS NOT NULL) NOT VALID;
+
+-- Step 2: VALIDATE CONSTRAINT (takes a SHARE UPDATE EXCLUSIVE lock — allows reads and writes)
+-- Run this separately, as it can take minutes on large tables
+ALTER TABLE users
+    VALIDATE CONSTRAINT users_org_id_not_null;
+
+-- Step 3: Once validated, convert to actual NOT NULL
+-- (PostgreSQL trusts the validated check constraint — this is instant)
+ALTER TABLE users
+    ALTER COLUMN org_id SET NOT NULL;
+
+-- Step 4: Drop the now-redundant check constraint
+ALTER TABLE users
+    DROP CONSTRAINT users_org_id_not_null;
+```
+
+**Validation after Phase 3:**
+```sql
+-- Confirm NOT NULL is enforced
+SELECT column_name, is_nullable
+FROM information_schema.columns
+WHERE table_name = 'users' AND column_name = 'org_id';
+-- Expected: is_nullable = 'NO'
+
+-- Test that insert without org_id fails (run in a transaction and roll back)
+BEGIN;
+INSERT INTO users (email) VALUES ('test@example.com');
+-- Expected: ERROR: null value in column "org_id" violates not-null constraint
+ROLLBACK;
+```
+
+**Rollback (Phase 3):**
+```sql
+-- Drop the NOT NULL constraint (restores nullable state)
+ALTER TABLE users ALTER COLUMN org_id DROP NOT NULL;
+-- Then deploy previous app version (dual-write)
+-- Note: Once app code reading the new column is live, rolling back the constraint
+-- without rolling back the app will cause issues — plan this carefully.
+```
+
+---
+
+### Phase 4 — Contract (Remove Old Column)
+
+**Goal:** Remove the old column once the app no longer references it.
+**Prerequisites:** Phase 3 fully deployed and stable for at least [X days/hours rollback window].
+**Warning:** This phase is destructive — the old column's data is permanently deleted.
+
+```sql
+BEGIN;
+
+-- Drop the old column
+ALTER TABLE users DROP COLUMN account_id;
+
+-- Drop any indexes that referenced the old column
+DROP INDEX IF EXISTS users_account_id_idx;
+
+COMMIT;
+```
+
+**Pre-drop validation:**
+```sql
+-- Confirm no application queries still reference the old column
+-- (Check this in code review and via a search of the codebase before running)
+-- grep -r "account_id" app/
+
+-- Confirm the column is safe to drop
+SELECT COUNT(*) FROM users WHERE account_id IS NOT NULL;
+-- Should be 0 (or irrelevant once new column is canonical)
+```
+
+**Rollback:** Not straightforward — dropped column data cannot be recovered. Only proceed to Phase 4 after the rollback window has passed and the change is confirmed stable.
+
+---
+
+## 4. Data Validation Plan
+
+Run these queries before and after the full migration to confirm data integrity.
+
+**Pre-migration baseline:**
+```sql
+-- Record these values before any migration step
+SELECT COUNT(*)   AS total_users FROM users;
+SELECT COUNT(*)   AS total_orgs  FROM organisations;
+SELECT MIN(created_at), MAX(created_at) FROM users;
+
+-- Check for any anomalies in the source data before backfill
+SELECT COUNT(*) AS users_without_account
+FROM users WHERE account_id IS NULL;
+```
+
+**Post-backfill integrity check:**
+```sql
+-- All users have an org that exists
+SELECT COUNT(*) AS orphaned_org_refs
+FROM users u
+WHERE u.org_id IS NOT NULL
+  AND NOT EXISTS (
+      SELECT 1 FROM organisations o WHERE o.id = u.org_id
+  );
+-- Expected: 0
+
+-- org_id matches expected value from source column
+SELECT COUNT(*) AS mismatched_backfill
+FROM users u
+JOIN accounts a ON u.account_id = a.id
+WHERE u.org_id != a.organisation_id;
+-- Expected: 0
+
+-- Row count unchanged (no rows created or deleted by migration)
+SELECT COUNT(*) AS total_users_after FROM users;
+-- Must match pre-migration baseline
+```
+
+**Post-contract final check:**
+```sql
+-- Old column is gone
+SELECT COUNT(*) FROM information_schema.columns
+WHERE table_name = 'users' AND column_name = 'account_id';
+-- Expected: 0
+
+-- New column is NOT NULL
+SELECT is_nullable FROM information_schema.columns
+WHERE table_name = 'users' AND column_name = 'org_id';
+-- Expected: NO
+```
+
+---
+
+## 5. Performance Impact Assessment
+
+| Step | Lock type | Lock duration | Traffic impact |
+|---|---|---|---|
+| Add nullable column | ACCESS EXCLUSIVE | Milliseconds | Negligible |
+| CREATE INDEX CONCURRENTLY | SHARE UPDATE EXCLUSIVE | Minutes (proportional to table size) | Reads and writes continue |
+| Batch backfill | Row-level locks only | <5s per batch | Low if batches are small |
+| ADD CONSTRAINT NOT VALID | ACCESS EXCLUSIVE | Milliseconds | Negligible |
+| VALIDATE CONSTRAINT | SHARE UPDATE EXCLUSIVE | Minutes | Reads and writes continue |
+| ALTER COLUMN SET NOT NULL | ACCESS EXCLUSIVE | Milliseconds (if check constraint validated) | Negligible |
+| DROP COLUMN | ACCESS EXCLUSIVE | Milliseconds | Negligible |
+
+**Expected load increase during backfill:**
+- DB CPU: [estimated % increase during batch writes]
+- DB I/O: [estimated increase]
+- Monitoring threshold to pause backfill: [e.g. DB CPU > 80% for >2 minutes]
+
+**Backfill rate estimate:**
+- Table size: [X million rows]
+- Batch size: [1000 rows]
+- Pause between batches: [100ms]
+- Estimated total duration: [X hours at Y rows/second]
+
+---
+
+## 6. Deployment Runbook
+
+Follow this checklist on the day of migration. Mark each step as done before proceeding.
+
+**Pre-migration (day before):**
+- [ ] DBA / tech lead has reviewed the migration plan
+- [ ] Performance impact assessed; monitoring dashboards ready
+- [ ] Backfill script tested on a staging DB with production-scale data
+- [ ] Rollback procedure tested on staging
+- [ ] On-call engineer briefed; Slack channel [#db-migrations] set up for coordination
+- [ ] Maintenance window scheduled (if required)
+
+**Phase 1 — Expand (T+0):**
+- [ ] Take a manual DB snapshot / verify automated backup is recent
+- [ ] Run `001_expand_add_org_id.sql` on production
+- [ ] Run Phase 1 validation queries — confirm pass
+- [ ] Deploy app version with dual-write
+- [ ] Monitor error rate for [10 minutes]
+
+**Phase 2 — Backfill (T+[X hours]):**
+- [ ] Confirm Phase 1 has been stable for [X hours]
+- [ ] Start backfill script in a screen/tmux session
+- [ ] Monitor progress via backfill progress query every [5 minutes]
+- [ ] Monitor DB CPU and I/O — pause if thresholds exceeded
+- [ ] Run completion validation — confirm 0 unbackfilled rows
+- [ ] Run integrity checks — confirm 0 orphaned refs, 0 mismatches
+
+**Phase 3 — Enforce (T+[X days]):**
+- [ ] Confirm backfill 100% complete and stable for [X hours]
+- [ ] Add NOT VALID constraint
+- [ ] Run VALIDATE CONSTRAINT (monitor duration and lock waits)
+- [ ] Alter column to NOT NULL
+- [ ] Run Phase 3 validation queries
+- [ ] Deploy app version reading only from new column
+- [ ] Monitor error rate for [30 minutes]
+
+**Phase 4 — Contract (T+[X days after rollback window]):**
+- [ ] Confirm rollback window has passed — no incidents, no rollback needed
+- [ ] Search codebase for references to old column — confirm zero
+- [ ] Run DROP COLUMN migration
+- [ ] Run final integrity checks
+- [ ] Close migration ticket; update schema documentation
+
+---
+
+## Quality Checks
+
+- [ ] Every migration phase has an independent rollback procedure — no phase assumes the next one has run
+- [ ] Batch backfill script includes a pause between batches to avoid saturating I/O
+- [ ] NOT NULL constraints use the NOT VALID + VALIDATE pattern on tables with >100k rows
+- [ ] The app dual-write period is explicitly defined — old column writes are not dropped until Phase 3 is deployed
+- [ ] Data validation queries include a row count check to confirm no data loss
+- [ ] Lock types are identified for every DDL statement — no "should be fine" assumptions
+- [ ] The deployment runbook names who runs each step, not just what to run
+- [ ] Phase 4 (contract) is explicitly gated on the rollback window passing — not run on the same day as Phase 3
@@ -0,0 +1,356 @@
+---
+name: database-schema-design
+description: "Document or design a database schema with entity relationships, table definitions, constraints, indexes, and access patterns. Use when asked to design a database, document an existing schema, model entities and relationships, define table structures, plan an index strategy, or produce a data model for review. Produces a structured schema document covering an ER diagram, table DDL definitions, index strategy, access pattern analysis, normalization decisions, and migration notes."
+---
+
+# Database Schema Design Skill
+
+Produce a complete database schema design document for a given domain. A schema document is not just a list of tables — it is a record of decisions: what was modelled, how entities relate, which queries the schema is optimised for, and what trade-offs were made.
+
+A good schema design document lets an engineer understand the data model, query it correctly, extend it safely, and write migrations without breaking things.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Domain description** — what the system does; what business objects are being modelled
+- **Entities and relationships** — the main things in the domain and how they relate (e.g. "a User has many Orders; an Order has many OrderItems; an OrderItem references a Product")
+- **Expected query patterns** — the most important read and write queries (e.g. "fetch all orders for a user, sorted by date"; "look up a product by SKU")
+- **Database engine** — PostgreSQL, MySQL, SQLite, CockroachDB, etc. — this affects DDL syntax and available types
+- **Expected data volume** — approximate row counts, growth rate, and any partitioning needs
+- **Constraints** — any existing conventions, naming standards, or migration constraints to respect
+
+## Output Format
+
+---
+
+# Database Schema Design: [Domain / Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Author:** [Name] | **Reviewed by:** [Name]
+**Date:** [Date] | **Database engine:** [PostgreSQL X.X / MySQL X.X / etc.]
+**Status:** [Draft / Reviewed / Approved]
+
+---
+
+## 1. Overview
+
+[2–3 sentences describing the domain being modelled, the scope of this schema, and any key design philosophy (e.g. "this schema prioritises read performance for the customer-facing API over write simplicity", or "designed for eventual migration to multi-tenancy")]
+
+**In scope:**
+- [Entity or subsystem]
+- [Entity or subsystem]
+
+**Out of scope:**
+- [e.g. Analytics / reporting tables — separate schema]
+- [e.g. Audit log tables — covered in separate design doc]
+
+---
+
+## 2. Entity Relationship Diagram
+
+```
+┌───────────────────┐         ┌───────────────────────┐
+│      users        │         │       organisations    │
+│─────────────────  │         │─────────────────────── │
+│ id (PK)           │    ┌───▶│ id (PK)                │
+│ org_id (FK)  ─────┼────┘    │ name                   │
+│ email             │         │ plan                   │
+│ display_name      │         │ created_at             │
+│ created_at        │         └───────────────────────┘
+│ updated_at        │
+└─────────┬─────────┘
+          │ 1
+          │
+          │ N
+┌─────────▼─────────┐         ┌───────────────────────┐
+│      [table_a]    │         │      [table_b]         │
+│─────────────────  │         │─────────────────────── │
+│ id (PK)           │    N    │ id (PK)                │
+│ user_id (FK) ─────┼────────▶│ [table_a]_id (FK)      │
+│ [field]           │    │    │ [field]                │
+│ [field]           │    │    │ [field]                │
+│ created_at        │         │ created_at             │
+└───────────────────┘         └───────────────────────┘
+```
+
+**Relationship summary:**
+
+| Entity A | Relationship | Entity B | Notes |
+|---|---|---|---|
+| organisations | has many | users | An org can have many users |
+| users | has many | [table_a] | Soft-deleted on user deletion |
+| [table_a] | has many | [table_b] | Cascade delete |
+| [table_b] | belongs to | [table_a] | Non-nullable FK |
+| [table_c] | many-to-many (via [join_table]) | [table_d] | Join table with metadata |
+
+---
+
+## 3. Table Definitions
+
+### `organisations`
+
+[1 sentence describing what this table stores and its role in the domain.]
+
+```sql
+CREATE TABLE organisations (
+    id          UUID            PRIMARY KEY DEFAULT gen_random_uuid(),
+    name        VARCHAR(255)    NOT NULL,
+    slug        VARCHAR(100)    NOT NULL UNIQUE,
+    plan        VARCHAR(50)     NOT NULL DEFAULT 'free'
+                                CHECK (plan IN ('free', 'pro', 'enterprise')),
+    settings    JSONB           NOT NULL DEFAULT '{}',
+    created_at  TIMESTAMPTZ     NOT NULL DEFAULT now(),
+    updated_at  TIMESTAMPTZ     NOT NULL DEFAULT now()
+);
+```
+
+| Column | Type | Nullable | Default | Notes |
+|---|---|---|---|---|
+| id | UUID | No | gen_random_uuid() | Surrogate PK — UUID preferred over serial for distributed use |
+| name | VARCHAR(255) | No | — | Display name; not unique |
+| slug | VARCHAR(100) | No | — | URL-safe identifier; unique across all orgs |
+| plan | VARCHAR(50) | No | 'free' | Constrained to known values via CHECK |
+| settings | JSONB | No | {} | Flexible config; avoid for queryable fields |
+| created_at | TIMESTAMPTZ | No | now() | Always use TIMESTAMPTZ, not TIMESTAMP |
+| updated_at | TIMESTAMPTZ | No | now() | Updated via trigger (see below) |
+
+---
+
+### `users`
+
+[1 sentence describing what this table stores.]
+
+```sql
+CREATE TABLE users (
+    id              UUID            PRIMARY KEY DEFAULT gen_random_uuid(),
+    org_id          UUID            NOT NULL REFERENCES organisations(id)
+                                    ON DELETE RESTRICT,
+    email           VARCHAR(254)    NOT NULL,
+    display_name    VARCHAR(255)    NOT NULL DEFAULT '',
+    role            VARCHAR(50)     NOT NULL DEFAULT 'member'
+                                    CHECK (role IN ('owner', 'admin', 'member', 'viewer')),
+    email_verified  BOOLEAN         NOT NULL DEFAULT false,
+    deleted_at      TIMESTAMPTZ     NULL,
+    created_at      TIMESTAMPTZ     NOT NULL DEFAULT now(),
+    updated_at      TIMESTAMPTZ     NOT NULL DEFAULT now(),
+
+    CONSTRAINT users_email_org_unique UNIQUE (email, org_id)
+);
+```
+
+| Column | Type | Nullable | Default | Notes |
+|---|---|---|---|---|
+| id | UUID | No | gen_random_uuid() | — |
+| org_id | UUID | No | — | FK to organisations; RESTRICT prevents orphaning |
+| email | VARCHAR(254) | No | — | RFC 5321 max length; unique per org (not globally) |
+| role | VARCHAR(50) | No | 'member' | Application-level RBAC |
+| deleted_at | TIMESTAMPTZ | Yes | NULL | Soft delete; NULL = active |
+
+**Soft delete policy:** Rows with `deleted_at IS NOT NULL` are considered deleted. All application queries MUST filter `WHERE deleted_at IS NULL` unless explicitly fetching deleted records. Use a view or ORM scope to enforce this.
+
+---
+
+### `[table_a]`
+
+[Description of what this table models.]
+
+```sql
+CREATE TABLE [table_a] (
+    id          UUID            PRIMARY KEY DEFAULT gen_random_uuid(),
+    user_id     UUID            NOT NULL REFERENCES users(id) ON DELETE CASCADE,
+    [field_1]   VARCHAR(255)    NOT NULL,
+    [field_2]   TEXT            NULL,
+    [field_3]   INTEGER         NOT NULL DEFAULT 0 CHECK ([field_3] >= 0),
+    status      VARCHAR(50)     NOT NULL DEFAULT 'pending'
+                                CHECK (status IN ('pending', 'active', 'archived')),
+    metadata    JSONB           NOT NULL DEFAULT '{}',
+    created_at  TIMESTAMPTZ     NOT NULL DEFAULT now(),
+    updated_at  TIMESTAMPTZ     NOT NULL DEFAULT now()
+);
+```
+
+| Column | Type | Nullable | Notes |
+|---|---|---|---|
+| user_id | UUID | No | CASCADE delete — when user is deleted, their [table_a] rows are too |
+| [field_1] | VARCHAR(255) | No | [Reason for length constraint] |
+| status | VARCHAR(50) | No | State machine: pending → active → archived (no other transitions) |
+| metadata | JSONB | No | [What is stored here and why it's not a typed column] |
+
+---
+
+### `[join_table]` *(Many-to-many)*
+
+[Description of the relationship this table represents.]
+
+```sql
+CREATE TABLE [join_table] (
+    [table_c]_id    UUID        NOT NULL REFERENCES [table_c](id) ON DELETE CASCADE,
+    [table_d]_id    UUID        NOT NULL REFERENCES [table_d](id) ON DELETE CASCADE,
+    granted_by      UUID        NOT NULL REFERENCES users(id) ON DELETE RESTRICT,
+    granted_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
+
+    PRIMARY KEY ([table_c]_id, [table_d]_id)
+);
+```
+
+**Why a composite PK:** The combination of `[table_c]_id + [table_d]_id` is the natural key — each association is unique and the primary key doubles as the uniqueness constraint without needing a separate index.
+
+---
+
+## 4. Index Strategy
+
+For each table, define which indexes are created and why. Include the query they are designed to serve.
+
+| Table | Index name | Columns | Type | Query served | Notes |
+|---|---|---|---|---|---|
+| users | `users_org_id_idx` | `(org_id)` | B-tree | `SELECT * FROM users WHERE org_id = $1` | FK lookup; required for join performance |
+| users | `users_email_lower_idx` | `(lower(email))` | B-tree (functional) | `WHERE lower(email) = lower($1)` | Case-insensitive email lookup |
+| users | `users_active_by_org_idx` | `(org_id, created_at DESC)` | B-tree | `WHERE org_id = $1 AND deleted_at IS NULL ORDER BY created_at DESC` | Partial index candidate (see below) |
+| [table_a] | `[table_a]_user_id_status_idx` | `(user_id, status)` | B-tree | `WHERE user_id = $1 AND status = 'active'` | Compound — order matters |
+| [table_a] | `[table_a]_metadata_gin_idx` | `metadata` | GIN | `WHERE metadata @> '{"key": "value"}'` | Only add if JSONB queried frequently |
+
+**Partial indexes (PostgreSQL):**
+
+```sql
+-- Index only active (non-deleted) users — dramatically smaller for soft-delete tables
+CREATE INDEX users_active_email_idx
+    ON users (email, org_id)
+    WHERE deleted_at IS NULL;
+
+-- Index only pending items — avoids indexing the majority of rows
+CREATE INDEX [table_a]_pending_idx
+    ON [table_a] (user_id, created_at)
+    WHERE status = 'pending';
+```
+
+**Index design principles applied:**
+- FKs that appear in JOIN conditions always have an index
+- Compound indexes follow selectivity order: most selective column first
+- Functional indexes for case-insensitive lookups
+- GIN indexes only where JSONB containment queries are frequent
+- Partial indexes for status-filtered queries on large tables
+
+---
+
+## 5. Access Pattern Analysis
+
+Document the primary queries this schema is designed to serve. For each, show the query, the indexes used, and any caveats.
+
+### AP-1: Fetch all active users for an organisation (paginated)
+
+**Frequency:** Very high — called on every dashboard load
+**Query:**
+```sql
+SELECT id, email, display_name, role, created_at
+FROM users
+WHERE org_id = $1
+  AND deleted_at IS NULL
+ORDER BY created_at DESC
+LIMIT 50 OFFSET $2;
+```
+**Index used:** `users_active_by_org_idx` (org_id, created_at DESC)
+**Notes:** Use keyset pagination (`WHERE created_at < $cursor`) at scale; OFFSET degrades past ~10k rows.
+
+---
+
+### AP-2: Look up a user by email (case-insensitive)
+
+**Frequency:** High — every authentication attempt
+**Query:**
+```sql
+SELECT id, org_id, role, email_verified
+FROM users
+WHERE lower(email) = lower($1)
+  AND deleted_at IS NULL;
+```
+**Index used:** `users_email_lower_idx`
+**Notes:** Returns multiple rows if same email exists across orgs. Application resolves by org context.
+
+---
+
+### AP-3: Fetch [table_a] items for a user by status
+
+**Frequency:** High
+**Query:**
+```sql
+SELECT *
+FROM [table_a]
+WHERE user_id = $1
+  AND status = $2
+ORDER BY created_at DESC
+LIMIT 25;
+```
+**Index used:** `[table_a]_user_id_status_idx`
+**Notes:** Compound index covers both filter columns. Status filter must come second in the index because user_id is more selective.
+
+---
+
+### AP-4: [Add further access patterns as needed]
+
+---
+
+## 6. Normalization Decisions
+
+Document deliberate choices to normalize or denormalize, with reasoning.
+
+| Decision | Approach | Reasoning |
+|---|---|---|
+| [e.g. Organisation name on users table?] | **Not denormalized** — always join to organisations | Avoid stale copies; org name changes are infrequent and joining is cheap |
+| [e.g. Status history] | **Not in this table** — separate `[table_a]_status_history` if needed | Current status is all that's needed for 99% of queries; history is auditing, not application data |
+| [e.g. JSONB `settings` column on organisations] | **Denormalized into JSONB** | Settings are read together; never queried by field; schema changes don't require migrations |
+| [e.g. Computed aggregate counts] | **Not stored** — computed at query time | Counts are small; maintaining a counter column requires careful locking; use `SELECT COUNT(*)` with the index |
+
+---
+
+## 7. Triggers and Automation
+
+```sql
+-- Automatically update updated_at on any row modification
+CREATE OR REPLACE FUNCTION set_updated_at()
+RETURNS TRIGGER AS $$
+BEGIN
+    NEW.updated_at = now();
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+
+-- Apply to all tables with updated_at
+CREATE TRIGGER users_updated_at
+    BEFORE UPDATE ON users
+    FOR EACH ROW EXECUTE FUNCTION set_updated_at();
+
+CREATE TRIGGER [table_a]_updated_at
+    BEFORE UPDATE ON [table_a]
+    FOR EACH ROW EXECUTE FUNCTION set_updated_at();
+```
+
+---
+
+## 8. Migration Notes
+
+If this schema is being introduced to an existing system, note the migration approach.
+
+| Step | Description | Backward compatible | Risk |
+|---|---|---|---|
+| 1 | Create `organisations` table | Yes — additive | Low |
+| 2 | Create `users` table | Yes — additive | Low |
+| 3 | Backfill `org_id` on existing users | **Requires dual-write period** | Medium |
+| 4 | Add NOT NULL constraint on `org_id` | Requires backfill to be 100% complete | Medium |
+| 5 | Remove deprecated columns | Requires app code updated first | Low once app deployed |
+
+**Backfill strategy:** [Describe how to handle existing data — batch size, rate limiting, validation queries]
+
+**Rollback:** Each migration step should be independently reversible. See [database-migration-plan skill] for the full rollback procedure template.
+
+---
+
+## Quality Checks
+
+- [ ] Every table has a primary key and a `created_at` column — no implicit ordering by row insertion
+- [ ] Every foreign key has a corresponding index — no missing FK indexes that would cause full table scans on joins
+- [ ] All TIMESTAMPTZ columns, not TIMESTAMP — timezone awareness is explicit
+- [ ] Soft-delete tables document the convention and where the filter is enforced (ORM scope, view, or query standard)
+- [ ] Every access pattern in the design has a supporting index or an explicit note that a full table scan is acceptable
+- [ ] JSONB columns are justified — not used as a substitute for proper schema design on queryable fields
+- [ ] Normalization decisions are documented with reasoning, not just stated
+- [ ] Migration notes address existing data if this is a schema change, not a greenfield schema
@@ -0,0 +1,332 @@
+---
+name: dependency-audit
+description: "Conduct a dependency audit for a project — checking for security vulnerabilities, license compliance issues, outdated packages, and transitive dependency risk. Use when asked to audit dependencies, review package security, check license compliance, assess dependency health, or produce a vulnerability report. Produces a vulnerability findings table, license compliance matrix, update priority matrix, dependency health score, and 30-day remediation plan."
+---
+
+# Dependency Audit Skill
+
+Produce a complete dependency audit report for a project — covering security vulnerabilities (with CVE references), license compliance against policy, outdated packages prioritised by risk, transitive dependency risk analysis, and a concrete remediation plan with timeline. A good dependency audit gives the team a clear, prioritised action list — not a raw dump of audit output that no one acts on.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Project language and ecosystem** — npm, pip/PyPI, Maven/Gradle, Go modules, Cargo, RubyGems, NuGet, or mixed
+- **Dependency list or package manifest** — paste the contents of `package.json`, `requirements.txt`, `go.mod`, `pom.xml`, etc., or provide the audit tool output
+- **License policy** — which licenses are allowed, which are restricted (e.g. "GPL is prohibited", "MIT/Apache/BSD only", or "no policy yet — recommend one")
+- **Current security tooling** — Dependabot, Snyk, OWASP Dependency-Check, npm audit, pip-audit, or none
+
+## Output Format
+
+---
+
+# Dependency Audit Report: [Project Name]
+
+**Ecosystem:** [npm / pip / Maven / Go / etc.]
+**Audit date:** [Date]
+**Auditor:** [Name]
+**Total direct dependencies:** [N]
+**Total transitive dependencies:** [N]
+**Audit tool(s) used:** [npm audit / pip-audit / Snyk / OWASP Dependency-Check / etc.]
+
+---
+
+## Executive Summary
+
+| Category | Finding | Risk level |
+|---|---|---|
+| Critical vulnerabilities | [N] CVEs requiring immediate action | [Critical / High / Low] |
+| High vulnerabilities | [N] CVEs — fix within 7 days | [High / Medium] |
+| License violations | [N] packages with non-compliant licenses | [High / Low] |
+| Severely outdated packages | [N] packages > 2 major versions behind | [Medium] |
+| Packages with no active maintenance | [N] packages — no commits in 12+ months | [Medium] |
+| **Overall dependency health score** | **[Score]/100** | **[Red / Amber / Green]** |
+
+**Scoring methodology:** Critical CVEs: −20 each. High CVEs: −10 each. License violations: −15 each. Abandoned packages: −5 each. Maximum deduction: 100. Score ≥80 = Green, 60–79 = Amber, <60 = Red.
+
+**Immediate actions required:**
+1. [Most critical action — e.g. "Upgrade lodash from 4.17.11 to 4.17.21 to fix CVE-2021-23337 (Critical — prototype pollution)"]
+2. [Second action]
+3. [Third action]
+
+---
+
+## 1. Security Vulnerability Findings
+
+### Critical and High Severity (Act within 24–72 hours)
+
+| Package | Installed version | Fix version | CVE | Severity | CVSS score | Description | Exploitability |
+|---|---|---|---|---|---|---|---|
+| [package-name] | [X.Y.Z] | [A.B.C] | [CVE-YYYY-NNNNN] | Critical | [9.x] | [e.g. Prototype pollution via `merge` function — remote code execution possible] | [Known exploit / PoC available / No known exploit] |
+| [package-name] | [X.Y.Z] | [A.B.C] | [CVE-YYYY-NNNNN] | High | [7.x] | [e.g. Path traversal in file serving utility] | [PoC available] |
+| [package-name] | [X.Y.Z] | [A.B.C] | [CVE-YYYY-NNNNN] | High | [7.x] | [e.g. Regular expression denial of service (ReDoS)] | [No known exploit] |
+
+### Medium Severity (Fix within 30 days)
+
+| Package | Installed version | Fix version | CVE | Severity | CVSS score | Description |
+|---|---|---|---|---|---|---|
+| [package-name] | [X.Y.Z] | [A.B.C] | [CVE-YYYY-NNNNN] | Medium | [5.x] | [Description] |
+| [package-name] | [X.Y.Z] | [A.B.C] | [CVE-YYYY-NNNNN] | Medium | [4.x] | [Description] |
+
+### Low Severity (Fix within 90 days or accept risk)
+
+| Package | Installed version | Fix version | CVE | Severity | Description |
+|---|---|---|---|---|---|
+| [package-name] | [X.Y.Z] | [A.B.C] | Low | [Description] |
+
+### Vulnerabilities With No Fix Available
+
+| Package | CVE | Severity | Recommended mitigation |
+|---|---|---|---|
+| [package-name] | [CVE-YYYY-NNNNN] | [High] | [e.g. "Remove this package — alternative: [replacement]"] |
+| [package-name] | [CVE-YYYY-NNNNN] | [Medium] | [e.g. "Vendor has a fix in progress — track issue [URL]. Mitigate by [X]"] |
+
+---
+
+## 2. License Compliance Matrix
+
+### License Policy Reference
+
+| License | Category | Policy | Notes |
+|---|---|---|---|
+| MIT | Permissive | Allowed | Attribution required in distributed products |
+| Apache 2.0 | Permissive | Allowed | Attribution + NOTICE file required |
+| BSD 2-Clause / 3-Clause | Permissive | Allowed | Attribution required |
+| ISC | Permissive | Allowed | |
+| MPL 2.0 | Weak copyleft | Allowed with review | Source disclosure required for modified MPL files only |
+| LGPL v2 / v3 | Weak copyleft | Allowed with review | Dynamic linking permitted; static linking may require disclosure |
+| GPL v2 / v3 | Strong copyleft | **Restricted** | May require open-sourcing the entire codebase — legal review required |
+| AGPL v3 | Strong copyleft | **Restricted** | Network use triggers copyleft — especially risky for SaaS |
+| SSPL | Source available | **Prohibited** | Not OSI-approved — treat as proprietary |
+| Proprietary / Commercial | Commercial | **Requires contract** | Verify license covers current use case and scale |
+| Unknown / Unlicensed | — | **Prohibited** | No license = all rights reserved — cannot use legally |
+
+### Findings: Packages With Compliance Issues
+
+| Package | License | Issue | Recommendation | Risk if unaddressed |
+|---|---|---|---|---|
+| [package-name] | GPL v3 | Copyleft — may require open-sourcing this project | Replace with [alternative] or get legal sign-off | Legal / IP risk |
+| [package-name] | AGPL v3 | Network copyleft — SaaS use triggers disclosure | Replace with [alternative] | Legal / IP risk |
+| [package-name] | Proprietary | License may not cover current usage tier | Verify license scope with vendor | Contract breach |
+| [package-name] | Unknown | No license declared in package metadata | Contact maintainer or replace | Cannot use legally |
+
+### All Licenses in Use (Full Inventory)
+
+| License | Package count | Compliance status |
+|---|---|---|
+| MIT | [N] | Compliant |
+| Apache 2.0 | [N] | Compliant |
+| BSD-3-Clause | [N] | Compliant |
+| ISC | [N] | Compliant |
+| MPL 2.0 | [N] | Review required |
+| GPL v3 | [N] | **Non-compliant** |
+| Unknown | [N] | **Non-compliant** |
+
+---
+
+## 3. Outdated Package Analysis
+
+### Severely Outdated (2+ major versions behind — high upgrade effort)
+
+| Package | Installed | Latest stable | Versions behind | Last updated | Breaking changes summary |
+|---|---|---|---|---|---|
+| [package-name] | [1.x.x] | [3.x.x] | 2 major | [Date] | [e.g. "API redesign in v2; async support added in v3"] |
+| [package-name] | [0.x.x] | [2.x.x] | 2 major | [Date] | [Summary] |
+
+### Moderately Outdated (1 major version behind)
+
+| Package | Installed | Latest stable | Versions behind | Security fix in newer version? |
+|---|---|---|---|---|
+| [package-name] | [2.x.x] | [3.x.x] | 1 major | [Yes — CVE-YYYY-NNNNN / No] |
+| [package-name] | [4.x.x] | [5.x.x] | 1 major | [No] |
+
+### Minor/Patch Updates Available (Low risk to update)
+
+| Package | Installed | Latest | Contains security fix? |
+|---|---|---|---|
+| [package-name] | [2.3.1] | [2.3.9] | [Yes / No] |
+| [package-name] | [1.0.0] | [1.2.1] | [No] |
+
+---
+
+## 4. Dependency Graph Risk Analysis
+
+### Transitive Dependency Risk
+
+Transitive (indirect) dependencies carry risk because they are not explicitly managed. These are the highest-risk transitive dependencies in this project:
+
+| Vulnerable transitive dep | Pulled in by | Installed version | Fix available | Action |
+|---|---|---|---|---|
+| [transitive-package] | [direct-parent] | [X.Y.Z] | [Yes — upgrade [parent] to [version]] | Upgrade direct dependency [parent] |
+| [transitive-package] | [direct-parent] | [X.Y.Z] | [No] | Remove [parent] or use [alternative] |
+
+### Dependency Concentration Risk
+
+These packages are depended on by many other packages in the project — a vulnerability or deprecation would have cascading effects:
+
+| Package | Depended on by (N packages) | Actively maintained? | Risk level |
+|---|---|---|---|
+| [package-name] | [N] | [Yes / No — last commit: date] | [High / Medium] |
+| [package-name] | [N] | [Yes] | [Medium] |
+
+### Abandoned / Unmaintained Packages
+
+| Package | Last release | Last commit | Weekly downloads | Recommended alternative |
+|---|---|---|---|---|
+| [package-name] | [Date] | [Date] | [N] | [alternative-package] |
+| [package-name] | [Date] | [Date] | [N] | [Maintained fork: URL] |
+
+---
+
+## 5. Remediation Plan
+
+### 30-Day Plan
+
+**Week 1 — Critical vulnerabilities (Days 1–7)**
+
+| Action | Owner | Package | Effort | Notes |
+|---|---|---|---|---|
+| Upgrade [package] [old] → [new] | [Name] | [package-name] | [30 min] | [No API changes / check breaking changes guide: URL] |
+| Replace [package] with [alternative] | [Name] | [package-name] | [2 hours] | [No fix available — must replace] |
+| Patch override for [transitive-dep] | [Name] | [transitive-dep] | [15 min] | [Add resolutions/overrides entry in manifest] |
+
+```bash
+# Commands for Week 1 upgrades:
+
+# npm
+npm install [package]@[target-version]
+npm audit fix --force  # use with caution — may introduce breaking changes
+
+# pip
+pip install --upgrade [package]==[target-version]
+pip-audit --fix  # if using pip-audit
+
+# Go
+go get [module]@[version]
+go mod tidy
+
+# Maven
+# Update pom.xml version property, then:
+mvn versions:use-latest-releases -DallowMajorUpdates=false
+mvn dependency:resolve
+```
+
+**Week 2 — High vulnerabilities and license violations (Days 8–14)**
+
+| Action | Owner | Package | Effort | Notes |
+|---|---|---|---|---|
+| Upgrade [package] | [Name] | [package-name] | [1 hour] | |
+| Replace GPL-licensed [package] | [Name] | [package-name] | [4 hours] | [Alternative: [package]] |
+| Legal review for [package] license | Legal team | [package-name] | [Legal team SLA] | [Submit via [process]] |
+
+**Week 3 — Medium vulnerabilities and abandoned packages (Days 15–21)**
+
+| Action | Owner | Package | Effort | Notes |
+|---|---|---|---|---|
+| Upgrade [package] | [Name] | [package-name] | [30 min] | |
+| Replace abandoned [package] | [Name] | [package-name] | [2 hours] | [Maintained fork or alternative: [URL]] |
+
+**Week 4 — Process improvements (Days 22–30)**
+
+| Action | Owner | Effort | Notes |
+|---|---|---|---|
+| Enable Dependabot / Renovate for automated PRs | [Name] | [2 hours] | [Config in Section 6] |
+| Add `npm audit` / `pip-audit` to CI — fail on Critical/High | [Name] | [1 hour] | [Config in Section 6] |
+| Document license policy in CONTRIBUTING.md | [Name] | [1 hour] | [Based on policy in Section 2] |
+| Schedule next quarterly audit | [Name] | [15 min] | [Add to team calendar] |
+
+---
+
+## 6. Policy Recommendations
+
+### Automated Vulnerability Scanning in CI
+
+Add the following to your CI pipeline to catch vulnerabilities before they merge:
+
+```yaml
+# GitHub Actions — adapt for your CI platform
+dependency-audit:
+  runs-on: ubuntu-latest
+  steps:
+    - uses: actions/checkout@v3
+
+    # npm
+    - name: npm audit
+      run: npm audit --audit-level=high
+      # Fails build on High or Critical vulnerabilities
+
+    # pip
+    - name: pip-audit
+      run: |
+        pip install pip-audit
+        pip-audit --requirement requirements.txt --severity high
+
+    # Go
+    - name: govulncheck
+      run: |
+        go install golang.org/x/vuln/cmd/govulncheck@latest
+        govulncheck ./...
+```
+
+### Dependabot / Renovate Configuration
+
+```yaml
+# .github/dependabot.yml — automated dependency update PRs
+version: 2
+updates:
+  - package-ecosystem: "[npm / pip / gomod / maven]"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+      day: "monday"
+    open-pull-requests-limit: 10
+    labels:
+      - "dependencies"
+      - "automated"
+    ignore:
+      # Ignore major version bumps — review these manually
+      - dependency-name: "*"
+        update-types: ["version-update:semver-major"]
+```
+
+### License Scanning
+
+```bash
+# npm — license checker
+npx license-checker --onlyAllow 'MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC' \
+  --failOn 'GPL;AGPL;LGPL'
+
+# Python — pip-licenses
+pip install pip-licenses
+pip-licenses --allow-only="MIT;Apache Software License;BSD License;ISC License" \
+  --fail-on="GNU General Public License"
+
+# Go — go-licenses
+go install github.com/google/go-licenses@latest
+go-licenses check ./... --allowed_licenses=MIT,Apache-2.0,BSD-2-Clause,BSD-3-Clause
+```
+
+---
+
+## 7. Dependency Health Score Detail
+
+| Category | Max points | Score | Notes |
+|---|---|---|---|
+| No critical vulnerabilities | 30 | [N]/30 | −20 per critical CVE |
+| No high vulnerabilities | 20 | [N]/20 | −10 per high CVE |
+| License compliance | 20 | [N]/20 | −15 per violation |
+| No abandoned packages | 15 | [N]/15 | −5 per abandoned package |
+| Up-to-date major versions | 10 | [N]/10 | −2 per major version behind |
+| Automated scanning enabled | 5 | [N]/5 | All-or-nothing |
+| **Total** | **100** | **[Score]/100** | **[Red / Amber / Green]** |
+
+---
+
+## Quality Checks
+
+- [ ] Every Critical and High CVE has a named owner and a resolution date in the 30-day plan
+- [ ] License findings have been reviewed by legal or a named engineer with authority to accept the risk
+- [ ] Transitive dependency vulnerabilities are included — not just direct dependencies
+- [ ] Abandoned packages have a concrete replacement recommendation, not just "consider replacing"
+- [ ] CI pipeline change is included — the audit findings should be the last time these are caught manually
+- [ ] The dependency health score is calculated from actual findings, not estimated
+- [ ] Remediation plan actions are specific commands or steps, not "upgrade package X" without version targets
@@ -0,0 +1,560 @@
+---
+name: disaster-recovery-plan
+description: "Write a disaster recovery plan for a service or system — covering RPO/RTO targets, failure scenario runbooks, backup and restore procedures, DR testing cadence, and communication templates. Use when asked to write a DR plan, document failover procedures, create recovery runbooks, define RTO/RPO targets, or prepare for a disaster recovery game day. Produces a full DR document with per-scenario recovery runbooks, backup validation procedures, testing schedule, and communication templates."
+---
+
+# Disaster Recovery Plan Skill
+
+Produce a complete disaster recovery plan for a service or system — giving engineers, SREs, and on-call responders everything they need to recover from a disaster scenario in the shortest possible time. A good DR plan is tested regularly, has exact commands (not vague instructions), and makes RTO/RPO targets measurable so the team knows whether recovery succeeded.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and what it does (business function and technical role)
+- **Criticality tier** — business impact of extended downtime (e.g. Tier 1 = revenue-critical, Tier 2 = ops impact, Tier 3 = internal only)
+- **Current infrastructure setup** — cloud provider, regions/zones, deployment model (Kubernetes, ECS, VMs, serverless)
+- **RPO/RTO requirements** — Recovery Point Objective (how much data loss is acceptable) and Recovery Time Objective (how long can it be down)
+- **Backup strategy** — what is backed up, how often, where backups are stored, retention policy
+- **On-call contacts** — names and contact details for the responder chain
+
+## Output Format
+
+---
+
+# Disaster Recovery Plan: [Service Name]
+
+**Team:** [Team name] | **Tech lead:** [Name]
+**Criticality tier:** [Tier 1 / Tier 2 / Tier 3] | **Last tested:** [Date]
+**Next DR test:** [Date] | **Document owner:** [Name]
+**Last updated:** [Date] | **Review cycle:** Quarterly
+
+> **Emergency? Skip to Section 3 — Failure Scenario Runbooks.** Find the scenario that matches your situation and follow the steps exactly.
+
+---
+
+## 1. Recovery Targets
+
+| Target | Value | Rationale |
+|---|---|---|
+| RPO (Recovery Point Objective) | [X minutes/hours] | [e.g. "Last committed transaction — database replication is synchronous"] |
+| RTO (Recovery Time Objective) | [Y minutes/hours] | [e.g. "Revenue impact begins at 30 min; target recovery in 15 min"] |
+| MTTR target (non-disaster) | [Z minutes] | [Operational incidents, not DR events] |
+| Data retention (backups) | [N days/weeks] | [Compliance requirement or operational policy] |
+| Backup frequency | [Every X hours] | [RPO-driven — backup interval must be ≤ RPO] |
+
+**What these mean in practice:**
+- If a database is corrupted, we can lose at most [X minutes] of transactions before the business impact is unacceptable.
+- The service must be operational again within [Y minutes/hours] of declaring a DR event.
+- If either target cannot be met, escalate to [Engineering Manager] immediately.
+
+---
+
+## 2. Failure Scenario Inventory
+
+| Scenario | Likelihood | Impact | RTO target | RPO target | Runbook |
+|---|---|---|---|---|---|
+| Single availability zone failure | Medium | [Partial / Full outage] | [15 min] | [0 — no data loss] | Section 3.1 |
+| Full region failure | Low | Full outage | [60 min] | [5 min] | Section 3.2 |
+| Database corruption / data loss | Low | Full outage | [90 min] | [RPO value] | Section 3.3 |
+| Critical dependency outage | High | [Partial degradation] | [30 min] | [N/A] | Section 3.4 |
+| Security breach / ransomware | Very low | Full outage + investigation | [4 hours] | [Last clean backup] | Section 3.5 |
+| Accidental bulk data deletion | Low | Partial or full data loss | [60 min] | [RPO value] | Section 3.6 |
+
+---
+
+## 3. Failure Scenario Runbooks
+
+### 3.1 Single Availability Zone Failure
+
+**Trigger:** One AZ becomes unreachable — pods/instances in that zone stop responding.
+**Detection:** PagerDuty alert `[AlertName]` fires, or cloud provider status page shows AZ degradation.
+**Expected RTO:** [15 minutes] | **Expected RPO:** Zero (no data loss if multi-AZ replication is working)
+
+**Step 1 — Confirm the failure**
+```bash
+# Check pod/instance health across zones
+kubectl get pods -o wide -n [namespace] | grep -v Running
+
+# Check which nodes are affected
+kubectl get nodes -o wide | grep -v Ready
+
+# Verify cloud provider AZ status
+# AWS: https://health.aws.amazon.com/health/status
+# GCP: https://status.cloud.google.com
+```
+
+**Step 2 — Assess whether auto-recovery has occurred**
+```bash
+# If using auto-scaling, check if replacement instances launched
+kubectl get pods -n [namespace] --watch
+
+# Check deployment replica count
+kubectl get deployment [service-name] -n [namespace]
+
+# Verify load balancer health checks are passing
+[cloud provider CLI command to check target group health]
+```
+
+**Step 3 — Force rescheduling if auto-recovery stalled**
+```bash
+# Cordon the affected node so no new pods schedule on it
+kubectl cordon [node-name]
+
+# Drain the node — moves all pods to healthy nodes
+kubectl drain [node-name] --ignore-daemonsets --delete-emptydir-data
+
+# Verify pods have rescheduled successfully
+kubectl get pods -o wide -n [namespace]
+```
+
+**Step 4 — Verify service health**
+```bash
+# Smoke test key endpoints
+curl -s -o /dev/null -w "%{http_code}" https://[service-url]/health
+curl -s -o /dev/null -w "%{http_code}" https://[service-url]/[critical-endpoint]
+
+# Check error rate in monitoring
+[dashboard link or query]
+```
+
+**Recovery confirmed when:** All pods are Running, health check returns 200, error rate is at baseline.
+
+---
+
+### 3.2 Full Region Failure
+
+**Trigger:** The primary region is entirely unavailable.
+**Detection:** All service health checks failing, cloud provider status page confirms region-wide event.
+**Expected RTO:** [60 minutes] | **Expected RPO:** [5 minutes — based on cross-region replication lag]
+
+**Step 1 — Confirm regional failure (5 minutes)**
+```bash
+# Confirm the primary region is unreachable
+ping [primary-region-endpoint] || echo "Primary region unreachable"
+
+# Check replication lag on standby region database
+[command to check replica lag — e.g. for RDS: aws rds describe-db-instances --region [dr-region]]
+```
+
+**Step 2 — Declare DR event and notify (2 minutes)**
+
+Post to `#incidents`:
+```
+🔴 DR EVENT — [Service Name] — Region Failure
+Primary region: [region] — UNREACHABLE
+Activating failover to: [dr-region]
+Incident commander: [Name]
+Next update: 15 minutes
+```
+
+Page [Engineering Manager] and [CTO/VP Eng] via PagerDuty.
+
+**Step 3 — Promote DR database (10 minutes)**
+```bash
+# AWS RDS — promote read replica to primary
+aws rds promote-read-replica \
+  --db-instance-identifier [dr-replica-identifier] \
+  --region [dr-region]
+
+# Wait for promotion to complete
+aws rds wait db-instance-available \
+  --db-instance-identifier [dr-replica-identifier] \
+  --region [dr-region]
+
+# Record the new database endpoint
+aws rds describe-db-instances \
+  --db-instance-identifier [dr-replica-identifier] \
+  --region [dr-region] \
+  --query 'DBInstances[0].Endpoint.Address'
+```
+
+**Step 4 — Deploy service in DR region (20 minutes)**
+```bash
+# Update service configuration to point at DR database
+kubectl set env deployment/[service-name] \
+  DATABASE_URL=[new-dr-database-url] \
+  -n [namespace] \
+  --context [dr-region-context]
+
+# Scale up the DR deployment
+kubectl scale deployment/[service-name] --replicas=[N] \
+  -n [namespace] \
+  --context [dr-region-context]
+
+# Verify all pods are running
+kubectl get pods -n [namespace] --context [dr-region-context]
+```
+
+**Step 5 — Cut over DNS / load balancer (5 minutes)**
+```bash
+# Update DNS to point to DR region load balancer
+# AWS Route 53:
+aws route53 change-resource-record-sets \
+  --hosted-zone-id [zone-id] \
+  --change-batch file://dr-failover-dns.json
+
+# Verify DNS propagation (may take up to [TTL] seconds)
+dig [service-domain] @8.8.8.8
+```
+
+**Step 6 — Verify end-to-end**
+```bash
+# Full smoke test against DR endpoint
+curl -s https://[service-url]/health
+[run automated smoke test suite if available]
+```
+
+**Recovery confirmed when:** DNS resolves to DR region, smoke tests pass, error rate is at baseline.
+
+**Post-failover actions (not urgent — after service is stable):**
+- Do not fail back to primary until root cause is confirmed resolved
+- Document data loss window (check replication lag at time of failure)
+- Begin post-incident review — see [incident-postmortem skill]
+
+---
+
+### 3.3 Database Corruption or Data Loss
+
+**Trigger:** Data in the database is corrupted, deleted, or otherwise incorrect due to a software bug, operator error, or hardware fault.
+**Detection:** Application errors referencing missing/invalid data, monitoring alerts on query error rate, user reports.
+**Expected RTO:** [90 minutes] | **Expected RPO:** [Backup interval — e.g. 1 hour]
+
+**Step 1 — Stop the bleeding immediately**
+```bash
+# Put the service into maintenance mode to prevent further writes to corrupted data
+[command to enable maintenance mode — e.g. kubectl set env deployment/[name] MAINTENANCE_MODE=true]
+
+# Or: scale down the service to zero to prevent writes
+kubectl scale deployment/[service-name] --replicas=0 -n [namespace]
+```
+
+**Step 2 — Assess scope of corruption**
+```bash
+# Identify which tables/records are affected
+[SQL query to check data integrity — e.g.]
+# psql $DATABASE_URL -c "SELECT COUNT(*) FROM [table] WHERE [integrity check condition]"
+
+# Determine when corruption started (cross-reference with deploy times and error logs)
+[log query to find earliest error — e.g. in Datadog:]
+# service:[service-name] status:error "[corruption error message]" | sort by timestamp asc
+```
+
+**Step 3 — Identify the correct restore point**
+```bash
+# List available backups
+[command to list backups — e.g. for RDS:]
+aws rds describe-db-snapshots \
+  --db-instance-identifier [db-identifier] \
+  --query 'DBSnapshots[*].[SnapshotCreateTime,DBSnapshotIdentifier]' \
+  --output table
+
+# Choose the most recent backup BEFORE corruption started
+# Record the chosen snapshot ID: [snapshot-id]
+```
+
+**Step 4 — Restore from backup**
+```bash
+# Restore to a NEW database instance (never overwrite production directly)
+aws rds restore-db-instance-from-db-snapshot \
+  --db-instance-identifier [service-name]-restored-[date] \
+  --db-snapshot-identifier [snapshot-id] \
+  --region [region]
+
+# Wait for restore to complete
+aws rds wait db-instance-available \
+  --db-instance-identifier [service-name]-restored-[date]
+
+# Get the restored instance endpoint
+aws rds describe-db-instances \
+  --db-instance-identifier [service-name]-restored-[date] \
+  --query 'DBInstances[0].Endpoint.Address'
+```
+
+**Step 5 — Validate restored data**
+```bash
+# Connect to restored database and verify integrity
+psql [restored-db-endpoint] -U [user] -d [database] -c "[data integrity query]"
+
+# Confirm record counts match expectations
+psql [restored-db-endpoint] -U [user] -d [database] -c "SELECT COUNT(*) FROM [critical-table]"
+```
+
+**Step 6 — Point service at restored database**
+```bash
+kubectl set env deployment/[service-name] \
+  DATABASE_URL=postgres://[user]:[pass]@[restored-endpoint]/[db] \
+  -n [namespace]
+
+kubectl scale deployment/[service-name] --replicas=[N] -n [namespace]
+```
+
+**Recovery confirmed when:** Service is running against restored database, data integrity checks pass, error rate is at baseline.
+
+---
+
+### 3.4 Critical Dependency Outage
+
+**Trigger:** A service that [service name] depends on is unavailable or degraded.
+**Detection:** Increased error rate or latency on endpoints that call [dependency], alerts from dependency owner.
+**Expected RTO:** Depends on dependency — [30 minutes for mitigation, resolution depends on dependency owner]
+
+**Dependency map:**
+
+| Dependency | Criticality | Degraded behaviour | Mitigation |
+|---|---|---|---|
+| [Database] | Critical — all writes fail | Full outage | Activate DR database (Section 3.3) |
+| [Cache — Redis] | High — latency increases | Performance degradation | Bypass cache, serve from DB |
+| [Auth service] | Critical — auth fails | All authenticated endpoints fail | Return cached tokens (if implemented) |
+| [Message queue] | Medium — async processing delays | Writes succeed, async jobs queue | Queue backlog — see on-call runbook |
+| [External API — name] | Low — feature X unavailable | Graceful degradation | Feature flag to disable feature X |
+
+**Mitigation steps:**
+```bash
+# Enable circuit breaker / fallback for [dependency] if implemented
+kubectl set env deployment/[service-name] [DEPENDENCY]_CIRCUIT_BREAKER=open -n [namespace]
+
+# Enable feature flag to disable [dependency-backed feature]
+[feature flag CLI command or dashboard link]
+
+# Check if dependency has a status page
+# [Dependency status URL]
+```
+
+**Escalation:** Contact [dependency] on-call via [PagerDuty / Slack `#[channel]`]. Share your service's error rate and the time dependency errors started.
+
+---
+
+### 3.5 Security Breach or Ransomware
+
+**Trigger:** Evidence of unauthorized access, data exfiltration, or encryption of service data.
+**Detection:** Security tooling alert, unusual access patterns, user reports of data exposure.
+**Expected RTO:** [4+ hours — prioritise containment over speed] | **Expected RPO:** [Last verified clean backup]
+
+**Step 1 — Isolate immediately**
+```bash
+# Take the service offline — do not attempt to recover while breach is active
+kubectl scale deployment/[service-name] --replicas=0 -n [namespace]
+
+# Revoke all API keys and service account credentials immediately
+[command to rotate secrets — e.g. via Vault or cloud provider]
+
+# Block all external access at network level
+[firewall/security group command to deny all inbound traffic]
+```
+
+**Step 2 — Notify security team immediately**
+Page [Security lead] via PagerDuty. Do NOT attempt to remediate without security team involvement.
+
+Post to `#security-incidents` (private channel, not `#incidents`):
+```
+🔴 SECURITY INCIDENT — [Service Name]
+Time detected: [Time]
+Evidence: [One sentence — what was observed]
+Actions taken: Service isolated, credentials revoked
+Awaiting: Security team guidance
+```
+
+**Step 3 — Preserve evidence**
+```bash
+# Export current logs before any remediation
+[log export command — preserve evidence for forensics]
+
+# Snapshot the current state of all infrastructure
+[snapshot/image command]
+```
+
+**Steps 4+ — Follow security team guidance.** Do not restore from backup until security team confirms the attack vector is closed.
+
+---
+
+### 3.6 Accidental Bulk Data Deletion
+
+**Trigger:** An operator, script, or application bug has deleted records in bulk.
+**Detection:** Sudden drop in record counts, user reports of missing data, application errors.
+**Expected RTO:** [60 minutes] | **Expected RPO:** [Backup interval]
+
+```bash
+# Step 1 — Stop further writes immediately
+kubectl scale deployment/[service-name] --replicas=0 -n [namespace]
+
+# Step 2 — Determine what was deleted and when
+psql $DATABASE_URL -c "
+  SELECT schemaname, tablename,
+         n_dead_tup, last_autovacuum
+  FROM pg_stat_user_tables
+  ORDER BY n_dead_tup DESC LIMIT 10;
+"
+
+# Step 3 — Check if deletion is recoverable via MVCC (PostgreSQL)
+# Records may still be recoverable if VACUUM has not run
+psql $DATABASE_URL -c "
+  SELECT * FROM [table]
+  WHERE xmax != 0  -- recently deleted rows
+  LIMIT 100;
+"
+
+# Step 4 — If not recoverable via MVCC, restore from backup
+# Follow Section 3.3 (Database Corruption runbook) from Step 3 onward
+```
+
+---
+
+## 4. Backup and Restore Procedures
+
+### Backup Configuration
+
+| Data store | Backup type | Frequency | Retention | Location |
+|---|---|---|---|---|
+| [Primary database] | Automated snapshots | Every [N] hours | [N] days | [S3 bucket / cloud storage path] |
+| [Primary database] | Transaction log backups | Continuous | [N] days | [Location] |
+| [Secondary store — e.g. Redis] | RDB dump | Daily | [N] days | [Location] |
+| [Blob/object storage] | Cross-region replication | Continuous | [N] days | [DR region bucket] |
+| [Config / secrets] | Terraform state + Vault backup | On change | Indefinite | [Location] |
+
+### Backup Validation (Run Weekly)
+
+```bash
+# Test restore of latest database backup to a throwaway instance
+aws rds restore-db-instance-from-db-snapshot \
+  --db-instance-identifier [service-name]-backup-test-$(date +%Y%m%d) \
+  --db-snapshot-identifier $(aws rds describe-db-snapshots \
+    --db-instance-identifier [db-id] \
+    --query 'sort_by(DBSnapshots, &SnapshotCreateTime)[-1].DBSnapshotIdentifier' \
+    --output text)
+
+# Wait for restore, then run integrity checks
+psql [test-instance-endpoint] -c "[integrity check query]"
+
+# Confirm row counts match recent production values (allow ≤ RPO difference)
+psql [test-instance-endpoint] -c "SELECT COUNT(*) FROM [critical-table]"
+
+# Destroy the test instance
+aws rds delete-db-instance \
+  --db-instance-identifier [service-name]-backup-test-$(date +%Y%m%d) \
+  --skip-final-snapshot
+```
+
+---
+
+## 5. DR Testing Cadence
+
+Regular testing is mandatory. An untested DR plan is not a DR plan.
+
+| Test type | Frequency | Who runs it | Pass criteria |
+|---|---|---|---|
+| Backup restore validation | Weekly (automated) | On-call rotation | Restore completes, integrity checks pass |
+| Zone failover drill | Monthly | Engineering team | RTO target met, zero data loss |
+| Region failover drill | Quarterly | Engineering + SRE | RTO/RPO targets met |
+| Full DR game day | Annually | Engineering + stakeholders | All scenarios exercised, gaps documented |
+| Chaos engineering (infra failures) | Weekly (automated) | Chaos engineering tooling | Service degrades gracefully, recovers automatically |
+
+### Game Day Procedure
+
+1. **Pre-game day (1 week before):** Notify all stakeholders, freeze production changes for the day, prepare DR environment.
+2. **Scope definition:** Choose 2–3 scenarios from Section 2. Document expected outcomes before the test.
+3. **Execute:** One person acts as incident commander, others execute runbook steps while another observes and times.
+4. **Measure:** Record actual RTO and RPO against targets for each scenario.
+5. **Debrief (same day):** Document gaps, runbook inaccuracies, and automation opportunities.
+6. **Action items:** File tickets for every gap found. Priority: P1 items must be fixed before next game day.
+
+---
+
+## 6. Communication Plan
+
+### Internal Communication During DR Event
+
+**Incident commander responsibilities:**
+- Declare the DR event and open the incident channel
+- Post updates every 15 minutes minimum
+- Make the call to fail over (do not let the team decide by committee)
+- Notify business stakeholders of expected recovery time
+
+**Notify these people at DR event start:**
+
+| Role | Name | Contact | When to notify |
+|---|---|---|---|
+| Engineering manager | [Name] | [Slack / Phone] | Immediately |
+| CTO / VP Engineering | [Name] | [Phone] | Tier 1 services: immediately |
+| Customer success lead | [Name] | [Slack] | If customer-facing impact |
+| Security lead | [Name] | [Slack / PagerDuty] | If breach suspected |
+| Legal / compliance | [Name] | [Email / Phone] | If data loss involves PII |
+
+### Communication Templates
+
+**DR event declared:**
+```
+🔴 DR EVENT — [Service Name]
+Time: [HH:MM UTC]
+Scenario: [Zone failure / Region failure / Data loss / etc.]
+Impact: [Who is affected and how]
+RTO target: [X minutes]
+Incident commander: [Name]
+War room: [Slack channel / call link]
+Next update: [Time + 15 min]
+```
+
+**Status update (every 15 minutes):**
+```
+🔴 DR UPDATE — [Service Name] — [HH:MM UTC]
+Status: [Investigating / Executing recovery / Verifying]
+Progress: [One sentence on current step]
+Blockers: [Any — or "None"]
+Updated RTO estimate: [Time]
+Next update: [Time + 15 min]
+```
+
+**Recovery confirmed:**
+```
+✅ DR RESOLVED — [Service Name] — [HH:MM UTC]
+Total downtime: [X minutes]
+Data loss: [None / X minutes of transactions]
+RTO target: [X min] — Actual: [Y min] — [MET / MISSED]
+RPO target: [X min] — Actual: [Y min] — [MET / MISSED]
+Root cause: [One sentence]
+Post-incident review: [Scheduled for / Link when created]
+```
+
+---
+
+## 7. DR Readiness Checklist
+
+Run this checklist quarterly and before any major infrastructure change:
+
+**Backups:**
+- [ ] Automated backups are running and alerts fire if they fail
+- [ ] Most recent backup restore was tested within the last 7 days
+- [ ] Backup retention meets RPO and compliance requirements
+- [ ] Backups are stored in a separate region / account from primary
+
+**Failover infrastructure:**
+- [ ] DR region / environment exists and is provisioned (not just documented)
+- [ ] DNS failover procedure is documented with exact commands
+- [ ] DR database replica is current (replication lag is within RPO)
+- [ ] Service can be deployed in DR region with a single command or automated pipeline
+
+**Runbooks:**
+- [ ] All runbooks in Section 3 have been tested within the last quarter
+- [ ] Runbook commands have been verified against current infrastructure (no stale references)
+- [ ] Contact list is current (no departed employees)
+
+**Access:**
+- [ ] On-call engineers have access to DR region console / CLI
+- [ ] Service account credentials for DR region are provisioned and tested
+- [ ] Break-glass accounts exist for emergency access if SSO is unavailable
+
+**Monitoring:**
+- [ ] Monitoring exists in DR region (not just primary)
+- [ ] Alerts fire correctly when DR environment has issues
+
+---
+
+## Quality Checks
+
+- [ ] RPO and RTO targets are specific numbers, not ranges, and are agreed with the business
+- [ ] Every command in every runbook has been run by a human in the last quarter — not copied from documentation untested
+- [ ] DR database exists in the DR region and replication lag is monitored
+- [ ] Backup restore has been tested end-to-end within the last 7 days
+- [ ] The game day schedule is on the team calendar — not just documented here
+- [ ] Contact list contains current phone numbers, not just Slack handles (Slack may be down during a DR event)
+- [ ] Security breach runbook (3.5) explicitly names the security team contact and does not attempt self-remediation
+- [ ] All thresholds (RTO/RPO) are visible in the monitoring dashboard so actual vs. target is measurable in real time
@@ -0,0 +1,338 @@
+---
+name: engineering-hiring-rubric
+description: "Build an engineering hiring rubric and technical interview scorecard for evaluating software engineers at a specific level. Use when asked to create an interview rubric, design a hiring process, build a technical scorecard, or standardize engineer evaluation. Produces a full interview scorecard, behavioral question bank, technical question set with evaluation criteria, system design rubric, and debrief agenda."
+---
+
+# Engineering Hiring Rubric
+
+Produce a complete hiring rubric and interview scorecard for evaluating software engineers at a specific role and level. The rubric must be specific enough that two interviewers who have never compared notes will score the same candidate within one level of each other. That requires: explicit behavioral anchors (what does "Strong Hire" look like vs. "Hire" for each competency), calibrated technical questions with written evaluation criteria, and a structured debrief format that surfaces signal rather than recency bias. Include calibration notes to help interviewers recognize and counter common evaluation biases.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Role** — backend, frontend, fullstack, SRE/platform, data, ML, or mobile engineer
+- **Level** — junior (L3/IC2), mid (L4/IC3), senior (L5/IC4), or staff (L6/IC5); clarify the company's level naming if different
+- **Team context** — what the team builds, team size, and what problems this hire will work on in the first year
+- **Tech stack** — primary languages and frameworks for the technical questions; list the stack explicitly
+- **Interview format** — which rounds are used (phone screen, coding, system design, behavioral, take-home); if not specified, produce a recommended format
+
+## Output Format
+
+---
+
+# Engineering Hiring Rubric: [Role] — [Level]
+
+**Role:** [e.g., Senior Backend Engineer]
+**Level equivalent:** [e.g., L5 / IC4 / Senior]
+**Team:** [Team name and one-sentence description of what they build]
+**Tech stack:** [Languages and frameworks]
+**Interview loop:** [List the rounds in order]
+
+---
+
+## 1. Role Definition and Level Expectations
+
+### What This Role Does
+
+[2–3 sentences describing the scope of work: what systems they'll own, what problems they'll solve, and who they'll work with. Make this specific to the team context provided.]
+
+### Level Bar
+
+Define the minimum bar for a Hire recommendation at this level. This is not the ideal candidate description — it is the floor.
+
+| Dimension | [Level] Floor | One Level Below (No Hire) | One Level Above (Stretch) |
+|-----------|--------------|---------------------------|---------------------------|
+| Technical scope | [e.g., "Owns a service or major feature area end-to-end with minimal guidance"] | [e.g., "Completes well-defined tasks; needs guidance on scope and approach"] | [e.g., "Leads cross-team technical initiatives; sets technical direction"] |
+| Problem solving | [e.g., "Breaks ambiguous problems into concrete sub-problems independently"] | [e.g., "Solves defined problems well; struggles with ambiguity"] | [e.g., "Identifies problems others miss; structures organization-level technical challenges"] |
+| Code quality | [e.g., "Writes production-ready code; anticipates edge cases; reviewable without significant rework"] | [e.g., "Writes working code that requires significant review feedback"] | [e.g., "Sets code quality standards; designs reusable abstractions adopted by others"] |
+| Communication | [e.g., "Communicates technical decisions clearly to peers and stakeholders"] | [e.g., "Communicates well with direct team; struggles with cross-team or stakeholder comms"] | [e.g., "Drives technical consensus across teams; writes documents others reference"] |
+| Ownership | [e.g., "Sees work to production; monitors after deploy; follows up on issues proactively"] | [e.g., "Delivers assigned work; escalates issues but doesn't drive them to resolution"] | [e.g., "Owns outcomes across teams; improves team processes and systems beyond their own work"] |
+
+---
+
+## 2. Interview Loop Structure
+
+| Round | Format | Duration | Interviewer | Competencies Assessed |
+|-------|--------|----------|-------------|----------------------|
+| Phone screen | Video call, technical questions | 45 min | [Hiring manager or senior engineer] | Problem solving, communication, basic technical depth |
+| Coding interview 1 | Live coding — [platform] | 60 min | [Engineer] | Coding, data structures, code quality |
+| Coding interview 2 | Live coding — [platform] | 60 min | [Engineer] | Algorithms, debugging, code quality |
+| System design | Whiteboard / shared doc | 60 min | [Senior/Staff engineer] | System design, scalability, technical communication |
+| Behavioral | Structured interview | 45 min | [Hiring manager] | Ownership, collaboration, growth mindset |
+| [Optional] Take-home | Asynchronous project | [X hours] | [Reviewer] | Code quality, thoroughness, real-world problem solving |
+
+**Interview coverage matrix:** Each competency dimension must be assessed by at least 2 independent interviewers.
+
+| Competency | Phone Screen | Coding 1 | Coding 2 | System Design | Behavioral |
+|-----------|-------------|---------|---------|--------------|-----------|
+| Coding | ○ | ● | ● | ○ | |
+| System design | ○ | | | ● | |
+| Problem solving | ● | ● | ● | ● | |
+| Code quality | | ● | ● | | |
+| Communication | ● | ● | ● | ● | ● |
+| Ownership | ○ | | | ○ | ● |
+| Debugging | | ● | ● | | |
+
+● = Primary signal  ○ = Secondary signal
+
+---
+
+## 3. Coding Interview Guide
+
+### Question Selection
+
+Choose 1–2 problems per coding round. Problems should be solvable in 30–40 minutes with the remaining time for discussion and follow-ups. Prefer problems with multiple solution tiers so you can see how far candidates take their thinking.
+
+### Problem Template
+
+**Problem: [Title]**
+
+*Prompt (read to candidate):*
+> [Problem statement — be specific. Include constraints (input size, value ranges). Avoid ambiguity that tests problem-reading rather than problem-solving.]
+
+*Example:*
+> Given a list of integers representing stock prices at each minute of a trading day, return the maximum profit you could achieve by making exactly one buy and one sell. You may not sell before you buy.
+
+**Clarifying questions a strong candidate will ask:**
+- [e.g., "Can the list be empty?" / "Are all values positive?" / "Can profit be negative — i.e., should we return 0 if no profit is possible?"]
+
+**Solution tiers:**
+
+| Tier | Approach | Time Complexity | Space Complexity | Signals |
+|------|----------|-----------------|-----------------|---------|
+| Baseline | [Brute force — O(n²) nested loop] | O(n²) | O(1) | Can solve the problem; understands correctness |
+| Expected | [Single pass, tracking min price seen so far] | O(n) | O(1) | Strong problem solver; explains tradeoff |
+| Strong | [Generalizes to k transactions, or extends to cooldown variant without prompting] | O(n) | O(1) | Staff-level generalization thinking |
+
+**Follow-up questions:**
+- [e.g., "What if you could make at most k trades?"]
+- [e.g., "How would you test this function? Write me 3 test cases."]
+- [e.g., "Walk me through your code as if you're explaining it in a code review."]
+
+**Evaluation rubric for this problem:**
+
+| Signal | Strong Hire | Hire | No Hire |
+|--------|------------|------|---------|
+| Problem comprehension | Asks 1–2 clarifying questions immediately; identifies edge cases before coding | Understands the problem after 1 prompt; misses 1–2 edge cases | Misunderstands the problem or requires repeated clarification |
+| Solution quality | O(n) solution; clean code; handles all edge cases | O(n) with hints; code is readable but has minor issues | O(n²) with hints, or correct solution with significant issues |
+| Code quality | Well-named variables; logical structure; would pass code review | Functional but verbose or inconsistently named | Hard to follow; would require significant review feedback |
+| Communication | Narrates thinking throughout; explains complexity; self-corrects | Explains solution when asked; answers follow-ups well | Silent during coding; unable to explain their approach |
+| Follow-ups | Extends solution confidently; identifies further improvements | Handles follow-ups with moderate prompting | Unable to extend or explain tradeoffs |
+
+---
+
+## 4. System Design Interview Guide
+
+### [Level]-Appropriate Design Scope
+
+At [Level], expect the candidate to:
+- [e.g., Senior: "Design a complete system with capacity estimates, component breakdown, and discussion of failure modes"]
+- [e.g., Mid: "Design the core components of a system; may need prompting on scalability and failure handling"]
+- [e.g., Junior: "Design a simple client-server system; focus on clarity of thinking over complete distributed systems knowledge"]
+
+### Sample Design Question
+
+**Question:** "Design [a URL shortener / a rate limiter / a notification service / a ride-matching system — choose one relevant to the team's domain]."
+
+**Evaluation dimensions:**
+
+| Dimension | What to assess | Strong Hire | Hire | No Hire |
+|-----------|---------------|------------|------|---------|
+| Requirements clarification | Does the candidate ask before designing? | Asks scope, scale, SLA, and key use cases before drawing anything | Asks some questions; may miss scale or SLA | Starts designing immediately without clarifying |
+| High-level design | Can they describe the major components? | Clear component breakdown with justified choices; covers data flow | Reasonable breakdown; may overcomplicate or undercomplicate | Missing key components or cannot explain data flow |
+| Data model | Can they design a schema or data structure for the system? | Models the core entities with normalization/denormalization tradeoffs discussed | Reasonable schema; may miss indexing or partitioning needs | Cannot model the data or produces clearly wrong schema |
+| Scalability | Can they identify and address bottlenecks? | Identifies bottlenecks proactively; proposes horizontal scaling, caching, or sharding as appropriate | Discusses scaling when prompted; reasonable solutions | Cannot identify bottlenecks or proposes solutions that don't match the scale |
+| Failure handling | Do they think about what happens when things break? | Proactively discusses failure modes: single points of failure, retry logic, idempotency | Discusses failure when prompted; identifies some failure modes | Does not think about failure; assumes happy path |
+| Communication | Is the design explained clearly? | Could run this meeting with a team of engineers at a real company | Clear enough to follow; some gaps in explanation | Difficult to follow; interviewer cannot understand the design |
+
+### Design Probing Questions
+
+Use these to probe depth after the candidate presents their design:
+- "Walk me through what happens when a write request comes in at peak load — 10,000 requests per second."
+- "Your primary database just failed. What happens to the system?"
+- "You estimated X QPS. How would your design change if it needed to handle 100× that?"
+- "Where is the first place this system would fall over under load?"
+- "How would you monitor this in production? What would your on-call runbook look like?"
+
+---
+
+## 5. Behavioral Interview Question Bank
+
+Map every question to a competency. Ask 4–6 questions per behavioral round using STAR format (Situation, Task, Action, Result). Do not ask leading questions.
+
+### Competency: Ownership and Delivery
+
+1. "Tell me about a time you owned something end-to-end — from design through production monitoring. What did you do when something went wrong after launch?"
+   - *Strong signal:* Describes proactive monitoring setup, a specific incident they caught themselves, and what they changed
+   - *Weak signal:* Describes writing the code and handing off; no discussion of production behavior
+
+2. "Describe a project that was significantly delayed or failed. What was your role, and what did you take responsibility for?"
+   - *Strong signal:* Direct ownership of their contribution to the failure; specific changes to how they work
+   - *Weak signal:* Attributes all delay to external factors; no reflection on their own actions
+
+### Competency: Technical Judgment
+
+3. "Tell me about a significant technical decision you made. What options did you consider, and how did you decide?"
+   - *Strong signal:* Named alternatives with clear tradeoffs; explains who they consulted; reflects on whether they'd decide the same way today
+   - *Weak signal:* "I knew X was the right answer" without describing the decision process
+
+4. "Describe a time you had to push back on a technical direction — either from management or from peers. What happened?"
+   - *Strong signal:* Evidence-based disagreement; constructive communication; willing to commit once decision was made even if they lost the argument
+   - *Weak signal:* Either never pushed back or pushed back emotionally without evidence
+
+### Competency: Collaboration and Communication
+
+5. "Tell me about a time you had to explain a complex technical concept to a non-technical stakeholder. How did you approach it?"
+   - *Strong signal:* Used analogy or simplified model; confirmed understanding; adapted to the audience
+   - *Weak signal:* "I explained it technically and told them to trust me"
+
+6. "Describe a situation where you and a peer strongly disagreed on an approach. How did it resolve?"
+   - *Strong signal:* Sought a third opinion or data; focused on the right outcome, not being right; maintained relationship
+   - *Weak signal:* Escalated immediately or capitulated without engaging
+
+### Competency: Growth and Learning
+
+7. "What is a significant technical mistake you made in the last two years? What did you learn from it?"
+   - *Strong signal:* Specific mistake, clear causal analysis, concrete behavioral change afterward
+   - *Weak signal:* Cannot name a specific mistake; describes a minor issue to avoid vulnerability
+
+8. "How do you stay current in [relevant technical area]? Give me a specific example of something you learned recently and applied."
+   - *Strong signal:* Named sources, applied learning in a specific project with a concrete outcome
+   - *Weak signal:* "I read blogs" with no specifics; no applied example
+
+---
+
+## 6. Full Interview Scorecard
+
+Complete one scorecard per interview round. Collect all scorecards before the debrief.
+
+```
+INTERVIEW SCORECARD
+===================
+Candidate:         ______________________
+Interviewer:       ______________________
+Round:             ______________________
+Date:              ______________________
+Interview format:  ______________________
+
+COMPETENCY RATINGS
+Rate each dimension independently. Do not average.
+Scale: 1 = Strong No Hire | 2 = No Hire | 3 = Hire | 4 = Strong Hire
+
+                          1    2    3    4    Notes
+Coding / Technical skill  [ ]  [ ]  [ ]  [ ]  ___________________________
+Problem solving           [ ]  [ ]  [ ]  [ ]  ___________________________
+System design             [ ]  [ ]  [ ]  [ ]  ___________________________  
+Code quality              [ ]  [ ]  [ ]  [ ]  ___________________________
+Debugging                 [ ]  [ ]  [ ]  [ ]  ___________________________
+Communication             [ ]  [ ]  [ ]  [ ]  ___________________________
+Ownership                 [ ]  [ ]  [ ]  [ ]  ___________________________
+Collaboration             [ ]  [ ]  [ ]  [ ]  ___________________________
+
+SPECIFIC EVIDENCE
+What did the candidate do or say that drove your rating?
+(Required — write observable behaviors, not impressions)
+
+Strongest signal (positive):
+___________________________________________________________________________
+
+Strongest concern or gap:
+___________________________________________________________________________
+
+OVERALL RECOMMENDATION
+[ ] Strong Hire    [ ] Hire    [ ] No Hire    [ ] Strong No Hire
+
+OVERALL RECOMMENDATION RATIONALE
+(Required — 3–5 sentences minimum. State your recommendation, the evidence
+that supports it, and the specific gap or risk if not a Strong Hire)
+___________________________________________________________________________
+___________________________________________________________________________
+___________________________________________________________________________
+
+Level signal: This candidate demonstrated [ L_ / L_ ] level behaviors.
+
+SHOULD INTERVIEWERS DISCUSS BEFORE DEBRIEF? 
+[ ] No — I have a clear independent signal
+[ ] Yes — I need context on [specific area] to complete my assessment
+```
+
+---
+
+## 7. Hiring Recommendation Framework
+
+| Recommendation | Meaning | When to use |
+|---------------|---------|-------------|
+| **Strong Hire** | Confident the candidate will exceed the level bar and be a high performer on the team | Evidence across 3+ competencies at above-bar level; no significant concerns |
+| **Hire** | Confident the candidate meets the level bar; will perform well | Meets bar on all must-have competencies; may have 1 area to develop |
+| **No Hire** | Does not meet the level bar | Below bar on 1+ must-have competency, or gap too large to close quickly |
+| **Strong No Hire** | Clear mismatch — well below the bar, or a specific disqualifying signal | Significant gaps across multiple competencies, or a values/behavior concern |
+
+**Must-hire competencies for [Role] at [Level]:** [List 3–4 competencies where a No Hire score on any one of them means the overall recommendation must be No Hire, regardless of performance elsewhere. Example: "Coding and System Design are must-hire competencies for a Senior Backend Engineer. Strong performance on Behavioral dimensions cannot compensate for a No Hire on Coding."]
+
+**Debrief rule:** A Strong Hire can override one No Hire only if: (a) the No Hire is not on a must-hire competency, and (b) the Strong Hire interviewer can articulate why the concern is not disqualifying. A Strong No Hire cannot be overridden — escalate to hiring manager.
+
+---
+
+## 8. Debrief Agenda
+
+Run the debrief before scorecards are shared verbally. Everyone submits a written scorecard first.
+
+```
+DEBRIEF AGENDA — [Candidate Name]
+Duration: 45 minutes
+Facilitator: [Hiring Manager]
+
+0:00 – 0:05  SCORECARD REVIEW
+  Each interviewer states their overall recommendation only (no rationale yet).
+  Facilitator notes alignment and disagreements on whiteboard/doc.
+
+0:05 – 0:15  EVIDENCE ROUND
+  Go around the table. Each interviewer shares:
+    - Their strongest positive signal (observable behavior, not impression)
+    - Their biggest concern (observable behavior, not impression)
+  No discussion yet — just evidence gathering.
+
+0:15 – 0:30  DISCUSS DISAGREEMENTS
+  Address only the competency dimensions where interviewers disagree.
+  Anchor discussion on: "What did you observe?" not "What do you think?"
+  If interviewers assessed different competencies, disagreement may reflect
+  insufficient signal — note this.
+
+0:30 – 0:40  DECISION
+  Reach a decision on overall recommendation.
+  If consensus: state the recommendation and rationale.
+  If not consensus: hiring manager makes the call and states why.
+
+0:40 – 0:45  PROCESS NOTES
+  - Were any questions unclear or hard to compare across candidates?
+  - Any bias signals observed during the debrief? (see Section 9)
+  - Feedback to improve the process for next time.
+```
+
+---
+
+## 9. Calibration and Bias Reduction Notes
+
+Brief every interviewer on these before they conduct their first interview for this role.
+
+| Bias | How it manifests | Counter-measure |
+|------|-----------------|-----------------|
+| Halo effect | Strong performance in round 1 colors ratings in round 2 | Submit scorecard before reading others; rate each competency independently |
+| Similarity bias | "I liked them" correlates with "they think like me" | Require observable evidence for every rating; check: "Is this a signal about their ability or their similarity to me?" |
+| Recency bias | Final impression dominates overall rating | Take notes during the interview; write evidence immediately after; debrief uses written evidence, not memory |
+| Expectation anchoring | First interviewer's opinion anchors all others | No verbal discussion between interviewers before debrief; written scorecards submitted before debrief starts |
+| Culture fit as cover | "Not a culture fit" without specific behavioral evidence | "Culture fit" is not a valid dimension on this scorecard; use Collaboration and Communication with evidence |
+| Credential bias | Degree or previous employer overweights rating | Do not list educational background in pre-interview briefing documents; focus on demonstrated behaviors |
+| Confidence ≠ Competence | Articulate candidates rated higher regardless of correctness | Grade the answer quality, not the delivery style; use written rubrics per question |
+
+---
+
+## Quality Checks
+
+- [ ] Level bar table defines a concrete floor for the level — not aspirational traits — with a comparison to one level below and above
+- [ ] Every behavioral question includes explicit Strong Hire and Weak/No Hire signal descriptions — not just the question text
+- [ ] Coding problem(s) include solution tiers with time and space complexity, plus a per-question rubric with behavioral anchors
+- [ ] System design rubric evaluates at minimum: requirements clarification, component design, data model, scalability, and failure handling
+- [ ] Scorecard uses observable behavior fields ("What did the candidate do or say") — not impression fields
+- [ ] Must-hire competencies are explicitly named for the role and level
+- [ ] Debrief agenda enforces written scorecard submission before verbal discussion to prevent anchoring
@@ -0,0 +1,164 @@
+---
+name: engineering-weekly-report
+description: "Write a weekly engineering status report for a team, service, or initiative. Use when asked to write a team update, weekly engineering report, sprint status email, or standing team communication to stakeholders. Produces a concise, scannable weekly report covering shipping progress, metrics, decisions, blockers, and next-week priorities."
+---
+
+# Engineering Weekly Report
+
+Produce a weekly engineering status report that a team can send to stakeholders, their engineering manager, and the team itself. The format is fixed week-over-week so readers know exactly where to look — shipping progress at the top, decisions in the middle, risks and next steps at the bottom. The report must be readable in under 2 minutes. Avoid prose walls: use bullet points, status tags, and short tables. If metrics are not provided, leave the metrics section with [data needed] markers rather than fabricating numbers.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Team name and report period** — team name plus week number or date range (e.g., "Platform Team, Week 21, May 12–16")
+- **Work items shipped this week** — what was completed and released or merged
+- **Work items in progress** — what is actively being worked on, with rough percent-complete if known
+- **Blocked items** — what is blocked, who owns the block, and what is needed to unblock
+- **Key decisions made** — any architecture, process, or priority decisions made this week
+- **Decisions needed next week** — any decisions that need to be made soon and who needs to make them
+- **Risks and escalations** — anything that threatens next week's commitments or needs leadership visibility
+- **Next week's top priorities** — the 3–5 things the team plans to accomplish next week
+
+Optional but useful:
+- **Key metrics** — reliability (error rate, p99 latency), velocity (story points completed), or other health indicators
+- **Team health notes** — PTO, new joins, attrition, morale signals worth noting
+- **Sprint or iteration number** — if the team runs sprints
+
+## Output Format
+
+---
+
+# Engineering Weekly Report — [Team Name]
+**Week:** [Week Number] | [Date Range, e.g., May 12–16, 2025]
+**Author:** [Name or Team Lead]
+**Distribution:** [e.g., Eng leadership, Product, Team]
+
+---
+
+## Shipping Progress
+
+### Shipped This Week
+
+| Item | Description | Impact |
+|------|-------------|--------|
+| [Feature / Fix / Infra change] | [One-line description] | [Who benefits / what it unblocks] |
+| [Feature / Fix / Infra change] | [One-line description] | [Who benefits / what it unblocks] |
+| [Feature / Fix / Infra change] | [One-line description] | [Who benefits / what it unblocks] |
+
+### In Progress
+
+| Item | Owner | Status | Target Ship |
+|------|-------|--------|-------------|
+| [Work item] | [Name] | [~40% / On Track / At Risk] | [Date or Sprint] |
+| [Work item] | [Name] | [~70% / On Track / At Risk] | [Date or Sprint] |
+| [Work item] | [Name] | [~20% / On Track / At Risk] | [Date or Sprint] |
+
+### Blocked
+
+| Item | Blocked Since | Blocker Description | Owner | Needed To Unblock |
+|------|--------------|--------------------|----|-------------------|
+| [Work item] | [Date] | [What is blocking progress] | [Name] | [Specific ask — decision, resource, dependency] |
+
+If no items are blocked: *No active blockers.*
+
+---
+
+## Key Metrics
+
+*Metrics reported as of [Date]. Prior week in parentheses.*
+
+| Metric | This Week | Last Week | Trend | Target |
+|--------|-----------|-----------|-------|--------|
+| Error rate (5xx) | [X%] | [X%] | [↑ / ↓ / →] | < [threshold] |
+| p99 latency | [Xms] | [Xms] | [↑ / ↓ / →] | < [threshold] |
+| Deployment frequency | [X deploys] | [X deploys] | [↑ / ↓ / →] | [target] |
+| Story points completed | [X] | [X] | [↑ / ↓ / →] | [sprint target] |
+| On-call page volume | [X pages] | [X pages] | [↑ / ↓ / →] | < [threshold] |
+
+**Metrics notes:** [Any context that makes the numbers meaningful — e.g., "Error rate spike on Tuesday tied to downstream dependency outage, resolved by EOD."]
+
+If metrics are not provided: replace table rows with `[data needed — provide metric values for this section]`.
+
+---
+
+## Decisions
+
+### Made This Week
+
+| Decision | Rationale | Owner | Stakeholders Informed |
+|----------|-----------|-------|----------------------|
+| [Decision description] | [Why — 1 sentence] | [Name] | [Yes / No — who] |
+| [Decision description] | [Why — 1 sentence] | [Name] | [Yes / No — who] |
+
+If no decisions were made: *No major decisions this week.*
+
+### Needed Next Week
+
+| Decision | Context | Deadline | Decision Owner |
+|----------|---------|----------|----------------|
+| [What needs to be decided] | [Why it matters, what happens if delayed] | [Date] | [Name or role] |
+
+If no decisions are pending: *No decisions pending.*
+
+---
+
+## Risks and Escalations
+
+| Risk | Likelihood | Impact | Mitigation | Escalate To |
+|------|-----------|--------|-----------|-------------|
+| [Risk description] | [High/Med/Low] | [High/Med/Low] | [What we're doing about it] | [Name/role if escalation needed] |
+
+**Escalations this week:** [Any item that needs immediate leadership attention — call it out explicitly here, do not bury it in a table row. If none: "None."]
+
+---
+
+## Team Health
+
+| Item | Status |
+|------|--------|
+| Team capacity this week | [X of Y people at full capacity] |
+| PTO / out of office | [Names and dates, or "None"] |
+| New joins / departures | [Name, role, and date, or "None"] |
+| On-call this week | [Name] |
+| On-call next week | [Name] |
+
+**Team notes:** [Any morale, workload, or team dynamic signals worth surfacing — keep this factual and constructive. If nothing to note: omit this line.]
+
+---
+
+## Next Week's Priorities
+
+*The [3–5] things this team will ship or meaningfully advance next week.*
+
+1. **[Priority item]** — [One sentence: what done looks like and who owns it]
+2. **[Priority item]** — [One sentence: what done looks like and who owns it]
+3. **[Priority item]** — [One sentence: what done looks like and who owns it]
+4. **[Priority item]** — [One sentence: what done looks like and who owns it]
+5. **[Priority item]** — [One sentence: what done looks like and who owns it]
+
+**Capacity risk:** [If the team is at reduced capacity next week (PTO, incidents, etc.), note it here so stakeholders calibrate expectations.]
+
+---
+
+## Appendix: Sprint Scorecard (if applicable)
+
+| Sprint | Committed | Completed | Completion Rate | Carried Over |
+|--------|-----------|-----------|----------------|--------------|
+| Sprint [N-1] | [X pts] | [X pts] | [X%] | [X pts] |
+| Sprint [N] (current) | [X pts] | [X pts — partial] | [X% at midpoint] | TBD |
+
+---
+
+*Questions or corrections: [Slack channel or email] | Next report: [Date]*
+
+---
+
+## Quality Checks
+
+- [ ] Every blocked item names a specific owner and states what is concretely needed to unblock it — not just "waiting on X"
+- [ ] Decisions-needed table includes a deadline and a named decision owner, not a vague "TBD"
+- [ ] Metrics table is either populated with real numbers or explicitly marked `[data needed]` — no fabricated metrics
+- [ ] Next week's priorities are written as outcomes ("ship X", "complete Y migration") not as activities ("work on X")
+- [ ] Escalations that need leadership attention are called out explicitly in the Risks section — not just buried in a table row
+- [ ] The entire report is readable in under 2 minutes — if it is longer than one printed page, trim it
+- [ ] Report period (week number and date range) is clearly stated in the header
@@ -0,0 +1,369 @@
+---
+name: feature-flag-guide
+description: "Write a feature flag management guide and lifecycle playbook for a service or team — covering flag taxonomy, creation checklist, rollout strategy, monitoring requirements, cleanup policy, and governance. Use when asked to document feature flag practices, create a flag rollout plan, write a feature flag policy, or guide a team on flag lifecycle management. Produces a flag lifecycle playbook, taxonomy reference, per-flag creation template, rollout decision tree, and cleanup checklist."
+---
+
+# Feature Flag Guide Skill
+
+Produce a complete feature flag management guide for a service or team — covering how flags are named and categorised, how to create and roll out a flag safely, what to monitor during rollout, when and how to clean up flags, and who is responsible for each stage. Feature flags without discipline become permanent technical debt. This guide gives the team a repeatable process so flags are created intentionally, rolled out safely, and removed when done.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service or team name** — scope of the guide
+- **Feature flag platform** — LaunchDarkly, Split, Unleash, Flagsmith, Flipt, or a custom/in-house solution
+- **Flag being documented** (if writing a per-flag guide) or "general guide" (if writing team-wide policy)
+- **Rollout constraints** — any compliance, data privacy, or contractual constraints on who can see a feature (e.g. HIPAA, EU-only, enterprise customers only)
+
+## Output Format
+
+---
+
+# Feature Flag Management Guide: [Service / Team Name]
+
+**Team:** [Team name] | **Platform:** [LaunchDarkly / Split / Unleash / Custom]
+**Document owner:** [Name] | **Last updated:** [Date]
+**Review cycle:** Quarterly, and whenever the flag platform changes
+
+---
+
+## 1. Flag Taxonomy
+
+Every flag belongs to exactly one category. The category determines default behaviour, who can enable it in production, and when it must be cleaned up.
+
+| Type | Purpose | Default state | Production gate | Max lifetime |
+|---|---|---|---|---|
+| **Release flag** | Controls rollout of a new feature — decouples deploy from release | Off | Tech lead approval | 90 days from feature launch |
+| **Experiment flag** | A/B or multivariate test — measures impact of a change | Off (control group) | Product + tech lead | Duration of experiment + 30 days |
+| **Ops flag** | Operational control — circuit breaker, kill switch, throttle | On (normal behaviour) | On-call engineer can toggle | Indefinite (review annually) |
+| **Permission flag** | Gates access by user segment, tier, or region | Off (restricted) | Product + Account owner | Indefinite (review annually) |
+
+**When in doubt:** If the flag is temporary (tied to a specific feature launch), it is a Release flag. If it will exist forever as a control knob, it is an Ops flag.
+
+---
+
+## 2. Flag Naming Convention
+
+All flags must follow this naming scheme:
+
+```
+[type]-[service]-[feature-description]
+```
+
+| Segment | Values | Example |
+|---|---|---|
+| type | `release`, `exp`, `ops`, `perm` | `release` |
+| service | Short service identifier, lowercase, hyphenated | `payments` |
+| feature-description | Kebab-case description, max 5 words | `new-checkout-flow` |
+
+**Full examples:**
+- `release-payments-new-checkout-flow` — release flag for a new checkout feature in the payments service
+- `exp-search-personalized-ranking` — experiment on personalized search ranking
+- `ops-api-rate-limit-override` — operational flag to override API rate limits
+- `perm-dashboard-beta-users-only` — permission flag gating dashboard for beta users
+
+**Do not:**
+- Use ticket numbers in flag names (`release-JIRA-1234` → not searchable or self-describing)
+- Use dates in flag names (`release-dark-mode-jan-2024` → flags outlive their dates)
+- Use vague names (`release-new-thing` → not useful when you have 50 flags)
+
+---
+
+## 3. Flag Creation Checklist
+
+Complete every item before creating a flag in the production environment.
+
+**Before creating the flag:**
+- [ ] Flag type determined from taxonomy (Section 1)
+- [ ] Flag name follows naming convention (Section 2)
+- [ ] Flag owner assigned — one named engineer responsible for cleanup
+- [ ] Cleanup date set in the flag description field (for Release and Experiment flags)
+- [ ] Rollout strategy defined — see Section 4
+- [ ] Monitoring plan defined — see Section 5
+- [ ] Code review approved with flag guard in place
+
+**Flag description field (required):**
+```
+Type: [Release / Experiment / Ops / Permission]
+Owner: [Name]
+Linked ticket: [JIRA-XXXX or GitHub issue URL]
+Purpose: [One sentence — what this flag controls]
+Cleanup by: [Date — required for Release and Experiment flags; "Annual review" for Ops/Permission]
+Rollout plan: [Link to this document or inline summary]
+```
+
+**Code requirements:**
+```python
+# Good — behaviour is clear when flag is off, and cleanup is obvious
+if flag_client.is_enabled("release-[service]-[feature]", user_context):
+    return new_feature_handler(request)
+else:
+    return existing_handler(request)
+
+# Bad — nested flags, ternaries, and implicit defaults make cleanup error-prone
+result = new_handler() if (f1 and not f2) or f3 else old_handler()
+```
+
+---
+
+## 4. Rollout Strategy
+
+### Decision Tree
+
+Use this decision tree to pick the right rollout strategy for a Release or Experiment flag:
+
+```
+Is the change reversible without a deploy?
+├── No → Use an Ops flag with manual enable, not a percentage rollout
+└── Yes → Continue
+
+Is there a user-level identifier available (user ID, session ID)?
+├── No → Use server-side percentage (stateless, but inconsistent per user)
+└── Yes → Use user-based percentage (consistent experience per user) ← preferred
+
+Is the change risky (touches payments, auth, or data writes)?
+├── Yes → Start at 1% → 5% → 25% → 50% → 100%, with 24-hour holds
+└── No → Start at 10% → 50% → 100%, with 4-hour holds
+
+Does the change affect specific customer tiers or geographies?
+├── Yes → Use segment-based targeting, not percentage rollout
+└── No → Use percentage rollout
+```
+
+### Rollout Stages
+
+| Stage | Percentage | Hold duration | Pass criteria before advancing |
+|---|---|---|---|
+| Canary | 1% | 24 hours | Error rate within SLO, no P1 incidents |
+| Early rollout | 5–10% | 24 hours | Error rate and latency match control group |
+| Partial rollout | 25–50% | 24–48 hours | Business metrics not degraded vs. control |
+| Majority | 75% | 24 hours | Final check — no regressions |
+| Full rollout | 100% | 48 hours | Stable — schedule cleanup |
+
+**Do not skip stages for Release flags on production.** Speed of rollout is not worth a production incident.
+
+### Segment-Based Targeting
+
+Use segment targeting when the rollout must be restricted:
+
+```yaml
+# LaunchDarkly segment example — adapt for your platform
+targeting_rules:
+  - clause:
+      attribute: "subscription_tier"
+      operator: "in"
+      values: ["enterprise", "team"]
+    serve: "on"
+  - clause:
+      attribute: "country"
+      operator: "in"
+      values: ["US", "CA", "GB"]
+    serve: "on"
+  default: "off"
+```
+
+---
+
+## 5. Monitoring Requirements
+
+Every flag that is not at 0% or 100% rollout requires active monitoring. Do not roll out a flag and walk away.
+
+### Required Metrics Per Flag
+
+| Metric | What to compare | Alert threshold |
+|---|---|---|
+| Error rate | Flag-on cohort vs. flag-off cohort | >2× baseline error rate in flag-on group |
+| p99 latency | Flag-on vs. flag-off | >20% higher latency in flag-on group |
+| [Primary business metric] | Flag-on vs. flag-off | >5% degradation in flag-on group |
+| [Conversion / completion rate] | Flag-on vs. flag-off | >2% drop in flag-on group |
+
+**Setting up split metric monitoring in [LaunchDarkly / Split / Datadog]:**
+```
+1. Navigate to the flag → Metrics tab
+2. Add metric: [primary business metric]
+3. Add metric: error_rate (service-level)
+4. Add metric: p99_latency (endpoint-level)
+5. Set alert: notify [flag owner] in Slack #[team-channel] if metric degrades by [threshold]
+6. Set experiment duration: [N days] if this is an Experiment flag
+```
+
+### Guardrail Metrics
+
+These metrics must never degrade, regardless of what the primary metric shows. If a guardrail is breached, roll back immediately — do not wait for investigation.
+
+- Error rate exceeds SLO threshold ([X]%)
+- p99 latency exceeds SLO threshold ([Y] ms)
+- [Service-specific guardrail — e.g. payment failure rate, auth failure rate]
+
+**Immediate rollback command if guardrail is breached:**
+```bash
+# [LaunchDarkly CLI]
+ld-cli flag update [project-key] [flag-key] --default-variation off
+
+# [Split CLI]
+split-cli update-treatment [flag-name] --treatment "off" --percentage 100
+
+# [Unleash CLI / API]
+curl -X POST https://[unleash-host]/api/admin/features/[flag-name]/disable \
+  -H "Authorization: [admin-token]"
+
+# [Custom — adapt to your implementation]
+[command or dashboard step]
+```
+
+---
+
+## 6. Per-Flag Creation Template
+
+Copy this template into your flag's description field and the linked ticket when creating a new flag:
+
+```markdown
+## Flag: [flag-name]
+
+**Type:** [Release / Experiment / Ops / Permission]
+**Owner:** [Name] ([Slack handle])
+**Created:** [Date]
+**Cleanup by:** [Date]
+**Linked ticket:** [URL]
+
+### Purpose
+[One paragraph: what this flag controls, why it exists, what "on" and "off" mean]
+
+### Rollout Plan
+| Stage | Target | Date | Approved by |
+|---|---|---|---|
+| Canary | 1% | [Date] | [Name] |
+| Early | 10% | [Date] | [Name] |
+| Partial | 50% | [Date] | [Name] |
+| Full | 100% | [Date] | [Name] |
+
+### Monitoring
+- Primary metric: [metric name and dashboard link]
+- Guardrail metrics: error rate < [X]%, p99 < [Y] ms
+- Alert channel: #[team-channel]
+
+### Rollback Procedure
+[Exact steps to turn the flag off in an emergency — should take < 2 minutes]
+
+### Cleanup Checklist
+- [ ] Flag at 100% for 48+ hours with no incidents
+- [ ] Code path for flag-off branch removed from codebase
+- [ ] Flag deleted from [platform]
+- [ ] Ticket closed
+```
+
+---
+
+## 7. Emergency Kill-Switch Procedure
+
+When a flag needs to be disabled immediately due to a production incident:
+
+**Time target: flag disabled within 2 minutes of decision.**
+
+```
+1. Go to [platform URL] — bookmark this: [URL]
+2. Search for the flag by name: [flag-name]
+3. Set to 0% / "off" for ALL users
+4. Verify the service error rate drops within 60 seconds
+5. Post to #incidents:
+   "🟡 Feature flag [flag-name] disabled — rolling back [feature description].
+    Owner: [name]. Error rate before: [X]%. Monitoring for recovery."
+6. Page the flag owner if not already aware
+```
+
+**For ops flags (kill switches that must turn OFF normally-on behaviour):**
+```bash
+# These flags are "on" by default and turned "off" to disable a feature
+# Confirm the flag polarity before toggling — "off" may mean "disabled" or "enabled" depending on naming
+# Flag [flag-name]: OFF = [feature behaviour when off]
+[kill switch command for your platform]
+```
+
+---
+
+## 8. Stale Flag Policy and Cleanup
+
+Stale flags are flags that are at 100% rollout, have been at 100% for >48 hours, or are past their cleanup date. Stale flags are technical debt.
+
+### Stale Flag Definition
+
+A flag is stale if ANY of the following are true:
+- It is a Release flag past its cleanup date
+- It has been at 100% (or 0%) rollout for more than 30 days
+- Its linked ticket is closed and code cleanup has not happened
+- Its owner has left the team
+
+### Cleanup Checklist
+
+```
+[ ] Flag is at 100% rollout and has been stable for 48+ hours
+[ ] Monitoring shows no issues for the flag-on cohort
+[ ] Code changes:
+    [ ] Remove the flag check from application code
+    [ ] Remove the "off" code path entirely — do not leave dead code
+    [ ] Remove any flag-related tests that test the off behaviour
+    [ ] Update any documentation that references the flag
+[ ] PR merged and deployed to production
+[ ] Flag deleted from [platform] (do not just disable — delete)
+[ ] Cleanup ticket closed
+[ ] Flag owner confirms cleanup in Slack: "Flag [name] has been cleaned up — [commit link]"
+```
+
+**Automated stale flag detection:**
+```bash
+# Run weekly — flags past cleanup date or at 100% for > 30 days
+# [Platform-specific query — adapt:]
+
+# LaunchDarkly API
+curl -s "https://app.launchdarkly.com/api/v2/flags/[project-key]" \
+  -H "Authorization: [api-key]" | \
+  jq '.items[] | select(.creationDate < (now - 2592000) * 1000) | {key: .key, created: .creationDate}'
+
+# Notify #engineering-housekeeping with list of stale flags
+```
+
+### Stale Flag Escalation
+
+| Age past cleanup date | Action |
+|---|---|
+| 0–14 days | Slack reminder to flag owner |
+| 14–30 days | Slack reminder to flag owner + tech lead |
+| 30+ days | Tech lead assigns cleanup, creates ticket with P2 priority |
+| 60+ days | Engineering manager reviews — flag may be force-deleted |
+
+---
+
+## 9. Governance
+
+### Who Can Do What
+
+| Action | Who | Approval required |
+|---|---|---|
+| Create a flag (any environment) | Any engineer | None — but must complete creation checklist |
+| Enable a flag in development | Any engineer | None |
+| Enable a flag in staging | Any engineer | None |
+| Enable a flag in production (0–10%) | Flag owner | Tech lead awareness |
+| Advance rollout in production (10–100%) | Flag owner | Tech lead sign-off per stage |
+| Enable an Ops flag in production | On-call engineer | None — these are break-glass controls |
+| Delete a flag | Flag owner | Tech lead confirmation that code cleanup is done |
+| Create a Permission flag | Flag owner | Product manager approval |
+
+### Audit Logging
+
+All flag changes in production must be traceable. Ensure the following are configured in [platform]:
+
+- **Change log:** Every production flag change logs: who changed it, what they changed, and when.
+- **Slack notifications:** Production flag changes post to `#[team]-flag-changes` automatically.
+- **Quarterly review:** Every quarter, the tech lead reviews the full flag inventory, confirms owners are current, and removes flags with no owner.
+
+---
+
+## Quality Checks
+
+- [ ] Every flag has an owner named in its description — no orphan flags
+- [ ] Release and Experiment flags have a cleanup date set — not open-ended
+- [ ] Monitoring is configured for every flag currently between 1–99% rollout
+- [ ] The emergency kill-switch procedure has been tested — on-call engineers have bookmarked the platform URL and know the steps
+- [ ] Stale flag detection runs automatically and results are reviewed weekly
+- [ ] Code review checklist includes: "Does this PR introduce a flag? If yes, is the creation checklist complete?"
+- [ ] At least one person other than the flag owner knows how to disable any given flag in an emergency
@@ -0,0 +1,292 @@
+---
+name: infra-as-code-review
+description: "Write an infrastructure-as-code review checklist and conduct a structured review of Terraform, CloudFormation, Pulumi, or Ansible code. Use when asked to review IaC code, audit infrastructure configurations, check cloud security posture, or produce a reusable IaC review checklist. Produces a structured review report with severity-categorized findings, remediation guidance, and a reusable checklist."
+---
+
+# Infrastructure-as-Code Review
+
+Produce a structured infrastructure-as-code review that applies security, reliability, and operational quality standards to a specific body of IaC code. The output serves two purposes: an actionable review report for the code at hand (with findings by severity and specific remediation steps), and a reusable checklist the team can apply to every future IaC change. If the user provides actual code, analyze it and populate the findings table with real issues. If no code is provided, produce the checklist and a template findings report.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **IaC tool** — Terraform, CloudFormation, Pulumi, Ansible, or CDK
+- **Cloud provider** — AWS, GCP, Azure, or multi-cloud
+- **What the code provisions** — a brief description (e.g., "VPC, EKS cluster, and RDS instance for the payments service")
+- **Security policies or naming standards in use** — any existing org standards to check against; if none, use sensible defaults
+- **The IaC code itself** — paste or describe it; if not provided, produce the checklist template only and note findings require code
+
+## Output Format
+
+---
+
+# IaC Review Report: [What Is Being Provisioned]
+
+**Reviewer:** [Name / Claude]
+**IaC Tool:** [Terraform / CloudFormation / Pulumi / Ansible / CDK]
+**Cloud Provider:** [AWS / GCP / Azure]
+**Code Location:** [Repo path or PR link]
+**Review Date:** [Date]
+**Overall Risk:** [Critical / High / Medium / Low]
+
+---
+
+## Executive Summary
+
+| Severity | Finding Count | Resolved in This Review | Carry-Over Risk |
+|----------|---------------|------------------------|-----------------|
+| Critical | [n] | [n] | [Yes/No — explain] |
+| High | [n] | [n] | [Yes/No — explain] |
+| Medium | [n] | [n] | [Yes/No — explain] |
+| Low | [n] | [n] | [Yes/No — explain] |
+| **Total** | **[n]** | **[n]** | |
+
+**Recommendation:** [Approve / Approve with Required Changes / Block — one sentence rationale]
+
+---
+
+## Findings
+
+### Critical Findings
+
+#### CRIT-01: [Finding Title]
+
+| Field | Detail |
+|-------|--------|
+| **Severity** | Critical |
+| **Category** | [IAM / Secrets / Encryption / Network / State / Naming / Cost] |
+| **Resource** | `[resource_type.resource_name]` |
+| **File / Line** | `[path/to/file.tf:42]` |
+| **Risk** | [What can go wrong — be specific about the attack vector or failure mode] |
+
+**Current code:**
+```hcl
+# [paste the problematic snippet]
+resource "aws_s3_bucket" "data" {
+  bucket = "my-bucket"
+  acl    = "public-read"   # PROBLEM: public read access
+}
+```
+
+**Remediation:**
+```hcl
+resource "aws_s3_bucket" "data" {
+  bucket = "my-bucket"
+}
+
+resource "aws_s3_bucket_public_access_block" "data" {
+  bucket                  = aws_s3_bucket.data.id
+  block_public_acls       = true
+  block_public_policy     = true
+  ignore_public_acls      = true
+  restrict_public_buckets = true
+}
+```
+
+**Why this matters:** [One sentence linking the specific risk to business impact — data exposure, compliance violation, etc.]
+
+---
+
+#### CRIT-02: [Next Critical Finding — repeat structure]
+
+---
+
+### High Findings
+
+#### HIGH-01: [Finding Title]
+
+| Field | Detail |
+|-------|--------|
+| **Severity** | High |
+| **Category** | [Category] |
+| **Resource** | `[resource_type.resource_name]` |
+| **File / Line** | `[path/to/file.tf:line]` |
+| **Risk** | [Specific risk description] |
+
+**Current code:**
+```hcl
+# [problematic snippet]
+```
+
+**Remediation:**
+```hcl
+# [fixed snippet]
+```
+
+---
+
+### Medium Findings
+
+#### MED-01: [Finding Title]
+
+| Field | Detail |
+|-------|--------|
+| **Severity** | Medium |
+| **Category** | [Category] |
+| **Resource** | `[resource_type.resource_name]` |
+| **File / Line** | `[path/to/file.tf:line]` |
+| **Risk** | [Specific risk description] |
+
+**Remediation:** [Prose or code snippet — choose whichever is clearer for this finding]
+
+---
+
+### Low Findings
+
+#### LOW-01: [Finding Title]
+
+| Field | Detail |
+|-------|--------|
+| **Severity** | Low |
+| **Category** | [Category] |
+| **Resource** | `[resource_type.resource_name]` |
+| **File / Line** | `[path/to/file.tf:line]` |
+| **Suggestion** | [What to improve and why] |
+
+---
+
+## Reusable IaC Review Checklist
+
+Use this checklist on every IaC pull request. Check every item; mark N/A only when the item genuinely does not apply to the resources being provisioned.
+
+### 1. IAM and Access Control
+
+- [ ] No wildcard actions (`"*"`) in IAM policies — policies follow least-privilege
+- [ ] No wildcard resource (`"*"`) in IAM policies unless explicitly justified with a comment
+- [ ] IAM roles use condition keys to restrict scope (e.g., `aws:RequestedRegion`, `sts:ExternalId`)
+- [ ] No IAM access keys or credentials hardcoded or in plaintext variables
+- [ ] EC2 / compute instances use instance profiles, not hardcoded credentials
+- [ ] S3 bucket policies do not allow public access unless the bucket is explicitly a public asset bucket
+- [ ] Cross-account trust policies name specific account IDs, not `"*"`
+- [ ] Service accounts (GCP) / managed identities (Azure) follow naming conventions and have documented purpose
+
+### 2. Secrets Management
+
+- [ ] No secrets, passwords, tokens, or API keys in plaintext in any `.tf`, `.yaml`, or `.json` file
+- [ ] No secrets in variable default values
+- [ ] Secrets sourced from Secrets Manager / Parameter Store / Vault — not from environment variables passed at plan time
+- [ ] `sensitive = true` is set on all output values and variables that contain secrets (Terraform)
+- [ ] State backend is encrypted — no unencrypted state files contain sensitive data
+- [ ] `.gitignore` or equivalent excludes `*.tfvars`, `terraform.tfstate`, and any file that may contain resolved secrets
+
+### 3. Encryption at Rest
+
+- [ ] Storage resources (S3, EBS, RDS, DynamoDB, GCS, Azure Blob) have encryption at rest enabled
+- [ ] Customer-managed keys (CMK/KMS) are used where required by policy — not solely AWS/GCP/Azure managed keys
+- [ ] KMS key rotation is enabled for all CMKs
+- [ ] Database snapshots have encryption enabled
+- [ ] Encryption is not disabled via `encrypted = false` or equivalent
+
+### 4. Encryption in Transit
+
+- [ ] Load balancers terminate TLS — HTTP-only listeners redirect to HTTPS or are absent
+- [ ] Minimum TLS version is 1.2; TLS 1.0 and 1.1 are explicitly disabled
+- [ ] RDS / database connections require SSL (`require_ssl = true` or equivalent parameter)
+- [ ] Internal service-to-service calls use TLS where the network is not fully private
+- [ ] S3 bucket policies include a `Deny` on non-TLS requests (`aws:SecureTransport: false`)
+
+### 5. Network and Public Access
+
+- [ ] Security groups / firewall rules do not permit `0.0.0.0/0` ingress except on ports 80/443 for public-facing services
+- [ ] SSH (port 22) and RDP (port 3389) are not open to `0.0.0.0/0`
+- [ ] Databases are in private subnets — not directly internet-routable
+- [ ] `publicly_accessible = false` on RDS instances unless explicitly required and documented
+- [ ] VPC has flow logs enabled
+- [ ] Network ACLs and security groups are layered (defense in depth)
+- [ ] S3 bucket public access block is enabled at the account and bucket level
+
+### 6. Logging, Monitoring, and Audit
+
+- [ ] CloudTrail / Cloud Audit Logs / Azure Monitor is enabled across all regions
+- [ ] S3 access logging is enabled on buckets containing sensitive or regulated data
+- [ ] RDS enhanced monitoring or equivalent is enabled
+- [ ] CloudWatch alarms or equivalent are defined for critical metrics (CPU, disk, error rate)
+- [ ] Log retention periods are defined — logs not retained indefinitely or deleted within 7 days
+
+### 7. Naming and Tagging Standards
+
+- [ ] All resources follow the team's naming convention: `[env]-[team]-[resource-type]-[identifier]`
+- [ ] Required tags are present on all taggable resources:
+  - [ ] `Environment` (e.g., prod / staging / dev)
+  - [ ] `Team` or `Owner`
+  - [ ] `Service` or `Application`
+  - [ ] `CostCenter` (if required by finance policy)
+  - [ ] `ManagedBy: terraform` (or equivalent IaC tool tag)
+- [ ] No resources with default names (e.g., `default-vpc`, `launch-wizard-1`)
+
+### 8. State Management and Backend
+
+- [ ] Remote state backend is configured — no local state in repository
+- [ ] State backend uses locking (DynamoDB for S3 backend, etc.)
+- [ ] State backend bucket/storage has versioning enabled
+- [ ] State backend bucket/storage has access logging enabled
+- [ ] Workspaces or separate state files are used per environment — no shared state between prod and non-prod
+- [ ] `terraform.tfstate` and `*.tfstate.backup` are in `.gitignore`
+
+### 9. Module and Resource Structure
+
+- [ ] Modules are versioned with explicit version pins — no floating `source = "git::...?ref=main"`
+- [ ] Provider versions are pinned in `required_providers` — no unconstrained `>= x.y`
+- [ ] Terraform version is pinned in `required_version`
+- [ ] Modules have a clear single responsibility — not one module that provisions everything
+- [ ] No copy-paste duplication — repeated patterns use modules or loops (`for_each`, `count`)
+- [ ] Outputs expose only what downstream consumers need — no unnecessary output sprawl
+
+### 10. Environment Parity
+
+- [ ] Prod and non-prod environments use the same module code, parameterized by environment variable
+- [ ] Instance sizes and replica counts differ by environment via variables — not by separate code branches
+- [ ] Non-prod does not have security controls disabled "to save money" (encryption off, logging off)
+
+### 11. Cost Impact
+
+- [ ] Large instance types (e.g., `r5.16xlarge`) or storage allocations are justified in a comment
+- [ ] Data transfer costs are considered for cross-region or cross-AZ architectures
+- [ ] Reserved instance or committed use discount eligibility is noted for long-lived resources
+- [ ] Auto-scaling is configured for variable workloads — no fixed oversized fleets for spiky traffic
+- [ ] Lifecycle policies are set on S3 buckets storing time-bounded data (logs, backups)
+
+### 12. Drift Risk
+
+- [ ] No resources that are commonly mutated in the console are managed by IaC without import documentation
+- [ ] `lifecycle { prevent_destroy = true }` is set on stateful resources in production (databases, state buckets)
+- [ ] `ignore_changes` is used sparingly and each instance is documented with a rationale comment
+- [ ] A plan is run against the live environment as part of the PR process — no unreviewed drift
+
+---
+
+## Findings Summary Table
+
+| ID | Title | Severity | Category | File | Status |
+|----|-------|----------|----------|------|--------|
+| CRIT-01 | [Title] | Critical | [Category] | [file:line] | Open |
+| HIGH-01 | [Title] | High | [Category] | [file:line] | Open |
+| MED-01 | [Title] | Medium | [Category] | [file:line] | Open |
+| LOW-01 | [Title] | Low | [Category] | [file:line] | Open |
+
+---
+
+## Required Actions Before Merge
+
+List only Critical and High findings that must be resolved before this code is merged:
+
+1. **CRIT-01 [Title]** — [One-line remediation instruction]
+2. **HIGH-01 [Title]** — [One-line remediation instruction]
+
+Medium and Low findings should be tracked as follow-up issues with a committed resolution date.
+
+---
+
+*Review conducted by [Reviewer] on [Date] — checklist version [1.0]*
+
+---
+
+## Quality Checks
+
+- [ ] Every finding includes: severity, category, specific resource name, file and line number, current code, and fixed code
+- [ ] Checklist covers all 12 categories: IAM, Secrets, Encryption at Rest, Encryption in Transit, Network, Logging, Naming/Tagging, State, Module Structure, Environment Parity, Cost, and Drift
+- [ ] Executive summary table is filled with real counts — not all zeros or all placeholders
+- [ ] "Required Actions Before Merge" section lists only Critical and High items
+- [ ] Code snippets in findings show both the problematic code AND the corrected version
+- [ ] Overall risk rating is justified by the highest-severity open finding
+- [ ] Checklist items are binary (checkable) — not narrative observations
@@ -0,0 +1,432 @@
+---
+name: load-testing-plan
+description: "Write a load and performance testing plan for a service. Use when asked to create a performance test plan, write load testing documentation, define stress or soak test scenarios, or set performance regression gates for CI. Produces a complete test plan document with scenario definitions, k6/Locust script skeleton, threshold table, result interpretation guide, and CI integration steps."
+---
+
+# Load Testing Plan Skill
+
+Produce a complete load and performance testing plan for a service — covering test objectives, scenario definitions, tooling configuration, success thresholds, and CI integration. A good load testing plan eliminates ambiguity about what "performance is acceptable" means, so engineers can run tests and get a pass/fail answer without having to interpret raw numbers themselves.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name and key endpoints** — which endpoints are under test (path, method, typical request/response shape)
+- **Current traffic baseline** — current requests/sec, p50/p99 latency, error rate under normal load
+- **Peak traffic expectations** — expected peak RPS (e.g. 10× baseline for flash sales, or seasonality peak)
+- **SLO targets** — latency SLOs (p99 < X ms), error rate SLO (< Y%), availability target
+- **Preferred testing tool** — k6, Locust, JMeter, Gatling, or no preference
+- **Test environment availability** — dedicated load test environment, staging, or production (with traffic shaping)
+
+## Output Format
+
+---
+
+# Load Testing Plan: [Service Name]
+
+**Author:** [Name] | **Team:** [Team name]
+**Date:** [Date] | **Review cycle:** Before each major release and quarterly
+**Testing tool:** [k6 / Locust / JMeter / Gatling]
+**Test environment:** [Environment name and URL]
+
+---
+
+## 1. Objectives and Scope
+
+**What we are testing:** [Service name] handles [describe function — e.g. "user authentication requests from the mobile and web clients"]. This plan validates that the service meets its SLOs under expected and elevated traffic conditions.
+
+**In scope:**
+- [Endpoint 1: METHOD /path — description]
+- [Endpoint 2: METHOD /path — description]
+- [Endpoint 3: METHOD /path — description]
+
+**Out of scope:**
+- [Any endpoints explicitly excluded and why — e.g. "admin APIs — low traffic, excluded from load test"]
+- [Third-party integrations that cannot be load-tested — mock them instead]
+
+---
+
+## 2. Performance Targets (Success Criteria)
+
+Every scenario has explicit pass/fail thresholds. A test run FAILS if any threshold is breached.
+
+| Metric | Baseline scenario | Stress scenario | Spike scenario | Soak scenario |
+|---|---|---|---|---|
+| p50 latency | < [X] ms | < [X × 1.5] ms | < [X × 2] ms | < [X] ms |
+| p95 latency | < [Y] ms | < [Y × 1.5] ms | < [Y × 2] ms | < [Y] ms |
+| p99 latency | < [Z] ms | < [Z × 2] ms | < [Z × 3] ms | < [Z] ms |
+| Error rate | < [0.1]% | < [1]% | < [2]% | < [0.1]% |
+| Throughput | ≥ [N] RPS | ≥ [N × 3] RPS | N/A | ≥ [N] RPS |
+| Failed requests | 0 (5xx) | < [threshold] | < [threshold] | 0 (5xx) |
+
+**SLO reference:** These thresholds are derived from the service SLOs — p99 < [Z ms], error rate < [0.1]%, availability [99.9]%.
+
+---
+
+## 3. Traffic Model
+
+**Baseline traffic (current production):**
+- Average RPS: [N] req/sec
+- Peak RPS (observed): [N] req/sec
+- Request distribution by endpoint:
+  - [Endpoint 1]: [X]% of traffic
+  - [Endpoint 2]: [Y]% of traffic
+  - [Endpoint 3]: [Z]% of traffic
+
+**Simulated user behaviour:**
+- Think time between requests: [X–Y] seconds (randomised)
+- Session duration: [N] minutes average
+- Authenticated vs anonymous ratio: [X]%/[Y]%
+- Geographic distribution: [Region 1 X]%, [Region 2 Y]%
+
+---
+
+## 4. Test Scenarios
+
+### Scenario 1: Baseline (Steady-State)
+
+**Purpose:** Confirm the service performs acceptably under normal production load.
+**Duration:** 10 minutes
+**Load profile:** Ramp to [N] RPS over 2 minutes, hold for 8 minutes.
+**Concurrency:** [N] virtual users
+
+**Pass criteria:** All thresholds in the Baseline column of the targets table above.
+
+---
+
+### Scenario 2: Stress Test
+
+**Purpose:** Find the breaking point — how much load can the service handle before SLOs are breached?
+**Duration:** 20–30 minutes
+**Load profile:** Ramp from [N] RPS (baseline) to [N × 5] RPS in 5-minute steps. Hold each step for 5 minutes. Stop at first SLO breach.
+**Concurrency:** Scales with RPS target
+
+**What to record:**
+- RPS at which p99 latency first exceeds SLO
+- RPS at which error rate first exceeds SLO
+- Whether the service recovers when load drops back to baseline
+
+---
+
+### Scenario 3: Spike Test
+
+**Purpose:** Simulate a sudden traffic surge (flash sale, viral event, bot attack).
+**Duration:** 15 minutes
+**Load profile:** Hold at [N] RPS (baseline) for 3 minutes, spike to [N × 10] RPS instantly, hold for 5 minutes, drop back to baseline for 7 minutes.
+
+**What to record:**
+- Latency during spike and recovery
+- Whether the service sheds load gracefully (rate limiting, queue depth)
+- Time to recover to baseline latency after spike ends
+
+---
+
+### Scenario 4: Soak / Endurance Test
+
+**Purpose:** Detect memory leaks, connection pool exhaustion, and slow degradation over time.
+**Duration:** 4–8 hours (run overnight)
+**Load profile:** Steady [N × 1.5] RPS (50% above baseline) for entire duration.
+
+**What to watch:**
+- Memory usage trend over time (should not grow unboundedly)
+- Error rate trend (should be flat, not creeping up)
+- GC pause frequency (JVM/Go services)
+- Database connection pool utilisation
+- p99 latency trend (should not creep up over hours)
+
+---
+
+## 5. Test Environment Requirements
+
+### Infrastructure
+
+| Component | Requirement | Notes |
+|---|---|---|
+| Service under test | Isolated from production | [N] replicas, matching prod resource limits |
+| Database | Separate instance with production-scale data | Seed script in section 7 |
+| Cache (Redis/Memcached) | Empty at test start | Ensures cold-start conditions are tested |
+| Load generator | Separate from service under test | [N] vCPUs, [N] GB RAM minimum |
+| Network | Low-latency path to service | Do not run generator on same host |
+
+### Data Seeding
+
+Before every test run, ensure the environment has:
+```bash
+# Seed test users (needed for authenticated endpoint tests)
+[seed command or script path — e.g. python scripts/seed_load_test_users.py --count 10000]
+
+# Seed test data for read endpoints
+[seed command — e.g. ./scripts/seed_products.sh --count 50000]
+
+# Verify seed completed
+[verification command — e.g. psql $DB_URL -c "SELECT COUNT(*) FROM users WHERE load_test=true"]
+```
+
+**Test data rules:**
+- Never use real production user data in load tests
+- Tag all test-generated records with `load_test=true` for easy cleanup
+- Run cleanup after each test: `[cleanup command]`
+
+---
+
+## 6. Tooling Setup
+
+### k6 Script Skeleton
+
+```javascript
+import http from 'k6/http';
+import { check, sleep } from 'k6';
+import { Rate, Trend } from 'k6/metrics';
+
+// Custom metrics
+const errorRate = new Rate('error_rate');
+const endpointLatency = new Trend('endpoint_latency', true);
+
+// Test configuration — override per scenario
+export const options = {
+  scenarios: {
+    baseline: {
+      executor: 'ramping-vus',
+      startVUs: 0,
+      stages: [
+        { duration: '2m', target: [BASELINE_VUS] },
+        { duration: '8m', target: [BASELINE_VUS] },
+        { duration: '1m', target: 0 },
+      ],
+    },
+  },
+  thresholds: {
+    http_req_duration: [
+      'p(95)<[Y_MS]',
+      'p(99)<[Z_MS]',
+    ],
+    error_rate: ['rate<0.01'],
+    http_req_failed: ['rate<0.01'],
+  },
+};
+
+// Auth helper — get token once per VU
+export function setup() {
+  const loginRes = http.post('[BASE_URL]/auth/login', JSON.stringify({
+    username: `load_test_user_${Math.floor(Math.random() * 10000)}@example.com`,
+    password: '[LOAD_TEST_PASSWORD]',
+  }), { headers: { 'Content-Type': 'application/json' } });
+
+  check(loginRes, { 'login ok': (r) => r.status === 200 });
+  return { token: loginRes.json('access_token') };
+}
+
+export default function (data) {
+  const headers = {
+    Authorization: `Bearer ${data.token}`,
+    'Content-Type': 'application/json',
+  };
+
+  // Endpoint 1: [Description]
+  const res1 = http.get('[BASE_URL]/[endpoint-1]', { headers });
+  check(res1, {
+    '[endpoint-1] status 200': (r) => r.status === 200,
+    '[endpoint-1] latency < [X]ms': (r) => r.timings.duration < [X],
+  });
+  errorRate.add(res1.status >= 400);
+  endpointLatency.add(res1.timings.duration, { endpoint: '[endpoint-1]' });
+
+  sleep(Math.random() * [THINK_TIME_MAX] + [THINK_TIME_MIN]);
+
+  // Endpoint 2: [Description]
+  const res2 = http.post('[BASE_URL]/[endpoint-2]',
+    JSON.stringify({ [key]: '[value]' }),
+    { headers }
+  );
+  check(res2, {
+    '[endpoint-2] status 201': (r) => r.status === 201,
+  });
+  errorRate.add(res2.status >= 400);
+}
+```
+
+### Locust Script Skeleton (alternative)
+
+```python
+from locust import HttpUser, task, between
+import random
+
+class [ServiceName]User(HttpUser):
+    wait_time = between([THINK_TIME_MIN], [THINK_TIME_MAX])
+    token = None
+
+    def on_start(self):
+        """Called once per simulated user — authenticate."""
+        user_id = random.randint(1, 10000)
+        response = self.client.post("/auth/login", json={
+            "username": f"load_test_user_{user_id}@example.com",
+            "password": "[LOAD_TEST_PASSWORD]",
+        })
+        self.token = response.json()["access_token"]
+        self.headers = {"Authorization": f"Bearer {self.token}"}
+
+    @task([WEIGHT_1])  # Weight = relative frequency
+    def [endpoint_1_task](self):
+        """[Endpoint 1 description]"""
+        with self.client.get(
+            "/[endpoint-1]",
+            headers=self.headers,
+            catch_response=True
+        ) as response:
+            if response.elapsed.total_seconds() > [LATENCY_THRESHOLD]:
+                response.failure(f"Too slow: {response.elapsed.total_seconds()}s")
+
+    @task([WEIGHT_2])
+    def [endpoint_2_task](self):
+        """[Endpoint 2 description]"""
+        self.client.post(
+            "/[endpoint-2]",
+            json={"[key]": "[value]"},
+            headers=self.headers,
+        )
+```
+
+### Running Tests
+
+```bash
+# k6 — run baseline scenario
+k6 run --env BASE_URL=https://[test-env-url] scripts/load_test.js
+
+# k6 — run stress scenario with output to InfluxDB
+k6 run --out influxdb=http://[influxdb-host]:8086/k6 \
+  --env SCENARIO=stress \
+  scripts/load_test.js
+
+# Locust — headless run
+locust -f locustfile.py \
+  --headless \
+  --users [N] \
+  --spawn-rate [N] \
+  --run-time 10m \
+  --host https://[test-env-url] \
+  --csv=results/[run-id]
+
+# Locust — web UI (interactive)
+locust -f locustfile.py --host https://[test-env-url]
+```
+
+---
+
+## 7. Metrics to Capture
+
+Capture all of the following during every test run. Missing any of these makes result comparison unreliable.
+
+| Metric | Source | Why it matters |
+|---|---|---|
+| p50, p95, p99, p999 latency per endpoint | Load tool | SLO validation |
+| Error rate (4xx, 5xx) per endpoint | Load tool | SLO validation |
+| Requests/sec (throughput) | Load tool | Capacity baseline |
+| CPU utilisation (%) | Infra monitoring | Saturation signal |
+| Memory utilisation (%) | Infra monitoring | Leak detection |
+| GC pause time / frequency | JVM/Go metrics | Latency spike root cause |
+| DB connection pool: active/idle/waiting | DB metrics | Pool exhaustion detection |
+| DB query latency (p99) | DB metrics | Downstream bottleneck |
+| Cache hit rate | Cache metrics | Miss storm detection |
+| Pod/instance count (if autoscaling) | Infra | Scaling behaviour |
+| Network in/out bytes | Infra | Bandwidth saturation |
+
+---
+
+## 8. Result Analysis Framework
+
+After each test run, work through this analysis in order:
+
+**Step 1 — Pass/fail check**
+Compare all captured metrics against the thresholds in Section 2. Record pass/fail per scenario.
+
+**Step 2 — Latency distribution**
+Plot the full latency histogram, not just percentiles. A bimodal distribution (two humps) indicates two distinct code paths — investigate the slow hump.
+
+**Step 3 — Error correlation**
+If errors occurred, correlate them with:
+- Time of occurrence (was it during ramp-up, steady state, or spike?)
+- Specific endpoint (is it one endpoint or all?)
+- Infrastructure events (CPU spike, OOM, DB connection exhaustion?)
+
+**Step 4 — Saturation analysis**
+Graph CPU, memory, and connection pool over time. If any resource reached 80%+ of capacity, it is a candidate bottleneck — even if SLOs passed this run.
+
+**Step 5 — Compare to baseline run**
+Every run should be compared to the previous run. A 10% regression in p99 latency warrants investigation even if it is still within SLO.
+
+**Regression classification:**
+
+| Change | Classification | Action |
+|---|---|---|
+| p99 within 5% of previous run | Green — no regression | No action |
+| p99 5–15% worse than previous | Yellow — watch | Investigate before next release |
+| p99 >15% worse than previous | Red — regression | Block release, file ticket |
+| Error rate increased vs previous | Red — regression | Block release |
+| SLO threshold breached | Critical | Block release, page on-call |
+
+---
+
+## 9. CI Integration
+
+Add load tests as a gated step in the release pipeline. Run the baseline scenario on every release candidate; run all scenarios weekly.
+
+```yaml
+# Example: GitHub Actions step (adapt for your CI platform)
+load-test:
+  runs-on: ubuntu-latest
+  needs: [deploy-staging]
+  if: github.ref == 'refs/heads/main'
+  steps:
+    - uses: actions/checkout@v3
+
+    - name: Install k6
+      run: |
+        curl -s https://dl.k6.io/key.gpg | sudo apt-key add -
+        echo "deb https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
+        sudo apt-get update && sudo apt-get install k6
+
+    - name: Seed test data
+      run: [seed command]
+
+    - name: Run baseline load test
+      run: |
+        k6 run \
+          --env BASE_URL=${{ secrets.LOAD_TEST_ENV_URL }} \
+          --out json=results.json \
+          scripts/load_test.js
+      env:
+        LOAD_TEST_ENV_URL: ${{ secrets.LOAD_TEST_ENV_URL }}
+
+    - name: Check thresholds
+      run: |
+        # k6 exits with non-zero if any threshold fails — this step fails the build
+        echo "k6 threshold check complete"
+
+    - name: Upload results
+      uses: actions/upload-artifact@v3
+      if: always()
+      with:
+        name: load-test-results-${{ github.run_id }}
+        path: results.json
+
+    - name: Cleanup test data
+      if: always()
+      run: [cleanup command]
+```
+
+**CI gates summary:**
+- Baseline scenario runs on every release to staging
+- Full scenario suite (stress, spike, soak) runs weekly on a schedule
+- Any threshold failure blocks promotion to production
+- Results are archived for trend analysis
+
+---
+
+## Quality Checks
+
+- [ ] All key endpoints are covered by at least one test scenario — no production endpoint is untested
+- [ ] Thresholds are derived from actual SLO targets, not guesses
+- [ ] Test data seeding is scripted and reproducible — tests do not rely on pre-existing environment state
+- [ ] The load generator runs on separate infrastructure from the service under test
+- [ ] CI integration blocks promotion on threshold failure — not just records results
+- [ ] Soak test has been run at least once to establish a memory and connection pool baseline
+- [ ] Results comparison to previous run is part of the analysis — not just absolute pass/fail
@@ -0,0 +1,484 @@
+---
+name: local-dev-setup
+description: "Write a local development environment setup guide for a service or project — covering prerequisites, repository setup, environment variables, local service dependencies, database seeding, running the service, running tests, common gotchas, IDE recommendations, and first-contribution checklist. Use when asked to write a dev setup guide, create onboarding documentation for engineers, document local environment setup, or write a getting-started guide for a codebase. Produces a complete setup guide that a new engineer can follow from zero to running tests in under 30 minutes, with a troubleshooting section for the most common setup failures."
+---
+
+# Local Dev Setup Skill
+
+Produce a complete local development environment setup guide for a service or project — walking a new engineer from zero (a clean laptop) to a working local environment with passing tests in under 30 minutes. A good setup guide reduces onboarding time, prevents the "it works on my machine" problem, and lets engineers make their first contribution with confidence. Write every step as a concrete command or action — not a description of what needs to happen.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and what it does
+- **Tech stack** — language, framework, database, cache, message queue, and any external services
+- **Dependencies** — databases, caches, message queues, and external services (mocked or real)
+- **Test framework** — how tests are run and what the test suite covers
+- **CI/CD platform** — GitHub Actions, CircleCI, Jenkins, etc. (for context on what "passing CI" means locally)
+
+## Output Format
+
+---
+
+# Local Development Setup: [Service Name]
+
+**Tech stack:** [Language + version] | [Framework] | [Database] | [Cache]
+**Estimated setup time:** [20–30 minutes] on a clean machine
+**Last verified:** [Date] on [macOS Ventura 13.x / Ubuntu 22.04]
+**Questions?** Ask in [Slack: #[team-channel]] or ping [@tech-lead-handle]
+
+> **First contribution?** Complete setup first (this doc), then read [CONTRIBUTING.md] for code standards and PR process.
+
+---
+
+## Prerequisites
+
+Install these tools before starting. The versions listed are the minimum required — newer patch versions are fine, newer major versions may have compatibility issues.
+
+### Required Tools
+
+| Tool | Required version | Install |
+|---|---|---|
+| [Git] | 2.x+ | Pre-installed on most systems; or `brew install git` |
+| [Language runtime — e.g. Go] | [1.22+] | [https://go.dev/dl/ or `brew install go`] |
+| [Docker] | 24.x+ | [https://docs.docker.com/get-docker/] |
+| [Docker Compose] | 2.x+ | Included with Docker Desktop; or `brew install docker-compose` |
+| [Make] | Any | Pre-installed on macOS/Linux |
+| [Tool — e.g. Node.js] | [20.x+] | [`brew install node` or https://nodejs.org] |
+| [Tool — e.g. psql client] | [15+] | `brew install postgresql@15` (client only) |
+
+### Optional but Recommended
+
+| Tool | Purpose | Install |
+|---|---|---|
+| [direnv] | Auto-load `.envrc` environment variables | `brew install direnv` + [setup instructions](https://direnv.net) |
+| [jq] | Pretty-print JSON in terminal | `brew install jq` |
+| [k9s] | Kubernetes cluster UI (if using K8s locally) | `brew install k9s` |
+| [mkcert] | Local HTTPS certificates | `brew install mkcert` |
+
+### Required Accounts and Access
+
+Before starting, make sure you have:
+- [ ] GitHub access to [org/repo] — request via [access request process / Slack: #it-help]
+- [ ] [AWS / GCP / Azure] account with [dev environment] access — request via [process]
+- [ ] [Internal tool — e.g. 1Password] for retrieving development secrets — request via [process]
+- [ ] [VPN access] if required to reach internal services — request via [process]
+
+---
+
+## 1. Repository Setup
+
+```bash
+# Clone the repository
+git clone git@github.com:[org]/[repo-name].git
+cd [repo-name]
+
+# Install git hooks (required — enforces commit message format and runs pre-commit checks)
+make install-hooks
+# Or manually:
+# cp scripts/hooks/pre-commit .git/hooks/pre-commit && chmod +x .git/hooks/pre-commit
+
+# Verify your git setup
+git config user.name   # should be your name
+git config user.email  # should be your work email
+```
+
+**If you see a permission denied error on clone:** Your SSH key is not added to GitHub. Follow [GitHub's SSH key guide](https://docs.github.com/en/authentication/connecting-to-github-with-ssh) or use HTTPS with a personal access token instead.
+
+---
+
+## 2. Environment Variables
+
+The service requires environment variables for configuration. **Never commit actual secrets to the repository.**
+
+### Step 1 — Copy the example file
+
+```bash
+cp .env.example .env.local
+```
+
+### Step 2 — Fill in the values
+
+Open `.env.local` in your editor. Below is a description of every variable and where to get its value:
+
+| Variable | Description | Where to get it | Example (not real) |
+|---|---|---|---|
+| `APP_ENV` | Environment name | Set to `development` | `development` |
+| `APP_PORT` | Port the service listens on | Set to `8080` for local | `8080` |
+| `DATABASE_URL` | PostgreSQL connection string | Use value from Docker Compose (Section 3) | `postgres://app:password@localhost:5432/[service]_dev` |
+| `REDIS_URL` | Redis connection string | Use value from Docker Compose | `redis://localhost:6379` |
+| `SECRET_KEY` | Application secret key | Generate with: `openssl rand -hex 32` | `[random 64-char hex]` |
+| `[EXTERNAL_SERVICE]_API_KEY` | API key for [External Service] | Retrieve from [1Password vault: "Dev API Keys"] or ask [name] | — |
+| `[EXTERNAL_SERVICE]_BASE_URL` | Base URL for [External Service] | Use sandbox URL: `https://sandbox.[external-service].com` | `https://sandbox.stripe.com` |
+| `LOG_LEVEL` | Logging verbosity | Set to `debug` for local development | `debug` |
+| `[FEATURE_FLAG_SDK_KEY]` | Feature flag platform SDK key | Retrieve from [LaunchDarkly/Split dev project] | — |
+
+**Using direnv (recommended):** Rename `.env.local` to `.envrc`, add `dotenv` at the top, and run `direnv allow`. Variables will load automatically when you `cd` into the project.
+
+---
+
+## 3. Local Service Dependencies
+
+All infrastructure dependencies run in Docker Compose. You do not need to install PostgreSQL, Redis, or Kafka locally.
+
+```bash
+# Start all dependencies (PostgreSQL, Redis, and any other services)
+docker compose up -d
+
+# Verify all containers are healthy
+docker compose ps
+# Expected output: all services show "healthy" status
+
+# View logs if something is not healthy
+docker compose logs [service-name]
+```
+
+### What Docker Compose Starts
+
+| Service | Port | Purpose | Health check |
+|---|---|---|---|
+| PostgreSQL [version] | `5432` | Primary database | `pg_isready -U app` |
+| Redis [version] | `6379` | Cache and session store | `redis-cli ping` |
+| [Kafka + Zookeeper] | `9092` / `2181` | Message queue | `kafka-topics.sh --list` |
+| [Mock server — e.g. WireMock] | `8089` | Mocks for external APIs in tests | `curl localhost:8089/__admin` |
+| [LocalStack] | `4566` | AWS service emulation (S3, SQS, etc.) | `aws --endpoint-url=http://localhost:4566 s3 ls` |
+
+**If a container exits immediately:** See Troubleshooting section — common causes are port conflicts and Docker memory limits.
+
+### Stopping Dependencies
+
+```bash
+# Stop containers (preserves data volumes)
+docker compose stop
+
+# Stop and remove containers (clears data — use when you want a fresh start)
+docker compose down -v
+```
+
+---
+
+## 4. Install Dependencies and Build
+
+```bash
+# Install language dependencies
+# Go:
+go mod download
+
+# Node.js:
+npm install   # or: yarn install / pnpm install
+
+# Python:
+python -m venv .venv
+source .venv/bin/activate   # On Windows: .venv\Scripts\activate
+pip install -r requirements-dev.txt
+
+# Verify build compiles cleanly
+make build
+# Expected: no errors; binary or compiled output in [./bin/ or ./dist/]
+```
+
+---
+
+## 5. Database Setup and Seeding
+
+```bash
+# Run database migrations (creates tables and schema)
+make db-migrate
+# Or directly:
+# [Migration command — e.g. "go run ./cmd/migrate up" or "alembic upgrade head" or "npm run db:migrate"]
+
+# Verify migrations applied
+# psql $DATABASE_URL -c "\dt"  # should list all tables
+
+# Seed the database with development data
+make db-seed
+# Or directly:
+# [Seed command — e.g. "go run ./cmd/seed" or "python scripts/seed.py" or "npm run db:seed"]
+
+# Verify seed data is present
+# psql $DATABASE_URL -c "SELECT COUNT(*) FROM [primary-table]"
+# Expected: [N] rows
+```
+
+**What the seed creates:**
+- [N] test user accounts (credentials in [scripts/seed/README.md or .env.example])
+- [N] sample [resources] for development and testing
+- Admin account: `[admin@example.com]` / password: see `.env.example` for dev password variable
+
+**To reset to a clean state:**
+```bash
+docker compose down -v   # wipe database volume
+docker compose up -d     # start fresh
+make db-migrate
+make db-seed
+```
+
+---
+
+## 6. Running the Service
+
+```bash
+# Run the service locally
+make run
+# Or directly:
+# [Run command — e.g. "go run ./cmd/server" or "python app.py" or "npm run dev"]
+
+# Expected output:
+# [Example of healthy startup log lines — e.g.:]
+# {"level":"info","message":"Database connected","host":"localhost","port":5432}
+# {"level":"info","message":"Redis connected","host":"localhost","port":6379}
+# {"level":"info","message":"Server listening","port":8080}
+```
+
+### Verify It's Working
+
+```bash
+# Health check
+curl http://localhost:8080/health
+# Expected: {"status":"ok","version":"[git-sha]"}
+
+# Test a key endpoint (authenticated)
+# First, get a dev token:
+curl -X POST http://localhost:8080/api/v1/auth/login \
+  -H "Content-Type: application/json" \
+  -d '{"email":"[dev-user-from-seed]@example.com","password":"[dev-password-from-env]"}'
+# Copy the token from the response, then:
+
+curl http://localhost:8080/api/v1/[resource] \
+  -H "Authorization: Bearer [token-from-above]"
+# Expected: 200 with JSON response
+```
+
+### Hot Reload (for Development)
+
+```bash
+# Run with hot reload — service restarts automatically on file changes
+make run-dev
+# Or:
+# [Hot reload command — e.g. "air" for Go / "uvicorn --reload" for Python / "npm run dev" for Node]
+```
+
+---
+
+## 7. Running Tests
+
+```bash
+# Run the full test suite
+make test
+# Or:
+# [Test command — e.g. "go test ./..." or "pytest" or "npm test"]
+
+# Run tests with coverage report
+make test-coverage
+# Coverage report: [./coverage.html or stdout]
+
+# Run a specific test file or test case
+# Go: go test ./pkg/[package]/... -run TestFunctionName
+# Python: pytest tests/test_[module].py::TestClass::test_method -v
+# Node: npm test -- --testPathPattern=[filename]
+
+# Run only unit tests (fast — no external dependencies)
+make test-unit
+
+# Run only integration tests (requires Docker Compose dependencies running)
+make test-integration
+```
+
+**Expected test results:**
+- Unit tests: [N] tests, all pass, [<30] seconds
+- Integration tests: [N] tests, all pass, [<2] minutes
+- Coverage: [≥80]% (enforced in CI — tests fail below this threshold)
+
+**Before pushing a PR, always run:**
+```bash
+make lint      # code linting — must pass
+make test      # full test suite — must pass
+make build     # verify compilation — must pass
+```
+
+---
+
+## 8. IDE Setup
+
+### VS Code (Recommended)
+
+Install the recommended extensions (VS Code will prompt you automatically):
+
+```json
+// .vscode/extensions.json — already in the repository
+{
+  "recommendations": [
+    "[language-extension — e.g. golang.go]",
+    "dbaeumer.vscode-eslint",
+    "esbenp.prettier-vscode",
+    "ms-azuretools.vscode-docker",
+    "eamodio.gitlens"
+  ]
+}
+```
+
+Workspace settings are in `.vscode/settings.json` — format on save is enabled, linter is configured automatically.
+
+**[Language]-specific setup:**
+```
+[e.g. Go: The gopls language server is installed automatically by the Go extension.
+ Run "Go: Install/Update Tools" from the command palette after installing the extension.]
+```
+
+### JetBrains (IntelliJ / GoLand / PyCharm / WebStorm)
+
+- Open the project root as the project directory
+- [Language SDK]: set to [version] — File → Project Structure → SDKs
+- Run configurations are checked into `.idea/runConfigurations/` — they appear automatically
+- Enable "Run formatters on save" in Settings → Tools → Actions on Save
+
+---
+
+## 9. Common Gotchas and Troubleshooting
+
+### Docker container exits immediately on startup
+
+**Symptom:** `docker compose ps` shows a container as `Exited (1)` seconds after starting.
+
+```bash
+# Check the container logs for the error
+docker compose logs [container-name]
+
+# Common causes:
+# 1. Port already in use — find and kill the conflicting process:
+lsof -ti tcp:[port] | xargs kill -9
+
+# 2. Docker doesn't have enough memory — allocate at least 4GB in Docker Desktop:
+# Docker Desktop → Settings → Resources → Memory → 4GB
+
+# 3. M1/M2 Mac architecture mismatch — add platform directive to docker-compose.yml:
+# platform: linux/amd64
+```
+
+### Database connection refused
+
+**Symptom:** Service fails to start with "connection refused" or "dial tcp localhost:5432: connect: connection refused"
+
+```bash
+# Is PostgreSQL actually running?
+docker compose ps postgres
+# If not running: docker compose up -d postgres
+
+# Is it on the right port?
+lsof -i :5432
+
+# Can you connect manually?
+psql postgres://app:password@localhost:5432/[service]_dev -c "SELECT 1"
+
+# If using a custom DATABASE_URL, verify it matches the docker-compose.yml settings exactly
+```
+
+### Migrations fail with "relation already exists"
+
+**Symptom:** `make db-migrate` errors with "ERROR: relation [table] already exists"
+
+```bash
+# Check current migration state
+[migration status command — e.g. "go run ./cmd/migrate status" or "alembic current"]
+
+# The database may be in a partial state — reset it:
+docker compose down -v
+docker compose up -d
+make db-migrate  # should now succeed on a clean database
+```
+
+### Tests fail with "connection refused" or dependency errors
+
+**Symptom:** Integration tests fail because they cannot connect to PostgreSQL or Redis.
+
+```bash
+# Integration tests need Docker Compose running
+docker compose up -d
+
+# Verify all containers are healthy before running tests
+docker compose ps   # all should show "healthy"
+
+# If containers are running but tests still fail, check environment variables:
+make test-integration  # should pick up .env.local automatically
+# If not: source .env.local && make test-integration
+```
+
+### `make lint` fails on a fresh checkout
+
+**Symptom:** Lint errors on files you have not modified.
+
+```bash
+# Formatting issue — auto-fix with:
+# Go:
+gofmt -w .
+goimports -w .
+
+# Python:
+black .
+isort .
+
+# Node/TypeScript:
+npm run lint:fix
+# Or: npx eslint --fix . && npx prettier --write .
+
+# Re-run lint to confirm
+make lint
+```
+
+### Environment variables not loading
+
+**Symptom:** Service starts but immediately fails with "missing required environment variable: [VAR]"
+
+```bash
+# Verify .env.local exists and has all required variables
+cat .env.local | grep "^[A-Z]" | awk -F= '{print $1}'
+
+# Compare against required variables in .env.example
+diff <(grep "^[A-Z_]*=" .env.example | cut -d= -f1 | sort) \
+     <(grep "^[A-Z_]*=" .env.local | cut -d= -f1 | sort)
+
+# Missing variables are shown in left column only (< prefix)
+```
+
+---
+
+## 10. First Contribution Checklist
+
+Before opening your first pull request, verify:
+
+**Setup complete:**
+- [ ] `make build` passes with no errors
+- [ ] `make test` passes — all tests green
+- [ ] `make lint` passes — no lint errors
+- [ ] Service starts and health check returns 200
+- [ ] You can authenticate and call at least one API endpoint
+
+**Git and GitHub:**
+- [ ] You have read [CONTRIBUTING.md] — code standards, commit message format, PR process
+- [ ] Your git user.name and user.email are set correctly
+- [ ] Pre-commit hooks are installed (`ls .git/hooks/pre-commit` should exist)
+- [ ] You have branched from `main` (not committing directly to main)
+
+**Development workflow:**
+- [ ] You know how to run a specific test: `[test command for single test]`
+- [ ] You know how to reset the database: `docker compose down -v && docker compose up -d && make db-migrate && make db-seed`
+- [ ] You have joined [Slack: #[team-channel]] and [#[service-consumers-channel] if applicable]
+- [ ] You have read the [architecture overview doc / README] — you understand what this service does
+
+**First PR:**
+- [ ] Changes are small and focused — one logical change per PR
+- [ ] Tests are added or updated for your change
+- [ ] `make test && make lint && make build` all pass locally before requesting review
+- [ ] PR description explains what changed and why (use the [pr-description-writer skill] if needed)
+
+---
+
+## Quality Checks
+
+- [ ] A new engineer with no prior knowledge of the project can follow this guide from start to finish without asking anyone for help
+- [ ] Every command is tested on a clean environment — not written from memory and assumed to work
+- [ ] Environment variables table covers every variable in `.env.example` — no undocumented variables
+- [ ] The troubleshooting section covers the 5 most common real failures observed during onboarding — not theoretical issues
+- [ ] Docker Compose version and Docker Desktop memory requirements are stated explicitly
+- [ ] "Expected output" is shown for key commands so engineers know whether a step succeeded
+- [ ] Setup time estimate is honest — verified by timing a real onboarding session, not estimated
@@ -0,0 +1,290 @@
+---
+name: microservices-decomposition
+description: "Design a microservices decomposition for a monolith or new system, defining service boundaries, ownership, communication patterns, and migration plan. Use when asked to decompose a monolith, define service boundaries, design a microservices architecture, or plan a strangler-fig migration. Produces a bounded context map, service inventory table, communication pattern decisions, data ownership matrix, migration roadmap, and risk register."
+---
+
+# Microservices Decomposition
+
+Produce a complete microservices decomposition design for a system — whether decomposing an existing monolith or designing service boundaries for a new system. Ground the decomposition in Domain-Driven Design (DDD) concepts: identify bounded contexts first, then derive service boundaries from them. Include communication pattern decisions (sync vs. async, event vs. RPC), data ownership rules, and a pragmatic migration plan if decomposing a monolith. Conway's Law is real — include an organizational alignment section. The deliverable should be specific enough that a team can begin implementation, not an abstract architectural diagram.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **System or domain description** — what the system does, its core domain, and the key business processes it supports
+- **Current architecture** — monolith (describe the tech stack and rough module structure), partial services (list existing services), or greenfield
+- **Team structure** — number of teams, team names if known, and approximate team sizes; this drives service ownership
+- **Performance and scalability requirements** — any specific SLAs, load characteristics, or scaling constraints per domain area
+- **Migration constraints** — what cannot be rewritten all at once, hard deadlines, zero-downtime requirements, budget constraints
+- **Integration points** — external systems, third-party APIs, or legacy systems that cannot be changed
+
+If decomposing a monolith, also ask for: approximate codebase size, what is most painful to change today, and where the team experiences the most coupling-related friction.
+
+## Output Format
+
+---
+
+# Microservices Decomposition: [System Name]
+
+**Author:** [Name / Team]
+**Date:** [Date]
+**Architecture type:** [Monolith decomposition / New system design]
+**Current state:** [One sentence describing what exists today]
+**Target state:** [One sentence describing the desired end state]
+
+---
+
+## 1. Domain Analysis
+
+### Core Domain
+
+[One paragraph: what is the core domain of this system? What does the business fundamentally do? What gives it competitive differentiation? The core domain gets the most investment and the cleanest service boundaries.]
+
+### Domain Map
+
+List every significant subdomain before assigning service boundaries. Classify each subdomain:
+
+| Subdomain | Type | Description | Current Location in Monolith |
+|-----------|------|-------------|------------------------------|
+| [Subdomain, e.g., Order Management] | Core | [What it does and why it matters] | [Module/package name or "new"] |
+| [Subdomain, e.g., Inventory] | Core | [Description] | [Location] |
+| [Subdomain, e.g., Notifications] | Supporting | [Description] | [Location] |
+| [Subdomain, e.g., Billing] | Supporting | [Description] | [Location] |
+| [Subdomain, e.g., Reporting] | Generic | [Description — candidates for off-the-shelf solutions] | [Location] |
+| [Subdomain, e.g., User Auth] | Generic | [Description] | [Location] |
+
+**Subdomain types:** Core = competitive differentiation, build with care; Supporting = necessary but not differentiating, build pragmatically; Generic = commodity, buy or use open source.
+
+---
+
+## 2. Bounded Context Map (ASCII)
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                        [System Name]                            │
+│                                                                 │
+│  ┌──────────────────┐    ┌──────────────────┐                  │
+│  │  [Context A]     │    │  [Context B]      │                  │
+│  │                  │─ ─►│                  │                  │
+│  │  [key concepts]  │    │  [key concepts]  │                  │
+│  └──────────────────┘    └──────────────────┘                  │
+│           │                       │                             │
+│           │ event                 │ sync                        │
+│           ▼                       ▼                             │
+│  ┌──────────────────┐    ┌──────────────────┐                  │
+│  │  [Context C]     │    │  [Context D]      │                  │
+│  │                  │    │                  │                  │
+│  │  [key concepts]  │    │  [key concepts]  │                  │
+│  └──────────────────┘    └──────────────────┘                  │
+│                                   │                             │
+│                          ┌────────┘                             │
+│                          ▼                                      │
+│                 ┌──────────────────┐                            │
+│                 │  [Context E]     │                            │
+│                 │  [key concepts]  │                            │
+│                 └──────────────────┘                            │
+│                                                                 │
+│  External: [Third-party system] ──► [Context that owns it]      │
+└─────────────────────────────────────────────────────────────────┘
+
+Legend:  ──► sync call   - -► async event   ═══ shared kernel
+```
+
+Render this map using the actual bounded contexts derived from the domain analysis. Place contexts that communicate frequently closer together. Label relationship types on arrows.
+
+### Context Relationships
+
+| Upstream Context | Downstream Context | Relationship Type | Integration Pattern |
+|-----------------|-------------------|------------------|---------------------|
+| [Context A] | [Context B] | Customer-Supplier | REST API call |
+| [Context B] | [Context C] | Published Language | Domain events via message bus |
+| [Context X] | [Context Y] | Conformist | [Downstream conforms to upstream's model] |
+| [Context X] | [Context Y] | Anti-Corruption Layer | [ACL translates upstream model to local model] |
+
+---
+
+## 3. Proposed Service Inventory
+
+| Service Name | Bounded Context | Core Responsibility | Team Owner | Tech Stack | Priority |
+|-------------|----------------|--------------------|-----------|-----------|---------| 
+| [service-name] | [Context] | [One sentence: what this service owns and does] | [Team] | [Language/framework] | [P1/P2/P3] |
+| [service-name] | [Context] | [Responsibility] | [Team] | [Stack] | [Priority] |
+| [service-name] | [Context] | [Responsibility] | [Team] | [Stack] | [Priority] |
+| [service-name] | [Context] | [Responsibility] | [Team] | [Stack] | [Priority] |
+| [service-name] | [Context] | [Responsibility] | [Team] | [Stack] | [Priority] |
+
+**Service count:** [N proposed services] for [M bounded contexts]. [Note if any context maps to multiple services and why — e.g., "the Orders context splits into order-intake and order-fulfillment because they have different scalability requirements."]
+
+### Service Responsibility Rules (applied to every service above)
+
+- Single bounded context ownership — a service does not straddle two bounded contexts
+- Owns its own data — no direct database access by other services
+- Independently deployable — no coordinated deploys required with other services
+- Has a named team owner — no shared ownership of a single service across teams
+- Exposes a defined API contract — not internal implementation
+
+---
+
+## 4. Inter-Service Communication Patterns
+
+### Pattern Decision Matrix
+
+| Communication Need | Recommended Pattern | Rationale |
+|-------------------|--------------------|-----------| 
+| Query another service's current state | Synchronous REST / gRPC | Low latency required; caller needs immediate response |
+| Notify other services of a state change | Async domain event | Decouples services; multiple consumers; sender doesn't care when it's processed |
+| Long-running workflow spanning services | Async saga (choreography or orchestration) | No single service owns the full workflow; rollback needed if steps fail |
+| Read-heavy cross-service aggregation | CQRS read model / materialized view | Avoid chatty sync calls at read time; build purpose-fit read models |
+| Real-time push to clients | WebSocket gateway service | Centralizes connection management; services emit events, gateway pushes |
+
+### Per-Service Communication Decisions
+
+| Service | Calls (sync) | Publishes (events) | Subscribes to (events) |
+|---------|-------------|-------------------|----------------------|
+| [service-name] | [service-name (endpoint)] | [EventName] | [EventName] |
+| [service-name] | — | [EventName], [EventName] | [EventName] |
+| [service-name] | [service-name (endpoint)] | — | [EventName] |
+
+### Event Catalog
+
+| Event Name | Producer | Consumers | Payload (key fields) | Trigger |
+|-----------|---------|---------|---------------------|---------|
+| [OrderPlaced] | [order-service] | [inventory-service, notification-service] | `orderId, customerId, lineItems, totalAmount` | Customer submits order |
+| [InventoryReserved] | [inventory-service] | [order-service] | `orderId, reservationId, items` | Inventory successfully reserved |
+| [PaymentProcessed] | [payment-service] | [order-service, notification-service] | `orderId, paymentId, amount, status` | Payment confirmed |
+
+---
+
+## 5. Data Ownership Matrix
+
+Each piece of data has exactly one owning service. Other services may cache or project a read model, but they do not write to the owner's database.
+
+| Data Entity | Owner Service | Authoritative Store | Consumers | Access Pattern |
+|-------------|--------------|--------------------|-----------| ---------------|
+| [Order] | [order-service] | [PostgreSQL] | [fulfillment-service, reporting-service] | Event subscription + read API |
+| [Customer] | [customer-service] | [PostgreSQL] | [order-service, notification-service] | Sync API call |
+| [Product Catalog] | [catalog-service] | [PostgreSQL] | [order-service, inventory-service] | Sync API + cached local copy |
+| [Inventory Level] | [inventory-service] | [Redis + PostgreSQL] | [catalog-service (read only)] | Event subscription |
+| [Payment Record] | [payment-service] | [PostgreSQL] | [order-service] | Event subscription |
+
+### Data Migration (if decomposing a monolith)
+
+| Data Entity | Current Location | Target Service | Migration Approach | Data Volume | Risk |
+|-------------|-----------------|---------------|-------------------|-------------|------|
+| [Entity] | [monolith.orders table] | [order-service] | Dual-write then cut over | [X rows] | [High/Med/Low] |
+| [Entity] | [monolith.users table] | [customer-service] | Extract and sync via CDC | [X rows] | [High/Med/Low] |
+
+---
+
+## 6. API Contract Definitions
+
+Define the surface area for each service. Full OpenAPI specs are written separately; this section establishes the contract boundaries.
+
+### [service-name] API
+
+**Base path:** `/api/v1/[resource]`
+**Owner team:** [Team]
+**SLA:** [p99 latency target, availability target]
+
+| Endpoint | Method | Description | Auth Required | Rate Limit |
+|----------|--------|-------------|--------------|------------|
+| `/[resources]` | GET | List [resources] with pagination | Yes | [X req/min] |
+| `/[resources]/{id}` | GET | Get single [resource] by ID | Yes | [X req/min] |
+| `/[resources]` | POST | Create new [resource] | Yes | [X req/min] |
+| `/[resources]/{id}` | PUT | Update [resource] | Yes | [X req/min] |
+| `/[resources]/{id}` | DELETE | Soft-delete [resource] | Yes — elevated | [X req/min] |
+
+[Repeat for each service.]
+
+---
+
+## 7. Strangler Fig Migration Plan (for monolith decomposition)
+
+Use the strangler fig pattern: extract services incrementally, route traffic through a facade, and retire monolith modules one at a time.
+
+### Migration Phases
+
+```
+Phase 1: Foundation (Weeks 1–[N])
+  - Deploy service infrastructure (CI/CD, observability, service mesh)
+  - Extract lowest-risk, highest-value service first
+  - Monolith continues to serve all traffic
+
+Phase 2: First Extractions (Weeks [N]–[M])
+  - Extract P1 services
+  - API gateway routes selected traffic to new services
+  - Monolith handles remaining traffic via facade pattern
+  - Both paths write to shared DB during transition (dual-write)
+
+Phase 3: Core Domain Services (Weeks [M]–[P])
+  - Extract P1 core domain services
+  - Data migration for extracted services
+  - Remove dual-write paths for completed migrations
+
+Phase 4: Monolith Retirement (Weeks [P]–[Q])
+  - Extract remaining services
+  - Monolith serves no production traffic
+  - Decommission monolith infrastructure
+```
+
+### Phase-by-Phase Roadmap
+
+| Phase | Service to Extract | Migration Approach | Team | Duration | Dependencies | Success Criteria |
+|-------|------------------|--------------------|------|----------|-------------|-----------------|
+| 1 | [service-name] | [Strangler facade / Branch by abstraction / Event interception] | [Team] | [X weeks] | [Infra ready, CI/CD pipeline] | [Traffic fully on new service, zero errors for 2 weeks] |
+| 2 | [service-name] | [Approach] | [Team] | [X weeks] | [Phase 1 complete] | [Success metric] |
+| 3 | [service-name] | [Approach] | [Team] | [X weeks] | [Phase 2 complete] | [Success metric] |
+
+### Rollback Plan
+
+For each migration phase, define the rollback trigger and mechanism:
+- **Rollback trigger:** Error rate on new service > [X%] sustained for [Y minutes], or p99 latency > [threshold]
+- **Rollback mechanism:** API gateway feature flag reverts all traffic to monolith path in < 5 minutes
+- **Data rollback:** Dual-write maintained for [X weeks] after cutover to allow replay if needed
+
+---
+
+## 8. Organizational Alignment (Conway's Law)
+
+Conway's Law: the architecture of a system mirrors the communication structure of the organization that builds it. Design service ownership to match team boundaries — or change the team boundaries.
+
+| Service | Proposed Owner Team | Current Team Assignment | Change Required |
+|---------|--------------------|-----------------------|-----------------|
+| [service-name] | [Team A] | [Same / Different] | [No change / Transfer to Team A / New team needed] |
+| [service-name] | [Team B] | [Team A currently] | [Transfer ownership] |
+
+**Misalignments identified:**
+- [Misalignment 1: e.g., "The notification service spans two teams today. Assign it entirely to Team B which already owns the messaging domain."]
+- [Misalignment 2: e.g., "The reporting service is owned by Data Eng but consumers are Product teams — establish a clear API contract and SLA."]
+
+**Team topology recommendation:** [Describe the recommended team structure — stream-aligned teams, platform team, enabling team — and how it maps to the proposed services.]
+
+---
+
+## 9. Risk Register
+
+| Risk | Likelihood | Impact | Mitigation | Owner |
+|------|-----------|--------|-----------|-------|
+| Data consistency across services during migration | High | High | Dual-write with reconciliation job; event sourcing for critical domains | [Name] |
+| Distributed transaction complexity (sagas) | Medium | High | Start with choreography; add orchestration only when choreography becomes unmanageable | [Name] |
+| Service mesh operational overhead | Medium | Medium | Start without a mesh; add after 5+ services deployed | [Name] |
+| Network latency replacing in-process calls | Medium | Medium | Cache aggressively; design read models to avoid chatty sync calls | [Name] |
+| Conway's Law friction during transition | High | Medium | Align team structure before starting extraction, not after | [Name] |
+| Over-decomposition (nanoservices) | Medium | High | Enforce minimum service size rule: a service must justify its own team/deployment overhead | [Name] |
+| Observability gaps during migration | High | High | Deploy distributed tracing before first extraction; establish correlation IDs | [Name] |
+| [Context-specific risk] | [Level] | [Level] | [Mitigation] | [Owner] |
+
+---
+
+*Questions about this design: [Slack channel or contact]*
+
+---
+
+## Quality Checks
+
+- [ ] Bounded context map is an ASCII diagram with labeled relationships — not a prose description of the contexts
+- [ ] Every service in the inventory table has a named team owner and a clear single-sentence responsibility statement
+- [ ] Data ownership matrix assigns every key entity to exactly one owning service — no shared ownership
+- [ ] Communication pattern decisions explain WHY sync vs. async was chosen for each interaction type
+- [ ] If decomposing a monolith, the strangler fig migration plan has phases with durations, dependencies, and success criteria
+- [ ] Risk register addresses at minimum: data consistency, distributed transactions, and Conway's Law alignment
+- [ ] Organizational alignment section maps services to teams and identifies misalignments that need to be resolved
@@ -0,0 +1,436 @@
+---
+name: monitoring-setup-guide
+description: "Write a monitoring setup guide for a service — defining what to measure, how to alert on it, and how to build the observability stack covering the four golden signals, business metrics, log strategy, distributed tracing, alerting rules, dashboard layout, and observability debt. Use when asked to set up monitoring for a service, define alerting strategy, write an observability plan, create a dashboard specification, or document logging standards for a team. Produces a metric definitions table, alert rules specification, dashboard layout wireframe, log schema, tracing setup checklist, and monitoring gap analysis."
+---
+
+# Monitoring Setup Guide Skill
+
+Produce a complete monitoring setup guide for a service — defining exactly what to measure, how to structure logs, how to configure alerts with actionable thresholds, and how to build dashboards that answer real operational questions. A good monitoring guide eliminates "we don't know what's happening in production" as a root cause category, and gives on-call engineers a single source of truth for what healthy looks like.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name and description** — what the service does and its role in the system
+- **Tech stack** — language, framework, and infrastructure (e.g. Go/gRPC on Kubernetes, Python/FastAPI on ECS)
+- **Current monitoring tooling** — Datadog, Prometheus + Grafana, CloudWatch, New Relic, Honeycomb, or none yet
+- **Key user journeys** — the 2–4 most important things a user or consumer does with the service (these drive what to alert on)
+- **Existing alerts** — paste any existing alert configurations or describe what's currently monitored
+
+## Output Format
+
+---
+
+# Monitoring Setup Guide: [Service Name]
+
+**Team:** [Team name] | **Tech lead:** [Name]
+**Stack:** [Language/Framework] on [Infrastructure]
+**Monitoring platform:** [Datadog / Prometheus+Grafana / CloudWatch / etc.]
+**Date:** [Date] | **Review cycle:** Quarterly
+
+---
+
+## 1. Monitoring Philosophy
+
+Good monitoring answers three questions:
+1. **Is the service healthy right now?** (alerting)
+2. **Was it healthy in the past, and is it trending worse?** (dashboards + SLO tracking)
+3. **Why did something fail?** (logs + traces)
+
+This guide defines the answers for [Service Name]. Every alert must be actionable — if an on-call engineer cannot take a specific action in response to the alert, the alert should not exist.
+
+**Key user journeys monitored:**
+- Journey 1: [e.g. "User submits a payment — POST /charges, receives confirmation"]
+- Journey 2: [e.g. "User views transaction history — GET /transactions"]
+- Journey 3: [e.g. "Subscription renewal job runs — background worker processes billing events"]
+
+---
+
+## 2. The Four Golden Signals
+
+Apply the four golden signals specifically to [Service Name]:
+
+### Latency
+
+Latency measures how long requests take to complete. Track it separately for successful and failed requests — slow failures hide behind fast errors if you only measure aggregate latency.
+
+| Metric | Description | Source | Dimensions |
+|---|---|---|---|
+| `[service].request.duration_ms` | End-to-end request latency | Application instrumentation | `endpoint`, `method`, `status_code` |
+| `[service].db.query_duration_ms` | Database query latency | ORM / query instrumentation | `query_name`, `table` |
+| `[service].external.request_duration_ms` | Outbound call latency to dependencies | HTTP client instrumentation | `target_service`, `endpoint` |
+| `[service].queue.processing_duration_ms` | Time to process one message (if applicable) | Consumer instrumentation | `queue_name`, `message_type` |
+
+**Latency SLO targets:**
+
+| Endpoint / operation | p50 target | p95 target | p99 target |
+|---|---|---|---|
+| `GET /api/v1/[resource]` | < [50] ms | < [200] ms | < [500] ms |
+| `POST /api/v1/[resource]` | < [100] ms | < [400] ms | < [1000] ms |
+| `GET /health` | < [10] ms | < [20] ms | < [50] ms |
+| [Background job name] | < [5] sec | < [15] sec | < [60] sec |
+
+### Traffic
+
+Traffic measures demand on the system. Use it to detect unexpected spikes, traffic drops (which can indicate upstream failures), and to capacity-plan.
+
+| Metric | Description | Source |
+|---|---|---|
+| `[service].request.count` | Requests per second | Application / load balancer |
+| `[service].request.count_by_endpoint` | RPS broken down by endpoint | Application |
+| `[service].queue.messages_consumed_per_second` | Consumer throughput | Queue consumer |
+| `[service].queue.depth` | Messages waiting in queue | Queue metrics |
+
+**Traffic baselines (update after observing production for 2+ weeks):**
+
+| Time period | Expected RPS | Low-traffic floor | Spike ceiling |
+|---|---|---|---|
+| Peak (weekday business hours) | [N] RPS | [N × 0.5] RPS | [N × 5] RPS |
+| Off-peak (nights/weekends) | [N × 0.2] RPS | [N × 0.05] RPS | [N] RPS |
+
+### Errors
+
+Errors measure the fraction of requests that fail. Distinguish between client errors (4xx — caller is doing something wrong) and server errors (5xx — the service is broken).
+
+| Metric | Description | Alert on? |
+|---|---|---|
+| `[service].request.error_rate` | 5xx errors / total requests | Yes — see alert rules |
+| `[service].request.client_error_rate` | 4xx errors / total requests | Threshold alert — sudden spike may indicate API misuse |
+| `[service].dependency.error_rate` | Errors calling downstream dependencies | Yes — upstream health signal |
+| `[service].queue.dlq_depth` | Messages in dead-letter queue | Yes — indicates processing failures |
+
+### Saturation
+
+Saturation measures how "full" the service is — how close to maximum capacity are the constrained resources.
+
+| Resource | Metric | Alert threshold | Source |
+|---|---|---|---|
+| CPU | `[service].cpu.utilisation_pct` | >80% sustained 5 min | Container / VM metrics |
+| Memory | `[service].memory.utilisation_pct` | >85% sustained 5 min | Container / VM metrics |
+| DB connections | `[service].db.connection_pool.utilisation_pct` | >75% | Application / DB metrics |
+| Thread pool / goroutines | `[service].runtime.goroutine_count` / `thread_count` | >N (establish baseline) | Runtime metrics |
+| Disk (if applicable) | `[service].disk.utilisation_pct` | >75% | Infrastructure |
+| Queue depth (if applicable) | `[service].queue.depth` | >[backlog threshold] | Queue metrics |
+
+---
+
+## 3. Business Metrics
+
+Beyond the golden signals, track metrics that measure whether the service is delivering business value. These matter for SLO reporting and product dashboards.
+
+| Metric | Description | Source | Alert? |
+|---|---|---|---|
+| `[service].[primary_action].success_rate` | [e.g. "Payment success rate"] | Application | Yes — if drops >5% vs 1h average |
+| `[service].[primary_action].count` | [e.g. "Payments processed per minute"] | Application | Yes — sudden drop (traffic anomaly) |
+| `[service].[resource].created_per_hour` | [e.g. "New accounts created"] | Application / DB | No — informational |
+| `[service].cache.hit_rate` | Fraction of requests served from cache | Cache instrumentation | Yes — if drops below [60]% |
+| `[service].job.[name].success_rate` | [Background job success rate] | Job framework | Yes — if drops below [99]% |
+
+---
+
+## 4. Log Strategy
+
+### Structured Logging Schema
+
+All logs must be structured JSON. Do not emit unstructured text logs in production. Every log line must include the mandatory fields.
+
+**Mandatory fields (every log line):**
+
+```json
+{
+  "timestamp": "2024-01-15T10:23:45.123Z",
+  "level": "info",
+  "service": "[service-name]",
+  "version": "[git-sha-short]",
+  "trace_id": "[uuid-from-request-context]",
+  "span_id": "[span-uuid]",
+  "request_id": "[uuid-per-request]",
+  "message": "[human readable description]"
+}
+```
+
+**Request log (emit for every HTTP request):**
+
+```json
+{
+  "timestamp": "...",
+  "level": "info",
+  "service": "[service-name]",
+  "event": "http_request",
+  "method": "POST",
+  "path": "/api/v1/[resource]",
+  "status_code": 201,
+  "duration_ms": 45,
+  "user_id": "[uuid — DO NOT log PII directly]",
+  "request_id": "[uuid]",
+  "trace_id": "[uuid]"
+}
+```
+
+**Error log (emit for every error with context):**
+
+```json
+{
+  "timestamp": "...",
+  "level": "error",
+  "service": "[service-name]",
+  "event": "error",
+  "error_code": "[application-error-code]",
+  "error_message": "[description — no sensitive data]",
+  "stack_trace": "[stack trace]",
+  "request_id": "[uuid]",
+  "trace_id": "[uuid]",
+  "context": {
+    "[key]": "[relevant context without PII]"
+  }
+}
+```
+
+### Log Levels — When to Use Each
+
+| Level | Use when | Example |
+|---|---|---|
+| `error` | Something failed that requires attention — this should page on-call eventually | Database query failed, external API returned 5xx, required config missing |
+| `warn` | Something unexpected happened but service is still functioning | Retry succeeded after failure, cache miss on expected hit, rate limit approaching |
+| `info` | Significant business events and request lifecycle | Request received, payment processed, user authenticated, job started/completed |
+| `debug` | Detailed diagnostic information — off in production by default | Query parameters, intermediate computation results, cache key lookups |
+
+### What NOT to Log
+
+**Never log:**
+- Passwords, tokens, API keys, or secrets (even hashed)
+- Full credit card numbers or PAN data
+- Social security numbers or government IDs
+- Full names + dates of birth + contact info in the same log line (PII aggregation)
+- Request/response bodies in full (use field-level extraction instead)
+- Health check requests (too noisy — exclude `GET /health` from access logs)
+
+---
+
+## 5. Distributed Tracing Setup
+
+Distributed tracing is mandatory for any service that calls other services. It enables root-cause analysis across service boundaries.
+
+### Instrumentation Checklist
+
+```
+[ ] Tracing library installed:
+    - Go: go.opentelemetry.io/otel
+    - Python: opentelemetry-sdk, opentelemetry-instrumentation
+    - Node: @opentelemetry/sdk-node
+    - Java: opentelemetry-java-instrumentation
+
+[ ] Tracer initialized at service startup with service name and version
+
+[ ] Trace context propagated via W3C Trace Context headers:
+    traceparent: 00-[trace-id]-[span-id]-01
+    tracestate: [optional vendor-specific]
+
+[ ] Automatic instrumentation enabled for:
+    [ ] Inbound HTTP/gRPC requests (creates root span)
+    [ ] Outbound HTTP/gRPC calls (creates child spans)
+    [ ] Database queries (creates child spans with sanitized query)
+    [ ] Cache operations (Redis, Memcached)
+    [ ] Message queue produce/consume
+
+[ ] Custom spans added for:
+    [ ] Key business operations ([e.g. payment processing, user lookup])
+    [ ] Background jobs (each job execution = root span)
+    [ ] Third-party API calls with custom attributes
+
+[ ] Span attributes to capture on all spans:
+    - user.id (if authenticated — no PII)
+    - deployment.environment (production/staging)
+    - service.version (git SHA)
+    - [service-specific key attributes]
+
+[ ] Trace exporter configured to: [Datadog / Jaeger / Tempo / OTLP endpoint]
+
+[ ] Sampling rate configured:
+    - Production: [1–10]% of requests (adjust based on volume and cost)
+    - Always sample: errors, slow requests (>p99 threshold), and 100% of [critical endpoint]
+```
+
+### Trace Instrumentation Examples
+
+```python
+# Python — OpenTelemetry example
+from opentelemetry import trace
+
+tracer = trace.get_tracer("[service-name]")
+
+def process_payment(payment_data):
+    with tracer.start_as_current_span("process_payment") as span:
+        span.set_attribute("payment.amount_cents", payment_data["amount"])
+        span.set_attribute("payment.currency", payment_data["currency"])
+        # Never: span.set_attribute("payment.card_number", ...)
+        try:
+            result = _do_process(payment_data)
+            span.set_status(trace.StatusCode.OK)
+            return result
+        except PaymentError as e:
+            span.set_status(trace.StatusCode.ERROR, str(e))
+            span.record_exception(e)
+            raise
+```
+
+---
+
+## 6. Alert Rules Specification
+
+Every alert must have: a name, a condition, a threshold, a severity, and a clear on-call action. Alerts without a clear action should not exist.
+
+### Alert Definitions
+
+| Alert name | Condition | Threshold | Severity | On-call action |
+|---|---|---|---|---|
+| `[Service]HighErrorRate` | 5xx error rate, 5-min rolling window | >1% for 2 consecutive windows | P1 | Check recent deploys; inspect error logs; see runbook [link] |
+| `[Service]CriticalErrorRate` | 5xx error rate, 2-min rolling window | >5% | P1 — immediate | Same as above — page immediately, do not wait |
+| `[Service]HighP99Latency` | p99 latency on key endpoints | >2× SLO target for 3 min | P2 | Check DB latency, cache hit rate, and upstream dependencies |
+| `[Service]LatencySLOBreach` | p99 latency | >SLO target for 5 consecutive minutes | P1 | SLO burn — page on-call, escalate if not resolved in 20 min |
+| `[Service]HighCPU` | CPU utilisation | >80% sustained for 5 min | P2 | Check for traffic spike; scale up if needed; check for runaway processes |
+| `[Service]HighMemory` | Memory utilisation | >85% sustained for 5 min | P2 | Check for memory leak (especially after deploys); restart pod if OOM imminent |
+| `[Service]DBConnectionPoolHigh` | DB connection pool utilisation | >75% | P2 | Check for long-running queries; consider scaling service or increasing pool size |
+| `[Service]DLQDepthHigh` | Dead-letter queue depth | >10 messages | P2 | Inspect DLQ messages for error pattern; fix bug and replay if safe |
+| `[Service]TrafficDropAnomaly` | RPS, compared to same hour yesterday | >50% drop sustained 5 min | P1 | Upstream may be down; check caller health; check load balancer |
+| `[Service]PrimaryActionSuccessRateDrop` | [Business metric success rate] | <[95]% over 10 min | P1 | [Service-specific action — e.g. "Check payment provider status"] |
+| `[Service]DownstreamDependencyErrors` | Error rate calling [dependency] | >5% over 5 min | P2 | Check [dependency] status page; enable fallback if available |
+
+### Alert Configuration Examples
+
+```yaml
+# Prometheus / Grafana alerting rules (adapt for your platform)
+groups:
+  - name: [service-name]-alerts
+    rules:
+
+      - alert: [Service]HighErrorRate
+        expr: |
+          (
+            sum(rate([service]_http_requests_total{status=~"5.."}[5m]))
+            /
+            sum(rate([service]_http_requests_total[5m]))
+          ) > 0.01
+        for: 2m
+        labels:
+          severity: critical
+          team: [team-name]
+        annotations:
+          summary: "High error rate on [Service Name]"
+          description: "Error rate is {{ $value | humanizePercentage }} (threshold: 1%)"
+          runbook_url: "[runbook link]"
+
+      - alert: [Service]HighP99Latency
+        expr: |
+          histogram_quantile(0.99,
+            sum(rate([service]_http_request_duration_seconds_bucket[5m])) by (le, endpoint)
+          ) > [0.5]
+        for: 3m
+        labels:
+          severity: warning
+          team: [team-name]
+        annotations:
+          summary: "p99 latency elevated on [Service Name]"
+          description: "p99 latency on {{ $labels.endpoint }} is {{ $value | humanizeDuration }}"
+          runbook_url: "[runbook link]"
+```
+
+```python
+# Datadog monitor configuration (Python SDK or Terraform)
+import datadog
+
+datadog.initialize(api_key="[key]", app_key="[key]")
+
+datadog.api.Monitor.create(
+    type="metric alert",
+    query=f"sum(last_5m):sum:{{service}}.http.errors{{service:[service-name]}} / sum:{{service}}.http.requests{{service:[service-name]}} > 0.01",
+    name="[Service] High Error Rate",
+    message="Error rate exceeded 1%. @pagerduty-[service-oncall]\n\nRunbook: [link]",
+    tags=["service:[service-name]", "team:[team-name]"],
+    options={
+        "thresholds": {"critical": 0.01, "warning": 0.005},
+        "notify_no_data": False,
+        "evaluation_delay": 60,
+    }
+)
+```
+
+---
+
+## 7. Dashboard Layout Specification
+
+The primary service dashboard must answer "is the service healthy right now?" at a glance. Use this layout:
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│  [SERVICE NAME] — Service Health Dashboard           [Time range ▼] │
+├───────────────┬───────────────┬───────────────┬─────────────────────┤
+│  Error rate   │  p99 Latency  │  RPS (current)│  SLO budget remaining│
+│  [BIG NUMBER] │  [BIG NUMBER] │  [BIG NUMBER] │  [BIG NUMBER / days] │
+│  vs SLO: 0.1% │  vs SLO: 500ms│  vs avg: [N]  │  [Error budget gauge]│
+├───────────────┴───────────────┴───────────────┴─────────────────────┤
+│                   Error rate over time (24h)                        │
+│  [Time series: 5xx rate line, SLO threshold line]                   │
+├─────────────────────────────────┬───────────────────────────────────┤
+│  Latency percentiles over time  │  Request throughput over time     │
+│  [Lines: p50, p95, p99, p999]   │  [Bars: RPS by endpoint]          │
+│  [SLO threshold horizontal line]│                                   │
+├─────────────────────────────────┴───────────────────────────────────┤
+│  Latency heatmap (all requests — shows distribution shape)          │
+├─────────────────────────────────┬───────────────────────────────────┤
+│  CPU utilisation over time      │  Memory utilisation over time     │
+│  [All instances/pods — lines]   │  [All instances/pods — lines]     │
+│  [Alert threshold: 80%]         │  [Alert threshold: 85%]           │
+├─────────────────────────────────┴───────────────────────────────────┤
+│  DB: connection pool utilisation│  DB: query latency (p99 per query)│
+├─────────────────────────────────┴───────────────────────────────────┤
+│  [Business metric 1 over time]  │  [Business metric 2 over time]    │
+│  e.g. Payment success rate      │  e.g. Orders created/min          │
+└─────────────────────────────────┴───────────────────────────────────┘
+```
+
+**Second dashboard — Dependency Health:**
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│  [SERVICE NAME] — Dependency Health                                 │
+├─────────────────────────────────────────────────────────────────────┤
+│  For each dependency: error rate | latency | current status         │
+│  [Database]    [N]% errors | [N]ms p99 | ● Healthy / ⚠ Degraded    │
+│  [Redis]       [N]% errors | [N]ms p99 | ● Healthy                 │
+│  [External API][N]% errors | [N]ms p99 | ● Healthy                 │
+├─────────────────────────────────────────────────────────────────────┤
+│  Outbound call latency over time (one line per dependency)          │
+├─────────────────────────────────────────────────────────────────────┤
+│  Circuit breaker / fallback state (if implemented)                  │
+└─────────────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## 8. Observability Debt Analysis
+
+Honest assessment of what is missing today and what the priority to add it is:
+
+| Gap | Impact | Priority | Effort | Owner | Target date |
+|---|---|---|---|---|---|
+| [e.g. No distributed tracing — can't see cross-service latency] | High — blind to dependency issues | P1 | [2 days] | [Name] | [Date] |
+| [e.g. No business metric alerts — only infra alerts] | High — silent business failures | P1 | [1 day] | [Name] | [Date] |
+| [e.g. Logs are unstructured text — not searchable] | Medium — slow incident investigation | P2 | [3 days] | [Name] | [Date] |
+| [e.g. No dead-letter queue monitoring] | Medium — failed messages go unnoticed | P2 | [4 hours] | [Name] | [Date] |
+| [e.g. Alert thresholds not calibrated to production baseline] | Medium — alert fatigue or missed alerts | P2 | [1 day] | [Name] | [Date] |
+| [e.g. No latency heatmap — outliers invisible in averages] | Low — harder to spot tail latency issues | P3 | [2 hours] | [Name] | [Date] |
+
+**Total observability debt: [N] items | Estimated effort: [N days]**
+
+---
+
+## Quality Checks
+
+- [ ] Every alert has a named on-call action — no alert says "investigate" without specifying what to investigate first
+- [ ] Alert thresholds are calibrated against production baselines, not set to default values from a template
+- [ ] Structured logging is implemented — no unstructured text log lines in production
+- [ ] PII is explicitly excluded from logs — a named engineer has verified this
+- [ ] Distributed tracing is propagating trace IDs across all service boundaries (verify with a test request)
+- [ ] The primary dashboard answers "is the service healthy?" in under 10 seconds — no hunting for the right panel
+- [ ] Business metrics are tracked alongside infrastructure metrics — not just four golden signals
+- [ ] Observability debt items have owners and dates — not just "would be nice to have"
@@ -0,0 +1,277 @@
+---
+name: performance-budget
+description: "Define and document performance budgets for a web service or application. Use when asked to set performance targets, define SLOs for latency or throughput, establish Core Web Vitals targets, create a performance baseline, or document performance regression policy. Produces a structured performance budget covering key user journeys, Core Web Vitals, backend latency SLOs, measurement tooling, CI enforcement, and breach response process."
+---
+
+# Performance Budget Skill
+
+Produce a complete, actionable performance budget document for a web service or application. A performance budget is not a wishlist — it is a set of measurable, enforced constraints that define what "acceptable performance" means and who is responsible when those constraints are violated.
+
+A good performance budget answers: what are the targets, how are they measured, what triggers an investigation, and what happens when a budget is breached.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name and type** — web app, API service, mobile app, or combination
+- **Key user journeys** — the 3–5 most important flows users take (e.g. "search → product page → checkout")
+- **Current baseline metrics** — P50/P95/P99 latency, LCP, CLS, INP if available (state "no baseline" if not collected yet)
+- **Tech stack** — frontend framework, backend language/framework, CDN, database
+- **Deployment environment** — cloud provider, region(s), edge/CDN configuration
+- **Cost constraints** — any budget or infrastructure limits that affect headroom
+
+## Output Format
+
+---
+
+# Performance Budget: [Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Last updated:** [Date] | **Owner:** [Name / role]
+**Environment:** [Production / Staging baseline] | **Review cadence:** [Quarterly / per-sprint]
+
+---
+
+## Overview
+
+[2–3 sentences describing the service, its user-facing performance requirements, and why performance is a priority. Reference the business impact of latency — e.g. conversion rate, user retention, SLA obligations.]
+
+**Performance philosophy:** [e.g. "Performance is a feature. Every engineer is responsible for keeping the service within budget. Regressions must be caught in CI before they reach production."]
+
+---
+
+## Key User Journeys
+
+Define the critical paths that the performance budget is designed to protect.
+
+| Journey ID | Journey name | Entry point | Exit point | Criticality |
+|---|---|---|---|---|
+| UJ-1 | [e.g. New user sign-up] | [Landing page] | [Dashboard] | Critical |
+| UJ-2 | [e.g. Core workflow task] | [e.g. /app/tasks] | [e.g. Task complete] | High |
+| UJ-3 | [e.g. Search and select] | [e.g. /search] | [e.g. Detail page] | High |
+| UJ-4 | [e.g. API data fetch] | [e.g. GET /api/items] | [e.g. 200 response] | Medium |
+
+---
+
+## Frontend Performance Budget
+
+*Complete this section for web and mobile applications. Skip for API-only services.*
+
+### Core Web Vitals Targets
+
+Targets apply to the 75th percentile of real user sessions (field data), measured on a mid-range Android device on a 4G connection unless otherwise stated.
+
+| Metric | Description | Good | Needs Improvement | Poor | **Our Target** | Current baseline |
+|---|---|---|---|---|---|---|
+| **LCP** | Largest Contentful Paint — perceived load speed | ≤2.5s | 2.5–4.0s | >4.0s | **[≤X.Xs]** | [Xs / not measured] |
+| **INP** | Interaction to Next Paint — responsiveness | ≤200ms | 200–500ms | >500ms | **[≤Xms]** | [Xms / not measured] |
+| **CLS** | Cumulative Layout Shift — visual stability | ≤0.1 | 0.1–0.25 | >0.25 | **[≤0.X]** | [X.XX / not measured] |
+| **FCP** | First Contentful Paint | ≤1.8s | 1.8–3.0s | >3.0s | **[≤X.Xs]** | [Xs / not measured] |
+| **TTFB** | Time to First Byte | ≤800ms | 800ms–1.8s | >1.8s | **[≤Xms]** | [Xms / not measured] |
+
+### Page Weight Budget
+
+| Asset type | Max size (compressed) | Current | Status |
+|---|---|---|---|
+| Total page weight | [e.g. 500KB] | [XKB / unknown] | [Within / Over / Unknown] |
+| JavaScript (initial load) | [e.g. 200KB] | [XKB / unknown] | [Within / Over / Unknown] |
+| CSS | [e.g. 50KB] | [XKB / unknown] | [Within / Over / Unknown] |
+| Images (above fold) | [e.g. 150KB] | [XKB / unknown] | [Within / Over / Unknown] |
+| Web fonts | [e.g. 50KB] | [XKB / unknown] | [Within / Over / Unknown] |
+| Third-party scripts | [e.g. 100KB] | [XKB / unknown] | [Within / Over / Unknown] |
+
+### Per-Journey Frontend Targets
+
+| Journey | LCP | INP | CLS | FCP | TTFB |
+|---|---|---|---|---|---|
+| UJ-1: [Journey name] | [≤Xs] | [≤Xms] | [≤0.X] | [≤Xs] | [≤Xms] |
+| UJ-2: [Journey name] | [≤Xs] | [≤Xms] | [≤0.X] | [≤Xs] | [≤Xms] |
+| UJ-3: [Journey name] | [≤Xs] | [≤Xms] | [≤0.X] | [≤Xs] | [≤Xms] |
+
+---
+
+## Backend Performance Budget
+
+### API Latency SLOs
+
+Targets measured at the service boundary (not including client-side network latency).
+
+| Endpoint / operation | Method | P50 | P95 | P99 | Max (hard limit) | Error rate |
+|---|---|---|---|---|---|---|
+| [e.g. /api/auth/login] | POST | [≤Xms] | [≤Xms] | [≤Xms] | [≤Xms] | [<X%] |
+| [e.g. /api/items] | GET | [≤Xms] | [≤Xms] | [≤Xms] | [≤Xms] | [<X%] |
+| [e.g. /api/items/:id] | GET | [≤Xms] | [≤Xms] | [≤Xms] | [≤Xms] | [<X%] |
+| [e.g. /api/items] | POST | [≤Xms] | [≤Xms] | [≤Xms] | [≤Xms] | [<X%] |
+| [e.g. Background job: sync] | — | [≤Xs] | [≤Xs] | [≤Xs] | [≤Xs] | [<X%] |
+
+**Overall service SLOs:**
+
+| SLO | Target | Measurement window |
+|---|---|---|
+| Availability | [99.X%] | 30-day rolling |
+| P95 latency (all endpoints) | [≤Xms] | 30-day rolling |
+| Error rate (5xx) | [<X%] | 30-day rolling |
+| Throughput (sustained) | [≥X req/s] | Peak hour |
+
+### Database Query Budget
+
+| Query / operation | P50 | P95 | Max | Notes |
+|---|---|---|---|---|
+| [e.g. User lookup by ID] | [≤Xms] | [≤Xms] | [≤Xms] | Index on `user_id` |
+| [e.g. List items for user] | [≤Xms] | [≤Xms] | [≤Xms] | Paginated, max 100 rows |
+| [e.g. Full-text search] | [≤Xms] | [≤Xms] | [≤Xms] | Elasticsearch / pg_trgm |
+
+---
+
+## Measurement Methodology
+
+### Real User Monitoring (RUM)
+
+**Tool:** [e.g. Google CrUX, SpeedCurve, Datadog RUM, Sentry Performance, custom]
+**Data source:** [Field data from real users / Lab data from synthetic tests / Both]
+**Sample rate:** [X% of sessions]
+**How to access:** [Dashboard URL or tool access instructions]
+
+**What is measured:**
+- [ ] Core Web Vitals (LCP, INP, CLS) per page and journey
+- [ ] Custom performance marks for business-critical interactions
+- [ ] Resource timing for key assets
+- [ ] Long tasks (>50ms on main thread)
+
+### Synthetic Monitoring
+
+**Tool:** [e.g. Lighthouse CI, WebPageTest, k6, Artillery, Playwright with performance assertions]
+**Frequency:** [Every X minutes / on every deploy / nightly]
+**Test location(s):** [e.g. eu-west-1, us-east-1]
+**Device profile:** [Desktop 10Mbps / Mobile 4G Moto G4 / both]
+
+**Synthetic test suite location:** [Link to test files]
+
+### Backend Observability
+
+**APM tool:** [e.g. Datadog, Grafana + Prometheus, New Relic, AWS X-Ray]
+**Metrics collected:**
+- Request rate, error rate, duration (RED metrics) per endpoint
+- Database query duration and connection pool utilisation
+- Cache hit/miss rates
+- Background job queue depth and processing latency
+
+**Dashboard:** [Link to primary performance dashboard]
+
+---
+
+## CI/CD Performance Enforcement
+
+Performance budgets are enforced at two gates:
+
+### Gate 1 — Build-time Bundle Analysis
+
+**Tool:** [e.g. bundlesize, size-limit, webpack-bundle-analyzer with CI assertion]
+**Config file:** [`[.bundlesizerc / .size-limit.js / etc.]`]
+**Trigger:** Every PR targeting `main`
+**Blocking:** Yes — PR cannot merge if bundle size budget is exceeded
+
+```json
+// Example .size-limit.js
+[
+  {
+    "path": "dist/js/*.js",
+    "limit": "200 KB"
+  },
+  {
+    "path": "dist/css/*.css",
+    "limit": "50 KB"
+  }
+]
+```
+
+### Gate 2 — Synthetic Performance Tests in CI
+
+**Tool:** [e.g. Lighthouse CI, k6, Artillery]
+**Trigger:** On deploy to staging
+**Blocking:** Yes — production deploy is blocked if thresholds fail
+**Thresholds checked:**
+- LCP ≤ [Xs]
+- CLS ≤ [0.X]
+- P95 API latency ≤ [Xms]
+- Error rate < [X%]
+
+**CI config location:** [`[.github/workflows/perf.yml / ci/performance.yaml]`]
+
+**How to run locally:**
+```bash
+# Run Lighthouse CI against local build
+[command — e.g. lhci autorun --config=lighthouserc.js]
+
+# Run load test locally
+[command — e.g. k6 run load-tests/api-smoke.js]
+```
+
+---
+
+## Budget Breach Response Process
+
+A budget breach is when a measured metric exceeds its target for [X consecutive measurements / X minutes sustained / a single deploy].
+
+### Breach Severity Levels
+
+| Severity | Condition | Response time | Who acts |
+|---|---|---|---|
+| P1 — Critical | >2× budget threshold in production | Immediate | On-call engineer + team lead |
+| P2 — High | >1.5× budget threshold in production | Within 4 hours | On-call engineer |
+| P3 — Medium | Threshold exceeded in production | Within 1 sprint | PR author + team |
+| P4 — Low | Threshold exceeded in staging only | Before merge | PR author |
+
+### Breach Investigation Checklist
+
+When a breach is detected, work through this checklist in order:
+
+**1. Identify the regression commit**
+```bash
+# Compare performance across recent deploys
+[command — e.g. datadog metrics query, lighthouse-ci compare, git bisect]
+```
+
+**2. Classify the breach**
+- [ ] Is this a code change? (new feature, refactor, dependency bump)
+- [ ] Is this an infrastructure change? (new instance type, config change)
+- [ ] Is this an external factor? (CDN issue, DNS, upstream dependency)
+- [ ] Is this a measurement anomaly? (test environment issue, sample size)
+
+**3. Immediate actions**
+- If P1/P2 in production and a code cause is confirmed: roll back or disable the feature flag
+- If cause is unknown: do not roll back immediately — gather more data first
+- Notify [#performance / #incidents Slack channel] with: metric name, current value, budget target, suspected cause
+
+**4. Resolution**
+- Fix the root cause — do not just adjust the budget threshold
+- Budget thresholds should only change after a team discussion and explicit approval from [tech lead / EM]
+- Document the breach in the [performance log / incident record]
+
+**Budget change policy:** Budget thresholds may only be relaxed if: (a) the feature delivering the regression has measurable business value that outweighs the performance cost, and (b) the change is reviewed and approved by [tech lead].
+
+---
+
+## Performance Review Cadence
+
+| Trigger | Action |
+|---|---|
+| Every sprint | Review P95/P99 latency trends; flag any creeping degradation |
+| Every quarter | Full performance budget review — update baselines, adjust targets, audit tooling |
+| After major feature launch | Re-measure all Core Web Vitals and API SLOs; update baselines |
+| After infrastructure change | Re-run full synthetic test suite; confirm no regression |
+| After dependency upgrade | Run bundle size diff; confirm no unexpected size increase |
+
+**Next scheduled review:** [Date]
+**Review owner:** [Name / role]
+
+---
+
+## Quality Checks
+
+- [ ] Every budget threshold is a specific number — not a range or "TBD"
+- [ ] Both frontend (if applicable) and backend targets are defined — not just one or the other
+- [ ] Measurement tooling is named with a link to the dashboard or config file
+- [ ] CI enforcement is configured for at least one gate (build-time or deploy-time)
+- [ ] Budget breach response process names specific Slack channels and owners
+- [ ] Budget thresholds are anchored to baseline measurements or a justified target — not pulled from thin air
+- [ ] Per-journey targets are defined for critical user journeys, not just global averages
@@ -0,0 +1,399 @@
+---
+name: rfc-writer
+description: "Write an engineering RFC (Request for Comments) for a technical decision, architectural change, or significant implementation approach. Use when asked to write an RFC, document a technical proposal, create a design doc, write an architecture decision for review, or produce a technical specification for team feedback. Produces a complete RFC document covering problem statement, motivation, proposed solution, alternatives rejected, implementation plan, migration plan, security and performance implications, observability changes, rollout plan, and open questions."
+---
+
+# RFC Writer Skill
+
+Produce a complete engineering RFC (Request for Comments) for a technical decision or architectural change. An RFC is a structured proposal document — not a persuasion document. Its purpose is to expose a decision to scrutiny, surface trade-offs, document alternatives considered, and create a permanent record of why a choice was made.
+
+A good RFC makes it possible for someone who wasn't in the room to understand years later why the team built something the way they did.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **RFC title and author** — what this RFC is about and who is proposing it
+- **Problem being solved** — what is broken, missing, or inadequate today; why action is needed now
+- **Proposed solution** — the approach the author is recommending, at least at a high level
+- **Context and constraints** — team size, existing architecture, timeline pressures, budget limits, compliance requirements
+- **Alternatives considered** — at least 2 alternative approaches the author has thought about
+- **Current status** — is this pre-decision (seeking feedback) or post-decision (documenting a made decision)?
+
+## Output Format
+
+---
+
+# RFC [Number]: [Title]
+
+**Author:** [Name] | **Team:** [Team name]
+**Created:** [Date] | **Last updated:** [Date]
+**Status:** Draft | In Review | Approved | Rejected | Superseded by RFC-[X]
+**Ticket:** [JIRA-XXX] | **Slack thread:** [#channel link]
+**Review deadline:** [Date — when comments should be submitted by]
+
+---
+
+## Abstract
+
+[2–4 sentences summarising the entire RFC. Should stand alone — someone reading only this should understand what is being proposed, why, and what the main trade-off is. Write this last.]
+
+---
+
+## 1. Problem Statement
+
+[Describe the problem being solved. Focus on the *problem*, not the solution. Be specific and quantified where possible.]
+
+**Current state:**
+[Describe how things work today — the existing system, process, or architecture. Include any relevant constraints or limitations.]
+
+**Why this is a problem now:**
+[Why is this being addressed now rather than earlier or later? Reference metrics, incidents, product requirements, or scaling thresholds that make this urgent or timely.]
+
+**Example of the problem in practice:**
+[A concrete scenario or incident that illustrates the problem. This helps reviewers understand the real-world impact, not just the abstract description.]
+
+```
+// Example: current behaviour that illustrates the problem
+[code snippet, log output, or sequence description showing the problem]
+```
+
+**Impact of not solving this:**
+- [Impact 1 — e.g. "New tenant onboarding requires 3 hours of manual configuration per account"]
+- [Impact 2 — e.g. "Auth service handles 400 req/s; projected to hit capacity within 8 weeks at current growth"]
+- [Impact 3 — e.g. "Current approach is incompatible with the upcoming multi-region requirement"]
+
+---
+
+## 2. Goals and Non-Goals
+
+**Goals:**
+- [ ] [Specific, measurable outcome — e.g. "Reduce tenant onboarding time from 3 hours to <5 minutes"]
+- [ ] [e.g. "Support 2,000 req/s on the auth service with P99 latency ≤50ms"]
+- [ ] [e.g. "Enable multi-region deployment without changes to the application layer"]
+
+**Non-goals:** *(what this RFC explicitly does not address)*
+- [e.g. "This RFC does not address authentication for internal service-to-service calls — see RFC-042"]
+- [e.g. "Performance improvements to the existing system — this RFC replaces it"]
+- [e.g. "Migration of historical data — covered in a follow-on RFC"]
+
+**Success metrics:**
+| Metric | Current | Target | Measurement method |
+|---|---|---|---|
+| [e.g. Onboarding time] | [3 hours] | [<5 minutes] | [Prometheus histogram on onboarding job duration] |
+| [e.g. Auth latency P99] | [120ms] | [≤50ms] | [Datadog APM] |
+| [e.g. Engineer setup time] | [4 hours] | [<30 minutes] | [Onboarding survey] |
+
+---
+
+## 3. Background and Motivation
+
+[Provide the context a reviewer needs to evaluate the proposal. This is not a repeat of the problem statement — it is the surrounding technical and business context.]
+
+**Existing system overview:**
+[Describe the relevant parts of the current architecture. Include an ASCII diagram if the relationships between components help understanding.]
+
+```
+[ASCII diagram of current architecture — optional but strongly recommended for architectural RFCs]
+
+  ┌──────────┐     ┌──────────────┐     ┌──────────────┐
+  │  Client  │────▶│  [Service A] │────▶│  [Service B] │
+  └──────────┘     └──────────────┘     └──────────────┘
+                           │
+                           ▼
+                   ┌──────────────┐
+                   │  [Database]  │
+                   └──────────────┘
+```
+
+**Prior work and related decisions:**
+- [RFC-XXX: Title — relevant previous decision; link]
+- [ADR-XXX: Title — architectural decision record]
+- [Any external standards, blog posts, or vendor documentation that informs this proposal]
+
+**Constraints:**
+- [e.g. Must remain backward compatible with v1 API clients for 12 months]
+- [e.g. Team has no Rust expertise — solution must be in Python or Go]
+- [e.g. Must be deployable without a maintenance window]
+
+---
+
+## 4. Proposed Solution
+
+[Describe the proposed approach clearly and specifically. Include enough detail that an engineer could begin implementing from this document, but don't write the code — that is for the PR.]
+
+### 4.1 High-Level Approach
+
+[1–3 paragraphs describing the overall solution. Explain the key idea and why it solves the problem.]
+
+### 4.2 Architecture
+
+```
+[ASCII diagram of the proposed architecture — what the system looks like after this RFC is implemented]
+
+  ┌──────────┐     ┌──────────────────┐     ┌──────────────┐
+  │  Client  │────▶│  [New Component] │────▶│  [Service B] │
+  └──────────┘     └──────────────────┘     └──────────────┘
+                           │                       │
+                           ▼                       ▼
+                   ┌──────────────┐       ┌──────────────┐
+                   │  [Store A]   │       │  [Store B]   │
+                   └──────────────┘       └──────────────┘
+```
+
+### 4.3 Detailed Design
+
+[Break the solution into its key components or decisions. For each, explain what it does and why it was designed this way.]
+
+**Component / Decision 1: [Name]**
+
+[Description of this component — what it does, how it works, why this approach was chosen.]
+
+```
+// Example interface, API contract, or pseudocode (not implementation code)
+[Relevant schema, API definition, data flow, or pseudocode]
+```
+
+**Component / Decision 2: [Name]**
+
+[Description]
+
+**Component / Decision 3: [Name]**
+
+[Description]
+
+### 4.4 API Changes
+
+*Complete this section if the RFC introduces or modifies any API endpoints, events, or interfaces.*
+
+**New endpoints / events:**
+```
+[HTTP method + path or event name]
+Request: { ... }
+Response: { ... }
+```
+
+**Modified endpoints:**
+- `[endpoint]`: [what changes and why; backward compatibility note]
+
+**Deprecated endpoints:**
+- `[endpoint]`: deprecated in favour of `[new endpoint]` — removal timeline: [date/version]
+
+### 4.5 Data Model Changes
+
+*Complete this section if any database schema or data structure changes are required.*
+
+[Describe schema changes at a high level. Reference the database-migration-plan skill for detailed migration steps.]
+
+```sql
+-- Key schema changes (abbreviated — full migration in [link])
+[DDL statements for key additions/changes]
+```
+
+---
+
+## 5. Alternatives Considered
+
+*Every alternative must include an explicit reason why it was rejected. "We went with the proposed solution" is not a reason.*
+
+### Alternative 1: [Name]
+
+**Description:**
+[What this alternative would involve.]
+
+**Pros:**
+- [Pro 1]
+- [Pro 2]
+
+**Cons:**
+- [Con 1]
+- [Con 2]
+
+**Why rejected:**
+[Specific reason — e.g. "Requires 3× the infrastructure cost", "Incompatible with multi-region requirement", "Team has no expertise in this technology and the ramp-up would miss the Q3 deadline"]
+
+---
+
+### Alternative 2: [Name]
+
+**Description:**
+[What this alternative would involve.]
+
+**Pros:**
+- [Pro 1]
+- [Pro 2]
+
+**Cons:**
+- [Con 1]
+- [Con 2]
+
+**Why rejected:**
+[Specific reason]
+
+---
+
+### Alternative 3: Do nothing / defer
+
+**Description:**
+Accept the current state and revisit the problem in [timeframe].
+
+**Why rejected:**
+[Why deferring is not acceptable — reference the impact of not solving this from Section 1.]
+
+---
+
+## 6. Implementation Plan
+
+**Estimated effort:** [X engineer-weeks] | **Target completion:** [Date / Quarter]
+**Team:** [Who is building this — names or roles]
+
+| Phase | Description | Duration | Dependencies | Owner |
+|---|---|---|---|---|
+| 1 | [e.g. Core implementation — new component built and tested] | [X weeks] | [None] | [Name] |
+| 2 | [e.g. Integration — connect new component to existing services] | [X weeks] | [Phase 1 complete] | [Name] |
+| 3 | [e.g. Rollout — canary deploy, then full rollout] | [X weeks] | [Phase 2 + staging validated] | [Name] |
+| 4 | [e.g. Cleanup — deprecate old system, remove feature flags] | [X weeks] | [Phase 3 stable for X weeks] | [Name] |
+
+**Key milestones:**
+- [ ] [Date]: [Milestone — e.g. "Core implementation complete and code-reviewed"]
+- [ ] [Date]: [Milestone — e.g. "Staging environment validation complete"]
+- [ ] [Date]: [Milestone — e.g. "10% canary traffic without regression"]
+- [ ] [Date]: [Milestone — e.g. "Full rollout complete"]
+- [ ] [Date]: [Milestone — e.g. "Old system decommissioned"]
+
+---
+
+## 7. Migration Plan
+
+*Complete this section if the RFC requires migrating existing users, data, or API consumers.*
+
+**Migration strategy:** [Big-bang / Phased / Parallel-run / Opt-in]
+
+**Who is affected:**
+- [e.g. All existing API v1 consumers — requires updated client libraries]
+- [e.g. X million rows in the `orders` table require backfilling]
+
+**Migration steps:**
+1. [Step 1 — describe action, who does it, estimated duration]
+2. [Step 2]
+3. [Step 3]
+
+**Backward compatibility window:** [How long will the old system/API remain available?]
+
+**Communication plan:**
+- [Who needs to be notified, when, and how — e.g. "API consumers will receive a deprecation notice 3 months before the old endpoint is removed"]
+
+---
+
+## 8. Security Implications
+
+[Describe the security impact of this change. If there are no security implications, state that explicitly with reasoning — do not leave this section blank.]
+
+| Concern | Impact | Mitigation |
+|---|---|---|
+| [e.g. New API endpoint exposed to internet] | [e.g. New attack surface] | [e.g. Rate limiting, auth required, WAF rules] |
+| [e.g. New data stored — user PII] | [e.g. GDPR scope expanded] | [e.g. Encrypted at rest, access log, data retention policy] |
+| [e.g. Service-to-service communication] | [e.g. Token forgery risk] | [e.g. mTLS between services] |
+
+**Has a threat model been produced or updated?** [Yes — link / No — required before implementation / Not required — reason]
+
+---
+
+## 9. Performance Implications
+
+[Describe the expected performance impact. Include projections for the new system and how it was estimated.]
+
+| Metric | Current | Projected | Measurement method |
+|---|---|---|---|
+| [e.g. P99 latency — /api/auth] | [120ms] | [≤50ms] | [Load test results — link] |
+| [e.g. Database query count per request] | [12] | [3] | [Query logging in staging] |
+| [e.g. Memory per instance] | [512MB] | [768MB] | [Profiling — link] |
+| [e.g. Infrastructure cost] | [$X/month] | [$Y/month] | [AWS cost calculator estimate] |
+
+**Load testing:** [Has load testing been done? Link to results. If not, when will it be done?]
+
+**Performance risks:**
+- [Risk 1 — e.g. "New component adds a network hop that may increase tail latency under congestion — needs validation at 2× peak load"]
+
+---
+
+## 10. Observability Changes
+
+*Describe what new or changed metrics, logs, traces, and alerts this RFC introduces.*
+
+**New metrics:**
+| Metric name | Type | Description | Alert threshold |
+|---|---|---|---|
+| `[service].[component].[metric]` | [counter/gauge/histogram] | [What it measures] | [e.g. P99 > 100ms for 5 min] |
+
+**New log events:**
+| Event | Level | When emitted | Key fields |
+|---|---|---|---|
+| `[event.name]` | INFO | [When] | `user_id`, `duration_ms`, `result` |
+
+**Distributed tracing:** [Are spans added for new components? Which operations are instrumented?]
+
+**Dashboard changes:** [New dashboard / updated existing dashboard — link]
+
+---
+
+## 11. Rollout Plan
+
+**Rollout strategy:** [Feature flag / Canary / Blue-green / Gradual traffic shift / Full deploy]
+
+| Stage | Traffic % | Duration | Success criteria | Rollback trigger |
+|---|---|---|---|---|
+| Internal testing | 0% (dogfood) | [X days] | [No errors in internal usage] | Any error |
+| Canary | 1% | [X hours] | [Error rate <0.1%; P99 latency within budget] | Error rate >0.5% |
+| Limited rollout | 10% | [X days] | [As above + business metrics stable] | Error rate >0.2% |
+| Full rollout | 100% | — | [All success metrics from Section 2 met] | Any SLO breach |
+
+**Feature flag:** [Name of feature flag, if applicable] — managed in [LaunchDarkly / Unleash / config]
+
+**Rollback procedure:**
+```
+// How to roll back if the rollout needs to be reversed
+1. [Step 1 — e.g. Toggle feature flag to off]
+2. [Step 2 — e.g. Deploy previous version]
+3. [Step 3 — e.g. Notify stakeholders]
+```
+
+---
+
+## 12. Open Questions
+
+[List any unresolved questions, design decisions not yet made, or areas where the author is specifically seeking feedback. Assign an owner and a resolution deadline for each.]
+
+| # | Question | Owner | Deadline | Resolution |
+|---|---|---|---|---|
+| 1 | [e.g. Should we use optimistic or pessimistic locking for concurrent updates to [resource]?] | [Name] | [Date] | [Pending / [Answer]] |
+| 2 | [e.g. What is the retention policy for [new data type]?] | [Name] | [Date] | [Pending / [Answer]] |
+| 3 | [e.g. Do we need a read replica for this query pattern at launch, or can we defer it?] | [Name] | [Date] | [Pending / [Answer]] |
+
+---
+
+## 13. Decision
+
+*To be filled in after the review period closes.*
+
+**Decision:** [Approved / Rejected / Approved with modifications]
+**Decision date:** [Date]
+**Decision makers:** [Names]
+
+**Summary of key feedback addressed:**
+- [Feedback item and how it was resolved]
+
+**Conditions of approval (if any):**
+- [e.g. Must complete load testing before Phase 2 begins]
+
+---
+
+## Quality Checks
+
+- [ ] The problem statement is specific and quantified — not "the current system is slow" but "P99 latency is 800ms; budget is 200ms"
+- [ ] Goals section includes measurable success metrics, not aspirational statements
+- [ ] Every alternative has an explicit rejection reason — not just a list of cons
+- [ ] Security implications section is completed, not left blank
+- [ ] Performance implications include projected numbers, not just "should be better"
+- [ ] Open questions are assigned to named owners with deadlines — not floating
+- [ ] The RFC is written to be read by someone who was not in the planning conversations
+- [ ] Migration plan addresses all affected parties — users, API consumers, data — not just the technical steps
@@ -0,0 +1,253 @@
+---
+name: security-threat-model
+description: "Write a STRIDE-based threat model for a service or feature. Use when asked to produce a threat model, document security risks, identify attack vectors, assess a service's security posture, or prepare for a security design review. Produces a structured threat model covering assets, trust boundaries, STRIDE threat enumeration per component, risk scores, mitigation controls, and residual risk sign-off."
+---
+
+# Security Threat Model Skill
+
+Produce a complete STRIDE-based threat model for a service or feature. A threat model is not a list of things that could go wrong — it is a structured analysis of attackers, assets, boundaries, and controls that lets an engineering team make informed, documented security decisions.
+
+A good threat model is specific enough that a new engineer can understand what is being protected, why each control exists, and what risk the team has accepted.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name and description** — what the service does, who uses it
+- **Architecture overview** — components, dependencies, data flows (a diagram description or ASCII diagram is fine)
+- **Deployment environment** — cloud provider, VPC/network topology, where it runs (Kubernetes, ECS, VMs, serverless)
+- **Data sensitivity** — what data does this service handle? PII, payment data, credentials, internal-only?
+- **Existing controls** — authentication method, encryption in transit/at rest, current WAF/firewall, existing security scanning
+- **Trust levels** — who are the principals? (anonymous public, authenticated users, internal services, admins)
+
+## Output Format
+
+---
+
+# Security Threat Model: [Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Author:** [Name] | **Reviewed by:** [Security lead / peer]
+**Date:** [Date] | **Next review:** [Date — recommend 6 months or after major architecture change]
+**Classification:** [Internal / Confidential]
+
+---
+
+## 1. Overview
+
+[2–3 sentences describing the service, its role in the system, and the scope of this threat model. State what is in scope and what is explicitly out of scope.]
+
+**In scope:**
+- [Component or data flow]
+- [Component or data flow]
+
+**Out of scope:**
+- [e.g. Third-party payment processor internals]
+- [e.g. Corporate network / end-user devices]
+
+---
+
+## 2. Asset Register
+
+Assets are the things worth protecting — data, capabilities, and reputational value.
+
+| Asset | Description | Sensitivity | Owner |
+|---|---|---|---|
+| [e.g. User PII] | Names, email addresses, profile data | High — GDPR-regulated | [Team] |
+| [e.g. API credentials] | Service-to-service auth tokens | Critical | [Team] |
+| [e.g. Session tokens] | User authentication state | High | [Team] |
+| [e.g. Audit logs] | Record of user and admin actions | Medium | [Team] |
+| [e.g. Service availability] | Uptime of the [X] endpoint | Medium | [Team] |
+
+**Data classification key:**
+- **Critical** — Credential material; exposure enables direct system compromise
+- **High** — PII, financial data, health data; regulated or high reputational impact
+- **Medium** — Internal configuration, non-sensitive business data
+- **Low** — Public information, anonymised data
+
+---
+
+## 3. Trust Boundaries and Architecture
+
+Trust boundaries are the lines that separate zones with different trust levels. Threats often occur when data or requests cross a boundary.
+
+```
+  ┌─────────────────────────────────────────────────────────────────┐
+  │  INTERNET (Untrusted)                                           │
+  │                                                                 │
+  │   [Public User]          [Bot / Attacker]                       │
+  └──────────────────────────────┬──────────────────────────────────┘
+                                 │ HTTPS
+                    ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
+                    Trust Boundary: Public → DMZ
+                    ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
+                                 ▼
+  ┌──────────────────────────────────────────────────────────────────┐
+  │  DMZ / Edge Layer                                                │
+  │   ┌────────────┐     ┌──────────────┐                           │
+  │   │  WAF / CDN │────▶│  API Gateway │                           │
+  │   └────────────┘     └──────┬───────┘                           │
+  └──────────────────────────────┼───────────────────────────────────┘
+                    ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
+                    Trust Boundary: Edge → Application VPC
+                    ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
+                                 ▼
+  ┌──────────────────────────────────────────────────────────────────┐
+  │  Application VPC (Private)                                       │
+  │   ┌──────────────┐     ┌────────────┐     ┌──────────────────┐  │
+  │   │  [Service A] │────▶│ [Service B]│────▶│  [Database]      │  │
+  │   └──────────────┘     └────────────┘     └──────────────────┘  │
+  │                                ▲                                  │
+  │                                │                                  │
+  │   ┌──────────────┐             │                                  │
+  │   │  Admin (IAM) │─────────────┘                                 │
+  └──────────────────────────────────────────────────────────────────┘
+```
+
+**Trust Boundaries identified:**
+
+| Boundary | From | To | Auth mechanism | Encrypted |
+|---|---|---|---|---|
+| TB-1 | Public internet | API Gateway | [JWT / OAuth / API key] | TLS 1.2+ |
+| TB-2 | API Gateway | Service A | [mTLS / internal JWT / IAM role] | [Yes/No] |
+| TB-3 | Service A | Database | [Connection string + IAM / username+password] | [Yes/No] |
+| TB-4 | Admin | Service B | [IAM role / VPN + MFA] | TLS |
+
+---
+
+## 4. STRIDE Threat Analysis
+
+STRIDE is a threat classification framework. For each significant component, enumerate threats in each category.
+
+**STRIDE key:**
+- **S** — Spoofing: Impersonating another user, service, or system
+- **T** — Tampering: Modifying data or code without authorisation
+- **R** — Repudiation: Denying an action occurred; insufficient audit trail
+- **I** — Information Disclosure: Exposing data to unauthorised parties
+- **D** — Denial of Service: Making the service unavailable
+- **E** — Elevation of Privilege: Gaining capabilities beyond what is authorised
+
+### Component: [API Gateway / Auth Layer]
+
+| ID | Category | Threat | Attack vector | Existing control |
+|---|---|---|---|---|
+| T-001 | S | Attacker forges a JWT token to authenticate as another user | Weak signing key or algorithm confusion (alg:none) | [e.g. RS256 with key rotation / none] |
+| T-002 | S | Attacker replays a stolen session token | Theft via XSS or network sniff | [e.g. Token expiry + refresh rotation] |
+| T-003 | T | Attacker modifies request headers to bypass tenant isolation | Missing validation of tenant ID header | [e.g. Server-side tenant resolution / none] |
+| T-004 | R | No audit trail for admin authentication events | Logging not configured for auth failures | [e.g. CloudTrail enabled / none] |
+| T-005 | I | Auth error messages reveal whether an email exists | Verbose error responses | [e.g. Normalised error responses / none] |
+| T-006 | D | Credential stuffing exhausts rate limits and blocks legitimate users | Automated login attempts | [e.g. Rate limiting per IP + CAPTCHA / none] |
+| T-007 | E | Compromised low-privilege token used to call admin endpoint | Missing role check on admin routes | [e.g. RBAC middleware on all routes / none] |
+
+### Component: [Application Service / Business Logic]
+
+| ID | Category | Threat | Attack vector | Existing control |
+|---|---|---|---|---|
+| T-008 | T | SQL/NoSQL injection via unsanitised user input | Unparameterised queries | [e.g. ORM with parameterised queries / none] |
+| T-009 | T | Mass assignment — attacker sets fields they should not (e.g. `isAdmin: true`) | API accepts extra fields without allowlist | [e.g. Input validation / none] |
+| T-010 | I | Insecure direct object reference — user accesses another user's resource | Missing ownership check on resource ID | [e.g. Ownership middleware / none] |
+| T-011 | I | Sensitive data in application logs (PII, tokens) | Over-logging in debug mode | [e.g. Log scrubbing / none] |
+| T-012 | D | Unprotected expensive endpoint triggers large DB scan | No pagination or query cost limit | [e.g. Pagination enforced / none] |
+| T-013 | R | Business-critical state changes not logged | No audit event on [operation] | [e.g. Audit log table / none] |
+
+### Component: [Database]
+
+| ID | Category | Threat | Attack vector | Existing control |
+|---|---|---|---|---|
+| T-014 | I | Database exposed to internet (misconfigured security group) | Direct connection from outside VPC | [e.g. No public IP, security group restricts to app subnet] |
+| T-015 | I | Backup snapshots not encrypted or accessible to wrong accounts | Unencrypted snapshot, public S3 | [e.g. Encrypted snapshots, private S3 bucket] |
+| T-016 | T | Privilege escalation via DB account with excessive permissions | App uses a superuser DB account | [e.g. Least-privilege DB role per service / none] |
+| T-017 | D | Runaway query or bulk delete causes data loss or outage | No query timeout or soft-delete | [e.g. Statement timeout, soft-delete on critical tables / none] |
+
+### Component: [Internal Service-to-Service Communication]
+
+| ID | Category | Threat | Attack vector | Existing control |
+|---|---|---|---|---|
+| T-018 | S | Rogue internal service impersonates a trusted service | No mutual authentication between services | [e.g. mTLS / service mesh / none] |
+| T-019 | I | Internal traffic sniffed on shared network | Unencrypted service-to-service calls | [e.g. Service mesh with TLS / none] |
+| T-020 | E | Compromised internal service calls privileged endpoints | No scoping on internal tokens | [e.g. Scoped service tokens / none] |
+
+---
+
+## 5. Risk Register
+
+Score each threat: **Likelihood (1–5)** × **Impact (1–5)** = **Risk Score (1–25)**
+
+Priority bands: Critical (20–25) | High (12–19) | Medium (6–11) | Low (1–5)
+
+| ID | Threat summary | Likelihood | Impact | Score | Priority | Status |
+|---|---|---|---|---|---|---|
+| T-001 | JWT forgery — auth bypass | 2 | 5 | 10 | Medium | [Open / Mitigated / Accepted] |
+| T-002 | Session token replay | 3 | 4 | 12 | High | [Open / Mitigated / Accepted] |
+| T-007 | Privilege escalation via missing role check | 3 | 5 | 15 | High | [Open / Mitigated / Accepted] |
+| T-008 | SQL injection | 2 | 5 | 10 | Medium | [Open / Mitigated / Accepted] |
+| T-010 | IDOR — cross-user data access | 3 | 4 | 12 | High | [Open / Mitigated / Accepted] |
+| T-014 | Database exposed to internet | 1 | 5 | 5 | Low | [Open / Mitigated / Accepted] |
+| T-018 | Rogue internal service impersonation | 2 | 4 | 8 | Medium | [Open / Mitigated / Accepted] |
+
+---
+
+## 6. Mitigations Table
+
+For every Open threat with priority Medium or above, define a specific mitigation.
+
+| ID | Threat | Mitigation | Owner | Target date | Ticket |
+|---|---|---|---|---|---|
+| T-002 | Session token replay | Implement token rotation on refresh — invalidate old token server-side immediately | [Engineer name] | [Date] | [JIRA-123] |
+| T-007 | Privilege escalation | Add RBAC middleware to all `/admin/*` routes; write integration test for role boundary | [Engineer name] | [Date] | [JIRA-124] |
+| T-010 | IDOR | Add ownership assertion to all resource-fetching service methods; add to code review checklist | [Engineer name] | [Date] | [JIRA-125] |
+| T-011 | PII in logs | Audit logging calls for PII fields; add scrubbing to logger middleware | [Engineer name] | [Date] | [JIRA-126] |
+| T-018 | Rogue service impersonation | Enable mTLS via service mesh or issue scoped service tokens per service | [Engineer name] | [Date] | [JIRA-127] |
+
+---
+
+## 7. Accepted Risks
+
+Accepted risks are threats the team has decided not to mitigate right now. Every accepted risk must have a named owner and a review date.
+
+| ID | Threat | Reason for acceptance | Risk owner | Review date |
+|---|---|---|---|---|
+| T-014 | Database public exposure | Database has no public IP assigned; control already in place — accepted as low likelihood | [Name] | [Date] |
+| [ID] | [Threat] | [Reason — e.g. "Effort exceeds risk at current scale; re-evaluate at 10× traffic"] | [Name] | [Date] |
+
+---
+
+## 8. Security Controls Summary
+
+| Control | Type | Covers threats | Implemented |
+|---|---|---|---|
+| JWT RS256 with 15-min expiry | Preventive | T-001, T-002 | [Yes / Partial / No] |
+| RBAC middleware on all routes | Preventive | T-007, T-020 | [Yes / Partial / No] |
+| Parameterised queries (ORM) | Preventive | T-008 | [Yes / Partial / No] |
+| Rate limiting (100 req/min per IP) | Preventive | T-006, T-012 | [Yes / Partial / No] |
+| CloudTrail / audit logging | Detective | T-004, T-013 | [Yes / Partial / No] |
+| Automated SAST in CI pipeline | Detective | T-008, T-009 | [Yes / Partial / No] |
+| Encrypted backups + private S3 | Preventive | T-015 | [Yes / Partial / No] |
+| Least-privilege DB role | Preventive | T-016 | [Yes / Partial / No] |
+| Incident response runbook | Corrective | All | [Yes / Partial / No] |
+
+---
+
+## 9. Review Cadence
+
+| Trigger | Action |
+|---|---|
+| Every 6 months | Full threat model review — update risk scores, close mitigated items |
+| Major architecture change | Update trust boundary diagram and re-run STRIDE for new components |
+| Security incident | Review relevant threats; add any newly discovered vectors |
+| New data classification | Add assets to register; assess whether new STRIDE categories apply |
+| Third-party dependency added | Assess supply chain threats for the new dependency |
+
+**Next scheduled review:** [Date]
+**Review owner:** [Name / Security lead]
+
+---
+
+## Quality Checks
+
+- [ ] Every trust boundary is named and its authentication mechanism is specified — not left as "TBD"
+- [ ] Every Critical and High risk in the risk register has a mitigation with a named owner and a target date
+- [ ] Every accepted risk has a named risk owner and a review date — no unowned accepted risks
+- [ ] The asset register includes data sensitivity levels and at least one entry for credential material
+- [ ] STRIDE analysis covers all major components — not just the API layer
+- [ ] Mitigation actions are specific enough to become a ticket (not "improve security")
+- [ ] The ASCII trust boundary diagram matches the architecture description provided
@@ -0,0 +1,292 @@
+---
+name: service-catalog-entry
+description: "Write a service catalog entry for a microservice or internal platform service — covering service identity, purpose, architecture context, SLAs, API contract summary, data classification, dependencies, operational runbooks, and known limitations. Use when asked to document a service for an internal developer portal, write a service README for a platform catalog, create a service overview page, or onboard a new service to a service registry. Produces a complete service catalog entry suitable for an internal developer portal or wiki."
+---
+
+# Service Catalog Entry Skill
+
+Produce a complete service catalog entry for a microservice or internal platform service — giving any engineer at the company the context they need to understand what the service does, how to depend on it, what its reliability characteristics are, and where to go when something goes wrong. A well-written catalog entry eliminates "who owns this?" and "is this safe to use?" questions that slow down teams depending on shared services.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** — the canonical identifier used in code, monitoring, and deployments
+- **Team and owner** — team name, tech lead name, and on-call contact
+- **Architecture overview** — what the service does, what calls it, and what it calls
+- **SLA requirements** — availability target, latency SLO, support tier, and maintenance window
+- **Key APIs** — the most important endpoints other teams use (method, path, brief description)
+- **Data handled** — what data the service stores or processes, sensitivity classification, retention
+
+## Output Format
+
+---
+
+# Service Catalog: [Service Name]
+
+> **[One sentence — what this service does for consumers, in plain language]**
+>
+> *e.g. "The Payments Service processes charge, refund, and subscription billing events for all Acme products."*
+
+---
+
+## Identity
+
+| Field | Value |
+|---|---|
+| **Service name** | `[service-name]` |
+| **Canonical repository** | [https://github.com/[org]/[repo]] |
+| **Owner team** | [Team name] |
+| **Tech lead** | [Name] ([Slack: @handle]) |
+| **On-call rotation** | [PagerDuty service link] |
+| **Slack channel** | `#[team-channel]` |
+| **Support tier** | [Tier 1 — 24/7 / Tier 2 — business hours / Tier 3 — best effort] |
+| **Status** | [Active / Deprecated / Sunset date: YYYY-MM-DD] |
+| **Language / runtime** | [e.g. Go 1.22 / Python 3.12 / Node 20] |
+| **Deployment platform** | [Kubernetes / ECS / Lambda / etc.] |
+| **Environments** | [Production: URL] | [Staging: URL] | [Dev: URL] |
+
+---
+
+## What It Does
+
+[Two to three paragraphs in plain language — no jargon or acronyms without explanation.]
+
+[Paragraph 1: The business problem this service solves. What would break or be missing if this service did not exist?]
+
+[Paragraph 2: How it works at a high level — the main processing model (e.g. request/response API, event-driven consumer, batch processor), what triggers it, and what it produces.]
+
+[Paragraph 3: What this service is NOT responsible for — the explicit boundaries. This prevents other teams from building incorrect assumptions about scope.]
+
+---
+
+## Architecture Context
+
+### System Diagram
+
+```
+[Upstream callers]          [This Service]             [Downstream dependencies]
+                                                        
+  [Web App]  ──────────→                          ──→  [Primary Database — PostgreSQL]
+  [Mobile API]  ────────→  [Service Name]         ──→  [Cache — Redis]
+  [Partner API] ────────→  (Port 8080/gRPC)       ──→  [Message Queue — Kafka/SQS]
+                                                   ──→  [External Service / API]
+                           ↓ emits events to
+                        [Event Bus / SNS]
+                           ↓ consumed by
+                  [Downstream Service A]
+                  [Downstream Service B]
+```
+
+### Who Depends on This Service
+
+| Caller | How they use it | Contact |
+|---|---|---|
+| [Service / Team A] | [e.g. "Calls POST /charges to initiate payments"] | [Slack: #team-a] |
+| [Service / Team B] | [e.g. "Subscribes to payment.completed events via Kafka topic"] | [Slack: #team-b] |
+| [Service / Team C] | [e.g. "Calls GET /subscriptions for billing status"] | [Slack: #team-c] |
+
+### What This Service Depends On
+
+| Dependency | Type | Criticality | Their on-call |
+|---|---|---|---|
+| [PostgreSQL instance] | Database | Critical — all writes fail without it | [DBA team: #db-oncall] |
+| [Redis cluster] | Cache | High — latency degrades without it | [Infra team: #infra-oncall] |
+| [Kafka cluster] | Message queue | High — async events queue | [Infra team: #infra-oncall] |
+| [Stripe API] | External API | Critical — payment processing fails | [vendor status: status.stripe.com] |
+| [Auth Service] | Internal service | Critical — all auth fails | [Auth team: #auth-oncall] |
+
+---
+
+## Service Level Agreement
+
+### Availability and Latency
+
+| SLO | Target | Measurement window | Error budget |
+|---|---|---|---|
+| Availability | [99.9%] | Rolling 30 days | [43 min/month] |
+| p50 latency (key endpoints) | < [50] ms | Rolling 24 hours | — |
+| p99 latency (key endpoints) | < [500] ms | Rolling 24 hours | — |
+| p99.9 latency (key endpoints) | < [2000] ms | Rolling 24 hours | — |
+| Error rate | < [0.1]% | Rolling 1 hour | — |
+
+**SLO dashboard:** [Link to monitoring dashboard]
+**Current error budget remaining:** [Link to SLO dashboard or inline value]
+
+### Support Tiers
+
+| Tier | Scope | Response time | Resolution time |
+|---|---|---|---|
+| P1 — Service down | All authenticated requests failing | 15 minutes | 1 hour |
+| P2 — Significant degradation | Error rate >1% or p99 >2× SLO | 30 minutes | 4 hours |
+| P3 — Minor issues | Non-critical endpoints degraded | Next business day | 3 business days |
+| Feature requests / bugs | Via standard ticket process | [Ticket SLA] | Per roadmap |
+
+**To raise an incident:** Page via [PagerDuty service link] or post in `#incidents`.
+**To raise a feature request or bug:** File a ticket in [JIRA project / GitHub repo Issues].
+
+### Maintenance Windows
+
+- **Planned downtime:** [e.g. "Sundays 02:00–04:00 UTC — advance notice posted to #[team-channel] 48h before"]
+- **Deployment window:** [e.g. "Weekdays 10:00–16:00 UTC — no deploys on Fridays or the day before a public holiday"]
+- **Breaking changes notice:** [e.g. "Minimum 30 days notice for breaking API changes — see versioning policy below"]
+
+---
+
+## API Contract
+
+### Authentication
+
+All API calls require: [e.g. "Bearer token via Authorization header. Tokens are issued by the Auth Service (`/api/v1/token`)"]
+
+```
+Authorization: Bearer [jwt-token]
+Content-Type: application/json
+```
+
+### Base URL
+
+| Environment | Base URL |
+|---|---|
+| Production | `https://[service-name].internal.[company].com` |
+| Staging | `https://[service-name].staging.[company].com` |
+| Local development | `http://localhost:[port]` |
+
+### Key Endpoints
+
+| Method | Path | Description | Auth required | Rate limit |
+|---|---|---|---|---|
+| `GET` | `/health` | Liveness and readiness check | No | None |
+| `GET` | `/api/v1/[resource]` | [Description — e.g. "List resources for the authenticated user"] | Yes | [100 req/min] |
+| `GET` | `/api/v1/[resource]/:id` | [Description — e.g. "Get a single resource by ID"] | Yes | [500 req/min] |
+| `POST` | `/api/v1/[resource]` | [Description — e.g. "Create a new resource"] | Yes | [50 req/min] |
+| `PUT` | `/api/v1/[resource]/:id` | [Description — e.g. "Update an existing resource"] | Yes | [50 req/min] |
+| `DELETE` | `/api/v1/[resource]/:id` | [Description] | Yes | [20 req/min] |
+
+**Full API documentation:** [OpenAPI/Swagger spec URL] | [Postman collection URL]
+
+### Versioning Policy
+
+- API version is in the URL path (`/api/v1/`, `/api/v2/`)
+- Minor additions (new optional fields, new endpoints) are non-breaking — no version bump
+- Breaking changes (removed fields, changed types, authentication changes) require a new major version
+- Deprecated versions are supported for [90 days] after the successor reaches GA
+- Deprecation notices are posted to `#[team-channel]` and emailed to registered consumers
+
+### Error Response Format
+
+```json
+{
+  "error": {
+    "code": "[ERROR_CODE]",
+    "message": "[Human-readable description]",
+    "request_id": "[UUID — include in support tickets]",
+    "details": {}
+  }
+}
+```
+
+Common error codes:
+
+| HTTP status | Error code | Meaning |
+|---|---|---|
+| 400 | `INVALID_REQUEST` | Request body or parameters fail validation |
+| 401 | `UNAUTHENTICATED` | Missing or invalid auth token |
+| 403 | `FORBIDDEN` | Token valid but lacks permission for this resource |
+| 404 | `NOT_FOUND` | Resource does not exist |
+| 409 | `CONFLICT` | Duplicate resource or state conflict |
+| 422 | `UNPROCESSABLE_ENTITY` | Request is valid but violates business rules |
+| 429 | `RATE_LIMITED` | Too many requests — back off and retry |
+| 500 | `INTERNAL_ERROR` | Unexpected server error — include request_id in support ticket |
+| 503 | `SERVICE_UNAVAILABLE` | Downstream dependency unavailable — retry with backoff |
+
+### Events Published (if event-driven)
+
+| Event | Topic / Queue | Schema | Published when |
+|---|---|---|---|
+| `[resource].created` | `[kafka-topic / sns-arn]` | [Schema URL] | [When a new resource is created] |
+| `[resource].updated` | `[kafka-topic / sns-arn]` | [Schema URL] | [When a resource is modified] |
+| `[resource].deleted` | `[kafka-topic / sns-arn]` | [Schema URL] | [When a resource is deleted] |
+
+---
+
+## Data Classification
+
+| Data element | Sensitivity | Stored in | Retention | Encrypted at rest |
+|---|---|---|---|---|
+| [User PII — e.g. email, name] | [PII / Restricted] | [PostgreSQL `users` table] | [Until account deletion] | Yes |
+| [Financial data — e.g. card last 4] | [PCI / Highly restricted] | [PostgreSQL `payment_methods` table] | [7 years per regulations] | Yes — field-level encryption |
+| [Operational logs] | [Internal] | [CloudWatch / Datadog] | [90 days] | Yes (at rest, not searched) |
+| [Anonymised analytics] | [Public] | [Data warehouse] | [Indefinite] | Yes |
+
+**Data residency:** [e.g. "All data stored in us-east-1. EU customer data stored in eu-west-1 per GDPR requirements."]
+**Compliance scope:** [e.g. SOC 2 Type II / PCI DSS Level 2 / HIPAA / GDPR]
+**Data access policy:** [e.g. "Production database access requires [approval process]. Access logged and reviewed quarterly."]
+
+---
+
+## Operational Runbooks
+
+| Runbook | Location | Use when |
+|---|---|---|
+| On-call runbook | [Wiki / GitHub link] | Responding to PagerDuty alerts |
+| Deployment runbook | [Wiki / GitHub link] | Deploying a new version to production |
+| Database migration runbook | [Wiki / GitHub link] | Running schema migrations |
+| Rollback runbook | [Wiki / GitHub link] | Rolling back a bad deploy |
+| Incident response runbook | [Wiki / GitHub link] | Declaring and managing incidents |
+| Disaster recovery plan | [Wiki / GitHub link] | Zone/region failure or data loss |
+
+**Monitoring dashboards:**
+
+| Dashboard | Link | Use it for |
+|---|---|---|
+| Service overview | [Datadog / Grafana link] | Error rate, latency, throughput |
+| Infrastructure | [Link] | CPU, memory, pod health |
+| Database | [Link] | Query performance, connection pool |
+| SLO / error budget | [Link] | Budget burn rate, availability |
+| Dependency health | [Link] | Upstream dependency status |
+
+---
+
+## Known Limitations
+
+Document limitations honestly — this section prevents other teams from building on incorrect assumptions.
+
+| Limitation | Impact | Workaround | Planned fix |
+|---|---|---|---|
+| [e.g. No bulk write API — items must be created one at a time] | [Slow for large imports — N HTTP calls required] | [Use the batch import CLI tool for >100 items] | [Bulk API in Q3 — ticket: [URL]] |
+| [e.g. List endpoints have a maximum page size of 100] | [Cannot retrieve more than 100 items in a single call] | [Paginate using `cursor` parameter] | [No current plan to increase — by design] |
+| [e.g. Rate limits are per-token, not per-service] | [High-traffic consumers may hit limits for other consumers on the same token] | [Request dedicated service-account token] | [Per-service rate limits in roadmap] |
+| [e.g. Eventual consistency on read-after-write for list endpoints] | [Record may not appear in list immediately after creation (<500ms lag)] | [Use GET /:id to confirm creation; do not rely on list for immediate consistency] | [Read-your-writes consistency available via `?consistent=true` — in progress] |
+
+---
+
+## Getting Started
+
+**To start using this service:**
+
+1. Request access: [Link to access request form or instructions]
+2. Get your service account credentials: [Link to process]
+3. Read the API docs: [OpenAPI spec URL]
+4. Try the sandbox environment: `https://[service-name].sandbox.[company].com`
+5. Join the consumer Slack channel: `#[service-name]-consumers`
+
+**Client libraries (if available):**
+
+| Language | Package | Installation |
+|---|---|---|
+| [Python] | [`[package-name]`] | `pip install [package-name]` |
+| [Go] | [`github.com/[org]/[package]`] | `go get github.com/[org]/[package]` |
+| [TypeScript/JS] | [`@[org]/[package]`] | `npm install @[org]/[package]` |
+
+---
+
+## Quality Checks
+
+- [ ] "What It Does" is written without jargon — a new engineer from another team can understand it in under 2 minutes
+- [ ] SLO targets are specific numbers agreed with stakeholders — not aspirational or copied from a template
+- [ ] All direct upstream consumers are listed in the "Who Depends on This" table — no omissions
+- [ ] API error codes are accurate and tested — not aspirational documentation
+- [ ] Known limitations are honest — nothing is glossed over to make the service look better than it is
+- [ ] All runbook links are live — not broken references or TODO placeholders
+- [ ] Data classification includes retention period and encryption status — not just sensitivity level
+- [ ] The entry has been reviewed by at least one consumer team to confirm it matches their experience of the service
@@ -0,0 +1,263 @@
+---
+name: sprint-velocity-analysis
+description: "Analyze sprint velocity data and produce an engineering team health report covering delivery trends, capacity utilization, and improvement recommendations. Use when asked to analyze sprint velocity, review team delivery health, identify delivery risks, or produce a retrospective data analysis. Produces a velocity trend analysis, health diagnosis table, top improvement recommendations with implementation steps, and a next-sprint capacity forecast."
+---
+
+# Sprint Velocity Analysis
+
+Analyze sprint velocity data to produce an honest engineering team health report. The goal is not to generate optimistic-looking charts — it is to surface delivery patterns, identify dysfunction early, and give the team and their manager actionable recommendations. Look for: velocity trends (improving, declining, flat, erratic), story point calibration consistency, carry-over patterns that indicate chronic over-commitment, and capacity-related signals. Produce text-based trend visualizations, a health diagnosis, and specific improvement recommendations with measurable targets.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Sprint history** — for each sprint: sprint name/number, committed story points, completed story points, and number of items carried over to next sprint; ideally 6–8 sprints minimum
+- **Team size and any changes** — current team size and any additions or departures during the data window
+- **Known disruptions** — holidays, company all-hands, on-call incidents, or other events that affected specific sprints
+- **Cycle time data (optional)** — if available, p50 and p90 cycle time per sprint (time from start to done)
+- **Definition of Done** — what "completed" means for this team (merged to main? deployed to prod? accepted by PO?)
+
+If cycle time data is not provided, omit that section and note it as a recommended data source to add.
+
+## Output Format
+
+---
+
+# Sprint Velocity Analysis: [Team Name]
+
+**Analysis period:** Sprint [N] through Sprint [N+7] ([Date range])
+**Team size:** [X engineers] ([note any changes during period])
+**Report date:** [Date]
+**Data source:** [Where this data came from — Jira, Linear, spreadsheet, etc.]
+
+---
+
+## Velocity Trend
+
+### Raw Data
+
+| Sprint | Committed | Completed | Completion Rate | Carried Over | Notes |
+|--------|-----------|-----------|----------------|--------------|-------|
+| [Sprint N] | [X pts] | [X pts] | [X%] | [X pts / X items] | [disruption or context] |
+| [Sprint N+1] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| [Sprint N+2] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| [Sprint N+3] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| [Sprint N+4] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| [Sprint N+5] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| [Sprint N+6] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| [Sprint N+7] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
+| **Average** | **[X pts]** | **[X pts]** | **[X%]** | **[X pts]** | |
+
+### Velocity Chart (Completed Points per Sprint)
+
+```
+Points
+  60 |
+  55 |          ●
+  50 |    ●           ●
+  45 | ●        ●          ●
+  40 |               ●          ●
+  35 |
+  30 |
+     +--+--+--+--+--+--+--+--
+      N N+1 N+2 N+3 N+4 N+5 N+6 N+7
+      Sprint
+
+  ● = Completed points   — = Average ([X pts])
+```
+
+Generate this chart using ASCII characters based on the actual data provided. Scale the Y-axis to the data range. Plot completed (not committed) points. Mark the average as a dashed line.
+
+### Trend Diagnosis
+
+| Metric | Value | Interpretation |
+|--------|-------|----------------|
+| Average velocity | [X pts/sprint] | [Baseline for planning] |
+| Velocity std deviation | [±X pts] | [Low < 15% of avg = stable; High > 25% = erratic] |
+| Trend direction | [Improving / Flat / Declining / Erratic] | [3-sprint trailing average vs. 3-sprint leading average] |
+| Average completion rate | [X%] | [Healthy: 80–95%; < 75% = chronic over-commitment] |
+| Carry-over rate | [X% of committed points carried over per sprint] | [Healthy: < 15%; > 25% = systemic issue] |
+| Sprints with completion rate < 75% | [X of 8 sprints] | [> 3 of 8 = structural problem, not noise] |
+
+---
+
+## Story Point Calibration
+
+Story points are only useful if they are applied consistently. Look for these calibration signals in the data:
+
+| Signal | Observed | Interpretation |
+|--------|----------|----------------|
+| High variance in velocity despite stable team size | [Yes / No] | Suggests inconsistent estimation — same effort scored differently week to week |
+| Consistent over-commitment (committed >> completed) | [Yes / No — by avg X pts per sprint] | Team is sandbagging estimates or ignoring historical capacity |
+| Consistent under-commitment (completed >> committed by > 20%) | [Yes / No] | Team is over-padding estimates or pulling in unplanned work frequently |
+| Frequent large items (> 13 pts) in carry-over | [Yes / No] | Items are too large to estimate reliably — need better decomposition |
+| Velocity cliff after team change | [Yes / No — Sprint N+X] | Team did not re-baseline capacity after composition changed |
+
+**Calibration verdict:** [Well-calibrated / Needs recalibration / Severely uncalibrated — one sentence explanation tied to the signals above]
+
+**If recalibration is needed:** [Specific recommendation — e.g., "Run a calibration session using the last 20 completed items, re-score them as a team, and use the resulting relative sizes to anchor future estimates."]
+
+---
+
+## Carry-Over Pattern Analysis
+
+Carry-over is the most reliable leading indicator of commitment reliability problems.
+
+| Sprint | Carried-Over Items | Common Themes in Carry-Over |
+|--------|-------------------|----------------------------|
+| [Sprint N] | [X items / X pts] | [Technical debt, dependency blocked, scoped wrong, etc.] |
+| [Sprint N+1] | [X items / X pts] | [Theme] |
+| [Sprint N+2] | [X items / X pts] | [Theme] |
+
+**Carry-over root causes identified:**
+- [Root cause 1: e.g., "5 of 12 carry-overs were blocked on a third-party API integration — external dependency, not estimation failure"]
+- [Root cause 2: e.g., "4 of 12 carry-overs were items estimated at 8+ points that were later found to be 2–3x larger than expected"]
+- [Root cause 3: e.g., "3 of 12 carry-overs were interruptions from on-call incidents consuming unplanned capacity"]
+
+---
+
+## Capacity Utilization
+
+| Sprint | Team Size | Available Capacity (pts) | Committed | Utilization % | Disruptions |
+|--------|-----------|--------------------------|-----------|--------------|-------------|
+| [Sprint N] | [X engineers] | [X pts] | [X pts] | [X%] | [Holiday / incident / none] |
+| [Sprint N+1] | [X engineers] | [X pts] | [X pts] | [X%] | |
+
+**Capacity calculation used:** [X engineers × Y pts/person/sprint = Z pts available. Adjust: if team capacity changed during the window, note which sprints used which team size.]
+
+**Average utilization:** [X%]
+**Utilization interpretation:** [< 70% = team is under-loaded or over-padding | 70–90% = healthy range | > 90% = no slack for unplanned work — fragile]
+
+---
+
+## Health Diagnosis
+
+| Dimension | Score | Evidence | Priority |
+|-----------|-------|----------|----------|
+| Delivery predictability | [Green / Yellow / Red] | [Average completion rate X%, std dev Y pts] | [High / Med / Low] |
+| Commitment accuracy | [Green / Yellow / Red] | [Team over-commits by avg X pts/sprint] | |
+| Estimation consistency | [Green / Yellow / Red] | [Velocity std dev ±X pts, calibration verdict] | |
+| Carry-over hygiene | [Green / Yellow / Red] | [X% carry-over rate, root causes] | |
+| Capacity management | [Green / Yellow / Red] | [Avg utilization X%, disruption handling] | |
+| Trend direction | [Green / Yellow / Red] | [Trailing 3-sprint avg vs. leading 3-sprint avg] | |
+
+**Scoring guide:** Green = operating within healthy range; Yellow = marginal — watch closely or single-sprint anomaly; Red = chronic issue requiring active intervention.
+
+**Overall health:** [Green / Yellow / Red] — [One sentence summary: "The team delivers consistently at X pts/sprint but chronic over-commitment is eroding morale and creating a misleading picture for stakeholders."]
+
+---
+
+## Blocker Frequency Analysis
+
+If blocker data was provided, complete this section. If not, note it as a recommended tracking addition.
+
+| Blocker Category | Frequency (last 8 sprints) | Avg Days Blocked | Impact (pts delayed) |
+|-----------------|--------------------------|------------------|---------------------|
+| External dependency | [X occurrences] | [X days] | [X pts] |
+| Technical debt / rework | [X occurrences] | [X days] | [X pts] |
+| Unclear requirements | [X occurrences] | [X days] | [X pts] |
+| On-call interruptions | [X occurrences] | [X days] | [X pts] |
+| Environment / tooling | [X occurrences] | [X days] | [X pts] |
+
+**Top blocker to address:** [Name the single highest-impact blocker category and what addressing it would mean for velocity.]
+
+---
+
+## Improvement Recommendations
+
+Provide 3 specific recommendations ordered by expected impact. Each recommendation must include a measurable success target and implementation steps.
+
+### Recommendation 1: [Title]
+
+**Problem it addresses:** [Which health dimension is Red or Yellow, and what the data shows]
+
+**What to do:**
+1. [Specific action step — concrete enough that a tech lead can assign it]
+2. [Next step]
+3. [Next step]
+
+**Who owns it:** [Tech lead / Engineering manager / Whole team]
+**When to start:** [This sprint / Next sprint / Within 2 weeks]
+
+**Measurable target:** [e.g., "Carry-over rate drops below 15% within 3 sprints" or "Completion rate above 80% for 4 consecutive sprints"]
+
+**How to know it's working:** [Leading indicator to watch before the outcome metric improves — e.g., "Carry-over items decreasing sprint-over-sprint even before the target is hit"]
+
+---
+
+### Recommendation 2: [Title]
+
+**Problem it addresses:** [Health dimension and evidence]
+
+**What to do:**
+1. [Step]
+2. [Step]
+3. [Step]
+
+**Who owns it:** [Role]
+**When to start:** [Timing]
+
+**Measurable target:** [Specific metric and timeframe]
+
+**How to know it's working:** [Leading indicator]
+
+---
+
+### Recommendation 3: [Title]
+
+**Problem it addresses:** [Health dimension and evidence]
+
+**What to do:**
+1. [Step]
+2. [Step]
+
+**Who owns it:** [Role]
+**When to start:** [Timing]
+
+**Measurable target:** [Specific metric and timeframe]
+
+**How to know it's working:** [Leading indicator]
+
+---
+
+## Next-Sprint Capacity Forecast
+
+**Next sprint:** [Sprint N+8]
+**Known team size:** [X engineers]
+**Known capacity reducers:** [PTO: X days total, on-call rotation: ~Y pts of unplanned capacity, etc.]
+
+| Factor | Impact |
+|--------|--------|
+| Base capacity (historical average) | [X pts] |
+| PTO / planned absences | −[X pts] |
+| On-call overhead (estimate) | −[X pts] |
+| Carry-over from Sprint [N+7] | +[X pts committed capacity already spoken for] |
+| **Recommended commitment ceiling** | **[X pts]** |
+
+**Confidence:** [High — stable team and known capacity | Medium — some uncertainty in disruption level | Low — team composition uncertain]
+
+**Recommendation for planning:** [One sentence — e.g., "Plan to Sprint [N+8] ceiling of X pts. Given the carry-over items, prioritize completing those before pulling in new scope."]
+
+---
+
+## Cycle Time Distribution (if data provided)
+
+| Sprint | p50 Cycle Time | p90 Cycle Time | Items Completed |
+|--------|---------------|---------------|-----------------|
+| [Sprint N] | [X days] | [X days] | [X items] |
+| [Average] | [X days] | [X days] | |
+
+**Cycle time interpretation:** [p90 > 2× p50 indicates a long-tail of stuck items that deserve investigation. p50 increasing over time indicates slowing throughput independent of story point changes.]
+
+If cycle time data was not provided: *Cycle time data was not included in this analysis. Recommend adding p50 and p90 cycle time per sprint to your tracking to detect throughput issues that story points alone cannot reveal.*
+
+---
+
+## Quality Checks
+
+- [ ] Velocity chart is generated from the actual data provided — not a generic placeholder chart
+- [ ] Trend diagnosis states a direction (Improving / Flat / Declining / Erratic) with a quantitative basis (trailing vs. leading average)
+- [ ] Carry-over root causes are specific categories with counts — not a generic observation that carry-over exists
+- [ ] Each of the 3 recommendations includes a named owner, a start date, and a measurable target with a timeframe
+- [ ] Next-sprint capacity forecast uses historical average as the baseline and deducts specific known reducers
+- [ ] Health diagnosis table uses Red/Yellow/Green with evidence cited in the Evidence column — no unsupported scores
+- [ ] If metrics are missing (cycle time, blocker log), the report explicitly calls them out as recommended additions
@@ -0,0 +1,290 @@
+---
+name: tech-radar
+description: "Build a technology radar for an engineering team, categorizing technologies into Adopt/Trial/Assess/Hold quadrants following the ThoughtWorks Tech Radar format. Use when asked to create a tech radar, evaluate the team's technology landscape, categorize tools and frameworks, or establish a technology strategy. Produces a full tech radar with quadrant tables, individual blip rationales, a decision trail, and a maintenance process guide."
+---
+
+# Tech Radar
+
+Produce a complete technology radar document for an engineering team. The radar gives the team a shared, explicit position on every significant technology in their stack — what to standardize on, what to experiment with, what to evaluate, and what to actively stop using. Follow the ThoughtWorks Tech Radar format: four quadrants (Techniques, Tools, Platforms, Languages & Frameworks) each with four rings (Adopt, Trial, Assess, Hold). Each technology entry ("blip") gets a ring assignment, a one-paragraph rationale, and a date. Include a decision trail showing what moved and why, and a maintenance process the team can run to keep the radar current.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Team or company name** — for the document header
+- **Current tech stack** — list every significant technology, tool, language, and platform the team currently uses
+- **Technologies under active evaluation** — tools or frameworks the team is currently trying or considering
+- **Technologies to deprecate or move off** — anything the team wants to stop using or is actively migrating away from
+- **Strategic technology bets** — any technologies the company has made a deliberate bet on (e.g., "we're all-in on Kubernetes" or "migrating to event-driven architecture")
+- **Team context** — team size, product domain, and any constraints (regulatory, compliance, vendor lock-in concerns)
+
+If a technology is mentioned without a ring placement, use the rationale inputs to determine the appropriate ring. When uncertain between two rings, ask.
+
+## Output Format
+
+---
+
+# Technology Radar: [Team / Company Name]
+
+**Edition:** [Month Year]
+**Maintained by:** [Team Name / Architecture Guild / CTO Office]
+**Review cadence:** Bi-annual (every 6 months)
+**Next review:** [Month Year + 6 months]
+
+---
+
+## How to Read This Radar
+
+This radar reflects [Team / Company Name]'s current thinking on technologies we use, evaluate, and retire. Use it to make consistent technology choices, onboard new engineers, and have structured conversations about the stack.
+
+**Quadrants** categorize the type of technology:
+
+| Quadrant | What belongs here |
+|----------|------------------|
+| **Techniques** | Methods, patterns, and practices (e.g., trunk-based development, event sourcing) |
+| **Tools** | Software tools used in the development and delivery process (e.g., linters, CI systems, observability platforms) |
+| **Platforms** | Infrastructure and hosting environments (e.g., AWS, Kubernetes, Snowflake) |
+| **Languages & Frameworks** | Programming languages and application frameworks (e.g., Go, React, FastAPI) |
+
+**Rings** express our recommendation:
+
+| Ring | Meaning | What to do |
+|------|---------|-----------|
+| **Adopt** | Industry-proven, working well for us — our standard choice | Use by default for new work; no special justification needed |
+| **Trial** | Worth pursuing — we are experimenting with it in limited production use | Use in a bounded context with architectural oversight; share learnings |
+| **Assess** | Worth exploring — we have not used it in production yet | Spike, prototype, or research; do not use in production without a review |
+| **Hold** | Do not start new work with this technology | Complete existing commitments; do not expand use; plan migration |
+
+---
+
+## Quadrant 1: Techniques
+
+### Adopt
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Technique name, e.g., Trunk-based development] | [Month Year] | [One sentence: why we adopted it and what it replaced] |
+| [Technique name] | [Month Year] | [One sentence rationale] |
+| [Technique name] | [Month Year] | [One sentence rationale] |
+
+**[Technique name] — Adopt**
+[One paragraph rationale. Explain what problem this technique solves, why it works well in your context, and what the team should know before applying it. Reference any internal experience — e.g., "We rolled this out across 8 services in 2024 and saw a 40% reduction in merge conflicts."]
+
+[Repeat for each Adopt-ring technique.]
+
+### Trial
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Technique name] | [Month Year] | [One sentence: what we're testing and where] |
+
+**[Technique name] — Trial**
+[One paragraph. What are we trialing? In which teams or services? What hypothesis are we testing? What would cause us to move it to Adopt vs. Hold?]
+
+### Assess
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Technique name] | [Month Year] | [One sentence: why we're interested] |
+
+**[Technique name] — Assess**
+[One paragraph. Why is this interesting to us? What would we need to see to move it to Trial? Who is responsible for the assessment?]
+
+### Hold
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Technique name] | [Month Year] | [One sentence: why we're stopping and what replaces it] |
+
+**[Technique name] — Hold**
+[One paragraph. Why are we putting this on hold? What is the migration path? What is the target end-state for teams still using it?]
+
+---
+
+## Quadrant 2: Tools
+
+### Adopt
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Tool name, e.g., GitHub Actions] | [Month Year] | [One sentence rationale] |
+| [Tool name] | [Month Year] | [One sentence rationale] |
+
+**[Tool name] — Adopt**
+[One paragraph rationale. Why is this our standard tool? What does it do well in our context? Any configuration or usage patterns the team should follow?]
+
+[Repeat for each Adopt-ring tool.]
+
+### Trial
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Tool name] | [Month Year] | [One sentence: what we're testing] |
+
+**[Tool name] — Trial**
+[One paragraph rationale and trial scope.]
+
+### Assess
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Tool name] | [Month Year] | [One sentence: why we're evaluating it] |
+
+**[Tool name] — Assess**
+[One paragraph: what sparked interest, who is evaluating, and timeline.]
+
+### Hold
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Tool name] | [Month Year] | [One sentence: what replaces it] |
+
+**[Tool name] — Hold**
+[One paragraph: deprecation rationale and migration path.]
+
+---
+
+## Quadrant 3: Platforms
+
+### Adopt
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Platform name, e.g., AWS EKS] | [Month Year] | [One sentence rationale] |
+| [Platform name] | [Month Year] | [One sentence rationale] |
+
+**[Platform name] — Adopt**
+[One paragraph. What does this platform provide? What are the boundaries of its use? Any internal golden-path setup the team should follow?]
+
+[Repeat for each Adopt-ring platform.]
+
+### Trial
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Platform name] | [Month Year] | [One sentence: scope of trial] |
+
+**[Platform name] — Trial**
+[One paragraph rationale and trial boundaries.]
+
+### Assess
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Platform name] | [Month Year] | [One sentence: why we're exploring it] |
+
+**[Platform name] — Assess**
+[One paragraph assessment plan.]
+
+### Hold
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Platform name] | [Month Year] | [One sentence: migration target and timeline] |
+
+**[Platform name] — Hold**
+[One paragraph: what triggered the hold decision, migration target, and timeline.]
+
+---
+
+## Quadrant 4: Languages & Frameworks
+
+### Adopt
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Language/Framework, e.g., Go] | [Month Year] | [One sentence rationale] |
+| [Language/Framework] | [Month Year] | [One sentence rationale] |
+
+**[Language/Framework] — Adopt**
+[One paragraph. What is this language or framework used for? What are the team's proficiency expectations? Any frameworks or libraries that go alongside it as part of the standard choice?]
+
+[Repeat for each Adopt-ring language or framework.]
+
+### Trial
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Language/Framework] | [Month Year] | [One sentence: bounded use case] |
+
+**[Language/Framework] — Trial**
+[One paragraph rationale.]
+
+### Assess
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Language/Framework] | [Month Year] | [One sentence: interest driver] |
+
+**[Language/Framework] — Assess**
+[One paragraph assessment plan.]
+
+### Hold
+
+| Technology | Since | Notes |
+|------------|-------|-------|
+| [Language/Framework] | [Month Year] | [One sentence: reason and migration path] |
+
+**[Language/Framework] — Hold**
+[One paragraph: deprecation rationale, existing system obligations, and timeline to retire.]
+
+---
+
+## Decision Trail
+
+This log records every ring movement since the radar's first edition. Use it to understand the evolution of our technology choices.
+
+| Technology | Quadrant | Previous Ring | New Ring | Edition | Reason |
+|------------|----------|--------------|----------|---------|--------|
+| [Name] | [Quadrant] | — | Adopt | [Month Year] | First placement — [one sentence why] |
+| [Name] | [Quadrant] | Assess | Trial | [Month Year] | [What prompted the move — evidence, team feedback, production trial results] |
+| [Name] | [Quadrant] | Trial | Adopt | [Month Year] | [Adoption rationale — usage results, team satisfaction, scale proven] |
+| [Name] | [Quadrant] | Adopt | Hold | [Month Year] | [Why moved to Hold — better alternative, security concern, cost, vendor issue] |
+| [Name] | [Quadrant] | — | Hold | [Month Year] | First placement — added directly to Hold because [reason] |
+
+---
+
+## Radar Maintenance Process
+
+### Who Contributes
+
+- **Architecture review group / CTO office** — final ring placement decisions
+- **All engineers** — submit blip nominations via [channel or form]
+- **Tech leads** — triage nominations and prepare proposals for review sessions
+
+### Update Cadence
+
+| Activity | Frequency | Owner |
+|----------|-----------|-------|
+| New blip nominations accepted | Ongoing — any engineer via [channel] | Anyone |
+| Nomination triage | Monthly | Tech leads |
+| Full radar review session | Every 6 months | Architecture group |
+| Published radar update | Every 6 months | [Owner name or role] |
+
+### How to Nominate a Blip
+
+1. Submit to [Slack channel / form URL] with: technology name, quadrant, proposed ring, and one-paragraph rationale.
+2. A tech lead reviews within 2 weeks and either schedules it for the next review session or requests more information.
+3. At the review session, the architecture group discusses and votes. Simple majority wins; ties go to Hold pending further evidence.
+4. Approved blips are added to the radar doc and the decision trail within 1 week of the session.
+
+### Ring Change Criteria
+
+| To move TO Adopt | To move TO Trial | To move TO Assess | To move TO Hold |
+|-----------------|-----------------|-------------------|-----------------|
+| Proven in multiple production systems; team broadly trained; clear operational runbook exists | At least one production use case running; architectural oversight in place; learnings documented | Concrete use case identified; spike completed or in progress; interest from at least 2 engineers | Better alternative exists; known security/compliance risk; strategic direction change; unacceptable maintenance burden |
+
+---
+
+*Questions about this radar: [Slack channel] | Submit a nomination: [URL or channel]*
+
+---
+
+## Quality Checks
+
+- [ ] Every blip has a written rationale paragraph — not just a table row entry
+- [ ] The decision trail is populated with at least the initial placement date for every blip
+- [ ] Hold-ring entries include a concrete migration path or target technology, not just "stop using it"
+- [ ] Ring definitions are present and include both what each ring means AND what engineers should do in response
+- [ ] Maintenance process includes: nomination channel, review cadence, who decides, and ring-change criteria
+- [ ] Technologies identified as "strategic bets" in the inputs are placed in Adopt (if proven) or Trial (if being rolled out)
+- [ ] Technologies identified for deprecation are in Hold with a rationale that references the replacement
@@ -0,0 +1,260 @@
+---
+name: technical-debt-register
+description: "Document and prioritize a technical debt backlog with business impact, effort estimates, and resolution strategy. Use when asked to audit technical debt, create a debt register, prioritize tech debt for a quarter, document architectural shortcuts, or build a debt reduction roadmap. Produces a structured technical debt register covering debt inventory by category, business impact per item, effort and priority scores, top-item resolution plans, and a quarterly debt reduction roadmap."
+---
+
+# Technical Debt Register Skill
+
+Produce a complete technical debt register for a team or service. A debt register is not a complaint list — it is a prioritized, business-impact-aware inventory that lets an engineering team make deliberate choices about which debt to pay down, in what order, and with what expected return.
+
+Good debt management is not eliminating all debt. It is ensuring debt is visible, owned, and resolved when the interest cost exceeds the cost of fixing it.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Team or service name** — what team and/or service this register covers
+- **Known debt items** — list of known technical debt, or ask Claude to elicit them by asking about: legacy code, missing tests, outdated dependencies, architectural shortcuts, manual processes, observability gaps, security backlogs
+- **Tech stack** — language, frameworks, infrastructure (helps Claude categorise and score items correctly)
+- **Team size and velocity** — number of engineers and approximate story points or days per sprint (needed for effort estimates)
+- **Current quarter / planning period** — so the roadmap targets the right timeframe
+
+## Output Format
+
+---
+
+# Technical Debt Register: [Team / Service Name]
+
+**Team:** [Name] | **Service(s):** [Name(s)]
+**Author:** [Name] | **Last updated:** [Date]
+**Planning period:** [Q[X] [Year]] | **Review cadence:** [Monthly / Quarterly]
+
+---
+
+## Overview
+
+[2–3 sentences describing the team's current debt situation, the main categories of debt, and the business context — e.g. are they in a growth phase where velocity matters, or approaching a compliance deadline where security debt is critical?]
+
+**Total items in register:** [X]
+**Unresolved items:** [X]
+**Critical/High priority items:** [X]
+**Estimated total resolution effort:** [X story points / X engineer-weeks]
+
+---
+
+## Debt Category Definitions
+
+| Category | Description | Examples |
+|---|---|---|
+| **Code quality** | Code that works but is hard to change safely | Duplicated logic, deeply nested conditionals, inconsistent error handling, missing abstraction |
+| **Architecture** | Structural decisions that limit scalability or increase coupling | Monolith that should be decomposed, sync calls that should be async, missing domain boundaries |
+| **Testing** | Gaps in test coverage that increase regression risk | Missing unit tests, no integration tests, flaky test suite, no test data management |
+| **Security** | Known vulnerabilities or missing security controls | Outdated dependencies with CVEs, missing rate limiting, hard-coded secrets, insufficient auth |
+| **Dependencies** | Outdated or risky external dependencies | End-of-life libraries, major version lag, abandoned packages |
+| **Infrastructure** | Infrastructure that limits reliability or developer productivity | Manual deployment steps, no IaC, single-AZ, missing autoscaling |
+| **Observability** | Gaps in visibility that slow incident response | Missing metrics, no distributed tracing, poor log structure, no alerting on key SLIs |
+| **Process** | Manual or error-prone operational processes | Manual DB migrations, no runbooks, tribal knowledge not documented |
+
+---
+
+## Debt Register
+
+### Scoring Method
+
+**Business impact (1–5):**
+- 5 — Blocking growth, causing production incidents, or creating compliance risk
+- 4 — Significantly slowing delivery or increasing incident likelihood
+- 3 — Noticeable slowdown; manageable but accumulating
+- 2 — Minor friction; low immediate risk
+- 1 — Cosmetic or aspirational; no current business impact
+
+**Effort to resolve (1–5, lower = easier):**
+- 1 — <0.5 day; single engineer
+- 2 — 0.5–2 days; single engineer
+- 3 — 3–5 days; single engineer or small pair
+- 4 — 1–2 weeks; team collaboration required
+- 5 — >2 weeks; significant planning and coordination
+
+**Priority score = Business impact × (6 − Effort)** *(rewards high-impact, low-effort items)*
+
+---
+
+| ID | Item | Category | Business impact (1–5) | Effort (1–5) | Priority score | Status | Owner |
+|---|---|---|---|---|---|---|---|
+| TD-001 | [e.g. No integration tests for payment flow] | Testing | 5 | 3 | 15 | Open | [Name] |
+| TD-002 | [e.g. Authentication library 3 major versions behind] | Security | 5 | 2 | 20 | Open | [Name] |
+| TD-003 | [e.g. Database queries not using connection pooling] | Architecture | 4 | 2 | 16 | Open | [Name] |
+| TD-004 | [e.g. Manual deployment process for [service]] | Infrastructure | 4 | 3 | 12 | In progress | [Name] |
+| TD-005 | [e.g. 200-line God function in order processing] | Code quality | 3 | 3 | 9 | Open | [Name] |
+| TD-006 | [e.g. No structured logging — plain text only] | Observability | 3 | 2 | 12 | Open | [Name] |
+| TD-007 | [e.g. ORM version has known N+1 query issue] | Dependencies | 3 | 3 | 9 | Open | [Name] |
+| TD-008 | [e.g. No runbook for [critical operation]] | Process | 3 | 1 | 15 | Open | [Name] |
+| TD-009 | [e.g. Test coverage at 34% — no meaningful safety net] | Testing | 4 | 4 | 8 | Open | [Name] |
+| TD-010 | [e.g. Hard-coded config values in application code] | Code quality | 2 | 1 | 10 | Open | [Name] |
+| TD-011 | [e.g. Service deployed single-AZ with no failover] | Infrastructure | 5 | 4 | 10 | Open | [Name] |
+| TD-012 | [e.g. No alerting on P95 latency for [endpoint]] | Observability | 4 | 1 | 20 | Open | [Name] |
+
+---
+
+## Category Breakdown
+
+```
+Category distribution (by item count):
+─────────────────────────────────────────────
+Code quality     ████████░░  [X items]  ([X]%)
+Architecture     ██████░░░░  [X items]  ([X]%)
+Testing          █████████░  [X items]  ([X]%)
+Security         ████░░░░░░  [X items]  ([X]%)
+Dependencies     ███░░░░░░░  [X items]  ([X]%)
+Infrastructure   ████░░░░░░  [X items]  ([X]%)
+Observability    ████░░░░░░  [X items]  ([X]%)
+Process          ██░░░░░░░░  [X items]  ([X]%)
+─────────────────────────────────────────────
+
+Priority distribution:
+Critical (score 20–25): [X items]
+High     (score 12–19): [X items]
+Medium   (score  6–11): [X items]
+Low      (score   1–5): [X items]
+```
+
+---
+
+## Top 5 Priority Items — Resolution Plans
+
+### TD-XXX: [Highest priority item name]
+
+**Priority score:** [Score] | **Category:** [Category] | **Owner:** [Name]
+
+**Problem:**
+[2–3 sentences describing what the debt is, how it manifests, and what pain it currently causes. Be specific — reference actual incidents, slowdowns, or risks.]
+
+**Business impact:**
+[What happens if this is not resolved? Reference any incidents, near-misses, or growth blockers. E.g. "This caused 2 production incidents in the last quarter and adds ~30 minutes of debugging time to any change in this area."]
+
+**Resolution approach:**
+[Clear description of the fix. Not "improve the code" — describe the actual work: "Extract the payment processing logic into a dedicated `PaymentService` class, write unit tests to 80% coverage, and update the 3 call sites."]
+
+**Steps:**
+1. [Specific, ticketable step]
+2. [Specific, ticketable step]
+3. [Specific, ticketable step]
+
+**Acceptance criteria:**
+- [ ] [Measurable criterion — e.g. "Zero hard-coded config values remain in application code"]
+- [ ] [Measurable criterion — e.g. "CI pipeline passes with new tests"]
+- [ ] [Measurable criterion]
+
+**Effort estimate:** [X story points / X days]
+**Suggested sprint:** [Q[X] Sprint [Y] / When [dependency] is complete]
+
+---
+
+### TD-XXX: [Second priority item name]
+
+**Priority score:** [Score] | **Category:** [Category] | **Owner:** [Name]
+
+**Problem:**
+[Description]
+
+**Business impact:**
+[Impact description]
+
+**Resolution approach:**
+[Approach description]
+
+**Steps:**
+1. [Step]
+2. [Step]
+3. [Step]
+
+**Acceptance criteria:**
+- [ ] [Criterion]
+- [ ] [Criterion]
+
+**Effort estimate:** [X story points / X days]
+**Suggested sprint:** [Sprint or timeframe]
+
+---
+
+### TD-XXX: [Third priority item]
+
+*(Follow same format as above)*
+
+---
+
+### TD-XXX: [Fourth priority item]
+
+*(Follow same format as above)*
+
+---
+
+### TD-XXX: [Fifth priority item]
+
+*(Follow same format as above)*
+
+---
+
+## Debt Reduction Roadmap
+
+### Guiding principles
+
+- Allocate [X%] of each sprint's capacity to debt resolution — recommended 15–20% for healthy teams
+- Security and dependency debt is addressed on a fixed cadence regardless of priority score
+- No new feature work in modules with Critical debt unless the debt is scheduled for the current sprint
+- Debt items closed without a resolution (accepted/deferred) must have a named owner and a review date
+
+### Quarterly plan
+
+| Quarter | Focus area | Items targeted | Estimated capacity | Expected outcome |
+|---|---|---|---|---|
+| **[Q1 Year]** (current) | Security + observability | TD-002, TD-012, TD-006 | [X] points / [Y] eng-days | Auth library current; latency alerting live; structured logging shipped |
+| **[Q2 Year]** | Architecture + reliability | TD-003, TD-011, TD-004 | [X] points / [Y] eng-days | Connection pooling fixed; multi-AZ deployed; deploy automation complete |
+| **[Q3 Year]** | Testing coverage | TD-001, TD-009 | [X] points / [Y] eng-days | Payment flow integration tests live; overall coverage ≥60% |
+| **[Q4 Year]** | Code quality + process | TD-005, TD-008, TD-010 | [X] points / [Y] eng-days | God functions refactored; runbooks complete; zero hard-coded config |
+
+### Sprint allocation model
+
+```
+Sprint capacity: [X] story points
+
+Allocation:
+  ├── Feature work:        [X * 0.75 = ~Y] points  (75%)
+  ├── Debt resolution:     [X * 0.15 = ~Y] points  (15%)
+  └── Unplanned/bugs:      [X * 0.10 = ~Y] points  (10%)
+
+Debt items that fit in one sprint ([≤Y] points each):
+  ✓ TD-002 ([X] points)
+  ✓ TD-012 ([X] points)
+  ✓ TD-006 ([X] points)
+  ✓ TD-008 ([X] points)
+
+Multi-sprint debt items (break into phases):
+  ~ TD-001: Phase 1 ([X] pts) → Phase 2 ([X] pts)
+  ~ TD-009: Requires dedicated debt sprint or pairing
+```
+
+---
+
+## Accepted / Deferred Debt
+
+Items where the cost of remediation currently exceeds the business value, accepted with explicit review dates.
+
+| ID | Item | Reason for deferral | Review date | Owner |
+|---|---|---|---|---|
+| TD-XXX | [Item] | [e.g. "Rewrite would require 3 weeks with no user-facing value at current scale; revisit at 10× traffic"] | [Date] | [Name] |
+| TD-XXX | [Item] | [e.g. "Dependency has a CVE but no upgrade path exists until Q3; mitigated by WAF rule"] | [Date] | [Name] |
+
+**Policy:** No item may be deferred more than twice without escalation to the engineering manager.
+
+---
+
+## Quality Checks
+
+- [ ] Every item has a named owner — no unowned debt
+- [ ] Priority scores are calculated using the formula, not assigned arbitrarily
+- [ ] Security and dependency items are not scored below their actual business impact because they feel "technical"
+- [ ] Top-5 resolution plans include specific, ticketable steps — not vague descriptions like "improve test coverage"
+- [ ] The quarterly roadmap allocates realistic capacity — debt allocation does not exceed actual sprint budget
+- [ ] Accepted/deferred items have a review date and a named owner — no permanently deferred items
+- [ ] The register distinguishes between debt (deliberate or accumulated shortcuts) and bugs (unintended defects)
+- [ ] Items are closed as resolved only when acceptance criteria are met — not when the PR is merged
Author	SHA1	Message	Date
mohitagw15856	bf65c16222	Merge pull request #12 from mohitagw15856/claude/add-engineering-skills-IfBhz Add 21 engineering skills — complete the 500-star milestone	2026-05-20 08:32:18 +01:00
Claude	beecb1cb31	Add 21 engineering skills — complete the 500-star milestone pm-engineering grows from 14 to 35 skills (v4.0.0), completing the full 25-skill promise made at the 500-star milestone. The library grows from 114 to 135 total skills. New skills added (21): - security-threat-model: STRIDE-based threat model with trust boundaries, per-component threat enumeration, risk scores, and mitigations - performance-budget: Performance budgets for Core Web Vitals and backend latency SLOs with CI enforcement - database-schema-design: Schema documentation with ER diagram, DDL definitions, index strategy, and access pattern analysis - database-migration-plan: Zero-downtime expand-contract migration plan with per-step rollback and data validation queries - technical-debt-register: Debt inventory with impact scoring, effort estimates, and quarterly resolution roadmap - rfc-writer: Engineering RFC covering problem, proposed solution, alternatives-with-rejection-reasons, and rollout plan - capacity-planning: Traffic forecasts, resource requirements by tier, scaling strategy, and infrastructure roadmap - load-testing-plan: Load test plan with baseline/stress/spike/soak scenarios, k6/Locust skeleton, and CI gates - disaster-recovery-plan: DR plan with RPO/RTO targets, per-scenario runbooks, game day testing, and communication templates - feature-flag-guide: Feature flag lifecycle — taxonomy, rollout strategy, monitoring requirements, cleanup policy, governance - dependency-audit: CVE vulnerabilities, license compliance, outdated packages, and 30-day remediation plan - service-catalog-entry: Microservice catalog entry with SLAs, API contract, data classification, and runbook links - monitoring-setup-guide: Four golden signals, alert rules spec, log schema, tracing setup, dashboard layout spec - local-dev-setup: Local development guide — prerequisites, env vars, Docker deps, test commands, 5 failure fixes - api-versioning-strategy: Versioning scheme, lifecycle policy, breaking change classification table, deprecation process - infra-as-code-review: IaC review for Terraform/CloudFormation/Pulumi with severity-classified findings - engineering-weekly-report: Consistent weekly status — shipped/blocked, metrics, decisions, risks, next week - tech-radar: ThoughtWorks-format radar with Adopt/Trial/Assess/Hold, blip rationales, maintenance process - sprint-velocity-analysis: Velocity trends, completion patterns, improvement recommendations, capacity forecast - microservices-decomposition: Domain-driven service boundaries, communication patterns, data ownership, migration plan - engineering-hiring-rubric: Technical interview rubric with level expectations, coding/system design scorecards, debrief guide Also: - plugin.json bumped to v4.0.0 with all 35 skills listed - marketplace.json updated to v11.0.0, library count 135 - README updated: skill count, all section numbers, engineering table expanded, star milestone marked complete https://claude.ai/code/session_01C3HwChrccJd145vJ6Z7ajF	2026-05-20 07:28:51 +00:00
mohitagw15856	8caa9c29b9	Add new plugins for Customer Success and Engineering	2026-05-17 15:45:45 +05:30
mohitagw15856	af29d30631	rebrand: PM = Professional, not just Product Management Reposition the library without changing the repo name or URLs. Adds 'PM stands for Professional' tagline to README header and marketplace.json description to reflect the library now covering 16 professions beyond product management.	2026-05-17 11:14:40 +01:00