chore: import upstream snapshot with attribution
This commit is contained in:
wehub-resource-sync
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "operations",
|
||||
"version": "1.3.0",
|
||||
"description": "Optimize business operations — vendor management, process documentation, change management, capacity planning, and compliance tracking. Keep your organization running efficiently.",
|
||||
"author": {
|
||||
"name": "Anthropic"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,32 @@
|
||||
{
|
||||
"mcpServers": {
|
||||
"slack": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.slack.com/mcp",
|
||||
"oauth": {
|
||||
"clientId": "1601185624273.8899143856786",
|
||||
"callbackPort": 3118
|
||||
}
|
||||
},
|
||||
"google calendar": {
|
||||
"type": "http",
|
||||
"url": ""
|
||||
},
|
||||
"gmail": {
|
||||
"type": "http",
|
||||
"url": ""
|
||||
},
|
||||
"notion": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.notion.com/mcp"
|
||||
},
|
||||
"atlassian": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.atlassian.com/v1/mcp"
|
||||
},
|
||||
"asana": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.asana.com/v2/mcp"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,20 @@
|
||||
# Connectors
|
||||
|
||||
## How tool references work
|
||||
|
||||
Plugin files use `~~category` as a placeholder for whatever tool the user connects in that category. For example, `~~ITSM` might mean ServiceNow, Zendesk, or any other service management tool with an MCP server.
|
||||
|
||||
Plugins are **tool-agnostic** — they describe workflows in terms of categories (ITSM, project tracker, knowledge base, 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 |
|
||||
|----------|-------------|-----------------|---------------|
|
||||
| Calendar | `~~calendar` | Google Calendar | Microsoft 365 |
|
||||
| Chat | `~~chat` | Slack | Microsoft Teams |
|
||||
| Email | `~~email` | Gmail, Microsoft 365 | — |
|
||||
| ITSM | `~~ITSM` | ServiceNow | Zendesk, Freshservice, Jira Service Management |
|
||||
| Knowledge base | `~~knowledge base` | Notion, Atlassian (Confluence) | Guru, Coda |
|
||||
| Project tracker | `~~project tracker` | Asana, Atlassian (Jira) | Linear, monday.com, ClickUp |
|
||||
| Procurement | `~~procurement` | — | Coupa, SAP Ariba, Zip |
|
||||
| Office suite | `~~office suite` | Microsoft 365 | Google Workspace |
|
||||
@@ -0,0 +1,134 @@
|
||||
# Operations Plugin
|
||||
|
||||
A business operations plugin primarily designed for [Cowork](https://claude.com/product/cowork), Anthropic's agentic desktop application — though it also works in Claude Code. Helps with vendor management, process documentation, change management, capacity planning, compliance tracking, and resource planning. Works with any ops team — standalone with your input, supercharged when you connect your ITSM, project tracker, and other tools.
|
||||
|
||||
## Installation
|
||||
|
||||
```bash
|
||||
claude plugins add knowledge-work-plugins/operations
|
||||
```
|
||||
|
||||
## Commands
|
||||
|
||||
Explicit workflows you invoke with a slash command:
|
||||
|
||||
| Command | Description |
|
||||
|---|---|
|
||||
| `/vendor-review` | Evaluate a vendor — cost analysis, risk assessment, contract summary, and renewal recommendation |
|
||||
| `/process-doc` | Document a business process — flowcharts, RACI matrices, SOPs, and runbooks |
|
||||
| `/change-request` | Create a change management request — impact analysis, rollback plan, approval routing |
|
||||
| `/capacity-plan` | Plan resource capacity — workload analysis, headcount modeling, utilization forecasting |
|
||||
| `/status-report` | Generate a status report — project updates, KPIs, risks, and action items for leadership |
|
||||
| `/runbook` | Create or update an operational runbook — step-by-step procedures for recurring tasks |
|
||||
|
||||
All commands work **standalone** (provide context and details) and get **supercharged** with MCP connectors.
|
||||
|
||||
## Skills
|
||||
|
||||
Domain knowledge Claude uses automatically when relevant:
|
||||
|
||||
| Skill | Description |
|
||||
|---|---|
|
||||
| `vendor-management` | Evaluate, compare, and manage vendor relationships — contracts, performance, risk |
|
||||
| `process-optimization` | Analyze and improve business processes — identify bottlenecks, reduce waste, streamline workflows |
|
||||
| `change-management` | Plan and execute organizational or technical changes — communication, training, adoption |
|
||||
| `risk-assessment` | Identify, assess, and mitigate operational risks — risk registers, impact analysis, controls |
|
||||
| `compliance-tracking` | Track compliance requirements — audits, certifications, regulatory deadlines, policy adherence |
|
||||
| `resource-planning` | Plan and optimize resource allocation — capacity, utilization, forecasting, budget |
|
||||
|
||||
## Example Workflows
|
||||
|
||||
### Evaluating a Vendor
|
||||
|
||||
```
|
||||
/vendor-review
|
||||
```
|
||||
|
||||
Provide the vendor name, contract details, or upload a proposal. Get a structured evaluation with cost analysis, risk flags, and a recommendation.
|
||||
|
||||
### Documenting a Process
|
||||
|
||||
```
|
||||
/process-doc employee offboarding
|
||||
```
|
||||
|
||||
Describe the process or walk me through it. Get a complete SOP with flowchart, RACI matrix, and step-by-step procedures.
|
||||
|
||||
### Submitting a Change Request
|
||||
|
||||
```
|
||||
/change-request
|
||||
```
|
||||
|
||||
Describe the change. Get an impact analysis, risk assessment, rollback plan, and communication template ready for approval.
|
||||
|
||||
### Planning Capacity
|
||||
|
||||
```
|
||||
/capacity-plan
|
||||
```
|
||||
|
||||
Upload team data or describe your resources. Get utilization analysis, bottleneck identification, and headcount recommendations.
|
||||
|
||||
### Leadership Status Report
|
||||
|
||||
```
|
||||
/status-report
|
||||
```
|
||||
|
||||
I'll pull updates from your connected tools (or ask you for input) and generate a polished status report with KPIs, risks, and next steps.
|
||||
|
||||
### Creating a Runbook
|
||||
|
||||
```
|
||||
/runbook monthly close process
|
||||
```
|
||||
|
||||
Walk me through the process once. I'll document it as a repeatable runbook with checklists, troubleshooting, and escalation paths.
|
||||
|
||||
## Standalone + Supercharged
|
||||
|
||||
Every command and skill works without any integrations:
|
||||
|
||||
| What You Can Do | Standalone | Supercharged With |
|
||||
|-----------------|------------|-------------------|
|
||||
| Vendor reviews | Provide details, upload proposals | Procurement, Knowledge base |
|
||||
| Process documentation | Describe the process | Knowledge base (existing docs) |
|
||||
| Change requests | Describe the change | ITSM, Project tracker |
|
||||
| Capacity planning | Upload data, describe team | Project tracker (workload data) |
|
||||
| Status reports | Provide updates manually | Project tracker, Chat, Calendar |
|
||||
| Runbooks | Walk through the process | Knowledge base, ITSM |
|
||||
|
||||
## 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 |
|
||||
|---|---|---|
|
||||
| **ITSM** | ServiceNow, Zendesk | Ticket management, change requests, incident tracking |
|
||||
| **Project tracker** | Asana, Jira, monday.com | Project status, resource allocation, task tracking |
|
||||
| **Knowledge base** | Notion, Confluence | Process docs, runbooks, policies |
|
||||
| **Chat** | Slack, Teams | Team coordination, approvals, status updates |
|
||||
| **Calendar** | Google Calendar, Microsoft 365 | Meeting scheduling, deadline tracking |
|
||||
| **Email** | Gmail, Microsoft 365 | Vendor communications, approvals |
|
||||
|
||||
See [CONNECTORS.md](CONNECTORS.md) for the full list of supported integrations.
|
||||
|
||||
## Settings
|
||||
|
||||
Create a local settings file at `operations/.claude/settings.local.json` to personalize:
|
||||
|
||||
```json
|
||||
{
|
||||
"company": "Your Company",
|
||||
"team": "Operations",
|
||||
"reportingCadence": "weekly",
|
||||
"approvalChain": ["Manager", "Director", "VP"],
|
||||
"complianceFrameworks": ["SOC 2", "ISO 27001"],
|
||||
"fiscalYearStart": "January"
|
||||
}
|
||||
```
|
||||
|
||||
The plugin will ask you for this information interactively if it's not configured.
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
name: capacity-plan
|
||||
description: Plan resource capacity — workload analysis and utilization forecasting. Use when heading into quarterly planning, the team feels overallocated and you need the numbers, deciding whether to hire or deprioritize, or stress-testing whether upcoming projects fit the people you have.
|
||||
argument-hint: "<team or project scope>"
|
||||
---
|
||||
|
||||
# /capacity-plan
|
||||
|
||||
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
|
||||
|
||||
Analyze team capacity and plan resource allocation.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/capacity-plan $ARGUMENTS
|
||||
```
|
||||
|
||||
## What I Need From You
|
||||
|
||||
- **Team size and roles**: Who do you have?
|
||||
- **Current workload**: What are they working on? (Upload from project tracker or describe)
|
||||
- **Upcoming work**: What's coming next quarter?
|
||||
- **Constraints**: Budget, hiring timeline, skill requirements
|
||||
|
||||
## Planning Dimensions
|
||||
|
||||
### People
|
||||
- Available headcount and skills
|
||||
- Current allocation and utilization
|
||||
- Planned hires and timeline
|
||||
- Contractor and vendor capacity
|
||||
|
||||
### Budget
|
||||
- Operating budget by category
|
||||
- Project-specific budgets
|
||||
- Variance tracking
|
||||
- Forecast vs. actual
|
||||
|
||||
### Time
|
||||
- Project timelines and dependencies
|
||||
- Critical path analysis
|
||||
- Buffer and contingency planning
|
||||
- Deadline management
|
||||
|
||||
## Utilization Targets
|
||||
|
||||
| Role Type | Target Utilization | Notes |
|
||||
|-----------|-------------------|-------|
|
||||
| IC / Specialist | 75-80% | Leave room for reactive work and growth |
|
||||
| Manager | 60-70% | Management overhead, meetings, 1:1s |
|
||||
| On-call / Support | 50-60% | Interrupt-driven work is unpredictable |
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Planning to 100% utilization (no buffer for surprises)
|
||||
- Ignoring meeting load and context-switching costs
|
||||
- Not accounting for vacation, holidays, and sick time
|
||||
- Treating all hours as equal (creative work ≠ admin work)
|
||||
|
||||
## Output
|
||||
|
||||
```markdown
|
||||
## Capacity Plan: [Team/Project]
|
||||
**Period:** [Date range] | **Team Size:** [X]
|
||||
|
||||
### Current Utilization
|
||||
| Person/Role | Capacity | Allocated | Available | Utilization |
|
||||
|-------------|----------|-----------|-----------|-------------|
|
||||
| [Name/Role] | [hrs/wk] | [hrs/wk] | [hrs/wk] | [X]% |
|
||||
|
||||
### Capacity Summary
|
||||
- **Total capacity**: [X] hours/week
|
||||
- **Currently allocated**: [X] hours/week ([X]%)
|
||||
- **Available**: [X] hours/week ([X]%)
|
||||
- **Overallocated**: [X people above 100%]
|
||||
|
||||
### Upcoming Demand
|
||||
| Project/Initiative | Start | End | Resources Needed | Gap |
|
||||
|--------------------|-------|-----|-----------------|-----|
|
||||
| [Project] | [Date] | [Date] | [X FTEs] | [Covered/Gap] |
|
||||
|
||||
### Bottlenecks
|
||||
- [Skill or role that's oversubscribed]
|
||||
- [Time period with a crunch]
|
||||
|
||||
### Recommendations
|
||||
1. [Hire / Contract / Reprioritize / Delay]
|
||||
2. [Specific action]
|
||||
|
||||
### Scenarios
|
||||
| Scenario | Outcome |
|
||||
|----------|---------|
|
||||
| Do nothing | [What happens] |
|
||||
| Hire [X] | [What changes] |
|
||||
| Deprioritize [Y] | [What frees up] |
|
||||
```
|
||||
|
||||
## If Connectors Available
|
||||
|
||||
If **~~project tracker** is connected:
|
||||
- Pull current workload and ticket assignments automatically
|
||||
- Show upcoming sprint or quarter commitments per person
|
||||
|
||||
If **~~calendar** is connected:
|
||||
- Factor in PTO, holidays, and recurring meeting load
|
||||
- Calculate actual available hours per person
|
||||
|
||||
## Tips
|
||||
|
||||
1. **Include all work** — BAU, projects, support, meetings. People aren't 100% available for project work.
|
||||
2. **Plan for buffer** — Target 80% utilization. 100% means no room for surprises.
|
||||
3. **Update regularly** — Capacity plans go stale fast. Review monthly.
|
||||
@@ -0,0 +1,121 @@
|
||||
---
|
||||
name: change-request
|
||||
description: Create a change management request with impact analysis and rollback plan. Use when proposing a system or process change that needs approval, preparing a change record for CAB review, documenting risk and rollback steps before a deployment, or planning stakeholder communications for a rollout.
|
||||
argument-hint: "<change description>"
|
||||
---
|
||||
|
||||
# /change-request
|
||||
|
||||
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
|
||||
|
||||
Create a structured change request with impact analysis, risk assessment, and rollback plan.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/change-request $ARGUMENTS
|
||||
```
|
||||
|
||||
## Change Management Framework
|
||||
|
||||
Apply the assess-plan-execute-sustain framework when building the request:
|
||||
|
||||
### 1. Assess
|
||||
- What is changing?
|
||||
- Who is affected?
|
||||
- How significant is the change? (Low / Medium / High)
|
||||
- What resistance should we expect?
|
||||
|
||||
### 2. Plan
|
||||
- Communication plan (who, what, when, how)
|
||||
- Training plan (what skills are needed, how to deliver)
|
||||
- Support plan (help desk, champions, FAQs)
|
||||
- Timeline with milestones
|
||||
|
||||
### 3. Execute
|
||||
- Announce and explain the "why"
|
||||
- Train and support
|
||||
- Monitor adoption
|
||||
- Address resistance
|
||||
|
||||
### 4. Sustain
|
||||
- Measure adoption and effectiveness
|
||||
- Reinforce new behaviors
|
||||
- Address lingering issues
|
||||
- Document lessons learned
|
||||
|
||||
## Communication Principles
|
||||
|
||||
- Explain the **why** before the **what**
|
||||
- Communicate early and often
|
||||
- Use multiple channels
|
||||
- Acknowledge what's being lost, not just what's being gained
|
||||
- Provide a clear path for questions and concerns
|
||||
|
||||
## Output
|
||||
|
||||
```markdown
|
||||
## Change Request: [Title]
|
||||
**Requester:** [Name] | **Date:** [Date] | **Priority:** [Critical/High/Medium/Low]
|
||||
**Status:** Draft | Pending Approval | Approved | In Progress | Complete
|
||||
|
||||
### Description
|
||||
[What is changing and why]
|
||||
|
||||
### Business Justification
|
||||
[Why this change is needed — cost savings, compliance, efficiency, risk reduction]
|
||||
|
||||
### Impact Analysis
|
||||
| Area | Impact | Details |
|
||||
|------|--------|---------|
|
||||
| Users | [High/Med/Low/None] | [Who is affected and how] |
|
||||
| Systems | [High/Med/Low/None] | [What systems are affected] |
|
||||
| Processes | [High/Med/Low/None] | [What workflows change] |
|
||||
| Cost | [High/Med/Low/None] | [Budget impact] |
|
||||
|
||||
### Risk Assessment
|
||||
| Risk | Likelihood | Impact | Mitigation |
|
||||
|------|-----------|--------|------------|
|
||||
| [Risk] | [H/M/L] | [H/M/L] | [How to mitigate] |
|
||||
|
||||
### Implementation Plan
|
||||
| Step | Owner | Timeline | Dependencies |
|
||||
|------|-------|----------|--------------|
|
||||
| [Step] | [Person] | [Date] | [What it depends on] |
|
||||
|
||||
### Communication Plan
|
||||
| Audience | Message | Channel | Timing |
|
||||
|----------|---------|---------|--------|
|
||||
| [Who] | [What to tell them] | [How] | [When] |
|
||||
|
||||
### Rollback Plan
|
||||
[Step-by-step plan to reverse the change if needed]
|
||||
- Trigger: [When to roll back]
|
||||
- Steps: [How to roll back]
|
||||
- Verification: [How to confirm rollback worked]
|
||||
|
||||
### Approvals Required
|
||||
| Approver | Role | Status |
|
||||
|----------|------|--------|
|
||||
| [Name] | [Role] | Pending |
|
||||
```
|
||||
|
||||
## If Connectors Available
|
||||
|
||||
If **~~ITSM** is connected:
|
||||
- Create the change request ticket automatically
|
||||
- Pull change advisory board schedule and approval workflows
|
||||
|
||||
If **~~project tracker** is connected:
|
||||
- Link to related implementation tasks and dependencies
|
||||
- Track change progress against milestones
|
||||
|
||||
If **~~chat** is connected:
|
||||
- Draft stakeholder notifications for the communication plan
|
||||
- Post change updates to the relevant team channels
|
||||
|
||||
## Tips
|
||||
|
||||
1. **Be specific about impact** — "Everyone" is not an impact assessment. "200 users in the billing team" is.
|
||||
2. **Always have a rollback plan** — Even if you're confident, plan for failure.
|
||||
3. **Communicate early** — Surprises create resistance. Previews create buy-in.
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: compliance-tracking
|
||||
description: Track compliance requirements and audit readiness. Trigger with "compliance", "audit prep", "SOC 2", "ISO 27001", "GDPR", "regulatory requirement", or when the user needs help tracking, preparing for, or documenting compliance activities.
|
||||
---
|
||||
|
||||
# Compliance Tracking
|
||||
|
||||
Help track compliance requirements, prepare for audits, and maintain regulatory readiness.
|
||||
|
||||
## Common Frameworks
|
||||
|
||||
| Framework | Focus | Key Requirements |
|
||||
|-----------|-------|-----------------|
|
||||
| SOC 2 | Service organizations | Security, availability, processing integrity, confidentiality, privacy |
|
||||
| ISO 27001 | Information security | Risk assessment, security controls, continuous improvement |
|
||||
| GDPR | Data privacy (EU) | Consent, data rights, breach notification, DPO |
|
||||
| HIPAA | Healthcare data (US) | PHI protection, access controls, audit trails |
|
||||
| PCI DSS | Payment card data | Encryption, access control, vulnerability management |
|
||||
|
||||
## Compliance Tracking Components
|
||||
|
||||
### Control Inventory
|
||||
- Map controls to framework requirements
|
||||
- Document control owners and evidence
|
||||
- Track control effectiveness
|
||||
|
||||
### Audit Calendar
|
||||
- Upcoming audit dates and deadlines
|
||||
- Evidence collection timelines
|
||||
- Remediation deadlines
|
||||
|
||||
### Evidence Management
|
||||
- What evidence is needed for each control
|
||||
- Where evidence is stored
|
||||
- When evidence was last collected
|
||||
|
||||
### Gap Analysis
|
||||
- Requirements vs. current state
|
||||
- Prioritized remediation plan
|
||||
- Timeline to compliance
|
||||
|
||||
## Output
|
||||
|
||||
Produce compliance status dashboards, gap analyses, audit prep checklists, and evidence collection plans.
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
name: process-doc
|
||||
description: Document a business process — flowcharts, RACI, and SOPs. Use when formalizing a process that lives in someone's head, building a RACI to clarify who owns what, writing an SOP for a handoff or audit, or capturing the exceptions and edge cases of how work actually gets done.
|
||||
argument-hint: "<process name or description>"
|
||||
---
|
||||
|
||||
# /process-doc
|
||||
|
||||
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
|
||||
|
||||
Document a business process as a complete standard operating procedure (SOP).
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/process-doc $ARGUMENTS
|
||||
```
|
||||
|
||||
## How It Works
|
||||
|
||||
Walk me through the process — describe it, paste existing docs, or just tell me the name and I'll ask the right questions. I'll produce a complete SOP.
|
||||
|
||||
## Output
|
||||
|
||||
```markdown
|
||||
## Process Document: [Process Name]
|
||||
**Owner:** [Person/Team] | **Last Updated:** [Date] | **Review Cadence:** [Quarterly/Annually]
|
||||
|
||||
### Purpose
|
||||
[Why this process exists and what it accomplishes]
|
||||
|
||||
### Scope
|
||||
[What's included and excluded]
|
||||
|
||||
### RACI Matrix
|
||||
| Step | Responsible | Accountable | Consulted | Informed |
|
||||
|------|------------|-------------|-----------|----------|
|
||||
| [Step] | [Who does it] | [Who owns it] | [Who to ask] | [Who to tell] |
|
||||
|
||||
### Process Flow
|
||||
[ASCII flowchart or step-by-step description]
|
||||
|
||||
### Detailed Steps
|
||||
|
||||
#### Step 1: [Name]
|
||||
- **Who**: [Role]
|
||||
- **When**: [Trigger or timing]
|
||||
- **How**: [Detailed instructions]
|
||||
- **Output**: [What this step produces]
|
||||
|
||||
#### Step 2: [Name]
|
||||
[Same format]
|
||||
|
||||
### Exceptions and Edge Cases
|
||||
| Scenario | What to Do |
|
||||
|----------|-----------|
|
||||
| [Exception] | [How to handle it] |
|
||||
|
||||
### Metrics
|
||||
| Metric | Target | How to Measure |
|
||||
|--------|--------|----------------|
|
||||
| [Metric] | [Target] | [Method] |
|
||||
|
||||
### Related Documents
|
||||
- [Link to related process or policy]
|
||||
```
|
||||
|
||||
## If Connectors Available
|
||||
|
||||
If **~~knowledge base** is connected:
|
||||
- Search for existing process documentation to update rather than duplicate
|
||||
- Publish the completed SOP to your wiki
|
||||
|
||||
If **~~project tracker** is connected:
|
||||
- Link the process to related projects and workflows
|
||||
- Create tasks for process improvement action items
|
||||
|
||||
## Tips
|
||||
|
||||
1. **Start messy** — You don't need a perfect description. Tell me how it works today and I'll structure it.
|
||||
2. **Include the exceptions** — "Usually we do X, but sometimes Y" is the most valuable part to document.
|
||||
3. **Name the people** — Even if roles change, knowing who does what today helps get the process right.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: process-optimization
|
||||
description: Analyze and improve business processes. Trigger with "this process is slow", "how can we improve", "streamline this workflow", "too many steps", "bottleneck", or when the user describes an inefficient process they want to fix.
|
||||
---
|
||||
|
||||
# Process Optimization
|
||||
|
||||
Analyze existing processes and recommend improvements.
|
||||
|
||||
## Analysis Framework
|
||||
|
||||
### 1. Map Current State
|
||||
- Document every step, decision point, and handoff
|
||||
- Identify who does what and how long each step takes
|
||||
- Note manual steps, approvals, and waiting times
|
||||
|
||||
### 2. Identify Waste
|
||||
- **Waiting**: Time spent in queues or waiting for approvals
|
||||
- **Rework**: Steps that fail and need to be redone
|
||||
- **Handoffs**: Each handoff is a potential point of failure or delay
|
||||
- **Over-processing**: Steps that add no value
|
||||
- **Manual work**: Tasks that could be automated
|
||||
|
||||
### 3. Design Future State
|
||||
- Eliminate unnecessary steps
|
||||
- Automate where possible
|
||||
- Reduce handoffs
|
||||
- Parallelize independent steps
|
||||
- Add checkpoints (not gates)
|
||||
|
||||
### 4. Measure Impact
|
||||
- Time saved per cycle
|
||||
- Error rate reduction
|
||||
- Cost savings
|
||||
- Employee satisfaction improvement
|
||||
|
||||
## Output
|
||||
|
||||
Produce a before/after process comparison with specific improvement recommendations, estimated impact, and an implementation plan.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
name: risk-assessment
|
||||
description: Identify, assess, and mitigate operational risks. Trigger with "what are the risks", "risk assessment", "risk register", "what could go wrong", or when the user is evaluating risks associated with a project, vendor, process, or decision.
|
||||
---
|
||||
|
||||
# Risk Assessment
|
||||
|
||||
Systematically identify, assess, and plan mitigations for operational risks.
|
||||
|
||||
## Risk Assessment Matrix
|
||||
|
||||
| | Low Impact | Medium Impact | High Impact |
|
||||
|---|-----------|---------------|-------------|
|
||||
| **High Likelihood** | Medium | High | Critical |
|
||||
| **Medium Likelihood** | Low | Medium | High |
|
||||
| **Low Likelihood** | Low | Low | Medium |
|
||||
|
||||
## Risk Categories
|
||||
|
||||
- **Operational**: Process failures, staffing gaps, system outages
|
||||
- **Financial**: Budget overruns, vendor cost increases, revenue impact
|
||||
- **Compliance**: Regulatory violations, audit findings, policy breaches
|
||||
- **Strategic**: Market changes, competitive threats, technology shifts
|
||||
- **Reputational**: Customer impact, public perception, partner relationships
|
||||
- **Security**: Data breaches, access control failures, third-party vulnerabilities
|
||||
|
||||
## Risk Register Format
|
||||
|
||||
For each risk, document:
|
||||
- **Description**: What could happen
|
||||
- **Likelihood**: High / Medium / Low
|
||||
- **Impact**: High / Medium / Low
|
||||
- **Risk Level**: Critical / High / Medium / Low
|
||||
- **Mitigation**: What we're doing to reduce likelihood or impact
|
||||
- **Owner**: Who is responsible for managing this risk
|
||||
- **Status**: Open / Mitigated / Accepted / Closed
|
||||
|
||||
## Output
|
||||
|
||||
Produce a prioritized risk register with specific, actionable mitigations. Focus on risks that are controllable and material.
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
name: runbook
|
||||
description: Create or update an operational runbook for a recurring task or procedure. Use when documenting a task that on-call or ops needs to run repeatably, turning tribal knowledge into exact step-by-step commands, adding troubleshooting and rollback steps to an existing procedure, or writing escalation paths for when things go wrong.
|
||||
argument-hint: "<process or task name>"
|
||||
---
|
||||
|
||||
# /runbook
|
||||
|
||||
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
|
||||
|
||||
Create a step-by-step operational runbook for a recurring task or procedure.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/runbook $ARGUMENTS
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
```markdown
|
||||
## Runbook: [Task Name]
|
||||
**Owner:** [Team/Person] | **Frequency:** [Daily/Weekly/Monthly/As Needed]
|
||||
**Last Updated:** [Date] | **Last Run:** [Date]
|
||||
|
||||
### Purpose
|
||||
[What this runbook accomplishes and when to use it]
|
||||
|
||||
### Prerequisites
|
||||
- [ ] [Access or permission needed]
|
||||
- [ ] [Tool or system required]
|
||||
- [ ] [Data or input needed]
|
||||
|
||||
### Procedure
|
||||
|
||||
#### Step 1: [Name]
|
||||
```
|
||||
[Exact command, action, or instruction]
|
||||
```
|
||||
**Expected result:** [What should happen]
|
||||
**If it fails:** [What to do]
|
||||
|
||||
#### Step 2: [Name]
|
||||
```
|
||||
[Exact command, action, or instruction]
|
||||
```
|
||||
**Expected result:** [What should happen]
|
||||
**If it fails:** [What to do]
|
||||
|
||||
### Verification
|
||||
- [ ] [How to confirm the task completed successfully]
|
||||
- [ ] [What to check]
|
||||
|
||||
### Troubleshooting
|
||||
| Symptom | Likely Cause | Fix |
|
||||
|---------|-------------|-----|
|
||||
| [What you see] | [Why] | [What to do] |
|
||||
|
||||
### Rollback
|
||||
[How to undo this if something goes wrong]
|
||||
|
||||
### Escalation
|
||||
| Situation | Contact | Method |
|
||||
|-----------|---------|--------|
|
||||
| [When to escalate] | [Who] | [How to reach them] |
|
||||
|
||||
### History
|
||||
| Date | Run By | Notes |
|
||||
|------|--------|-------|
|
||||
| [Date] | [Person] | [Any issues or observations] |
|
||||
```
|
||||
|
||||
## If Connectors Available
|
||||
|
||||
If **~~knowledge base** is connected:
|
||||
- Search for existing runbooks to update rather than create from scratch
|
||||
- Publish the completed runbook to your ops wiki
|
||||
|
||||
If **~~ITSM** is connected:
|
||||
- Link the runbook to related incident types and change requests
|
||||
- Auto-populate escalation contacts from on-call schedules
|
||||
|
||||
## Tips
|
||||
|
||||
1. **Be painfully specific** — "Run the script" is not a step. "Run `python sync.py --prod --dry-run` from the ops server" is.
|
||||
2. **Include failure modes** — What can go wrong at each step and what to do about it.
|
||||
3. **Test the runbook** — Have someone unfamiliar with the process follow it. Fix where they get stuck.
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
name: status-report
|
||||
description: Generate a status report with KPIs, risks, and action items. Use when writing a weekly or monthly update for leadership, summarizing project health with green/yellow/red status, surfacing risks and decisions that need stakeholder attention, or turning a pile of project tracker activity into a readable narrative.
|
||||
argument-hint: "[weekly | monthly | quarterly] [project or team]"
|
||||
---
|
||||
|
||||
# /status-report
|
||||
|
||||
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
|
||||
|
||||
Generate a polished status report for leadership or stakeholders. See the **risk-assessment** skill for risk matrix frameworks and severity definitions.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/status-report $ARGUMENTS
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
```markdown
|
||||
## Status Report: [Project/Team] — [Period]
|
||||
**Author:** [Name] | **Date:** [Date]
|
||||
|
||||
### Executive Summary
|
||||
[3-4 sentence overview — what's on track, what needs attention, key wins]
|
||||
|
||||
### Overall Status: 🟢 On Track / 🟡 At Risk / 🔴 Off Track
|
||||
|
||||
### Key Metrics
|
||||
| Metric | Target | Actual | Trend | Status |
|
||||
|--------|--------|--------|-------|--------|
|
||||
| [KPI] | [Target] | [Actual] | [up/down/flat] | 🟢/🟡/🔴 |
|
||||
|
||||
### Accomplishments This Period
|
||||
- [Win 1]
|
||||
- [Win 2]
|
||||
|
||||
### In Progress
|
||||
| Item | Owner | Status | ETA | Notes |
|
||||
|------|-------|--------|-----|-------|
|
||||
| [Item] | [Person] | [Status] | [Date] | [Context] |
|
||||
|
||||
### Risks and Issues
|
||||
| Risk/Issue | Impact | Mitigation | Owner |
|
||||
|------------|--------|------------|-------|
|
||||
| [Risk] | [Impact] | [What we're doing] | [Who] |
|
||||
|
||||
### Decisions Needed
|
||||
| Decision | Context | Deadline | Recommended Action |
|
||||
|----------|---------|----------|--------------------|
|
||||
| [Decision] | [Why it matters] | [When] | [What I recommend] |
|
||||
|
||||
### Next Period Priorities
|
||||
1. [Priority 1]
|
||||
2. [Priority 2]
|
||||
3. [Priority 3]
|
||||
```
|
||||
|
||||
## If Connectors Available
|
||||
|
||||
If **~~project tracker** is connected:
|
||||
- Pull project status, completed items, and upcoming milestones automatically
|
||||
- Identify at-risk items and overdue tasks
|
||||
|
||||
If **~~chat** is connected:
|
||||
- Scan recent team discussions for decisions and blockers to include
|
||||
- Offer to post the finished report to a channel
|
||||
|
||||
If **~~calendar** is connected:
|
||||
- Reference key meetings and decisions from the reporting period
|
||||
|
||||
## Tips
|
||||
|
||||
1. **Lead with the headline** — Busy leaders read the first 3 lines. Make them count.
|
||||
2. **Be honest about risks** — Surfacing issues early builds trust. Surprises erode it.
|
||||
3. **Make decisions easy** — For each decision needed, provide context and a recommendation.
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
name: vendor-review
|
||||
description: Evaluate a vendor — cost analysis, risk assessment, and recommendation. Use when reviewing a new vendor proposal, deciding whether to renew or replace a contract, comparing two vendors side-by-side, or building a TCO breakdown and negotiation points before procurement sign-off.
|
||||
argument-hint: "<vendor name or proposal>"
|
||||
---
|
||||
|
||||
# /vendor-review
|
||||
|
||||
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
|
||||
|
||||
Evaluate a vendor with structured analysis covering cost, risk, performance, and fit.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/vendor-review $ARGUMENTS
|
||||
```
|
||||
|
||||
## What I Need From You
|
||||
|
||||
- **Vendor name**: Who are you evaluating?
|
||||
- **Context**: New vendor evaluation, renewal decision, or comparison?
|
||||
- **Details**: Contract terms, pricing, proposal document, or current performance data
|
||||
|
||||
## Evaluation Framework
|
||||
|
||||
### Cost Analysis (Total Cost of Ownership)
|
||||
- Total cost of ownership (not just license fees)
|
||||
- Implementation and migration costs
|
||||
- Training and onboarding costs
|
||||
- Ongoing support and maintenance
|
||||
- Exit costs (data migration, contract termination)
|
||||
|
||||
### Risk Assessment
|
||||
- Vendor financial stability
|
||||
- Security and compliance posture
|
||||
- Concentration risk (single vendor dependency)
|
||||
- Contract lock-in and exit terms
|
||||
- Business continuity and disaster recovery
|
||||
|
||||
### Performance Metrics
|
||||
- SLA compliance
|
||||
- Support response times
|
||||
- Uptime and reliability
|
||||
- Feature delivery cadence
|
||||
- Customer satisfaction
|
||||
|
||||
### Comparison Matrix
|
||||
When comparing vendors, produce a side-by-side matrix covering: pricing, features, integrations, security, support, contract terms, and references.
|
||||
|
||||
## Output
|
||||
|
||||
```markdown
|
||||
## Vendor Review: [Vendor Name]
|
||||
**Date:** [Date] | **Type:** [New / Renewal / Comparison]
|
||||
|
||||
### Summary
|
||||
[2-3 sentence recommendation]
|
||||
|
||||
### Cost Analysis
|
||||
| Component | Annual Cost | Notes |
|
||||
|-----------|-------------|-------|
|
||||
| License/subscription | $[X] | [Per seat, flat, usage-based] |
|
||||
| Implementation | $[X] | [One-time] |
|
||||
| Support/maintenance | $[X] | [Included or add-on] |
|
||||
| **Total Year 1** | **$[X]** | |
|
||||
| **Total 3-Year** | **$[X]** | |
|
||||
|
||||
### Risk Assessment
|
||||
| Risk | Likelihood | Impact | Mitigation |
|
||||
|------|-----------|--------|------------|
|
||||
| [Risk] | High/Med/Low | High/Med/Low | [Mitigation] |
|
||||
|
||||
### Strengths
|
||||
- [Strength 1]
|
||||
- [Strength 2]
|
||||
|
||||
### Concerns
|
||||
- [Concern 1]
|
||||
- [Concern 2]
|
||||
|
||||
### Recommendation
|
||||
[Proceed / Negotiate / Pass] — [Reasoning]
|
||||
|
||||
### Negotiation Points
|
||||
- [Leverage point 1]
|
||||
- [Leverage point 2]
|
||||
```
|
||||
|
||||
## If Connectors Available
|
||||
|
||||
If **~~knowledge base** is connected:
|
||||
- Search for existing vendor evaluations, contracts, and performance reviews
|
||||
- Pull procurement policies and approval thresholds
|
||||
|
||||
If **~~procurement** is connected:
|
||||
- Pull current contract terms, spend history, and renewal dates
|
||||
- Compare pricing against existing vendor agreements
|
||||
|
||||
## Tips
|
||||
|
||||
1. **Upload the proposal** — I can extract pricing, terms, and SLAs from vendor documents.
|
||||
2. **Compare vendors** — "Compare Vendor A vs Vendor B" gets you a side-by-side analysis.
|
||||
3. **Include current spend** — For renewals, knowing what you pay now helps evaluate price changes.
|
||||
Reference in New Issue
Block a user