feat: add 27 new skills across 7 professions — 80 skills, 21 plugins (v5.0.0)
This commit is contained in:
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/plugin.schema.json",
|
||||
"name": "pm-operations",
|
||||
"version": "1.0.0",
|
||||
"description": "Operations skills: Process Documentation, SOP Writer, Vendor Evaluation, Project Status Report. Document workflows, write audit-ready SOPs, evaluate vendors with weighted scorecards, and produce RAG status reports.",
|
||||
"author": {
|
||||
"name": "Mohit Aggarwal",
|
||||
"email": "mohit15856@gmail.com"
|
||||
},
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills",
|
||||
"license": "MIT",
|
||||
"keywords": ["operations", "process", "sop", "vendor", "procurement", "project-management", "rag-status"]
|
||||
}
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
name: process-documentation
|
||||
description: "Document any business process in a clear, structured format. Use when asked to document a process, write a process guide, create a workflow document, or map out how something works. Produces a complete process document with steps, roles, inputs, outputs, and edge cases."
|
||||
---
|
||||
|
||||
# Process Documentation Skill
|
||||
|
||||
Produces clear, structured process documentation that someone new to a role can follow without needing to ask questions.
|
||||
|
||||
## Required Inputs
|
||||
- **Process name**
|
||||
- **Process description** (rough notes are fine)
|
||||
- **Who does this process** (roles involved)
|
||||
- **How often it runs** (daily / weekly / monthly / event-triggered)
|
||||
- **Tools involved**
|
||||
- **Known edge cases**
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Process: [Process Name]
|
||||
**Owner:** [Role] | **Frequency:** [How often] | **Estimated time:** [Duration]
|
||||
|
||||
---
|
||||
|
||||
### Purpose
|
||||
[1-2 sentences. Why does this process exist? What breaks if it is not done?]
|
||||
|
||||
### Scope
|
||||
**In scope:** [What this covers]
|
||||
**Out of scope:** [What it does not cover]
|
||||
|
||||
### Prerequisites
|
||||
- [ ] [Required access or information]
|
||||
- [ ] [Any dependency that must be completed first]
|
||||
|
||||
---
|
||||
|
||||
### Roles and Responsibilities
|
||||
|
||||
| Role | Responsibility |
|
||||
|---|---|
|
||||
| [Role 1] | [What they do] |
|
||||
|
||||
---
|
||||
|
||||
### Process Steps
|
||||
|
||||
**Step 1: [Step name]**
|
||||
- **Who:** [Role]
|
||||
- **When:** [Trigger or timing]
|
||||
- **How:** [Substeps numbered]
|
||||
- **Output:** [What exists at end of this step]
|
||||
- **Tool:** [System used]
|
||||
|
||||
[Continue for all steps]
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases and Exceptions
|
||||
|
||||
| Situation | What to do | Who to contact |
|
||||
|---|---|---|
|
||||
| [Edge case] | [Action] | [Name/role] |
|
||||
|
||||
---
|
||||
|
||||
### Common Mistakes
|
||||
[2-4 things people get wrong the first time]
|
||||
|
||||
### Escalation Path
|
||||
[Name/role] → [Next level] → [Final escalation]
|
||||
|
||||
### Review
|
||||
Next review due: [Date]
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Document this process: [description]"
|
||||
- "Write a process guide for [workflow]"
|
||||
- "Map out how [process] works"
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
name: project-status-report
|
||||
description: "Write a structured project status report for any project. Use when asked to write a project update, status report, RAG report, project dashboard narrative, or weekly project communication. Produces a clear status report with RAG ratings, milestone progress, risks, and decisions needed."
|
||||
---
|
||||
|
||||
# Project Status Report Skill
|
||||
|
||||
Produces a clear, structured project status report — the weekly communication that keeps stakeholders informed without requiring a meeting.
|
||||
|
||||
## Required Inputs
|
||||
- **Project name**
|
||||
- **Reporting period**
|
||||
- **Current RAG status** (Red / Amber / Green)
|
||||
- **Key milestones** (due, delivered, coming)
|
||||
- **Issues or blockers**
|
||||
- **Decisions needed from stakeholders**
|
||||
- **Budget status** (if tracked)
|
||||
- **Audience** (steering committee / sponsor / PMO / full team)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Project Status Report: [Project Name]
|
||||
**Period:** [Date range] | **Author:** [PM] | **Next report:** [Date]
|
||||
|
||||
---
|
||||
|
||||
### Overall Status
|
||||
|
||||
| Dimension | Status | Last period | Trend |
|
||||
|---|---|---|---|
|
||||
| Overall | Red / Amber / Green | [Last] | Improving / Stable / Declining |
|
||||
| Schedule | | | |
|
||||
| Budget | | | |
|
||||
| Scope | | | |
|
||||
| Risks | | | |
|
||||
|
||||
RAG definitions:
|
||||
- Green: On track. No significant issues.
|
||||
- Amber: At risk. Issues identified but mitigations in place.
|
||||
- Red: Off track. Escalation or decisions required to recover.
|
||||
|
||||
---
|
||||
|
||||
### Executive Summary
|
||||
[3-5 sentences. Headline story. If it is Red, say so immediately and why. Never bury bad news after good news.]
|
||||
|
||||
---
|
||||
|
||||
### Milestone Progress
|
||||
|
||||
| Milestone | Due date | Status | Comment |
|
||||
|---|---|---|---|
|
||||
| [Milestone] | [Date] | Complete / At risk / Delayed / On track | [One line] |
|
||||
|
||||
**Completed this period:** [What was delivered]
|
||||
**Due next period:** [What is expected]
|
||||
|
||||
---
|
||||
|
||||
### Issues and Blockers
|
||||
|
||||
**[Issue title] — Critical / High / Low**
|
||||
- **Description:** [What the issue is]
|
||||
- **Impact:** [What happens if unresolved]
|
||||
- **Owner:** [Who is resolving]
|
||||
- **Action:** [What is being done]
|
||||
- **Resolution date:** [When it will be closed]
|
||||
|
||||
---
|
||||
|
||||
### Risks
|
||||
|
||||
| Risk | Likelihood | Impact | Mitigation | Owner |
|
||||
|---|---|---|---|---|
|
||||
| [Risk] | H/M/L | H/M/L | [Action] | [Name] |
|
||||
|
||||
---
|
||||
|
||||
### Decisions Required
|
||||
|
||||
| Decision | Background | Options | Recommendation | Needed by |
|
||||
|---|---|---|---|---|
|
||||
| [Decision] | [Context] | [Options] | [Recommendation] | [Date] |
|
||||
|
||||
---
|
||||
|
||||
### Budget Summary
|
||||
|
||||
| | Budget | Actual to date | Forecast | Variance |
|
||||
|---|---|---|---|---|
|
||||
| Total | £ | £ | £ | £ F/A |
|
||||
|
||||
---
|
||||
|
||||
### Next Period Plan
|
||||
[3-5 specific bullet points — what will happen next period]
|
||||
|
||||
## Writing Rules
|
||||
- Never soften a Red status
|
||||
- Milestones are binary: complete or not complete
|
||||
- Decisions must be genuinely actionable
|
||||
- Keep to one page where possible
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a project status report for [project]"
|
||||
- "Generate a RAG status update for [project]"
|
||||
- "Write the steering committee report for [project]"
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
name: sop-writer
|
||||
description: "Write a Standard Operating Procedure (SOP) for any operational task. Use when asked to write an SOP, standard operating procedure, work instruction, or operating manual. Produces a formal SOP with purpose, scope, procedure steps, quality checks, and version control."
|
||||
---
|
||||
|
||||
# SOP Writer Skill
|
||||
|
||||
Produces formal, audit-ready SOPs suitable for regulated industries, ISO certification, or operational scaling.
|
||||
|
||||
## Required Inputs
|
||||
- **SOP title** (e.g. "SOP-001: New Client Onboarding")
|
||||
- **Department / function**
|
||||
- **Process description**
|
||||
- **Regulatory or quality standard** (ISO 9001, GMP, CQC, FCA, etc.)
|
||||
- **Roles involved**
|
||||
- **Tools or equipment used**
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
**[COMPANY NAME] — Standard Operating Procedure**
|
||||
|
||||
| Document ID | [SOP-XXX] |
|
||||
|---|---|
|
||||
| Title | [Title] |
|
||||
| Department | [Department] |
|
||||
| Version | 1.0 |
|
||||
| Effective date | [Date] |
|
||||
| Review date | [Date] |
|
||||
| Status | Draft / Under review / Approved |
|
||||
|
||||
---
|
||||
|
||||
### 1. Purpose
|
||||
[1-2 sentences. Why does this SOP exist?]
|
||||
|
||||
### 2. Scope
|
||||
**Applies to:** [Roles, departments, locations]
|
||||
**Does not apply to:** [Explicit exclusions]
|
||||
|
||||
### 3. Definitions
|
||||
| Term | Definition |
|
||||
|---|---|
|
||||
| [Term] | [Plain English definition] |
|
||||
|
||||
### 4. Responsibilities
|
||||
| Role | Responsibility |
|
||||
|---|---|
|
||||
| [Role] | [Specific responsibility] |
|
||||
|
||||
### 5. Required Materials / Tools / Access
|
||||
- [Item]
|
||||
|
||||
### 6. Procedure
|
||||
|
||||
| Step | Action | Responsible | Record/Output |
|
||||
|---|---|---|---|
|
||||
| 6.1.1 | [Imperative action: "Open [system] and navigate to [location]"] | [Role] | [What to record] |
|
||||
|
||||
NOTE: Steps must be written in imperative form. Each step must have one action only.
|
||||
|
||||
### 7. Quality Checks
|
||||
|
||||
| Check point | What to verify | Pass criteria | If fail |
|
||||
|---|---|---|---|
|
||||
| [After step X] | [What to check] | [What good looks like] | [What to do] |
|
||||
|
||||
### 8. Non-Conformance
|
||||
1. [Immediate action]
|
||||
2. [Who to notify]
|
||||
3. [How to document deviation]
|
||||
|
||||
### 9. References
|
||||
[Related SOPs, policies, standards]
|
||||
|
||||
### 10. Document History
|
||||
|
||||
| Version | Date | Author | Changes |
|
||||
|---|---|---|---|
|
||||
| 1.0 | [Date] | [Name] | Initial release |
|
||||
|
||||
## Quality Checks
|
||||
- All steps in imperative form
|
||||
- Each step has exactly one action
|
||||
- Roles specified for every step
|
||||
- Quality checkpoints at critical stages
|
||||
- Non-conformance process defined
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write an SOP for [process]"
|
||||
- "Create a standard operating procedure for [task]"
|
||||
- "Write a work instruction for [process]"
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
name: vendor-evaluation
|
||||
description: "Create a structured vendor evaluation framework for any procurement decision. Use when asked to evaluate vendors, compare suppliers, run an RFP scoring process, or assess a software or service provider. Produces a weighted scorecard, evaluation criteria, and recommendation framework."
|
||||
---
|
||||
|
||||
# Vendor Evaluation Skill
|
||||
|
||||
Produces a structured vendor evaluation framework — from defining criteria through to a scored comparison and recommendation.
|
||||
|
||||
## Required Inputs
|
||||
- **What you are procuring**
|
||||
- **Vendors being evaluated** (minimum 2)
|
||||
- **Key decision criteria** (if known)
|
||||
- **Decision makers**
|
||||
- **Budget range**
|
||||
- **Timeline to decide**
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Evaluation Criteria and Weights
|
||||
|
||||
| Category | Weight | Rationale |
|
||||
|---|---|---|
|
||||
| Functional fit | [%] | Does it do what we need? |
|
||||
| Commercial terms | [%] | Price, flexibility, payment |
|
||||
| Implementation | [%] | How hard to get started? |
|
||||
| Support and SLA | [%] | What happens when things go wrong? |
|
||||
| Security and compliance | [%] | Meets regulatory requirements? |
|
||||
| Vendor stability | [%] | Will this company exist in 3 years? |
|
||||
| References | [%] | Who else uses this? |
|
||||
|
||||
Weights must total 100%.
|
||||
|
||||
### 2. Scoring Rubric
|
||||
- 5: Exceeds requirements — clear best-in-class
|
||||
- 4: Meets requirements — fully satisfies with minor gaps
|
||||
- 3: Partially meets — notable gaps requiring workarounds
|
||||
- 2: Significant gaps — would require workarounds
|
||||
- 1: Does not meet — cannot satisfy requirement
|
||||
|
||||
### 3. Vendor Scorecard
|
||||
|
||||
| Criterion | Weight | [Vendor A] | Weighted | [Vendor B] | Weighted | [Vendor C] | Weighted |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| Functional fit | [%] | /5 | | /5 | | /5 | |
|
||||
| [Continue...] | | | | | | | |
|
||||
| **Total** | 100% | | **/5** | | **/5** | | **/5** |
|
||||
|
||||
### 4. Key Questions for Every Vendor
|
||||
Functional: Walk through [most critical use case]. What can your product not do that customers ask for?
|
||||
Commercial: What is included vs add-ons? Contract minimum term and notice period? Price protection at renewal?
|
||||
Implementation: Typical implementation for our size? What do you need from our team?
|
||||
Support: SLA for critical issues? Support included vs charged extra?
|
||||
Security: ISO 27001 / SOC 2 certified? Where is data stored? Breach notification process?
|
||||
|
||||
### 5. Reference Check Questions
|
||||
- How long using [vendor]? Implementation surprises? Support responsiveness? One thing you wish you had known? Would you choose them again?
|
||||
|
||||
### 6. Recommendation
|
||||
|
||||
**Recommended vendor:** [Name] | **Score:** [X/5]
|
||||
**Rationale:** [Specific strengths that matter for this decision]
|
||||
**Key risks:** [Risk and mitigation]
|
||||
**Conditions:** [Contract terms to negotiate before signing]
|
||||
**Runner-up:** [Vendor and why they lost]
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Help me evaluate vendors for [procurement]"
|
||||
- "Create a vendor scorecard for [software/service]"
|
||||
- "Compare [Vendor A] vs [Vendor B] for [use case]"
|
||||
Reference in New Issue
Block a user