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
This commit is contained in:
Claude
@@ -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
|
||||
Reference in New Issue
Block a user