opencode-knowledge-work 0.0.0-stage → 0.1.0

package/content/design/skills/design-ux-copy/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: ux-copy
+description: Write or review UX copy — microcopy, error messages, empty states, CTAs. Trigger with "write copy for", "what should this button say?", "review this error message", or when naming a CTA, wording a confirmation dialog, filling an empty state, or writing onboarding text.
+argument-hint: "<context or copy to review>"
+---
+
+# /ux-copy
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
+
+Write or review UX copy for any interface context.
+
+## Usage
+
+```
+/ux-copy $ARGUMENTS
+```
+
+## What I Need From You
+
+- **Context**: What screen, flow, or feature?
+- **User state**: What is the user trying to do? How are they feeling?
+- **Tone**: Formal, friendly, playful, reassuring?
+- **Constraints**: Character limits, platform guidelines?
+
+## Principles
+
+1. **Clear**: Say exactly what you mean. No jargon, no ambiguity.
+2. **Concise**: Use the fewest words that convey the full meaning.
+3. **Consistent**: Same terms for the same things everywhere.
+4. **Useful**: Every word should help the user accomplish their goal.
+5. **Human**: Write like a helpful person, not a robot.
+
+## Copy Patterns
+
+### CTAs
+- Start with a verb: "Start free trial", "Save changes", "Download report"
+- Be specific: "Create account" not "Submit"
+- Match the outcome to the label
+
+### Error Messages
+Structure: What happened + Why + How to fix
+- "Payment declined. Your card was declined by your bank. Try a different card or contact your bank."
+
+### Empty States
+Structure: What this is + Why it's empty + How to start
+- "No projects yet. Create your first project to start collaborating with your team."
+
+### Confirmation Dialogs
+- Make the action clear: "Delete 3 files?" not "Are you sure?"
+- Describe consequences: "This can't be undone"
+- Label buttons with the action: "Delete files" / "Keep files" not "OK" / "Cancel"
+
+### Tooltips
+- Concise, helpful, never obvious
+
+### Loading States
+- Set expectations, reduce anxiety
+
+### Onboarding
+- Progressive disclosure, one concept at a time
+
+## Voice and Tone
+
+Adapt tone to context:
+- **Success**: Celebratory but not over the top
+- **Error**: Empathetic and helpful
+- **Warning**: Clear and actionable
+- **Neutral**: Informative and concise
+
+## Output
+
+```markdown
+## UX Copy: [Context]
+
+### Recommended Copy
+**[Element]**: [Copy]
+
+### Alternatives
+| Option | Copy | Tone | Best For |
+|--------|------|------|----------|
+| A | [Copy] | [Tone] | [When to use] |
+| B | [Copy] | [Tone] | [When to use] |
+| C | [Copy] | [Tone] | [When to use] |
+
+### Rationale
+[Why this copy works — user context, clarity, action-orientation]
+
+### Localization Notes
+[Anything translators should know — idioms to avoid, character expansion, cultural context]
+```
+
+## If Connectors Available
+
+If **~~knowledge base** is connected:
+- Pull your brand voice guidelines and content style guide
+- Check for existing copy patterns and terminology standards
+
+If **~~design tool** is connected:
+- View the screen context in Figma to understand the full user flow
+- Check character limits and layout constraints from the design
+
+## Tips
+
+1. **Be specific about context** — "Error message when payment fails" is better than "error message."
+2. **Share your brand voice** — "We're professional but warm" helps me match your tone.
+3. **Consider the user's emotional state** — Error messages need empathy. Success messages can celebrate.

package/content/engineering/.mcp.json

@@ -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": ""
+    }
+  }
+}

package/content/engineering/CONNECTORS.md

@@ -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 |

package/content/engineering/README.md

@@ -0,0 +1,136 @@
+# 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 plugin marketplace add anthropics/knowledge-work-plugins
+claude plugin install engineering@knowledge-work-plugins
+```
+
+## 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.

package/content/engineering/skills/engineering-architecture/SKILL.md

@@ -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.

package/content/engineering/skills/engineering-code-review/SKILL.md

@@ -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.

package/content/engineering/skills/engineering-debug/SKILL.md

@@ -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.

package/content/engineering/skills/engineering-deploy-checklist/SKILL.md

@@ -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.