Windsurf + Aider targets, MCP server, and demo placement (#33)
Broadens both reach (more tools) and content types (an MCP server), continuing the multi-platform story. Windsurf + Aider: - build-exports.mjs gains two platforms: exports/windsurf/*.md (workspace rules, trigger: model_decision) and exports/aider/*.md (conventions for `aider --read`). Now 5 platforms (ChatGPT, Gemini, Cursor, Windsurf, Aider). - install.sh + bin/cli.mjs install both (windsurf -> .windsurf/rules, aider -> .aider/skills with a --read hint); generated README index is excluded from copies. - One-line windsurf-install.sh / aider-install.sh wrappers for parity. MCP server (new content type): - mcp/server.mjs — zero-dependency stdio MCP server exposing list_skills, search_skills, get_skill. Published as a second bin (pm-claude-skills-mcp). Logs to stderr; reads bundled skills/ at startup. mcp/README.md documents client config. Also: README hero "See it in action" demo placement (ready to swap in a GIF; recording guide in web/docs-assets/README.md), Works-With table + exports + install docs updated, CHANGELOG Unreleased. package.json files/bin updated. Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
mohitagw15856
GitHub
@@ -0,0 +1,189 @@
|
||||
# Email Triage
|
||||
|
||||
## The Problem
|
||||
|
||||
Most of us spend real time triaging email that could be sorted automatically. Scrolling through a mixed inbox of newsletters, order confirmations, Jira notifications, and actual human asks is a tax on focus. The 40 emails since lunch contain maybe 4 that actually need you — this skill finds those 4.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
| Requirement | Details |
|
||||
|-------------|---------|
|
||||
| Gmail connector | Must be active in Claude settings (Settings → Connectors → Gmail) |
|
||||
| Gmail account | The account you want triaged |
|
||||
|
||||
If the Gmail connector is not connected, Claude will prompt you to connect it before proceeding.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
| Input | Required | Default | Notes |
|
||||
|-------|----------|---------|-------|
|
||||
| Time window | No | Last 8 hours | Accepts: "last 8 hours", "last 24h", "today", "since Monday", "last 3 days" |
|
||||
| Always-include senders | No | None | Specific names or email addresses that always surface, regardless of content |
|
||||
| Always-ignore senders | No | None | Domains or addresses to always suppress (e.g. noreply@*, jira@company.com) |
|
||||
| Focus area | No | None | Optional context: "focus on anything from clients" or "flag anything about the launch" |
|
||||
|
||||
## What Gets Filtered Out
|
||||
|
||||
Claude suppresses the following categories. They are counted in the summary but not shown:
|
||||
|
||||
- Order confirmations and shipping notifications
|
||||
- Marketing and promotional emails (including "one-time" offer emails)
|
||||
- Newsletter subscriptions and digest emails
|
||||
- Automated system notifications (monitoring alerts, CI/CD, build reports)
|
||||
- Calendar invites that have already been accepted or declined
|
||||
- Read receipts and delivery confirmations
|
||||
- Social media notifications (LinkedIn, Twitter/X, etc.)
|
||||
- Internal ticket updates unless the ticket is assigned to you and requires action
|
||||
- Bank and financial statements (surfaced count only, not content)
|
||||
|
||||
## What Gets Surfaced
|
||||
|
||||
Claude surfaces only emails that meet one or more of these criteria:
|
||||
|
||||
- A human is waiting for a reply
|
||||
- A decision is being requested
|
||||
- There is a deadline or time-sensitive ask, explicit or implied
|
||||
- The sender is someone who does not usually email you (potential priority signal)
|
||||
- The email is from a sender in your always-include list
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
## Inbox Triage — [Time window] | [Date], [Time]
|
||||
**Total emails scanned:** X | **Actionable:** Y | **Filtered out:** Z
|
||||
|
||||
---
|
||||
|
||||
### 🔴 High Priority — Needs reply or decision today
|
||||
|
||||
**From:** [Name] <email@domain.com>
|
||||
**Subject:** [Subject line]
|
||||
**Received:** [Time, e.g. 2:14 PM]
|
||||
**What they need:** [One sentence — the actual ask, not a summary of the email]
|
||||
**Reply starter:** "[A draft opener they can continue — 1 sentence max]"
|
||||
|
||||
---
|
||||
|
||||
**From:** [Name] <email@domain.com>
|
||||
**Subject:** [Subject line]
|
||||
**Received:** [Time]
|
||||
**What they need:** [One sentence]
|
||||
**Reply starter:** "[Draft opener]"
|
||||
|
||||
---
|
||||
|
||||
### 🟡 Medium Priority — Reply within 24–48h
|
||||
|
||||
**From:** [Name] <email@domain.com>
|
||||
**Subject:** [Subject line]
|
||||
**Received:** [Time]
|
||||
**What they need:** [One sentence]
|
||||
**Reply starter:** "[Draft opener]" *(or "No reply needed — action only: [what to do]")*
|
||||
|
||||
---
|
||||
|
||||
### 🟢 FYI — Worth knowing, no action required
|
||||
|
||||
- **[Name]** re: [Subject] — [One-line summary of why it might be relevant]
|
||||
- **[Name]** re: [Subject] — [One-line summary]
|
||||
|
||||
---
|
||||
|
||||
### ⚪ Filtered Out — [Z emails]
|
||||
Receipts: X | Newsletters: X | Notifications: X | Other automated: X
|
||||
*(No action needed — not shown in detail)*
|
||||
```
|
||||
|
||||
## Instructions for Claude
|
||||
|
||||
### Step 1 — Connect and confirm the time window
|
||||
|
||||
Confirm the Gmail connector is active. Parse the requested time window and translate it to an exact datetime range (e.g. "last 8 hours" = [current time minus 8 hours] to now). State the window at the top of the output.
|
||||
|
||||
### Step 2 — Read the inbox
|
||||
|
||||
Fetch emails from the inbox for the specified time window. Include: sender name, sender email, subject, received time, and email body (or first 500 words if long). Do not fetch emails older than the window.
|
||||
|
||||
### Step 3 — Apply ignore rules
|
||||
|
||||
If the user specified always-ignore senders or domains, suppress those immediately. If no ignore list was given, apply standard suppression (see What Gets Filtered Out). Track counts for the filtered summary.
|
||||
|
||||
### Step 4 — Classify each remaining email
|
||||
|
||||
For each non-suppressed email, classify into one of four categories:
|
||||
|
||||
- **High Priority**: A human is waiting on a reply today, or there is an explicit deadline within 24 hours
|
||||
- **Medium Priority**: A reply is needed but not urgently, or there is an implicit ask without a hard deadline
|
||||
- **FYI**: No action needed, but the user would likely want to know about it
|
||||
- **Filtered Out**: Falls into a suppressed category — add to count, do not show
|
||||
|
||||
Apply the always-include list after classification: any email from a flagged sender surfaces regardless of category, with its actual classification.
|
||||
|
||||
### Step 5 — Write the "What they need" line
|
||||
|
||||
This is the highest-value part of the output. Write exactly one sentence that captures the actual ask — not a summary of the email, the ask.
|
||||
|
||||
Bad: "Sarah sent an email about the Q3 report."
|
||||
Good: "Sarah needs your sign-off on the Q3 report before she sends it to the board at 5 PM."
|
||||
|
||||
If there is no clear ask, it is probably FYI or filtered out.
|
||||
|
||||
### Step 6 — Write the reply starter
|
||||
|
||||
For High and Medium priority emails, write a one-sentence reply opener. The opener should:
|
||||
- Match the tone of the sender (formal vs. casual)
|
||||
- Acknowledge the ask directly
|
||||
- Be something the user can actually send with minimal editing
|
||||
|
||||
Example: "Thanks for flagging this — let me check with the team and get back to you by EOD."
|
||||
|
||||
If the email requires an action rather than a reply (e.g. "please approve this expense"), write: "No reply needed — action only: [describe the action]."
|
||||
|
||||
### Step 7 — Assemble and deliver the output
|
||||
|
||||
Use the output format exactly as specified. Do not add extra sections, editorialise, or explain your reasoning. The output should be scannable in under 60 seconds.
|
||||
|
||||
### Step 8 — Offer next steps
|
||||
|
||||
After the triage output, offer one of:
|
||||
- "Want me to draft replies to any of these?"
|
||||
- "Say 'reply to [name]' and I'll draft it."
|
||||
|
||||
Keep this to one line. Do not elaborate.
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Time window was applied correctly — no emails outside the window are included
|
||||
- [ ] Gmail connector was confirmed active before reading
|
||||
- [ ] Every High Priority email has a specific, concrete "What they need" sentence — not a vague summary
|
||||
- [ ] Reply starters match the tone of the original email (formal/informal)
|
||||
- [ ] Filtered-out count is accurate and broken down by category
|
||||
- [ ] FYI section contains only emails with no action required — nothing actionable is buried here
|
||||
- [ ] Always-include senders surfaced regardless of category
|
||||
- [ ] Always-ignore senders/domains are fully suppressed
|
||||
- [ ] Output is scannable — no unnecessary prose, no padding
|
||||
- [ ] Financial statements and sensitive content were counted but not shown in full
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not surface FYI emails in the High or Medium priority sections — burying actionable items with informational ones defeats the purpose of triage
|
||||
- [ ] Do not write vague "What they need" summaries ("Sarah sent an email about the report") — every summary must state the actual ask, not a description of the email
|
||||
- [ ] Do not apply the same tone to every reply starter — a formal email from a client requires a different opener than a casual Slack-style email from a colleague
|
||||
- [ ] Do not include emails outside the requested time window — time window accuracy is the core trust signal for this skill
|
||||
- [ ] Do not omit the filtered-out count — users need to know how much was scanned, not just what was surfaced, to trust the triage is complete
|
||||
|
||||
## Dispatch / Mobile Usage
|
||||
|
||||
This skill works from the Claude mobile app (Dispatch). On mobile, the output renders cleanly with the emoji priority markers serving as visual anchors for quick scanning. Recommended mobile trigger: "Check my emails" or "/email-triage".
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- `/email-triage`
|
||||
- "Check my emails"
|
||||
- "What emails need my attention?"
|
||||
- "Triage my inbox for the last 8 hours"
|
||||
- "What came in since this morning?"
|
||||
- "Any urgent emails I need to deal with?"
|
||||
- "Triage my inbox — ignore anything from Jira and the marketing domain"
|
||||
- "Check emails from the last 24 hours, flag anything from [client name]"
|
||||
- "What do I need to reply to today?"
|
||||
@@ -0,0 +1,201 @@
|
||||
# Morning Intelligence Skill
|
||||
|
||||
Write the prompt that writes your briefing. A 15-question interview extracts your exact context — role, topics, sources, exclusions, format, recency — then produces a single master prompt you can paste into a scheduled task or Claude Code Routine and never touch again.
|
||||
|
||||
> **Pro tip:** Run this interview with Opus for the best output. Opus asks sharper follow-up questions and writes a tighter master prompt.
|
||||
|
||||
> **Credit:** Originally created by Ashwin Francis (Cash&Cache) — adapted and extended for this library.
|
||||
|
||||
---
|
||||
|
||||
## Required Inputs
|
||||
|
||||
No inputs required upfront. The skill runs the interview first.
|
||||
|
||||
If the user has already provided context (e.g. pasted a role description or topic list), absorb it and skip those questions in the interview — don't ask for information already given.
|
||||
|
||||
---
|
||||
|
||||
## How the Interview Works
|
||||
|
||||
Run questions **one at a time** (or in small groups of 2–3 where they're closely related). Don't dump all 15 at once. Wait for each answer before proceeding. Ask natural follow-ups where the answer is vague.
|
||||
|
||||
### Interview Questions
|
||||
|
||||
**Block 1 — Who you are and how you read**
|
||||
|
||||
1. What is your role, and what lens do you read news through? (e.g. "Head of Product at a B2B SaaS — I read for competitive moves, AI tooling, and enterprise buying signals.")
|
||||
2. What are the 3–5 topics you always want covered? Be specific — "AI" is too broad; "AI applied to enterprise software" is better.
|
||||
3. What are 2–3 topics you actively want filtered out — things that waste your time every morning?
|
||||
|
||||
**Block 2 — Sources and signals**
|
||||
|
||||
4. Which publications, newsletters, or outlets do you trust most? (Examples: The Information, TLDR, Benedict Evans, Stratechery, FT, specific subreddits)
|
||||
5. Are there any Twitter/X accounts, Substack writers, or niche sources that are must-reads for you specifically?
|
||||
6. Is there any geography that matters — are you focused on a specific country, region, or market?
|
||||
|
||||
**Block 3 — Story type and recency**
|
||||
|
||||
7. What mix of story types do you want? Rank or weight these: breaking news / in-depth analysis / opinion / data & research / product launches & announcements.
|
||||
8. How fresh does the content need to be? Only today's news? Last 24 hours? Last 48 hours? Or are you okay with "last few days" if a story is important enough?
|
||||
|
||||
**Block 4 — Format and time**
|
||||
|
||||
9. How do you want the brief formatted? Options: bullet list by topic / short narrative paragraphs / a digest with headlines + 1-line summaries / a table / mixed.
|
||||
10. What's your reading time budget in the morning? 5 minutes (tight digest) / 10 minutes (fuller brief) / 15 minutes (comprehensive).
|
||||
|
||||
**Block 5 — This week specifically**
|
||||
|
||||
11. Is there anything you're tracking this week in particular — a specific company, deal, product launch, regulatory development, or ongoing story?
|
||||
|
||||
**Block 6 — Follow-up clarification (questions 12–15)**
|
||||
|
||||
Based on the answers above, ask 4 targeted follow-up questions to sharpen ambiguities. Examples of what to probe:
|
||||
|
||||
- If a topic is still broad: "You said [topic] — do you want the technical angle, the business/market angle, or both?"
|
||||
- If sources are vague: "When you say [publication], do you want everything from them or only specific sections/writers?"
|
||||
- If format is unclear: "You want bullets — should each topic have its own section with 3–5 bullets, or one flat list of all stories?"
|
||||
- If recency conflicts with format: "You want only today's news but a comprehensive 15-minute brief — on slow news days, should I go deeper on one story or pull from the last 48 hours to fill it out?"
|
||||
- If exclusions are vague: "You said no [topic] — does that include adjacent topics like [related thing], or strictly [topic]?"
|
||||
|
||||
Use your judgement on which 4 are most worth asking given the actual answers.
|
||||
|
||||
---
|
||||
|
||||
## Output Structure
|
||||
|
||||
After the interview is complete, produce three things in order:
|
||||
|
||||
### 1. Summary of What You Told Me
|
||||
|
||||
A brief summary of the interview, clustered into thematic pillars. This lets the user verify the master prompt will be accurate before it's written.
|
||||
|
||||
```
|
||||
WHAT I HEARD
|
||||
────────────
|
||||
Role lens: [1 sentence]
|
||||
Core topics: [Pillar 1] · [Pillar 2] · [Pillar 3]
|
||||
Exclusions: [Topic A], [Topic B]
|
||||
Sources: [List]
|
||||
Story mix: [e.g. 60% analysis, 30% news, 10% data]
|
||||
Recency: [e.g. Last 24 hours, today only for breaking]
|
||||
Format: [e.g. Bullets by topic, ~10 min read]
|
||||
This week: [Specific tracking items]
|
||||
```
|
||||
|
||||
Confirm: "Does this look right? I'll write the master prompt based on this."
|
||||
|
||||
---
|
||||
|
||||
### 2. The Master Prompt
|
||||
|
||||
Formatted and ready to paste. Start with a markdown code block so the user can copy it cleanly.
|
||||
|
||||
````
|
||||
```
|
||||
MORNING INTELLIGENCE BRIEF — MASTER PROMPT
|
||||
==========================================
|
||||
|
||||
You are an intelligence analyst briefing [ROLE] at the start of their day.
|
||||
|
||||
TASK
|
||||
Generate a personalised morning news brief covering the following.
|
||||
|
||||
TOPICS TO COVER
|
||||
1. [Topic / Pillar 1] — focus on [angle]
|
||||
2. [Topic / Pillar 2] — focus on [angle]
|
||||
3. [Topic / Pillar 3] — focus on [angle]
|
||||
[add pillars as needed]
|
||||
|
||||
NEVER INCLUDE
|
||||
- [Excluded topic 1]
|
||||
- [Excluded topic 2]
|
||||
- [Excluded topic 3]
|
||||
|
||||
PREFERRED SOURCES (prioritise these)
|
||||
[Source 1], [Source 2], [Source 3], [Source 4]
|
||||
|
||||
STORY TYPE MIX
|
||||
[e.g. Prioritise analysis and data-driven pieces. Include breaking news only if significant. Skip opinion unless it's from [specific writer].]
|
||||
|
||||
RECENCY
|
||||
[e.g. Cover only the last 24 hours. For ongoing stories I'm tracking, include relevant developments from the last 48 hours.]
|
||||
|
||||
CURRENTLY TRACKING THIS WEEK
|
||||
[Specific story / company / topic the user flagged]
|
||||
|
||||
FORMAT
|
||||
[e.g. Organise by topic. Under each topic: 2–4 bullet points. Each bullet: headline + 1–2 sentence summary + source name. End with a "What to watch today" section: 2–3 sentences on what matters most today.]
|
||||
|
||||
LENGTH
|
||||
Target a [5/10/15]-minute read.
|
||||
|
||||
TONE
|
||||
Analyst voice. No fluff. Lead with the signal, not the noise. If something is uncertain or based on incomplete reporting, flag it as such.
|
||||
```
|
||||
````
|
||||
|
||||
---
|
||||
|
||||
### 3. Setup Guide
|
||||
|
||||
A short section below the master prompt:
|
||||
|
||||
```
|
||||
HOW TO USE THIS PROMPT
|
||||
──────────────────────
|
||||
|
||||
OPTION A — Cowork Scheduled Tasks (Claude Pro/Max)
|
||||
Requires: Desktop app open at scheduled time
|
||||
1. Open Claude desktop → Cowork → Scheduled Tasks
|
||||
2. Create a new task, set your time (e.g. 7:00 AM)
|
||||
3. Paste the master prompt as the task content
|
||||
4. Save. It will run every morning when your desktop app is open.
|
||||
|
||||
OPTION B — Claude Code Routines (runs in the cloud)
|
||||
Requires: Claude Code with Routines access
|
||||
Advantage: Runs without your laptop being on
|
||||
1. In your project root, create or open .claude/routines.json
|
||||
2. Add a new routine with a cron schedule (e.g. "0 7 * * *" for 7 AM daily)
|
||||
3. Set the prompt field to the master prompt above
|
||||
4. Commit and push — Claude Code will run it on schedule.
|
||||
|
||||
UPDATING YOUR BRIEF
|
||||
When your focus shifts, re-run this skill. The interview takes 5–10 minutes
|
||||
and produces a new master prompt to replace the old one.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every interview question was asked — none skipped unless the user already provided the answer
|
||||
- [ ] The "What I Heard" summary was shown and confirmed before writing the master prompt
|
||||
- [ ] The master prompt uses specific topic angles, not vague category names (not "AI" — "AI applied to enterprise software")
|
||||
- [ ] Exclusions are explicitly stated in the master prompt with a NEVER INCLUDE section
|
||||
- [ ] Sources are listed in order of preference, not as a flat unordered list
|
||||
- [ ] Story type mix is written as a directive, not just a list
|
||||
- [ ] Recency instruction handles the edge case of slow news days
|
||||
- [ ] Format instruction is precise enough that a different AI could follow it correctly
|
||||
- [ ] The master prompt is inside a code block so it copies cleanly
|
||||
- [ ] Both setup options (Cowork and Claude Code Routines) are included
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not skip the interview and write a generic master prompt — a brief that is not tailored to the user's specific role and topics will be ignored after the first day
|
||||
- [ ] Do not proceed to write the master prompt without confirming the "What I Heard" summary — errors in the summary will silently propagate into a prompt that produces the wrong briefing every morning
|
||||
- [ ] Do not use broad topic labels in the master prompt (e.g. "AI", "tech news") — every topic must have a specific angle or focus to produce signal-to-noise ratio worth reading
|
||||
- [ ] Do not omit the NEVER INCLUDE section — without explicit exclusions, the briefing will fill with noise that the user said they wanted filtered out
|
||||
- [ ] Do not ask all 15 questions at once — the interview must run one question or small group at a time to produce specific, considered answers
|
||||
|
||||
---
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Set up my morning intelligence brief"
|
||||
- "Build me a morning news prompt"
|
||||
- "Interview me for a morning briefing skill"
|
||||
- "I want to start every day with a personalised news digest"
|
||||
- "Help me set up a daily AI news brief"
|
||||
- "Create a scheduled morning news prompt for me"
|
||||
- "Build me a prompt for my daily briefing routine"
|
||||
@@ -0,0 +1,92 @@
|
||||
# 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]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every step has a named role (not "someone" or "the team")
|
||||
- [ ] Edge cases and exceptions table is complete
|
||||
- [ ] Prerequisites are listed so someone new can prepare before starting
|
||||
- [ ] Escalation path is named (specific people or roles, not just "your manager")
|
||||
- [ ] Review date is set
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write steps without specifying who is responsible for each — ownership must be explicit throughout
|
||||
- [ ] Do not omit the escalation path — every process must say what happens when something goes wrong
|
||||
- [ ] Do not document the ideal process if the real process differs — document reality, then note improvements separately
|
||||
- [ ] Do not skip edge cases and exceptions — they are where most process failures actually occur
|
||||
- [ ] Do not produce documentation without a review date — undated process docs quickly become incorrect
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Document this process: [description]"
|
||||
- "Write a process guide for [workflow]"
|
||||
- "Map out how [process] works"
|
||||
@@ -0,0 +1,120 @@
|
||||
# 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
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Red status is stated immediately (not buried after positives)
|
||||
- [ ] Every issue has a named owner and a resolution date
|
||||
- [ ] Decisions required are genuinely actionable by the audience
|
||||
- [ ] Milestones are binary (complete or not complete — no "85% done")
|
||||
- [ ] Executive summary can stand alone for a stakeholder who reads nothing else
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not rate project health as Green while listing unresolved critical blockers
|
||||
- [ ] Do not report milestone progress as a percentage — milestones are binary: complete or not complete
|
||||
- [ ] Do not bury risks at the bottom — if something is high risk, it belongs in the executive summary
|
||||
- [ ] Do not leave decisions required without specifying who must decide and by when
|
||||
- [ ] Do not write an executive summary that requires reading the full report to understand — it must stand alone
|
||||
|
||||
## 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,163 @@
|
||||
# RACI Matrix Skill
|
||||
|
||||
This skill produces a complete RACI (Responsible, Accountable, Consulted, Informed) matrix for a project, product launch, or ongoing process. Output is ready to share with teams to clarify ownership, reduce decision bottlenecks, and eliminate duplication of effort.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Project or process name**
|
||||
- **Key activities or decisions** to map (or the user can describe the project and the skill will derive them)
|
||||
- **Teams or roles involved** (list team names and key individuals if helpful)
|
||||
- **Primary purpose** — clarifying launch ownership / onboarding a new team / reducing bottlenecks / governance documentation
|
||||
- **RACI variant** — standard RACI, or RASCI (adds Supportive), or DACI (Driver, Approver, Contributors, Informed)?
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# RACI Matrix: [Project / Process Name]
|
||||
|
||||
**Version:** [1.0]
|
||||
**Owner:** [Programme lead / PM]
|
||||
**Date:** [Date]
|
||||
**Teams involved:** [List teams]
|
||||
|
||||
---
|
||||
|
||||
## 1. Role Definitions
|
||||
|
||||
Before reading the matrix, agree on what each letter means for this project:
|
||||
|
||||
| Letter | Role | Definition | Rules |
|
||||
|---|---|---|---|
|
||||
| **R** | Responsible | Does the work. One or more people actually execute the task. | Multiple Rs are allowed — but if there are many, consider splitting the task |
|
||||
| **A** | Accountable | Owns the outcome. Signs off on decisions. Answers if something goes wrong. | **There must be exactly one A per row.** Never two. Never zero. |
|
||||
| **C** | Consulted | Provides expertise or input before work is done. Two-way communication. | Consulted parties must be engaged — not just available. Cap at 3 per row or it becomes noise |
|
||||
| **I** | Informed | Notified of progress or outcomes. One-way communication. | Informed only — they don't review or approve |
|
||||
|
||||
**Golden rules:**
|
||||
- Every row has exactly one **A**
|
||||
- The same person or team should not be **A** for more than [X] rows — spreads accountability too thin
|
||||
- **C** is expensive — consulting someone means they must respond. Use it intentionally
|
||||
- If someone is **R** they cannot also be **A** for the same task unless they are the decision-maker (common in small teams)
|
||||
|
||||
---
|
||||
|
||||
## 2. RACI Matrix
|
||||
|
||||
Columns = teams or roles. Rows = activities or decisions.
|
||||
|
||||
| Activity / Decision | [Role 1] | [Role 2] | [Role 3] | [Role 4] | [Role 5] | Notes |
|
||||
|---|---|---|---|---|---|---|
|
||||
| **[Phase 1: Discovery]** | | | | | | |
|
||||
| Define project scope and objectives | A/R | C | I | I | — | PM leads; engineering consulted on technical feasibility |
|
||||
| Conduct user research | R | A | C | I | — | UX researcher executes; PM accountable |
|
||||
| Approve discovery findings | C | A | I | R | — | |
|
||||
| **[Phase 2: Design]** | | | | | | |
|
||||
| Define solution approach | A | R | C | I | I | |
|
||||
| Design system / UI designs | C | A/R | I | I | — | |
|
||||
| Design review and sign-off | C | R | A | I | — | |
|
||||
| Accessibility review | I | R | A | C | — | |
|
||||
| **[Phase 3: Build]** | | | | | | |
|
||||
| Technical architecture decision | C | C | A/R | I | — | |
|
||||
| Sprint planning | A | C | R | I | I | |
|
||||
| Code review and merge | I | C | R | A | — | |
|
||||
| Security review | I | C | C | A/R | — | |
|
||||
| **[Phase 4: Launch]** | | | | | | |
|
||||
| Launch go / no-go decision | A | C | C | R | I | PM holds final authority |
|
||||
| Release to production | C | I | A/R | I | — | |
|
||||
| Customer communications | A/R | I | I | I | C | |
|
||||
| Post-launch monitoring | C | I | R | A | — | |
|
||||
| **[Ongoing / BAU]** | | | | | | |
|
||||
| Incident response | I | C | R | A | — | |
|
||||
| Feature prioritisation | A/R | C | C | I | I | |
|
||||
| Stakeholder reporting | A/R | I | I | I | C | |
|
||||
|
||||
---
|
||||
|
||||
## 3. Decision Map
|
||||
|
||||
For high-stakes decisions, document the decision type, who holds authority, and how disagreements are resolved:
|
||||
|
||||
| Decision | Authority (A) | Must consult (C) | Escalation path if disagreed |
|
||||
|---|---|---|---|
|
||||
| Scope change >20% effort | [Exec sponsor / Programme lead] | [PM, Engineering lead] | [Steering committee] |
|
||||
| Budget overrun >10% | [Finance / Exec] | [PM, Programme lead] | [CFO / Board] |
|
||||
| Architecture pattern change | [Engineering lead] | [Tech lead, Security] | [CTO] |
|
||||
| Go-live date change | [PM] | [Engineering, Comms, CS] | [Programme sponsor] |
|
||||
| Feature cut from scope | [PM] | [Product, UX, Engineering] | [CPO] |
|
||||
|
||||
---
|
||||
|
||||
## 4. Common RACI Anti-Patterns — and Fixes
|
||||
|
||||
Review the completed matrix against these failure modes:
|
||||
|
||||
| Anti-pattern | Symptom | Fix |
|
||||
|---|---|---|
|
||||
| **Multiple As** | Two teams both think they own an outcome | Agree one A; the other becomes C or I |
|
||||
| **No A** | Decisions stall; no one feels responsible | Assign the most senior stakeholder as A |
|
||||
| **Everyone is C** | Every decision goes to a committee | Audit each C — does this person actually provide input that changes outcomes? If not, move to I |
|
||||
| **R without A** | Work gets done but no one owns quality | Add an A; usually the manager of the R |
|
||||
| **A without R** | Accountability without execution — manager is disconnected | Add an R from the team; or combine A/R if appropriate |
|
||||
| **Too many Rs** | Diffusion of responsibility | Split the task into sub-tasks, each with one clear R |
|
||||
| **Key team missing from matrix** | They're affected but not in the RACI | Add them; assign at minimum I for relevant rows |
|
||||
|
||||
---
|
||||
|
||||
## 5. Communication Template
|
||||
|
||||
Once the RACI is agreed, use this template to communicate it to all involved teams:
|
||||
|
||||
---
|
||||
|
||||
**Subject:** [Project Name] — Roles and Responsibilities Agreed
|
||||
|
||||
We've finalised the RACI matrix for [Project Name]. Here's what it means for you:
|
||||
|
||||
**[Role 1 team]:** You are **Accountable** for [X, Y, Z activities]. This means you make the final call on those decisions and answer if outcomes are not met.
|
||||
|
||||
**[Role 2 team]:** You are **Responsible** for [A, B, C]. You execute the work. For [D], you are **Consulted** — we need your input before decisions are finalised.
|
||||
|
||||
**[Role 3 team]:** You are **Informed** on [E, F] — we'll send you updates at [weekly / milestone / launch]. No action required unless you see something that needs escalation.
|
||||
|
||||
Please review the full matrix here: [Link]. Raise any concerns by [Date] — after that, we'll treat it as agreed.
|
||||
|
||||
---
|
||||
|
||||
## 6. RACI Review Cadence
|
||||
|
||||
| Trigger | Action |
|
||||
|---|---|
|
||||
| New team member joins | Review rows relevant to their role — update R as needed |
|
||||
| Phase change (e.g. discovery → delivery) | Review full matrix — some Rs and As will shift |
|
||||
| Escalation or confusion about ownership | Use the matrix to diagnose — find the missing A |
|
||||
| 3 months into a long programme | Full RACI review — roles drift over time |
|
||||
| Team restructure or reorganisation | Full rebuild — ownership assumptions change |
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every row has exactly one **A**
|
||||
- [ ] No individual or team is **A** for more than their realistic sphere of authority
|
||||
- [ ] **C** columns are sparse — consulting everyone dilutes the process
|
||||
- [ ] Matrix was reviewed and agreed by at least one representative from each role column
|
||||
- [ ] A communication plan exists to share the RACI with all involved parties
|
||||
- [ ] Decision map covers the top 5–10 highest-stakes decisions in the project
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not assign more than one Accountable per task — shared accountability means no accountability
|
||||
- [ ] Do not create a RACI with more than 5–6 roles — it becomes unreadable and unenforceable
|
||||
- [ ] Do not include tasks so broad that the RACI cannot be acted upon — break down to decision-level granularity
|
||||
- [ ] Do not skip the conflict resolution process — RACI matrices without a process for disputes are unused after the first disagreement
|
||||
- [ ] Do not confuse Responsible with Accountable — document the distinction clearly for each role
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Build a RACI matrix for our product launch"
|
||||
- "Create a responsibility matrix for our new cross-functional project"
|
||||
- "Who owns what on this initiative? Help me build a RACI"
|
||||
- "Map out decision rights for our engineering and product teams"
|
||||
- "Generate a RACI for a [migration / launch / process] involving [teams]"
|
||||
@@ -0,0 +1,214 @@
|
||||
# Risk Register Skill
|
||||
|
||||
This skill produces a complete risk register for a project, programme, or product. Output follows standard risk management practice with likelihood × impact scoring, RAG status, a risk heat map, and specific mitigation and contingency plans. Ready to share with a project board, steering committee, or programme office.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Project or product name**
|
||||
- **Project stage** (discovery / delivery / launch / live / programme-level)
|
||||
- **Key objectives** — what is the project trying to achieve?
|
||||
- **Known risks** — anything already on the team's radar (even informal concerns count)
|
||||
- **Key dependencies** — external vendors, teams, systems, or regulatory approvals
|
||||
- **Deadline or milestone sensitivity** — are there hard dates that cannot move?
|
||||
- **Audience** — who will read this? (internal team / executive steering / external board / regulator)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Risk Register: [Project / Product Name]
|
||||
|
||||
**Project stage:** [Discovery / Delivery / Launch / Live / Programme]
|
||||
**Version:** [1.0]
|
||||
**Owner:** [PM / Programme Manager / Risk Lead]
|
||||
**Last reviewed:** [Date]
|
||||
**Next review:** [Date — recommend weekly during delivery, monthly during discovery]
|
||||
**Status:** [Active / Archived]
|
||||
|
||||
---
|
||||
|
||||
## 1. Risk Scoring Framework
|
||||
|
||||
**Likelihood (L)**
|
||||
|
||||
| Score | Label | Definition |
|
||||
|---|---|---|
|
||||
| 5 | Almost certain | >80% probability of occurring |
|
||||
| 4 | Likely | 60–80% probability |
|
||||
| 3 | Possible | 40–60% probability |
|
||||
| 2 | Unlikely | 20–40% probability |
|
||||
| 1 | Rare | <20% probability |
|
||||
|
||||
**Impact (I)**
|
||||
|
||||
| Score | Label | Definition |
|
||||
|---|---|---|
|
||||
| 5 | Critical | Programme failure, regulatory breach, major financial loss, safety event |
|
||||
| 4 | High | Significant schedule delay (>4 weeks), scope reduction, reputational damage |
|
||||
| 3 | Medium | Moderate delay (1–4 weeks), cost overrun, reduced quality |
|
||||
| 2 | Low | Minor delay (<1 week), manageable cost increase |
|
||||
| 1 | Negligible | Minimal impact, easily absorbed |
|
||||
|
||||
**Risk Score = L × I**
|
||||
|
||||
| Score | RAG | Action |
|
||||
|---|---|---|
|
||||
| 20–25 | 🔴 Critical | Immediate escalation; active management required |
|
||||
| 12–19 | 🔴 High | Owner-assigned mitigation; weekly review |
|
||||
| 8–11 | 🟡 Medium | Mitigation planned; fortnightly review |
|
||||
| 4–7 | 🟡 Low | Monitor; monthly review |
|
||||
| 1–3 | 🟢 Negligible | Accept; review if context changes |
|
||||
|
||||
---
|
||||
|
||||
## 2. Risk Register
|
||||
|
||||
| ID | Risk | Category | L | I | Score | RAG | Owner | Status | Mitigation | Contingency | Review date |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| R01 | [Risk description — be specific: "Third-party API may not support required volume, causing X to fail"] | [Schedule / Technical / Resource / Commercial / Compliance / External] | [1–5] | [1–5] | [L×I] | 🔴/🟡/🟢 | [Name] | [Open / Mitigating / Closed] | [What are we doing to reduce likelihood or impact?] | [What do we do if it happens?] | [Date] |
|
||||
| R02 | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] |
|
||||
|
||||
---
|
||||
|
||||
## 3. Risk Categories — Common Risks by Type
|
||||
|
||||
Use these to prompt risk identification. Add, remove, or customise for your project.
|
||||
|
||||
### Schedule & Delivery
|
||||
- Key milestone depends on a dependency that has not confirmed availability
|
||||
- Team capacity reduced by planned or unplanned absence during critical period
|
||||
- Technical complexity is underestimated — story points consistently overrun
|
||||
- External approval (regulator, legal, procurement) takes longer than planned
|
||||
|
||||
### Technical
|
||||
- Integration with a third-party system not yet prototyped or agreed
|
||||
- Existing technical debt makes the change harder or riskier than estimated
|
||||
- Security or compliance review required before launch has not been scoped
|
||||
- Performance under production load untested
|
||||
- Key technical knowledge held by one person (single point of failure)
|
||||
|
||||
### Resource & People
|
||||
- Key SME or engineer leaving or unavailable during critical phase
|
||||
- Budget not confirmed for Phase 2 of the project
|
||||
- Stakeholder sponsor changes role or leaves the organisation
|
||||
- Team not yet at full capacity (hiring lag, access issues, onboarding time)
|
||||
|
||||
### Commercial & Financial
|
||||
- Vendor or partner contract not yet signed
|
||||
- Cost estimate based on assumptions that have not been validated
|
||||
- Revenue or savings case depends on assumptions outside the team's control
|
||||
- Currency exposure or exchange rate risk for international projects
|
||||
|
||||
### Compliance & Regulatory
|
||||
- Data privacy impact assessment (DPIA) not yet complete
|
||||
- Regulatory approval required and timeline is uncertain
|
||||
- GDPR, HIPAA, SOC 2, or sector-specific compliance requirement not yet mapped
|
||||
- Legal review of terms of service or contracts pending
|
||||
|
||||
### Stakeholder & Adoption
|
||||
- Key user group has low awareness or motivation to adopt the change
|
||||
- Internal resistance from a team that will be affected by the change
|
||||
- Executive sponsor not consistently engaged — decisions are slow
|
||||
- Communications plan not yet agreed with change management team
|
||||
|
||||
### External
|
||||
- Market or competitive change could undermine the business case
|
||||
- Macroeconomic conditions affect budget or priority
|
||||
- Supplier or infrastructure provider risk (e.g. cloud provider, hardware)
|
||||
- Geopolitical or regulatory environment change
|
||||
|
||||
---
|
||||
|
||||
## 4. Risk Heat Map
|
||||
|
||||
Plot risks by likelihood (Y axis) and impact (X axis):
|
||||
|
||||
```
|
||||
│ Low Medium High Critical
|
||||
│ (1) (2-3) (4) (5)
|
||||
─────────┼────────────────────────────────────
|
||||
Almost │ 🟡 🟡 🔴 🔴
|
||||
certain │
|
||||
(5) │
|
||||
─────────┼────────────────────────────────────
|
||||
Likely │ 🟡 🟡 🔴 🔴
|
||||
(4) │
|
||||
─────────┼────────────────────────────────────
|
||||
Possible │ 🟢 🟡 🟡 🔴
|
||||
(3) │
|
||||
─────────┼────────────────────────────────────
|
||||
Unlikely │ 🟢 🟢 🟡 🟡
|
||||
(2) │
|
||||
─────────┼────────────────────────────────────
|
||||
Rare │ 🟢 🟢 🟢 🟡
|
||||
(1) │
|
||||
```
|
||||
|
||||
[Plot each risk ID on this grid — e.g. R01 lands at L4/I5 = 🔴 Critical]
|
||||
|
||||
---
|
||||
|
||||
## 5. Top Risks — Executive Summary
|
||||
|
||||
For steering committee or board-level reporting:
|
||||
|
||||
| Rank | Risk | Score | RAG | Owner | Mitigation status |
|
||||
|---|---|---|---|---|---|
|
||||
| 1 | [Most critical risk — plain English description] | [X] | 🔴 | [Owner] | [Active / Planned / Not started] |
|
||||
| 2 | [...] | [...] | 🔴 | [...] | [...] |
|
||||
| 3 | [...] | [...] | 🟡 | [...] | [...] |
|
||||
| 4 | [...] | [...] | 🟡 | [...] | [...] |
|
||||
| 5 | [...] | [...] | 🟡 | [...] | [...] |
|
||||
|
||||
**Decisions required from steering:**
|
||||
- [Any risk that requires budget, scope, or timeline decision to mitigate]
|
||||
|
||||
---
|
||||
|
||||
## 6. Risk Changes Since Last Review
|
||||
|
||||
| Risk ID | Change | Detail |
|
||||
|---|---|---|
|
||||
| [R03] | Score increased | [L moved from 2 → 4 — vendor confirmed delay in API availability] |
|
||||
| [R07] | Risk closed | [Legal sign-off received on 12 May] |
|
||||
| [NEW] | New risk identified | [R09 — budget freeze announcement affects Phase 2 funding] |
|
||||
|
||||
---
|
||||
|
||||
## 7. Risk Closure Criteria
|
||||
|
||||
A risk is closed when:
|
||||
- The risk event can no longer occur (e.g. milestone passed, contract signed), OR
|
||||
- The residual risk score drops to Negligible (1–3) AND the team formally accepts it, OR
|
||||
- The risk has materialised and transitioned to an **issue** (tracked separately)
|
||||
|
||||
**Issues log:** [Link to issues log — risks that have materialised and are now active problems being managed]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every risk has a specific owner — not "the team" or "TBD"
|
||||
- [ ] Mitigations describe what is actively being done — not "monitor and review"
|
||||
- [ ] Contingency plans exist for all Critical and High risks
|
||||
- [ ] Risk descriptions are specific — "vendor may be late" is not specific enough; name the vendor and the dependency
|
||||
- [ ] Register has been reviewed in the last [X] days
|
||||
- [ ] Closed risks are archived, not deleted — they provide audit trail
|
||||
- [ ] Risks are distinguished from issues — a risk is something that might happen; an issue is something that has happened
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Build a risk register for our product launch"
|
||||
- "Create a risk matrix for [project name]"
|
||||
- "What risks should I document for a data migration project?"
|
||||
- "Generate a risk register for our steering committee"
|
||||
- "Help me identify and score risks for our Q3 delivery plan"
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not assign risks to "the team" or "TBD" — every risk must have a named individual owner
|
||||
- [ ] Do not write mitigations as "monitor and review" — mitigations must describe what is actively being done to reduce likelihood or impact
|
||||
- [ ] Do not delete closed risks — they provide an audit trail; archive them instead
|
||||
- [ ] Do not confuse risks with issues — a risk is something that might happen; an issue is something that has already happened
|
||||
- [ ] Do not leave Critical or High risks without a contingency plan — what happens if the mitigation fails must be documented
|
||||
@@ -0,0 +1,97 @@
|
||||
# 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 written in imperative form ("Open...", "Navigate...", "Confirm...")
|
||||
- [ ] Each step has exactly one action
|
||||
- [ ] Role specified for every step
|
||||
- [ ] Quality checkpoints at critical stages
|
||||
- [ ] Non-conformance process defines who to notify and how to document
|
||||
- [ ] Document history table and review date are included
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write an SOP for [process]"
|
||||
- "Create a standard operating procedure for [task]"
|
||||
- "Write a work instruction for [process]"
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write steps that contain more than one action — each step must be a single, auditable action in imperative form
|
||||
- [ ] Do not omit a role from any step — every action must be assigned to a specific role or the SOP cannot be enforced
|
||||
- [ ] Do not skip the non-conformance section — an SOP without a deviation process cannot meet audit or regulatory requirements
|
||||
- [ ] Do not produce an SOP without a review date and version history — undated documents cannot be relied upon for compliance
|
||||
- [ ] Do not use passive voice in procedure steps — write "Open the system" not "The system should be opened"
|
||||
@@ -0,0 +1,82 @@
|
||||
# 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]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Evaluation criteria weights total 100%
|
||||
- [ ] Scoring rubric is defined before scoring vendors (not post-hoc)
|
||||
- [ ] Reference check questions are included
|
||||
- [ ] Recommendation includes risks and conditions, not just a winner
|
||||
- [ ] Runner-up rationale explains why they lost (enables future conversations)
|
||||
- [ ] Contract terms to negotiate are specified
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not weight all evaluation criteria equally — the scorecard must reflect the relative importance of each criterion
|
||||
- [ ] Do not evaluate vendors only on features — security, support, contract terms, and financial stability matter too
|
||||
- [ ] Do not produce a recommendation without explaining why the runner-up lost — this enables future vendor conversations
|
||||
- [ ] Do not skip contract terms to negotiate — identifying leverage points is part of the procurement decision
|
||||
- [ ] Do not recommend a vendor without stating the conditions under which the recommendation would change
|
||||
|
||||
## 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]"
|
||||
+151
@@ -0,0 +1,151 @@
|
||||
# Workshop Facilitation Guide Skill
|
||||
|
||||
Produces a complete facilitation guide for any workshop — from a 90-minute problem-solving session to a full-day strategy workshop. Includes step-by-step activity instructions and facilitation moves for when things go off track.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Workshop goal** (what decision or output should exist at the end?)
|
||||
- **Participants** (number, roles, mix of seniority)
|
||||
- **Duration** (90 min / half day / full day / multi-day)
|
||||
- **Format** (in-person / remote / hybrid)
|
||||
- **Known tensions** (optional — pre-existing conflicts or disagreements to navigate)
|
||||
- **Non-negotiables** (anything that cannot be decided or changed in the room)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Workshop Facilitation Guide: [Session Name]
|
||||
|
||||
**Date:** [TBD / as provided]
|
||||
**Duration:** [X hours]
|
||||
**Participants:** [N people, roles]
|
||||
**Format:** [In-person / Remote / Hybrid]
|
||||
**Facilitator:** [Leave for user]
|
||||
|
||||
---
|
||||
|
||||
## Workshop Objectives
|
||||
|
||||
By the end of this session, the group will have:
|
||||
1. [Specific output 1 — e.g. "Agreed on the top 3 priorities for Q3"]
|
||||
2. [Specific output 2]
|
||||
3. [Specific output 3]
|
||||
|
||||
**How we will know it worked:** [Observable test for success — e.g. "Everyone can name the agreed priorities without looking at their notes"]
|
||||
|
||||
---
|
||||
|
||||
## Pre-Workshop Preparation
|
||||
|
||||
**Facilitator:**
|
||||
- [ ] Confirm objectives with session sponsor (30 min pre-read call recommended)
|
||||
- [ ] Send pre-read to participants [X days before] — max 2 pages
|
||||
- [ ] Prepare all materials (printed / Miro boards / slides)
|
||||
- [ ] Set up room or virtual space
|
||||
|
||||
**Participants (pre-work):**
|
||||
- [Specific pre-work — max 20 minutes. If more, fewer people do it]
|
||||
|
||||
---
|
||||
|
||||
## Full Agenda
|
||||
|
||||
| Time | Activity | Duration | Format | Output |
|
||||
|---|---|---|---|---|
|
||||
| [00:00] | Welcome and framing | 10 min | Facilitator-led | Shared expectations |
|
||||
| [00:10] | [Activity 1] | [X min] | [Format] | [Output] |
|
||||
| [00:X] | [Activity 2] | [X min] | [Format] | [Output] |
|
||||
| [00:X] | Break | 15 min | — | — |
|
||||
| [00:X] | [Activity 3] | [X min] | [Format] | [Output] |
|
||||
| [00:X] | Decisions and next steps | 20 min | Whole group | Committed actions |
|
||||
| [00:X] | Close | 10 min | Facilitator-led | Energy and commitment |
|
||||
|
||||
---
|
||||
|
||||
## Activity Instructions
|
||||
|
||||
For each activity:
|
||||
|
||||
### Activity [N]: [Name]
|
||||
|
||||
**Purpose:** [Why this activity at this moment]
|
||||
**Time:** [X minutes]
|
||||
**Format:** [Individual / Pairs / Small groups / Whole group]
|
||||
**Materials:** [Post-its, Miro, printed sheets, etc.]
|
||||
|
||||
**Instructions to give participants:**
|
||||
> "[Exact words to say when launching the activity — unambiguous, no jargon]"
|
||||
|
||||
**Step-by-step:**
|
||||
1. [What happens in minute 0–X]
|
||||
2. [What happens next]
|
||||
3. [How to consolidate and move forward]
|
||||
|
||||
**If the group gets stuck:** [Specific facilitation move — e.g. "Ask each person to write one idea silently before sharing"]
|
||||
**Watch out for:** [Common failure mode — e.g. "One voice dominating. Use round-robin to surface quieter participants"]
|
||||
**Time warning:** [What to do if running long — e.g. "Skip the prioritisation vote and let facilitator propose the top 3"]
|
||||
|
||||
---
|
||||
|
||||
## Decision-Making Protocol
|
||||
|
||||
Agree this with the group at the start:
|
||||
|
||||
**How decisions will be made in this session:**
|
||||
- [ ] Consensus (everyone must actively agree)
|
||||
- [ ] Consent (no one has a blocking objection)
|
||||
- [ ] Majority vote (50%+1)
|
||||
- [ ] Facilitator/sponsor decides after hearing input
|
||||
|
||||
**What happens with unresolved disagreements:** [Parking lot / escalate to sponsor / decide by [person] after session]
|
||||
|
||||
---
|
||||
|
||||
## Facilitation Moves (Quick Reference)
|
||||
|
||||
| Situation | Move |
|
||||
|---|---|
|
||||
| Silence after a question | "Take 2 minutes to write your thoughts before we share" |
|
||||
| One person dominating | "Let's hear from someone we haven't heard from yet" |
|
||||
| Off-topic tangent | "That's important — let me put it in the parking lot. Back to [focus]" |
|
||||
| Group stuck, no ideas | "What would [competitor / different industry] do here?" |
|
||||
| No consensus, running out of time | "Let's do a quick dot vote to identify the strongest options" |
|
||||
| Energy low after lunch | "Stand up and tell the person next to you your one key takeaway so far" |
|
||||
|
||||
---
|
||||
|
||||
## Close: Commitments and Next Steps
|
||||
|
||||
End every session with:
|
||||
1. **What did we decide?** — Read back every decision made. Ask: "Does anyone have a concern with how I've captured this?"
|
||||
2. **What will we do?** — Specific actions, named owners, concrete deadlines
|
||||
3. **Who needs to know?** — Who will communicate outputs to absent stakeholders, and how?
|
||||
4. **When do we meet again?** — Schedule the follow-up before the room empties
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Workshop objective is a specific output, not a vague goal ("aligned on strategy")
|
||||
- [ ] All activities have explicit timing and format
|
||||
- [ ] A decision-making protocol is agreed at the start
|
||||
- [ ] Activities alternate between individual work and group work
|
||||
- [ ] Parking lot is used actively (not a graveyard)
|
||||
- [ ] Close captures decisions and actions before the room empties
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not design a workshop without explicitly linking every activity to a session goal — purposeless activities waste participant time
|
||||
- [ ] Do not schedule more than 90 minutes of continuous structured activity without a break
|
||||
- [ ] Do not close a workshop without capturing decisions and actions before the room empties — post-session follow-up is too late
|
||||
- [ ] Do not plan a workshop without considering psychological safety for sensitive topics — establish ground rules at the start
|
||||
- [ ] Do not underestimate timing — add 20% buffer to all activity estimates, especially for groups over 8 people
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Design a workshop for [goal] with [group]"
|
||||
- "Plan a facilitated session to [outcome]"
|
||||
- "Help me run a [type] workshop with my team"
|
||||
- "Create a facilitation guide for [topic]"
|
||||
Reference in New Issue
Block a user