chore: import upstream snapshot with attribution
This commit is contained in:
wehub-resource-sync
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "engineering",
|
||||
"version": "1.2.0",
|
||||
"description": "Streamline engineering workflows — standups, code review, architecture decisions, incident response, and technical documentation. Works with your existing tools or standalone.",
|
||||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,48 @@
|
||||
{
|
||||
"mcpServers": {
|
||||
"slack": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.slack.com/mcp",
|
||||
"oauth": {
|
||||
"clientId": "1601185624273.8899143856786",
|
||||
"callbackPort": 3118
|
||||
}
|
||||
},
|
||||
"linear": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.linear.app/mcp"
|
||||
},
|
||||
"asana": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.asana.com/v2/mcp"
|
||||
},
|
||||
"atlassian": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.atlassian.com/v1/mcp"
|
||||
},
|
||||
"notion": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.notion.com/mcp"
|
||||
},
|
||||
"github": {
|
||||
"type": "http",
|
||||
"url": "https://api.githubcopilot.com/mcp/"
|
||||
},
|
||||
"pagerduty": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.pagerduty.com/mcp"
|
||||
},
|
||||
"datadog": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.datadoghq.com/api/unstable/mcp-server/mcp"
|
||||
},
|
||||
"google calendar": {
|
||||
"type": "http",
|
||||
"url": ""
|
||||
},
|
||||
"gmail": {
|
||||
"type": "http",
|
||||
"url": ""
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,19 @@
|
||||
# Connectors
|
||||
|
||||
## How tool references work
|
||||
|
||||
Plugin files use `~~category` as a placeholder for whatever tool the user connects in that category. For example, `~~source control` might mean GitHub, GitLab, or any other VCS with an MCP server.
|
||||
|
||||
Plugins are **tool-agnostic** — they describe workflows in terms of categories (source control, CI/CD, monitoring, etc.) rather than specific products. The `.mcp.json` pre-configures specific MCP servers, but any MCP server in that category works.
|
||||
|
||||
## Connectors for this plugin
|
||||
|
||||
| Category | Placeholder | Included servers | Other options |
|
||||
|----------|-------------|-----------------|---------------|
|
||||
| Chat | `~~chat` | Slack | Microsoft Teams |
|
||||
| Source control | `~~source control` | GitHub | GitLab, Bitbucket |
|
||||
| Project tracker | `~~project tracker` | Linear, Asana, Atlassian (Jira/Confluence) | Shortcut, ClickUp |
|
||||
| Knowledge base | `~~knowledge base` | Notion | Confluence, Guru, Coda |
|
||||
| Monitoring | `~~monitoring` | Datadog | New Relic, Grafana, Splunk |
|
||||
| Incident management | `~~incident management` | PagerDuty | Opsgenie, Incident.io, FireHydrant |
|
||||
| CI/CD | `~~CI/CD` | — | CircleCI, GitHub Actions, Jenkins, BuildKite |
|
||||
@@ -0,0 +1,135 @@
|
||||
# Engineering Plugin
|
||||
|
||||
A software engineering plugin primarily designed for [Cowork](https://claude.com/product/cowork), Anthropic's agentic desktop application — though it also works in Claude Code. Helps with standups, code review, architecture decisions, incident response, debugging, and technical documentation. Works with any engineering team — standalone with your input, supercharged when you connect your source control, project tracker, and monitoring tools.
|
||||
|
||||
## Installation
|
||||
|
||||
```bash
|
||||
claude plugins add knowledge-work-plugins/engineering
|
||||
```
|
||||
|
||||
## Commands
|
||||
|
||||
Explicit workflows you invoke with a slash command:
|
||||
|
||||
| Command | Description |
|
||||
|---|---|
|
||||
| `/standup` | Generate a standup update from your recent activity — commits, PRs, tickets, and chat |
|
||||
| `/review` | Review code changes — security, performance, style, and correctness |
|
||||
| `/debug` | Structured debugging session — reproduce, isolate, diagnose, and fix |
|
||||
| `/architecture` | Create or evaluate architecture decisions — ADR format with trade-off analysis |
|
||||
| `/incident` | Run an incident response workflow — triage, communicate, mitigate, and write postmortem |
|
||||
| `/deploy-checklist` | Pre-deployment checklist — verify tests, review changes, check dependencies, confirm rollback plan |
|
||||
|
||||
All commands work **standalone** (paste code, describe your system, upload files) and get **supercharged** with MCP connectors.
|
||||
|
||||
## Skills
|
||||
|
||||
Domain knowledge Claude uses automatically when relevant:
|
||||
|
||||
| Skill | Description |
|
||||
|---|---|
|
||||
| `code-review` | Review code for bugs, security issues, performance, and maintainability |
|
||||
| `incident-response` | Triage and manage production incidents — status updates, runbooks, postmortems |
|
||||
| `system-design` | Design systems and services — architecture diagrams, API design, data modeling |
|
||||
| `tech-debt` | Identify, categorize, and prioritize technical debt — build a remediation plan |
|
||||
| `testing-strategy` | Design test strategies — unit, integration, e2e coverage, test plan creation |
|
||||
| `documentation` | Write and maintain technical documentation — READMEs, API docs, runbooks, onboarding guides |
|
||||
|
||||
## Example Workflows
|
||||
|
||||
### Morning Standup
|
||||
|
||||
```
|
||||
/standup
|
||||
```
|
||||
|
||||
If your tools are connected, I'll pull your recent commits, PR activity, and ticket updates. Otherwise, tell me what you worked on and I'll format it.
|
||||
|
||||
### Code Review
|
||||
|
||||
```
|
||||
/review https://github.com/org/repo/pull/123
|
||||
```
|
||||
|
||||
Share a PR link, paste a diff, or point to files. Get a structured review covering security, performance, correctness, and style.
|
||||
|
||||
### Debugging an Issue
|
||||
|
||||
```
|
||||
/debug Users are getting 500 errors on the checkout page
|
||||
```
|
||||
|
||||
Walk through a structured debugging process: reproduce, isolate, diagnose, fix. I'll help you think through it systematically.
|
||||
|
||||
### Architecture Decision
|
||||
|
||||
```
|
||||
/architecture Should we use a message queue or direct API calls between services?
|
||||
```
|
||||
|
||||
Get a structured ADR with options analysis, trade-offs, and a recommendation.
|
||||
|
||||
### Incident Response
|
||||
|
||||
```
|
||||
/incident The payments service is returning 503s
|
||||
```
|
||||
|
||||
Start an incident workflow: triage severity, draft communications, track timeline, and generate a postmortem when resolved.
|
||||
|
||||
### Pre-Deploy Check
|
||||
|
||||
```
|
||||
/deploy-checklist auth-service v2.3.0
|
||||
```
|
||||
|
||||
Get a customized deployment checklist based on your service and what's changing.
|
||||
|
||||
## Standalone + Supercharged
|
||||
|
||||
Every command and skill works without any integrations:
|
||||
|
||||
| What You Can Do | Standalone | Supercharged With |
|
||||
|-----------------|------------|-------------------|
|
||||
| Standup updates | Describe your work | Source control, Project tracker, Chat |
|
||||
| Code review | Paste diff or code | Source control (pull PRs automatically) |
|
||||
| Debug sessions | Describe the problem | Monitoring (pull logs and metrics) |
|
||||
| Architecture decisions | Describe the system | Knowledge base (find prior ADRs) |
|
||||
| Incident response | Describe the incident | Monitoring, Incident management, Chat |
|
||||
| Deploy checklists | Describe the deploy | CI/CD, Source control |
|
||||
|
||||
## MCP Integrations
|
||||
|
||||
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](CONNECTORS.md).
|
||||
|
||||
Connect your tools for a richer experience:
|
||||
|
||||
| Category | Examples | What It Enables |
|
||||
|---|---|---|
|
||||
| **Source control** | GitHub, GitLab | PR diffs, commit history, branch status |
|
||||
| **Project tracker** | Linear, Jira, Asana | Ticket status, sprint data, assignments |
|
||||
| **Monitoring** | Datadog, New Relic | Logs, metrics, alerts, dashboards |
|
||||
| **Incident management** | PagerDuty, Opsgenie | On-call schedules, incident tracking, paging |
|
||||
| **Chat** | Slack, Teams | Team discussions, standup channels |
|
||||
| **Knowledge base** | Notion, Confluence | ADRs, runbooks, onboarding docs |
|
||||
|
||||
See [CONNECTORS.md](CONNECTORS.md) for the full list of supported integrations.
|
||||
|
||||
## Settings
|
||||
|
||||
Create a local settings file at `engineering/.claude/settings.local.json` to personalize:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "Your Name",
|
||||
"title": "Software Engineer",
|
||||
"team": "Your Team",
|
||||
"company": "Your Company",
|
||||
"techStack": ["Python", "TypeScript", "PostgreSQL", "AWS"],
|
||||
"defaultBranch": "main",
|
||||
"deployProcess": "canary"
|
||||
}
|
||||
```
|
||||
|
||||
The plugin will ask you for this information interactively if it's not configured.
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
name: architecture
|
||||
description: Create or evaluate an architecture decision record (ADR). Use when choosing between technologies (e.g., Kafka vs SQS), documenting a design decision with trade-offs and consequences, reviewing a system design proposal, or designing a new component from requirements and constraints.
|
||||
argument-hint: "<decision or system to design>"
|
||||
---
|
||||
|
||||
# /architecture
|
||||
|
||||
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
|
||||
|
||||
Create an Architecture Decision Record (ADR) or evaluate a system design.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/architecture $ARGUMENTS
|
||||
```
|
||||
|
||||
## Modes
|
||||
|
||||
**Create an ADR**: "Should we use Kafka or SQS for our event bus?"
|
||||
**Evaluate a design**: "Review this microservices proposal"
|
||||
**System design**: "Design the notification system for our app"
|
||||
|
||||
See the **system-design** skill for detailed frameworks on requirements gathering, scalability analysis, and trade-off evaluation.
|
||||
|
||||
## Output — ADR Format
|
||||
|
||||
```markdown
|
||||
# ADR-[number]: [Title]
|
||||
|
||||
**Status:** Proposed | Accepted | Deprecated | Superseded
|
||||
**Date:** [Date]
|
||||
**Deciders:** [Who needs to sign off]
|
||||
|
||||
## Context
|
||||
[What is the situation? What forces are at play?]
|
||||
|
||||
## Decision
|
||||
[What is the change we're proposing?]
|
||||
|
||||
## Options Considered
|
||||
|
||||
### Option A: [Name]
|
||||
| Dimension | Assessment |
|
||||
|-----------|------------|
|
||||
| Complexity | [Low/Med/High] |
|
||||
| Cost | [Assessment] |
|
||||
| Scalability | [Assessment] |
|
||||
| Team familiarity | [Assessment] |
|
||||
|
||||
**Pros:** [List]
|
||||
**Cons:** [List]
|
||||
|
||||
### Option B: [Name]
|
||||
[Same format]
|
||||
|
||||
## Trade-off Analysis
|
||||
[Key trade-offs between options with clear reasoning]
|
||||
|
||||
## Consequences
|
||||
- [What becomes easier]
|
||||
- [What becomes harder]
|
||||
- [What we'll need to revisit]
|
||||
|
||||
## Action Items
|
||||
1. [ ] [Implementation step]
|
||||
2. [ ] [Follow-up]
|
||||
```
|
||||
|
||||
## If Connectors Available
|
||||
|
||||
If **~~knowledge base** is connected:
|
||||
- Search for prior ADRs and design docs
|
||||
- Find relevant technical context
|
||||
|
||||
If **~~project tracker** is connected:
|
||||
- Link to related epics and tickets
|
||||
- Create implementation tasks
|
||||
|
||||
## Tips
|
||||
|
||||
1. **State constraints upfront** — "We need to ship in 2 weeks" or "Must handle 10K rps" shapes the answer.
|
||||
2. **Name your options** — Even if you're leaning one way, I'll give a more balanced analysis with explicit alternatives.
|
||||
3. **Include non-functional requirements** — Latency, cost, team expertise, and maintenance burden matter as much as features.
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
name: code-review
|
||||
description: Review code changes for security, performance, and correctness. Trigger with a PR URL or diff, "review this before I merge", "is this code safe?", or when checking a change for N+1 queries, injection risks, missing edge cases, or error handling gaps.
|
||||
argument-hint: "<PR URL, diff, or file path>"
|
||||
---
|
||||
|
||||
# /code-review
|
||||
|
||||
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
|
||||
|
||||
Review code changes with a structured lens on security, performance, correctness, and maintainability.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/code-review <PR URL or file path>
|
||||
```
|
||||
|
||||
Review the provided code changes: @$1
|
||||
|
||||
If no specific file or URL is provided, ask what to review.
|
||||
|
||||
## How It Works
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ CODE REVIEW │
|
||||
├─────────────────────────────────────────────────────────────────┤
|
||||
│ STANDALONE (always works) │
|
||||
│ ✓ Paste a diff, PR URL, or point to files │
|
||||
│ ✓ Security audit (OWASP top 10, injection, auth) │
|
||||
│ ✓ Performance review (N+1, memory leaks, complexity) │
|
||||
│ ✓ Correctness (edge cases, error handling, race conditions) │
|
||||
│ ✓ Style (naming, structure, readability) │
|
||||
│ ✓ Actionable suggestions with code examples │
|
||||
├─────────────────────────────────────────────────────────────────┤
|
||||
│ SUPERCHARGED (when you connect your tools) │
|
||||
│ + Source control: Pull PR diff automatically │
|
||||
│ + Project tracker: Link findings to tickets │
|
||||
│ + Knowledge base: Check against team coding standards │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Review Dimensions
|
||||
|
||||
### Security
|
||||
- SQL injection, XSS, CSRF
|
||||
- Authentication and authorization flaws
|
||||
- Secrets or credentials in code
|
||||
- Insecure deserialization
|
||||
- Path traversal
|
||||
- SSRF
|
||||
|
||||
### Performance
|
||||
- N+1 queries
|
||||
- Unnecessary memory allocations
|
||||
- Algorithmic complexity (O(n²) in hot paths)
|
||||
- Missing database indexes
|
||||
- Unbounded queries or loops
|
||||
- Resource leaks
|
||||
|
||||
### Correctness
|
||||
- Edge cases (empty input, null, overflow)
|
||||
- Race conditions and concurrency issues
|
||||
- Error handling and propagation
|
||||
- Off-by-one errors
|
||||
- Type safety
|
||||
|
||||
### Maintainability
|
||||
- Naming clarity
|
||||
- Single responsibility
|
||||
- Duplication
|
||||
- Test coverage
|
||||
- Documentation for non-obvious logic
|
||||
|
||||
## Output
|
||||
|
||||
```markdown
|
||||
## Code Review: [PR title or file]
|
||||
|
||||
### Summary
|
||||
[1-2 sentence overview of the changes and overall quality]
|
||||
|
||||
### Critical Issues
|
||||
| # | File | Line | Issue | Severity |
|
||||
|---|------|------|-------|----------|
|
||||
| 1 | [file] | [line] | [description] | 🔴 Critical |
|
||||
|
||||
### Suggestions
|
||||
| # | File | Line | Suggestion | Category |
|
||||
|---|------|------|------------|----------|
|
||||
| 1 | [file] | [line] | [description] | Performance |
|
||||
|
||||
### What Looks Good
|
||||
- [Positive observations]
|
||||
|
||||
### Verdict
|
||||
[Approve / Request Changes / Needs Discussion]
|
||||
```
|
||||
|
||||
## If Connectors Available
|
||||
|
||||
If **~~source control** is connected:
|
||||
- Pull the PR diff automatically from the URL
|
||||
- Check CI status and test results
|
||||
|
||||
If **~~project tracker** is connected:
|
||||
- Link findings to related tickets
|
||||
- Verify the PR addresses the stated requirements
|
||||
|
||||
If **~~knowledge base** is connected:
|
||||
- Check changes against team coding standards and style guides
|
||||
|
||||
## Tips
|
||||
|
||||
1. **Provide context** — "This is a hot path" or "This handles PII" helps me focus.
|
||||
2. **Specify concerns** — "Focus on security" narrows the review.
|
||||
3. **Include tests** — I'll check test coverage and quality too.
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: debug
|
||||
description: Structured debugging session — reproduce, isolate, diagnose, and fix. Trigger with an error message or stack trace, "this works in staging but not prod", "something broke after the deploy", or when behavior diverges from expected and the cause isn't obvious.
|
||||
argument-hint: "<error message or problem description>"
|
||||
---
|
||||
|
||||
# /debug
|
||||
|
||||
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
|
||||
|
||||
Run a structured debugging session to find and fix issues systematically.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/debug $ARGUMENTS
|
||||
```
|
||||
|
||||
## How It Works
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ DEBUG │
|
||||
├─────────────────────────────────────────────────────────────────┤
|
||||
│ Step 1: REPRODUCE │
|
||||
│ ✓ Understand the expected vs. actual behavior │
|
||||
│ ✓ Identify exact reproduction steps │
|
||||
│ ✓ Determine scope (when did it start? who is affected?) │
|
||||
│ │
|
||||
│ Step 2: ISOLATE │
|
||||
│ ✓ Narrow down the component, service, or code path │
|
||||
│ ✓ Check recent changes (deploys, config changes, dependencies) │
|
||||
│ ✓ Review logs and error messages │
|
||||
│ │
|
||||
│ Step 3: DIAGNOSE │
|
||||
│ ✓ Form hypotheses and test them │
|
||||
│ ✓ Trace the code path │
|
||||
│ ✓ Identify root cause (not just symptoms) │
|
||||
│ │
|
||||
│ Step 4: FIX │
|
||||
│ ✓ Propose a fix with explanation │
|
||||
│ ✓ Consider side effects and edge cases │
|
||||
│ ✓ Suggest tests to prevent regression │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## What I Need From You
|
||||
|
||||
Tell me about the problem. Any of these help:
|
||||
- Error message or stack trace
|
||||
- Steps to reproduce
|
||||
- What changed recently
|
||||
- Logs or screenshots
|
||||
- Expected vs. actual behavior
|
||||
|
||||
## Output
|
||||
|
||||
```markdown
|
||||
## Debug Report: [Issue Summary]
|
||||
|
||||
### Reproduction
|
||||
- **Expected**: [What should happen]
|
||||
- **Actual**: [What happens instead]
|
||||
- **Steps**: [How to reproduce]
|
||||
|
||||
### Root Cause
|
||||
[Explanation of why the bug occurs]
|
||||
|
||||
### Fix
|
||||
[Code changes or configuration fixes needed]
|
||||
|
||||
### Prevention
|
||||
- [Test to add]
|
||||
- [Guard to put in place]
|
||||
```
|
||||
|
||||
## If Connectors Available
|
||||
|
||||
If **~~monitoring** is connected:
|
||||
- Pull logs, error rates, and metrics around the time of the issue
|
||||
- Show recent deploys and config changes that may correlate
|
||||
|
||||
If **~~source control** is connected:
|
||||
- Identify recent commits and PRs that touched affected code paths
|
||||
- Check if the issue correlates with a specific change
|
||||
|
||||
If **~~project tracker** is connected:
|
||||
- Search for related bug reports or known issues
|
||||
- Create a ticket for the fix once identified
|
||||
|
||||
## Tips
|
||||
|
||||
1. **Share error messages exactly** — Don't paraphrase. The exact text matters.
|
||||
2. **Mention what changed** — Recent deploys, dependency updates, and config changes are top suspects.
|
||||
3. **Include context** — "This works in staging but not prod" or "Only affects large payloads" narrows things fast.
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
name: deploy-checklist
|
||||
description: Pre-deployment verification checklist. Use when about to ship a release, deploying a change with database migrations or feature flags, verifying CI status and approvals before going to production, or documenting rollback triggers ahead of time.
|
||||
argument-hint: "[service or release name]"
|
||||
---
|
||||
|
||||
# /deploy-checklist
|
||||
|
||||
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
|
||||
|
||||
Generate a pre-deployment checklist to verify readiness before shipping.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/deploy-checklist $ARGUMENTS
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
```markdown
|
||||
## Deploy Checklist: [Service/Release]
|
||||
**Date:** [Date] | **Deployer:** [Name]
|
||||
|
||||
### Pre-Deploy
|
||||
- [ ] All tests passing in CI
|
||||
- [ ] Code reviewed and approved
|
||||
- [ ] No known critical bugs in release
|
||||
- [ ] Database migrations tested (if applicable)
|
||||
- [ ] Feature flags configured (if applicable)
|
||||
- [ ] Rollback plan documented
|
||||
- [ ] On-call team notified
|
||||
|
||||
### Deploy
|
||||
- [ ] Deploy to staging and verify
|
||||
- [ ] Run smoke tests
|
||||
- [ ] Deploy to production (canary if available)
|
||||
- [ ] Monitor error rates and latency for 15 min
|
||||
- [ ] Verify key user flows
|
||||
|
||||
### Post-Deploy
|
||||
- [ ] Confirm metrics are nominal
|
||||
- [ ] Update release notes / changelog
|
||||
- [ ] Notify stakeholders
|
||||
- [ ] Close related tickets
|
||||
|
||||
### Rollback Triggers
|
||||
- Error rate exceeds [X]%
|
||||
- P50 latency exceeds [X]ms
|
||||
- [Critical user flow] fails
|
||||
```
|
||||
|
||||
## Customization
|
||||
|
||||
Tell me about your deploy and I'll customize the checklist:
|
||||
- "We use feature flags" → adds flag verification steps
|
||||
- "This includes a database migration" → adds migration-specific checks
|
||||
- "This is a breaking API change" → adds consumer notification steps
|
||||
|
||||
## If Connectors Available
|
||||
|
||||
If **~~source control** is connected:
|
||||
- Pull the release diff and list of changes
|
||||
- Verify all PRs are approved and merged
|
||||
|
||||
If **~~CI/CD** is connected:
|
||||
- Check build and test status automatically
|
||||
- Verify pipeline is green before deploy
|
||||
|
||||
If **~~monitoring** is connected:
|
||||
- Pre-fill rollback trigger thresholds from current baselines
|
||||
- Set up post-deploy metric watch
|
||||
|
||||
## Tips
|
||||
|
||||
1. **Run before every deploy** — Even routine ones. Checklists prevent "I forgot to..."
|
||||
2. **Customize once, reuse** — Tell me your stack and I'll remember your deploy process.
|
||||
3. **Include rollback criteria** — Decide when to roll back before you deploy, not during.
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
name: documentation
|
||||
description: Write and maintain technical documentation. Trigger with "write docs for", "document this", "create a README", "write a runbook", "onboarding guide", or when the user needs help with any form of technical writing — API docs, architecture docs, or operational runbooks.
|
||||
---
|
||||
|
||||
# Technical Documentation
|
||||
|
||||
Write clear, maintainable technical documentation for different audiences and purposes.
|
||||
|
||||
## Document Types
|
||||
|
||||
### README
|
||||
- What this is and why it exists
|
||||
- Quick start (< 5 minutes to first success)
|
||||
- Configuration and usage
|
||||
- Contributing guide
|
||||
|
||||
### API Documentation
|
||||
- Endpoint reference with request/response examples
|
||||
- Authentication and error codes
|
||||
- Rate limits and pagination
|
||||
- SDK examples
|
||||
|
||||
### Runbook
|
||||
- When to use this runbook
|
||||
- Prerequisites and access needed
|
||||
- Step-by-step procedure
|
||||
- Rollback steps
|
||||
- Escalation path
|
||||
|
||||
### Architecture Doc
|
||||
- Context and goals
|
||||
- High-level design with diagrams
|
||||
- Key decisions and trade-offs
|
||||
- Data flow and integration points
|
||||
|
||||
### Onboarding Guide
|
||||
- Environment setup
|
||||
- Key systems and how they connect
|
||||
- Common tasks with walkthroughs
|
||||
- Who to ask for what
|
||||
|
||||
## Principles
|
||||
|
||||
1. **Write for the reader** — Who is reading this and what do they need?
|
||||
2. **Start with the most useful information** — Don't bury the lede
|
||||
3. **Show, don't tell** — Code examples, commands, screenshots
|
||||
4. **Keep it current** — Outdated docs are worse than no docs
|
||||
5. **Link, don't duplicate** — Reference other docs instead of copying
|
||||
@@ -0,0 +1,158 @@
|
||||
---
|
||||
name: incident-response
|
||||
description: Run an incident response workflow — triage, communicate, and write postmortem. Trigger with "we have an incident", "production is down", an alert that needs severity assessment, a status update mid-incident, or when writing a blameless postmortem after resolution.
|
||||
argument-hint: "<incident description or alert>"
|
||||
---
|
||||
|
||||
# /incident-response
|
||||
|
||||
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
|
||||
|
||||
Manage an incident from detection through postmortem.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/incident-response $ARGUMENTS
|
||||
```
|
||||
|
||||
## Modes
|
||||
|
||||
```
|
||||
/incident-response new [description] # Start a new incident
|
||||
/incident-response update [status] # Post a status update
|
||||
/incident-response postmortem # Generate postmortem from incident data
|
||||
```
|
||||
|
||||
If no mode is specified, ask what phase the incident is in.
|
||||
|
||||
## How It Works
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ INCIDENT RESPONSE │
|
||||
├─────────────────────────────────────────────────────────────────┤
|
||||
│ Phase 1: TRIAGE │
|
||||
│ ✓ Assess severity (SEV1-4) │
|
||||
│ ✓ Identify affected systems and users │
|
||||
│ ✓ Assign roles (IC, comms, responders) │
|
||||
│ │
|
||||
│ Phase 2: COMMUNICATE │
|
||||
│ ✓ Draft internal status update │
|
||||
│ ✓ Draft customer communication (if needed) │
|
||||
│ ✓ Set up war room and cadence │
|
||||
│ │
|
||||
│ Phase 3: MITIGATE │
|
||||
│ ✓ Document mitigation steps taken │
|
||||
│ ✓ Track timeline of events │
|
||||
│ ✓ Confirm resolution │
|
||||
│ │
|
||||
│ Phase 4: POSTMORTEM │
|
||||
│ ✓ Blameless postmortem document │
|
||||
│ ✓ Timeline reconstruction │
|
||||
│ ✓ Root cause analysis (5 whys) │
|
||||
│ ✓ Action items with owners │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Severity Classification
|
||||
|
||||
| Level | Criteria | Response Time |
|
||||
|-------|----------|---------------|
|
||||
| SEV1 | Service down, all users affected | Immediate, all-hands |
|
||||
| SEV2 | Major feature degraded, many users affected | Within 15 min |
|
||||
| SEV3 | Minor feature issue, some users affected | Within 1 hour |
|
||||
| SEV4 | Cosmetic or low-impact issue | Next business day |
|
||||
|
||||
## Communication Guidance
|
||||
|
||||
Provide clear, factual updates at regular cadence. Include: what's happening, who's affected, what we're doing, when the next update is.
|
||||
|
||||
## Output — Status Update
|
||||
|
||||
```markdown
|
||||
## Incident Update: [Title]
|
||||
**Severity:** SEV[1-4] | **Status:** Investigating | Identified | Monitoring | Resolved
|
||||
**Impact:** [Who/what is affected]
|
||||
**Last Updated:** [Timestamp]
|
||||
|
||||
### Current Status
|
||||
[What we know now]
|
||||
|
||||
### Actions Taken
|
||||
- [Action 1]
|
||||
- [Action 2]
|
||||
|
||||
### Next Steps
|
||||
- [What's happening next and ETA]
|
||||
|
||||
### Timeline
|
||||
| Time | Event |
|
||||
|------|-------|
|
||||
| [HH:MM] | [Event] |
|
||||
```
|
||||
|
||||
## Output — Postmortem
|
||||
|
||||
```markdown
|
||||
## Postmortem: [Incident Title]
|
||||
**Date:** [Date] | **Duration:** [X hours] | **Severity:** SEV[X]
|
||||
**Authors:** [Names] | **Status:** Draft
|
||||
|
||||
### Summary
|
||||
[2-3 sentence plain-language summary]
|
||||
|
||||
### Impact
|
||||
- [Users affected]
|
||||
- [Duration of impact]
|
||||
- [Business impact if quantifiable]
|
||||
|
||||
### Timeline
|
||||
| Time (UTC) | Event |
|
||||
|------------|-------|
|
||||
| [HH:MM] | [Event] |
|
||||
|
||||
### Root Cause
|
||||
[Detailed explanation of what caused the incident]
|
||||
|
||||
### 5 Whys
|
||||
1. Why did [symptom]? → [Because...]
|
||||
2. Why did [cause 1]? → [Because...]
|
||||
3. Why did [cause 2]? → [Because...]
|
||||
4. Why did [cause 3]? → [Because...]
|
||||
5. Why did [cause 4]? → [Root cause]
|
||||
|
||||
### What Went Well
|
||||
- [Things that worked]
|
||||
|
||||
### What Went Poorly
|
||||
- [Things that didn't work]
|
||||
|
||||
### Action Items
|
||||
| Action | Owner | Priority | Due Date |
|
||||
|--------|-------|----------|----------|
|
||||
| [Action] | [Person] | P0/P1/P2 | [Date] |
|
||||
|
||||
### Lessons Learned
|
||||
[Key takeaways for the team]
|
||||
```
|
||||
|
||||
## If Connectors Available
|
||||
|
||||
If **~~monitoring** is connected:
|
||||
- Pull alert details and metrics
|
||||
- Show graphs of affected metrics
|
||||
|
||||
If **~~incident management** is connected:
|
||||
- Create or update incident in PagerDuty/Opsgenie
|
||||
- Page on-call responders
|
||||
|
||||
If **~~chat** is connected:
|
||||
- Post status updates to incident channel
|
||||
- Create war room channel
|
||||
|
||||
## Tips
|
||||
|
||||
1. **Start writing immediately** — Don't wait for complete information. Update as you learn more.
|
||||
2. **Keep updates factual** — What we know, what we've done, what's next. No speculation.
|
||||
3. **Postmortems are blameless** — Focus on systems and processes, not individuals.
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
name: standup
|
||||
description: Generate a standup update from recent activity. Use when preparing for daily standup, summarizing yesterday's commits and PRs and ticket moves, formatting work into yesterday/today/blockers, or structuring a few rough notes into a shareable update.
|
||||
argument-hint: "[yesterday | today | blockers]"
|
||||
---
|
||||
|
||||
# /standup
|
||||
|
||||
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
|
||||
|
||||
Generate a standup update by pulling together recent activity across your tools.
|
||||
|
||||
## How It Works
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ STANDUP │
|
||||
├─────────────────────────────────────────────────────────────────┤
|
||||
│ STANDALONE (always works) │
|
||||
│ ✓ Tell me what you worked on and I'll structure it │
|
||||
│ ✓ Format for daily standup (yesterday / today / blockers) │
|
||||
│ ✓ Keep it concise and action-oriented │
|
||||
├─────────────────────────────────────────────────────────────────┤
|
||||
│ SUPERCHARGED (when you connect your tools) │
|
||||
│ + Source control: Recent commits and PRs │
|
||||
│ + Project tracker: Ticket status changes │
|
||||
│ + Chat: Relevant discussions and decisions │
|
||||
│ + CI/CD: Build and deploy status │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## What I Need From You
|
||||
|
||||
**Option A: Let me pull it**
|
||||
If your tools are connected, just say `/standup` and I'll gather everything automatically.
|
||||
|
||||
**Option B: Tell me what you did**
|
||||
"Worked on the auth migration, reviewed 3 PRs, got blocked on the API rate limiting issue."
|
||||
|
||||
## Output
|
||||
|
||||
```markdown
|
||||
## Standup — [Date]
|
||||
|
||||
### Yesterday
|
||||
- [Completed item with ticket reference if available]
|
||||
- [Completed item]
|
||||
|
||||
### Today
|
||||
- [Planned item with ticket reference]
|
||||
- [Planned item]
|
||||
|
||||
### Blockers
|
||||
- [Blocker with context and who can help]
|
||||
```
|
||||
|
||||
## If Connectors Available
|
||||
|
||||
If **~~source control** is connected:
|
||||
- Pull recent commits and PRs (opened, reviewed, merged)
|
||||
- Summarize code changes at a high level
|
||||
|
||||
If **~~project tracker** is connected:
|
||||
- Pull tickets moved to "in progress" or "done"
|
||||
- Show upcoming sprint items
|
||||
|
||||
If **~~chat** is connected:
|
||||
- Scan for relevant discussions and decisions
|
||||
- Flag threads needing your response
|
||||
|
||||
## Tips
|
||||
|
||||
1. **Run it every morning** — Build a habit and never scramble for standup notes.
|
||||
2. **Add context** — After I generate, add any nuance about blockers or priorities.
|
||||
3. **Share format** — Ask me to format for Slack, email, or your team's standup tool.
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
name: system-design
|
||||
description: Design systems, services, and architectures. Trigger with "design a system for", "how should we architect", "system design for", "what's the right architecture for", or when the user needs help with API design, data modeling, or service boundaries.
|
||||
---
|
||||
|
||||
# System Design
|
||||
|
||||
Help design systems and evaluate architectural decisions.
|
||||
|
||||
## Framework
|
||||
|
||||
### 1. Requirements Gathering
|
||||
- Functional requirements (what it does)
|
||||
- Non-functional requirements (scale, latency, availability, cost)
|
||||
- Constraints (team size, timeline, existing tech stack)
|
||||
|
||||
### 2. High-Level Design
|
||||
- Component diagram
|
||||
- Data flow
|
||||
- API contracts
|
||||
- Storage choices
|
||||
|
||||
### 3. Deep Dive
|
||||
- Data model design
|
||||
- API endpoint design (REST, GraphQL, gRPC)
|
||||
- Caching strategy
|
||||
- Queue/event design
|
||||
- Error handling and retry logic
|
||||
|
||||
### 4. Scale and Reliability
|
||||
- Load estimation
|
||||
- Horizontal vs. vertical scaling
|
||||
- Failover and redundancy
|
||||
- Monitoring and alerting
|
||||
|
||||
### 5. Trade-off Analysis
|
||||
- Every decision has trade-offs. Make them explicit.
|
||||
- Consider: complexity, cost, team familiarity, time to market, maintainability
|
||||
|
||||
## Output
|
||||
|
||||
Produce clear, structured design documents with diagrams (ASCII or described), explicit assumptions, and trade-off analysis. Always identify what you'd revisit as the system grows.
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
name: tech-debt
|
||||
description: Identify, categorize, and prioritize technical debt. Trigger with "tech debt", "technical debt audit", "what should we refactor", "code health", or when the user asks about code quality, refactoring priorities, or maintenance backlog.
|
||||
---
|
||||
|
||||
# Tech Debt Management
|
||||
|
||||
Systematically identify, categorize, and prioritize technical debt.
|
||||
|
||||
## Categories
|
||||
|
||||
| Type | Examples | Risk |
|
||||
|------|----------|------|
|
||||
| **Code debt** | Duplicated logic, poor abstractions, magic numbers | Bugs, slow development |
|
||||
| **Architecture debt** | Monolith that should be split, wrong data store | Scaling limits |
|
||||
| **Test debt** | Low coverage, flaky tests, missing integration tests | Regressions ship |
|
||||
| **Dependency debt** | Outdated libraries, unmaintained dependencies | Security vulns |
|
||||
| **Documentation debt** | Missing runbooks, outdated READMEs, tribal knowledge | Onboarding pain |
|
||||
| **Infrastructure debt** | Manual deploys, no monitoring, no IaC | Incidents, slow recovery |
|
||||
|
||||
## Prioritization Framework
|
||||
|
||||
Score each item on:
|
||||
- **Impact**: How much does it slow the team down? (1-5)
|
||||
- **Risk**: What happens if we don't fix it? (1-5)
|
||||
- **Effort**: How hard is the fix? (1-5, inverted — lower effort = higher priority)
|
||||
|
||||
Priority = (Impact + Risk) x (6 - Effort)
|
||||
|
||||
## Output
|
||||
|
||||
Produce a prioritized list with estimated effort, business justification for each item, and a phased remediation plan that can be done alongside feature work.
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
name: testing-strategy
|
||||
description: Design test strategies and test plans. Trigger with "how should we test", "test strategy for", "write tests for", "test plan", "what tests do we need", or when the user needs help with testing approaches, coverage, or test architecture.
|
||||
---
|
||||
|
||||
# Testing Strategy
|
||||
|
||||
Design effective testing strategies balancing coverage, speed, and maintenance.
|
||||
|
||||
## Testing Pyramid
|
||||
|
||||
```
|
||||
/ E2E \ Few, slow, high confidence
|
||||
/ Integration \ Some, medium speed
|
||||
/ Unit Tests \ Many, fast, focused
|
||||
```
|
||||
|
||||
## Strategy by Component Type
|
||||
|
||||
- **API endpoints**: Unit tests for business logic, integration tests for HTTP layer, contract tests for consumers
|
||||
- **Data pipelines**: Input validation, transformation correctness, idempotency tests
|
||||
- **Frontend**: Component tests, interaction tests, visual regression, accessibility
|
||||
- **Infrastructure**: Smoke tests, chaos engineering, load tests
|
||||
|
||||
## What to Cover
|
||||
|
||||
Focus on: business-critical paths, error handling, edge cases, security boundaries, data integrity.
|
||||
|
||||
Skip: trivial getters/setters, framework code, one-off scripts.
|
||||
|
||||
## Output
|
||||
|
||||
Produce a test plan with: what to test, test type for each area, coverage targets, and example test cases. Identify gaps in existing coverage.
|
||||
Reference in New Issue
Block a user