feat: Opus 4.7 release — 3 new vision/document skills, 3 updated skills (v5.2.0, 93 skills)
This commit is contained in:
mohitagw15856
@@ -1,8 +1,8 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
|
||||
"name": "pm-claude-skills",
|
||||
"version": "5.1.0",
|
||||
"description": "90 Claude Skills across 14 professions — product management, marketing, engineering, data, design, Figma, leadership, legal, finance, HR, sales, operations, research, and more. Save 10-15 hours per week.",
|
||||
"version": "5.2.0",
|
||||
"description": "93 Claude Skills across 14 professions — product management, legal, finance, HR, sales, engineering, design, Figma, operations, research, and more. Now with Opus 4.7-optimised vision and document skills.",
|
||||
"owner": {
|
||||
"name": "Mohit Aggarwal",
|
||||
"email": "mohit15856@gmail.com"
|
||||
@@ -10,8 +10,8 @@
|
||||
"plugins": [
|
||||
{
|
||||
"name": "pm-essentials",
|
||||
"description": "Core PM skills: PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis. The 5 skills every PM needs first.",
|
||||
"version": "3.0.0",
|
||||
"description": "Core PM skills: PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis, Word Doc Tracked Changes. The essentials every PM needs first.",
|
||||
"version": "3.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-essentials",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
@@ -34,8 +34,8 @@
|
||||
},
|
||||
{
|
||||
"name": "pm-delivery",
|
||||
"description": "Sprint & delivery skills: Sprint Planning, Technical Spec Template, A/B Test Planner, Go-to-Market Planner, Product Launch Checklist, Sprint Brief, Retro Analysis.",
|
||||
"version": "3.0.0",
|
||||
"description": "Sprint & delivery skills: Sprint Planning, Technical Spec, A/B Test Planner, Go-to-Market Planner, Launch Checklist, Sprint Brief, Retro Analysis, PPTX Slide Auditor.",
|
||||
"version": "3.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-delivery",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
@@ -83,15 +83,15 @@
|
||||
{
|
||||
"name": "pm-engineering",
|
||||
"description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record. Structured outputs for engineering teams and technical PMs.",
|
||||
"version": "1.0.0",
|
||||
"version": "1.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-engineering",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-data",
|
||||
"description": "Data & analytics skills: Metrics Framework, SQL Query Explainer, Dashboard Brief. Build North Star metric trees, explain and optimise SQL, and spec dashboards from business questions.",
|
||||
"version": "1.0.0",
|
||||
"description": "Data & analytics skills: Metrics Framework, SQL Query Explainer, Dashboard Brief, Chart Data Extractor. Build North Star metric trees, explain SQL, spec dashboards, and digitise chart images.",
|
||||
"version": "1.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-data",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
@@ -123,7 +123,7 @@
|
||||
{
|
||||
"name": "pm-legal",
|
||||
"description": "Legal skills: Contract Review, NDA Analyser, Legal Brief, Compliance Checklist. Flag risks in contracts and NDAs, draft legal memos in IRAC format, and generate GDPR, SOC 2, FCA and other compliance checklists.",
|
||||
"version": "1.0.0",
|
||||
"version": "1.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-legal",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
@@ -179,7 +179,7 @@
|
||||
{
|
||||
"name": "pm-figma",
|
||||
"description": "Figma skills for PMs and designers: Component Audit, Design Brief, Annotation Guide, Design Review, User Flow Planner, Variant Matrix, Spacing System, Prototype Plan, Design QA, PM Design Critique. Work smarter across the full Figma design lifecycle.",
|
||||
"version": "1.0.0",
|
||||
"version": "1.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-figma",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
|
||||
@@ -1,21 +1,27 @@
|
||||
# 🧠 Claude Skills Library — 90 Skills for Every Profession
|
||||
# 🧠 Claude Skills Library — 93 Skills for Every Profession
|
||||
|
||||
> **Save 8–10 hours per week across 14 professions. Install in 2 minutes.**
|
||||
> **Save 8–10 hours per week across 14 professions. Install in 2 minutes. Now with Opus 4.7-optimised vision and document skills.**
|
||||
|
||||
A community-built library of Claude Skills covering product management, marketing, engineering, data, design, Figma, leadership, legal, finance, HR, sales, operations, research, and more. Each skill is a structured SKILL.md file that teaches Claude how to produce professional-grade outputs for your specific workflows.
|
||||
|
||||
**🆕 Latest release (v5.2.0):** Three new skills that leverage Claude Opus 4.7's improved vision and document capabilities — pptx-slide-auditor, docx-tracked-changes-writer, and chart-data-extractor.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Quick Install (2 minutes)
|
||||
|
||||
In Claude Code, run:
|
||||
|
||||
/plugin marketplace add https://github.com/mohitagw15856/pm-claude-skills
|
||||
|
||||
```bash
|
||||
/plugin marketplace add mohitagw15856/pm-claude-skills
|
||||
```
|
||||
|
||||
Or install by profession:
|
||||
|
||||
claude plugin install pm-essentials@pm-claude-skills # Core PM
|
||||
```bash
|
||||
claude plugin install pm-essentials@pm-claude-skills # Core PM + Word tracked changes
|
||||
claude plugin install pm-delivery@pm-claude-skills # Delivery + PowerPoint auditor
|
||||
claude plugin install pm-data@pm-claude-skills # Data + chart data extractor
|
||||
claude plugin install pm-legal@pm-claude-skills # Legal
|
||||
claude plugin install pm-finance@pm-claude-skills # Finance
|
||||
claude plugin install pm-hr@pm-claude-skills # HR
|
||||
@@ -24,14 +30,31 @@ claude plugin install pm-operations@pm-claude-skills # Operations
|
||||
claude plugin install pm-research@pm-claude-skills # Research & Healthcare
|
||||
claude plugin install pm-cross@pm-claude-skills # Cross-profession
|
||||
claude plugin install pm-figma@pm-claude-skills # Figma
|
||||
|
||||
```
|
||||
|
||||
Or clone and symlink for auto-updates:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/mohitagw15856/pm-claude-skills.git ~/pm-claude-skills
|
||||
mkdir -p ~/.claude/skills
|
||||
ln -s ~/pm-claude-skills/skills/* ~/.claude/skills/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🆕 What's New in v5.2.0 — Opus 4.7 Release
|
||||
|
||||
Three new skills designed specifically to leverage Claude Opus 4.7's improved vision and document capabilities:
|
||||
|
||||
| Skill | Bundle | What It Does |
|
||||
|---|---|---|
|
||||
| **PPTX Slide Auditor** | pm-delivery | Audit a PowerPoint deck for layout issues, text overflow, visual hierarchy problems, and consistency gaps |
|
||||
| **Word Doc Tracked Changes** | pm-essentials | Produce properly-formatted tracked changes for Word documents — insertions, deletions, margin comments |
|
||||
| **Chart Data Extractor** | pm-data | Extract pixel-level data from chart images and produce a structured data table with confidence levels |
|
||||
|
||||
Plus three existing skills (figma-design-qa, code-review-checklist, compliance-checklist) updated to remove verification scaffolding that Opus 4.7 no longer needs — faster and cleaner outputs.
|
||||
|
||||
**Read the full story:** [Part 13 — I Re-Tested My 90 Claude Skills on Opus 4.7](#)
|
||||
|
||||
---
|
||||
|
||||
@@ -50,205 +73,209 @@ This repo was built alongside a published article series. Read the full story:
|
||||
| Part 7 | 33 Claude Skills for PMs Are Now in the Claude Code Marketplace | [Read →](https://medium.com/product-powerhouse/33-claude-skills-for-pms-are-now-in-the-claude-code-marketplace-heres-how-to-install-them-7968ab6bb1e1) |
|
||||
| Part 8 | I Added 20 New Claude Skills Beyond Product Management | [Read →](https://medium.com/product-powerhouse/i-built-20-new-claude-skills-for-every-profession-heres-the-full-library-50278e00bf72) |
|
||||
| Part 9 | 80 Claude Skills for Every Profession — Lawyers, Doctors, Finance, HR, Sales and More | [Read →](https://medium.com/@mohit15856/80-claude-skills-for-every-profession-lawyers-doctors-finance-hr-sales-and-more-3dfde9ec0033) |
|
||||
| Part 10 | A Day in the Life With 80 Claude Skills — What Actually Gets Triggered | [Read →](https://medium.com/@mohit15856/80-claude-skills-for-every-profession-lawyers-doctors-finance-hr-sales-and-more-3dfde9ec0033)|
|
||||
| Part 11 | 10 Figma Claude Skills for PMs and Designers — The Complete Figma Toolkit | *Latest — Link TBC* |
|
||||
| Part 10 | A Day in the Life With 80 Claude Skills | *Link TBC* |
|
||||
| Part 11 | 10 Figma Claude Skills for PMs and Designers | *Link TBC* |
|
||||
| Part 12 | I Built the Same Skills Library for ChatGPT — Here's What's Different | [Read →](https://medium.com/product-powerhouse/i-built-the-same-skills-library-for-chatgpt-heres-what-s-different-a9305f9c20b9) |
|
||||
| Part 13 | I Re-Tested My 90 Claude Skills on Opus 4.7 — Here's What Got Better | *Latest — Link TBC* |
|
||||
|
||||
---
|
||||
|
||||
## 🗂️ All 90 Skills
|
||||
## 🗂️ All 93 Skills
|
||||
|
||||
### 🛠️ Product Management (Skills 1–33)
|
||||
### 🛠️ Product Management (Skills 1–34)
|
||||
**Bundles:** `pm-essentials` · `pm-discovery` · `pm-planning` · `pm-delivery` · `pm-analytics` · `pm-strategy` · `pm-advanced` · `pm-rituals`
|
||||
|
||||
> The original toolkit covering the full PM lifecycle — discovery, prioritisation, delivery, strategy, stakeholder comms, and weekly rituals.
|
||||
> The original toolkit covering the full PM lifecycle — discovery, prioritisation, delivery, strategy, stakeholder comms, and weekly rituals. Now includes Word tracked changes and PowerPoint slide auditing.
|
||||
|
||||
| # | Skill | What It Does |
|
||||
|---|---|---|
|
||||
| 1–5 | **pm-essentials** | PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis |
|
||||
| 6–9 | **pm-discovery** | Discovery Interview Guide, Job Story Mapper, User Interview Synthesis, Assumption Mapper |
|
||||
| 10–15 | **pm-planning** | OKR Builder, Feature Prioritisation (RICE/MoSCoW/Kano/ICE), Roadmap Presentation, Pricing Strategy |
|
||||
| 16–22 | **pm-delivery** | Sprint Planning, Technical Spec, A/B Test Planner, Go-to-Market Planner, Launch Checklist, Sprint Brief, Retro |
|
||||
| 23–25 | **pm-analytics** | Data Analysis Standard, Retention Analysis, Product Health Analysis |
|
||||
| 26–31 | **pm-strategy** | Competitor Signal Tracker, Competitive Intelligence Monitor, Stakeholder Influence Mapper, Strategic Narrative, Executive Update, Ambiguity Resolver |
|
||||
| 32–33 | **pm-advanced** | AI Product Canvas, Multi-Source Signal Synthesiser, Experiment Designer, Design Handoff Brief |
|
||||
| 1–6 | **pm-essentials** | PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis, **Word Doc Tracked Changes** 🆕 |
|
||||
| 7–10 | **pm-discovery** | Discovery Interview Guide, Job Story Mapper, User Interview Synthesis, Assumption Mapper |
|
||||
| 11–16 | **pm-planning** | OKR Builder, Feature Prioritisation (RICE/MoSCoW/Kano/ICE), Roadmap Presentation, Pricing Strategy |
|
||||
| 17–24 | **pm-delivery** | Sprint Planning, Technical Spec, A/B Test Planner, Go-to-Market Planner, Launch Checklist, Sprint Brief, Retro, **PPTX Slide Auditor** 🆕 |
|
||||
| 25–27 | **pm-analytics** | Data Analysis Standard, Retention Analysis, Product Health Analysis |
|
||||
| 28–33 | **pm-strategy** | Competitor Signal Tracker, Competitive Intelligence Monitor, Stakeholder Influence Mapper, Strategic Narrative, Executive Update, Ambiguity Resolver |
|
||||
| 34 | **pm-advanced** | AI Product Canvas, Multi-Source Signal Synthesiser, Experiment Designer, Design Handoff Brief |
|
||||
|
||||
> See [Part 7 article](https://medium.com/product-powerhouse/33-claude-skills-for-pms-are-now-in-the-claude-code-marketplace-heres-how-to-install-them-7968ab6bb1e1) for full PM skills detail.
|
||||
|
||||
---
|
||||
|
||||
### 📣 Marketing & GTM (Skills 34–37)
|
||||
### 📣 Marketing & GTM (Skills 35–38)
|
||||
**Bundle:** `pm-gtm`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 34 | **Go-To-Market** | `skills/go-to-market/` | Positioning statements, messaging pillars, feature/benefit mapping, role-specific use cases |
|
||||
| 35 | **Content Calendar** | `skills/content-calendar/` | Multi-channel content calendars with opening hooks, formats, and repurposing map |
|
||||
| 36 | **Competitor Teardown** | `skills/competitor-teardown/` | Full competitive analysis: positioning map, feature comparison, messaging gaps, SWOT, recommendations |
|
||||
| 37 | **Email Campaign** | `skills/email-campaign/` | Sequenced email campaigns with subject lines, preview text, body copy, and CTAs |
|
||||
| 35 | **Go-To-Market** | `skills/go-to-market/` | Positioning statements, messaging pillars, feature/benefit mapping, role-specific use cases |
|
||||
| 36 | **Content Calendar** | `skills/content-calendar/` | Multi-channel content calendars with opening hooks, formats, and repurposing map |
|
||||
| 37 | **Competitor Teardown** | `skills/competitor-teardown/` | Full competitive analysis: positioning map, feature comparison, messaging gaps, SWOT, recommendations |
|
||||
| 38 | **Email Campaign** | `skills/email-campaign/` | Sequenced email campaigns with subject lines, preview text, body copy, and CTAs |
|
||||
|
||||
---
|
||||
|
||||
### 👩💻 Engineering & Tech (Skills 38–41)
|
||||
### 👩💻 Engineering & Tech (Skills 39–42)
|
||||
**Bundle:** `pm-engineering`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 38 | **Code Review Checklist** | `skills/code-review-checklist/` | Tailored PR review checklists by language, type, and risk level |
|
||||
| 39 | **Incident Postmortem** | `skills/incident-postmortem/` | Blameless postmortems with timeline, RCA, impact, and action items |
|
||||
| 40 | **API Docs Writer** | `skills/api-docs-writer/` | Developer-facing API docs: endpoints, parameters, response schemas, code examples |
|
||||
| 41 | **Architecture Decision Record** | `skills/architecture-decision-record/` | ADRs with context, options considered, decision, consequences, and risks |
|
||||
| 39 | **Code Review Checklist** | `skills/code-review-checklist/` | Tailored PR review checklists by language, type, and risk level |
|
||||
| 40 | **Incident Postmortem** | `skills/incident-postmortem/` | Blameless postmortems with timeline, RCA, impact, and action items |
|
||||
| 41 | **API Docs Writer** | `skills/api-docs-writer/` | Developer-facing API docs: endpoints, parameters, response schemas, code examples |
|
||||
| 42 | **Architecture Decision Record** | `skills/architecture-decision-record/` | ADRs with context, options considered, decision, consequences, and risks |
|
||||
|
||||
---
|
||||
|
||||
### 📊 Data & Analytics (Skills 42–44)
|
||||
### 📊 Data & Analytics (Skills 43–46)
|
||||
**Bundle:** `pm-data`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 42 | **Metrics Framework** | `skills/metrics-framework/` | North Star + metric tree, dashboard tiers, counter-metrics |
|
||||
| 43 | **SQL Query Explainer** | `skills/sql-query-explainer/` | Explain, optimise, write, and document SQL in plain English |
|
||||
| 44 | **Dashboard Brief** | `skills/dashboard-brief/` | Complete dashboard spec: KPIs, charts, filters, layout, data requirements |
|
||||
| 43 | **Metrics Framework** | `skills/metrics-framework/` | North Star + metric tree, dashboard tiers, counter-metrics |
|
||||
| 44 | **SQL Query Explainer** | `skills/sql-query-explainer/` | Explain, optimise, write, and document SQL in plain English |
|
||||
| 45 | **Dashboard Brief** | `skills/dashboard-brief/` | Complete dashboard spec: KPIs, charts, filters, layout, data requirements |
|
||||
| 46 | **Chart Data Extractor** 🆕 | `skills/chart-data-extractor/` | Extract pixel-level data from chart images into structured data tables |
|
||||
|
||||
---
|
||||
|
||||
### 🧑💼 Leadership & People (Skills 45–47)
|
||||
### 🧑💼 Leadership & People (Skills 47–49)
|
||||
**Bundle:** `pm-people`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 45 | **Performance Review** | `skills/performance-review/` | Structured reviews from bullet-point notes — self, manager, peer, and upward |
|
||||
| 46 | **Hiring Rubric** | `skills/hiring-rubric/` | Interview scorecards with competencies, behavioural questions, and panel guide |
|
||||
| 47 | **Team Offsite Planner** | `skills/team-offsite-planner/` | Full offsite agenda, session facilitation notes, and logistics checklist |
|
||||
| 47 | **Performance Review** | `skills/performance-review/` | Structured reviews from bullet-point notes — self, manager, peer, and upward |
|
||||
| 48 | **Hiring Rubric** | `skills/hiring-rubric/` | Interview scorecards with competencies, behavioural questions, and panel guide |
|
||||
| 49 | **Team Offsite Planner** | `skills/team-offsite-planner/` | Full offsite agenda, session facilitation notes, and logistics checklist |
|
||||
|
||||
---
|
||||
|
||||
### 🎨 Design & UX (Skills 48–50)
|
||||
### 🎨 Design & UX (Skills 50–52)
|
||||
**Bundle:** `pm-design`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 48 | **UX Research Plan** | `skills/ux-research-plan/` | Research plans with screener, discussion guide, and synthesis framework |
|
||||
| 49 | **Design Critique** | `skills/design-critique/` | Structured feedback using JTBD, Gestalt principles, and Nielsen's heuristics |
|
||||
| 50 | **Accessibility Audit** | `skills/accessibility-audit/` | WCAG 2.2 audit with prioritised remediation and quick wins |
|
||||
| 50 | **UX Research Plan** | `skills/ux-research-plan/` | Research plans with screener, discussion guide, and synthesis framework |
|
||||
| 51 | **Design Critique** | `skills/design-critique/` | Structured feedback using JTBD, Gestalt principles, and Nielsen's heuristics |
|
||||
| 52 | **Accessibility Audit** | `skills/accessibility-audit/` | WCAG 2.2 audit with prioritised remediation and quick wins |
|
||||
|
||||
---
|
||||
|
||||
### 🏢 Business & Strategy (Skills 51–53)
|
||||
### 🏢 Business & Strategy (Skills 53–55)
|
||||
**Bundle:** `pm-business`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 51 | **Investor Update** | `skills/investor-update/` | Monthly/quarterly investor updates: metrics, highlights, challenges, and asks |
|
||||
| 52 | **Board Deck Narrative** | `skills/board-deck-narrative/` | Slide-by-slide board presentation structure with narrative beats and talking points |
|
||||
| 53 | **Job Application** | `skills/job-application/` | Tailored CV summary, ATS keyword optimisation, and cover letter for any JD |
|
||||
| 53 | **Investor Update** | `skills/investor-update/` | Monthly/quarterly investor updates: metrics, highlights, challenges, and asks |
|
||||
| 54 | **Board Deck Narrative** | `skills/board-deck-narrative/` | Slide-by-slide board presentation structure with narrative beats and talking points |
|
||||
| 55 | **Job Application** | `skills/job-application/` | Tailored CV summary, ATS keyword optimisation, and cover letter for any JD |
|
||||
|
||||
---
|
||||
|
||||
### ⚖️ Legal (Skills 54–57)
|
||||
### ⚖️ Legal (Skills 56–59)
|
||||
**Bundle:** `pm-legal`
|
||||
|
||||
> ⚠️ All legal skills include a disclaimer. Not a substitute for qualified legal advice.
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 54 | **Contract Review** | `skills/contract-review/` | Structured review with key terms, flagged clauses, risk rating, and plain English summary |
|
||||
| 55 | **NDA Analyser** | `skills/nda-analyser/` | Clause-by-clause NDA analysis with risk flags and negotiation checklist |
|
||||
| 56 | **Legal Brief** | `skills/legal-brief/` | Legal memos and argument outlines in IRAC format (Issue, Rule, Application, Conclusion) |
|
||||
| 57 | **Compliance Checklist** | `skills/compliance-checklist/` | GDPR, SOC 2, ISO 27001, FCA, HIPAA compliance checklists with prioritised gap analysis |
|
||||
| 56 | **Contract Review** | `skills/contract-review/` | Structured review with key terms, flagged clauses, risk rating, and plain English summary |
|
||||
| 57 | **NDA Analyser** | `skills/nda-analyser/` | Clause-by-clause NDA analysis with risk flags and negotiation checklist |
|
||||
| 58 | **Legal Brief** | `skills/legal-brief/` | Legal memos and argument outlines in IRAC format (Issue, Rule, Application, Conclusion) |
|
||||
| 59 | **Compliance Checklist** | `skills/compliance-checklist/` | GDPR, SOC 2, ISO 27001, FCA, HIPAA compliance checklists with prioritised gap analysis |
|
||||
|
||||
---
|
||||
|
||||
### 💰 Finance (Skills 58–61)
|
||||
### 💰 Finance (Skills 60–63)
|
||||
**Bundle:** `pm-finance`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 58 | **Financial Model Narrative** | `skills/financial-model-narrative/` | Turns P&L and model outputs into board-ready written narratives |
|
||||
| 59 | **Budget Variance Analysis** | `skills/budget-variance-analysis/` | Variance table with root cause commentary and management summary |
|
||||
| 60 | **Investor Pitch Deck** | `skills/investor-pitch-deck/` | Slide-by-slide pitch deck structure with what each slide must prove |
|
||||
| 61 | **Financial Due Diligence** | `skills/financial-due-diligence/` | DD document request list, analytical questions, and red flags checklist |
|
||||
| 60 | **Financial Model Narrative** | `skills/financial-model-narrative/` | Turns P&L and model outputs into board-ready written narratives |
|
||||
| 61 | **Budget Variance Analysis** | `skills/budget-variance-analysis/` | Variance table with root cause commentary and management summary |
|
||||
| 62 | **Investor Pitch Deck** | `skills/investor-pitch-deck/` | Slide-by-slide pitch deck structure with what each slide must prove |
|
||||
| 63 | **Financial Due Diligence** | `skills/financial-due-diligence/` | DD document request list, analytical questions, and red flags checklist |
|
||||
|
||||
---
|
||||
|
||||
### 👥 HR (Skills 62–65)
|
||||
### 👥 HR (Skills 64–67)
|
||||
**Bundle:** `pm-hr`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 62 | **Job Description Writer** | `skills/job-description-writer/` | Inclusive, structured JDs with built-in language review and salary range nudge |
|
||||
| 63 | **Onboarding Plan** | `skills/onboarding-plan/` | 30/60/90-day plans with week-by-week structure, milestones, and manager checklist |
|
||||
| 64 | **Employee Engagement Survey** | `skills/employee-engagement-survey/` | Survey design + results analysis mode with eNPS and action planning template |
|
||||
| 65 | **Redundancy Consultation** | `skills/redundancy-consultation/` | Process timeline, at-risk letter, consultation script, and confirmation letter — UK law |
|
||||
| 64 | **Job Description Writer** | `skills/job-description-writer/` | Inclusive, structured JDs with built-in language review and salary range nudge |
|
||||
| 65 | **Onboarding Plan** | `skills/onboarding-plan/` | 30/60/90-day plans with week-by-week structure, milestones, and manager checklist |
|
||||
| 66 | **Employee Engagement Survey** | `skills/employee-engagement-survey/` | Survey design + results analysis mode with eNPS and action planning template |
|
||||
| 67 | **Redundancy Consultation** | `skills/redundancy-consultation/` | Process timeline, at-risk letter, consultation script, and confirmation letter — UK law |
|
||||
|
||||
---
|
||||
|
||||
### 🤝 Sales (Skills 66–69)
|
||||
### 🤝 Sales (Skills 68–71)
|
||||
**Bundle:** `pm-sales`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 66 | **Sales Battlecard** | `skills/sales-battlecard/` | One-page competitive battlecard with objection responses and landmine questions |
|
||||
| 67 | **Discovery Call Prep** | `skills/discovery-call-prep/` | Call brief with research summary, hypothesis, structured questions, and success criteria |
|
||||
| 68 | **Proposal Writer** | `skills/proposal-writer/` | Commercial proposals structured around the prospect's problem, not the product |
|
||||
| 69 | **Account Plan** | `skills/account-plan/` | Strategic account plan with relationship map, whitespace analysis, risks, and 90-day actions |
|
||||
| 68 | **Sales Battlecard** | `skills/sales-battlecard/` | One-page competitive battlecard with objection responses and landmine questions |
|
||||
| 69 | **Discovery Call Prep** | `skills/discovery-call-prep/` | Call brief with research summary, hypothesis, structured questions, and success criteria |
|
||||
| 70 | **Proposal Writer** | `skills/proposal-writer/` | Commercial proposals structured around the prospect's problem, not the product |
|
||||
| 71 | **Account Plan** | `skills/account-plan/` | Strategic account plan with relationship map, whitespace analysis, risks, and 90-day actions |
|
||||
|
||||
---
|
||||
|
||||
### ⚙️ Operations (Skills 70–73)
|
||||
### ⚙️ Operations (Skills 72–75)
|
||||
**Bundle:** `pm-operations`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 70 | **Process Documentation** | `skills/process-documentation/` | Clear process docs with steps, roles, edge cases — followable by a new starter |
|
||||
| 71 | **SOP Writer** | `skills/sop-writer/` | Formal, audit-ready SOPs with version control, quality checks, and non-conformance process |
|
||||
| 72 | **Vendor Evaluation** | `skills/vendor-evaluation/` | Weighted vendor scorecard, RFP questions, reference check template, and recommendation |
|
||||
| 73 | **Project Status Report** | `skills/project-status-report/` | RAG status reports with milestone progress, issues, risks, and decisions required |
|
||||
| 72 | **Process Documentation** | `skills/process-documentation/` | Clear process docs with steps, roles, edge cases — followable by a new starter |
|
||||
| 73 | **SOP Writer** | `skills/sop-writer/` | Formal, audit-ready SOPs with version control, quality checks, and non-conformance process |
|
||||
| 74 | **Vendor Evaluation** | `skills/vendor-evaluation/` | Weighted vendor scorecard, RFP questions, reference check template, and recommendation |
|
||||
| 75 | **Project Status Report** | `skills/project-status-report/` | RAG status reports with milestone progress, issues, risks, and decisions required |
|
||||
|
||||
---
|
||||
|
||||
### 🏥 Research & Healthcare (Skills 74–77)
|
||||
### 🏥 Research & Healthcare (Skills 76–79)
|
||||
**Bundle:** `pm-research`
|
||||
|
||||
> ⚠️ Healthcare skills are for documentation and educational purposes only. All clinical content must be reviewed by a qualified professional.
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 74 | **Clinical Case Summary** | `skills/clinical-case-summary/` | SBAR handovers, SOAP notes, and case reports for educational and documentation use |
|
||||
| 75 | **Research Protocol** | `skills/research-protocol/` | Complete study protocols with objectives, methodology, ethics, and analysis plan |
|
||||
| 76 | **Patient Communication** | `skills/patient-communication/` | Plain English patient letters, leaflets, and results communications at Grade 6 reading level |
|
||||
| 77 | **Literature Review** | `skills/literature-review/` | Thematically organised literature reviews with synthesis, critical analysis, and gap identification |
|
||||
| 76 | **Clinical Case Summary** | `skills/clinical-case-summary/` | SBAR handovers, SOAP notes, and case reports for educational and documentation use |
|
||||
| 77 | **Research Protocol** | `skills/research-protocol/` | Complete study protocols with objectives, methodology, ethics, and analysis plan |
|
||||
| 78 | **Patient Communication** | `skills/patient-communication/` | Plain English patient letters, leaflets, and results communications at Grade 6 reading level |
|
||||
| 79 | **Literature Review** | `skills/literature-review/` | Thematically organised literature reviews with synthesis, critical analysis, and gap identification |
|
||||
|
||||
---
|
||||
|
||||
### 🌐 Cross-Profession (Skills 78–80)
|
||||
### 🌐 Cross-Profession (Skills 80–82)
|
||||
**Bundle:** `pm-cross`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 78 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
|
||||
| 79 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
|
||||
| 80 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
|
||||
| 80 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
|
||||
| 81 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
|
||||
| 82 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
|
||||
|
||||
---
|
||||
|
||||
### 🖼️ Figma (Skills 81–90)
|
||||
### 🖼️ Figma (Skills 83–92)
|
||||
**Bundle:** `pm-figma`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 81 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
|
||||
| 82 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
|
||||
| 83 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
|
||||
| 84 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
|
||||
| 85 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
|
||||
| 86 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
|
||||
| 87 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
|
||||
| 88 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
|
||||
| 89 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
|
||||
| 90 | **Figma Design Critique (PM)** | `skills/figma-design-critique-pm/` | PM-perspective design critique focused on product outcomes, not aesthetics |
|
||||
| 83 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
|
||||
| 84 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
|
||||
| 85 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
|
||||
| 86 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
|
||||
| 87 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
|
||||
| 88 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
|
||||
| 89 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
|
||||
| 90 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
|
||||
| 91 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
|
||||
| 92 | **Figma Design Critique (PM)** | `skills/figma-design-critique-pm/` | PM-perspective design critique focused on product outcomes, not aesthetics |
|
||||
|
||||
```bash
|
||||
claude plugin install pm-figma@pm-claude-skills
|
||||
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
@@ -264,6 +291,7 @@ This is an open-source community library. If you've built a skill that saves you
|
||||
4. Raise a pull request with a short description of what the skill does and why you built it
|
||||
|
||||
**SKILL.md template:**
|
||||
```markdown
|
||||
---
|
||||
name: your-skill-name
|
||||
description: "One sentence. Use when [trigger condition]. Produces [output description]."
|
||||
@@ -272,7 +300,7 @@ description: "One sentence. Use when [trigger condition]. Produces [output descr
|
||||
# Skill Title
|
||||
|
||||
[Instructions for Claude to follow when this skill is invoked]
|
||||
|
||||
```
|
||||
|
||||
**What makes a good skill:**
|
||||
- Solves a recurring professional workflow (not a one-off task)
|
||||
@@ -303,8 +331,9 @@ Have a skill idea? [Open an issue](../../issues) or raise it in [Discussions](..
|
||||
|
||||
Install the whole library or just the bundles you need:
|
||||
|
||||
```bash
|
||||
# Install everything
|
||||
/plugin marketplace add https://github.com/mohitagw15856/pm-claude-skills
|
||||
/plugin marketplace add mohitagw15856/pm-claude-skills
|
||||
|
||||
# Install by profession
|
||||
claude plugin install pm-essentials@pm-claude-skills
|
||||
@@ -329,13 +358,23 @@ claude plugin install pm-operations@pm-claude-skills
|
||||
claude plugin install pm-research@pm-claude-skills
|
||||
claude plugin install pm-cross@pm-claude-skills
|
||||
claude plugin install pm-figma@pm-claude-skills
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🤖 Companion Repository — ChatGPT Custom GPTs
|
||||
|
||||
If you use ChatGPT instead of Claude Code, there's a companion repo with the same professional frameworks built as Custom GPT system prompts:
|
||||
|
||||
**[professional-gpt-library](https://github.com/mohitagw15856/professional-gpt-library)** — 10 starter GPTs across 8 professions, MIT licence.
|
||||
|
||||
Read the full breakdown: [Part 12 — I Built the Same Skills Library for ChatGPT](https://medium.com/product-powerhouse/i-built-the-same-skills-library-for-chatgpt-heres-what-s-different-a9305f9c20b9)
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Custom Skills for Your Team
|
||||
|
||||
The 90 skills in this library are built for general professional workflows. But the most powerful version of Claude Skills is one built specifically for *your* team — your templates, your terminology, your processes, your quality standards.
|
||||
The 93 skills in this library are built for general professional workflows. But the most powerful version of Claude Skills is one built specifically for *your* team — your templates, your terminology, your processes, your quality standards.
|
||||
|
||||
**What custom skills look like in practice:**
|
||||
|
||||
|
||||
Vendored
BIN
Binary file not shown.
Executable
+36
@@ -0,0 +1,36 @@
|
||||
#!/bin/bash
|
||||
|
||||
# =============================================================================
|
||||
# create-plugin-json-pm-figma.sh
|
||||
# Run from the ROOT of your pm-claude-skills repo.
|
||||
# Creates the .claude-plugin/plugin.json for the pm-figma bundle.
|
||||
# =============================================================================
|
||||
|
||||
set -e
|
||||
|
||||
if [ ! -d "$(pwd)/plugins" ]; then
|
||||
echo "ERROR: Run from the root of pm-claude-skills"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
mkdir -p plugins/pm-figma/.claude-plugin
|
||||
|
||||
cat > plugins/pm-figma/.claude-plugin/plugin.json << 'EOF'
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/plugin.schema.json",
|
||||
"name": "pm-figma",
|
||||
"version": "1.0.0",
|
||||
"description": "Figma skills for product managers and designers: Component Audit, Design Brief, Annotation Guide, Design Review, User Flow Planner, Variant Matrix, Spacing System, Prototype Plan, Design QA, PM Design Critique. Work smarter in Figma across the full design lifecycle.",
|
||||
"author": {
|
||||
"name": "Mohit Aggarwal",
|
||||
"email": "mohit15856@gmail.com"
|
||||
},
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills",
|
||||
"license": "MIT",
|
||||
"keywords": ["figma", "design", "product-management", "design-system", "components", "prototype", "handoff", "ux"]
|
||||
}
|
||||
EOF
|
||||
|
||||
echo "✓ plugins/pm-figma/.claude-plugin/plugin.json created"
|
||||
echo ""
|
||||
echo "Next: run setup-pm-figma.sh then update-marketplace.sh"
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: chart-data-extractor
|
||||
description: "Extract pixel-level data from an image of a chart or graph and produce a structured data table. Use when asked to extract data from a chart image, transcribe numbers from a graph, digitise a chart, or turn a screenshot of data into a table. Produces a structured table with extracted values, confidence levels, and a reconstructed chart source. Best used with Claude Opus 4.7 or newer for reliable chart data extraction."
|
||||
---
|
||||
|
||||
# Chart Data Extractor Skill
|
||||
|
||||
Extracts data from images of charts and graphs — bar charts, line charts, pie charts, scatter plots, and tables in images — producing a structured data table that can be used in spreadsheets or rebuilt in any charting tool. Built to leverage Opus 4.7 pixel-level image analysis capabilities.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **The chart image** (upload a screenshot or image file)
|
||||
- **Chart type** (if ambiguous — bar / line / pie / scatter / other)
|
||||
- **What matters most** (approximate trends / precise values / specific data points / categorisation)
|
||||
- **Known axis values** (optional — if the user knows the max/min values to anchor the extraction)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Chart Identification
|
||||
|
||||
| Attribute | Value |
|
||||
|---|---|
|
||||
| Chart type | [Bar / Line / Pie / Scatter / Area / Other] |
|
||||
| Chart title (if visible) | [Title text] |
|
||||
| X-axis label | [Label + unit] |
|
||||
| Y-axis label | [Label + unit] |
|
||||
| Number of series | N |
|
||||
| Legend categories | [List] |
|
||||
| Data period (if time-based) | [Start — End] |
|
||||
|
||||
### 2. Extracted Data Table
|
||||
|
||||
| [X axis] | [Series 1] | [Series 2] | ... |
|
||||
|---|---|---|---|
|
||||
| [Value] | [Value] | [Value] | |
|
||||
|
||||
### 3. Confidence Levels
|
||||
|
||||
For each data point or series, flag confidence:
|
||||
|
||||
- **High confidence:** data points where the value is clearly readable against gridlines or labels
|
||||
- **Medium confidence:** data points where the value is interpolated between gridlines
|
||||
- **Low confidence:** data points where the value is ambiguous or overlaps with other elements
|
||||
|
||||
Low-confidence points should be explicitly listed — not silently included in the main table.
|
||||
|
||||
### 4. Notable Observations
|
||||
|
||||
Observations that the data itself reveals:
|
||||
- Peak value: [Value, when, in which series]
|
||||
- Lowest value: [Value, when, in which series]
|
||||
- Largest delta between series: [Details]
|
||||
- Any anomalies or outliers visible in the chart
|
||||
|
||||
### 5. Reconstructed Source
|
||||
|
||||
CSV format for direct use:
|
||||
|
||||
```csv
|
||||
[x_axis],[series_1],[series_2]
|
||||
[value],[value],[value]
|
||||
```
|
||||
|
||||
### 6. Assumptions and Caveats
|
||||
|
||||
- Grid resolution: [How precisely values could be read — e.g. "Y-axis has major gridlines every 10 units, minor every 2"]
|
||||
- Interpolation used: [Any values that required estimating between gridlines]
|
||||
- Unclear data: [Anything in the chart that could not be read reliably]
|
||||
- Axis scale: [Linear/logarithmic/etc — note if not obvious]
|
||||
|
||||
### 7. Follow-up Options
|
||||
|
||||
Ask the user which of these they want:
|
||||
- Rebuild the chart in a specified format (Excel formula, Python matplotlib, D3, etc.)
|
||||
- Produce a narrative description of what the chart shows
|
||||
- Compare this data against another chart or source
|
||||
- Flag potentially misleading visual choices in the original (truncated axes, misleading scales, etc.)
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Every extracted number specifies which series it belongs to
|
||||
- [ ] Confidence levels are explicit for ambiguous points
|
||||
- [ ] Low-confidence values are flagged separately, not silently included
|
||||
- [ ] Assumptions about axis scale and interpolation are stated
|
||||
- [ ] CSV output is clean and directly usable
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Extract the data from this chart"
|
||||
- "Transcribe the numbers in this graph"
|
||||
- "Turn this chart image into a spreadsheet"
|
||||
- "Digitise this chart so I can rebuild it"
|
||||
- "What are the exact values in this bar chart?"
|
||||
|
||||
## Why This Works Better on Opus 4.7
|
||||
Earlier models struggled with pixel-level data transcription from charts, often hallucinating values or misreading gridline positions. Opus 4.7 uses a higher image resolution (2576px vs 1568px) with coordinates mapping 1:1 to pixels, making chart data extraction reliable for practical use.
|
||||
Vendored
BIN
Binary file not shown.
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,93 @@
|
||||
---
|
||||
name: pptx-slide-auditor
|
||||
description: "Audit a PowerPoint presentation for layout issues, text overflow, visual hierarchy problems, and consistency gaps. Use when asked to review a slide deck, check a presentation before a meeting, audit slides for layout problems, or QA a deck before sharing. Produces a slide-by-slide report with issues ranked by severity and specific fixes. Best used with Claude Opus 4.7 or newer for reliable slide-level vision analysis."
|
||||
---
|
||||
|
||||
# PPTX Slide Auditor Skill
|
||||
|
||||
Runs a systematic visual and structural audit of a PowerPoint presentation — identifying layout issues, text overflow, inconsistent styling, weak visual hierarchy, and slides that will cause problems in a presentation setting. Built to leverage Opus 4.7 vision improvements for pixel-level layout analysis.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **The deck** (upload the .pptx file or individual slide screenshots)
|
||||
- **Audience** (internal team / executive / external client / conference / investor)
|
||||
- **Presentation mode** (presented live / sent to read / shared async on video)
|
||||
- **Areas of concern** (optional — e.g. "I think slide 12 is overcrowded")
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Deck Overview
|
||||
| Metric | Result |
|
||||
|---|---|
|
||||
| Total slides | N |
|
||||
| Overall status | Ready / Minor fixes needed / Major revisions required |
|
||||
| Readability score | /10 |
|
||||
| Visual consistency score | /10 |
|
||||
| Most common issue | [Pattern observed across multiple slides] |
|
||||
|
||||
### 2. Slide-by-Slide Audit
|
||||
|
||||
For each slide with issues:
|
||||
|
||||
**Slide N: [Slide title]**
|
||||
- Status: Ready / Fix before sending / Major revision
|
||||
- Issues found:
|
||||
- [Specific issue with exact location — e.g. "Body text extends beyond the text frame on the right side"]
|
||||
- [Issue 2]
|
||||
- Suggested fix: [Specific action — move element, reduce text, resize]
|
||||
|
||||
Slides with no issues: just list the slide numbers. Do not write anything else about them.
|
||||
|
||||
### 3. Pattern Issues Across the Deck
|
||||
|
||||
Issues that repeat across multiple slides:
|
||||
|
||||
**[Pattern title — e.g. "Inconsistent body text size"]**
|
||||
- Slides affected: [list]
|
||||
- Root cause: [master slide issue / manual overrides / mixed templates]
|
||||
- Fix: [Single action to resolve across all affected slides]
|
||||
|
||||
### 4. Visual Hierarchy Check
|
||||
|
||||
| Dimension | Status | Notes |
|
||||
|---|---|---|
|
||||
| Title consistency (size, font, colour) | Pass / Fail | |
|
||||
| Body text readability at presentation distance | Pass / Fail | |
|
||||
| Image placement alignment | Pass / Fail | |
|
||||
| Whitespace and breathing room | Pass / Fail | |
|
||||
| Data visualisation clarity | Pass / Fail / N/A | |
|
||||
|
||||
### 5. Audience-Specific Flags
|
||||
|
||||
Based on the stated audience:
|
||||
|
||||
- **Executive audience:** flag slides with too much text, complex tables, or unclear bottom-line messages
|
||||
- **External client:** flag slides with internal jargon, unfinished placeholder text, or confidentiality concerns
|
||||
- **Live presentation:** flag slides that will be hard to read from the back of a room
|
||||
- **Async/video:** flag slides that assume a presenter voiceover
|
||||
|
||||
### 6. Prioritised Fix List
|
||||
|
||||
| # | Fix | Slide | Effort | Impact |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [Specific fix] | Slide N | Low/Med/High | High |
|
||||
|
||||
Order by: fixes before handoff (critical) > consistency fixes (high) > polish (medium).
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Every issue references a specific slide number and location on the slide
|
||||
- [ ] Pattern issues are identified separately from slide-specific issues
|
||||
- [ ] Fix list is ordered by impact, not by slide order
|
||||
- [ ] Audience-appropriate concerns flagged explicitly
|
||||
- [ ] Slides without issues are listed briefly, not ignored
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Audit this slide deck before my board meeting"
|
||||
- "Review this PowerPoint for layout issues"
|
||||
- "Check this presentation for consistency problems"
|
||||
- "QA my deck before I send it to the client"
|
||||
- "What is wrong with slide 7 in this deck?"
|
||||
|
||||
## Why This Works Better on Opus 4.7
|
||||
Earlier models struggled with precise spatial analysis of slide layouts — they would hallucinate issues or miss obvious overflow problems. Opus 4.7 vision improvements mean coordinates map 1:1 to pixels, making slide-level issue detection reliable without manual screenshot annotation.
|
||||
@@ -1,114 +1,107 @@
|
||||
---
|
||||
name: code-review-checklist
|
||||
description: "Generate a tailored code review checklist for any PR, language, or risk level. Use when asked to create a code review checklist, review guidelines, PR standards, or quality gates for a codebase. Produces a structured, prioritised checklist adapted to the specific language, PR type, and risk level."
|
||||
description: "Generate a tailored code review checklist for any pull request based on the language, type of change, and risk level. Use when asked to review code, check a PR, review a pull request, or generate a code review checklist. Produces a focused checklist with language-specific checks, risk-level-appropriate depth, and a clear approve/request-changes recommendation. Optimised for Opus 4.7 and newer models."
|
||||
---
|
||||
|
||||
# Code Review Checklist Skill
|
||||
|
||||
This skill generates a structured, prioritised code review checklist tailored to a specific PR, language, and risk level. It helps reviewers be thorough without being bureaucratic.
|
||||
Produces a tailored code review checklist for a specific pull request — scaled to the language, type of change, and risk level. Not a generic template.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Programming language(s)** (e.g. Python, TypeScript, Go, Java)
|
||||
- **PR type** (new feature / bug fix / refactor / performance improvement / security patch / infrastructure change)
|
||||
- **Risk level** (Low: internal tooling, Low traffic / Medium: user-facing feature / High: payment, auth, data pipeline, public API)
|
||||
- **Team context** (optional: team size, seniority mix, any known recurring issues)
|
||||
- **Language and framework** (e.g. TypeScript + React / Python + FastAPI / Go)
|
||||
- **Type of change** (feature / bug fix / refactor / dependency upgrade / security patch / performance)
|
||||
- **Risk level** (low / medium / high / critical)
|
||||
- **PR description** (paste the description or link to the PR)
|
||||
- **Author context** (new starter / experienced / external contributor)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Checklist Header
|
||||
### 1. Review Summary
|
||||
**PR:** [Title or reference]
|
||||
**Scope assessment:** [Small / Medium / Large / Too large — should be split]
|
||||
**Recommended review depth:** [Skim / Standard / Deep dive]
|
||||
**Estimated review time:** [Minutes]
|
||||
|
||||
**PR:** [Title if provided]
|
||||
**Language:** [Language]
|
||||
**Type:** [PR Type]
|
||||
**Risk Level:** [Low / Medium / High]
|
||||
**Estimated review depth:** [Quick scan ~15 min / Standard ~30 min / Deep review ~60 min+]
|
||||
### 2. Correctness Checks
|
||||
|
||||
---
|
||||
Language-specific correctness checks — choose based on the language stated:
|
||||
|
||||
### 2. The Checklist
|
||||
**For TypeScript/JavaScript:**
|
||||
- Type definitions match actual usage
|
||||
- No implicit `any` in non-test code
|
||||
- Async/await used consistently; no unhandled promises
|
||||
- Null/undefined handling is explicit
|
||||
|
||||
Organise into sections. Mark each item with a priority indicator:
|
||||
- 🔴 **MUST** — Blocking. PR should not merge without this.
|
||||
- 🟡 **SHOULD** — Important. Address before merge unless there's a good reason not to.
|
||||
- 🟢 **CONSIDER** — Nice to have. Worth a comment but not blocking.
|
||||
**For Python:**
|
||||
- Type hints present on public functions
|
||||
- Exception handling is specific (no bare except)
|
||||
- Resources are closed (context managers, with blocks)
|
||||
|
||||
#### Section A: Correctness
|
||||
- 🔴 Does the code do what the ticket/requirement describes?
|
||||
- 🔴 Are edge cases handled? (nulls, empty arrays, zero values, max values)
|
||||
- 🔴 Are error states handled and surfaced appropriately?
|
||||
- 🟡 Does the happy path have adequate test coverage?
|
||||
- 🟡 Are failure paths tested?
|
||||
**For Go:**
|
||||
- Errors are handled or explicitly ignored with a comment
|
||||
- Context propagation is correct
|
||||
- Goroutine lifetimes are bounded
|
||||
|
||||
#### Section B: Security (scale with risk level — expand for High risk PRs)
|
||||
- 🔴 [High risk only] Is user input sanitised before use in queries or commands?
|
||||
- 🔴 [High risk only] Are auth/permission checks in place?
|
||||
- 🟡 Are secrets/credentials committed anywhere? (check .env handling)
|
||||
- 🟡 Are third-party dependencies known-safe versions?
|
||||
[Include only the section matching the stated language]
|
||||
|
||||
#### Section C: Performance
|
||||
- 🟡 Are there N+1 query patterns in database calls?
|
||||
- 🟡 Is there unnecessary work inside loops?
|
||||
- 🟢 Are database queries indexed appropriately?
|
||||
- 🟢 Is caching considered where appropriate?
|
||||
### 3. Change-Type-Specific Checks
|
||||
|
||||
#### Section D: Readability & Maintainability
|
||||
- 🟡 Are function and variable names clear without needing a comment to explain them?
|
||||
- 🟡 Are complex logic blocks explained with inline comments?
|
||||
- 🟢 Is the code consistent with existing patterns in the codebase?
|
||||
- 🟢 Are there any magic numbers that should be named constants?
|
||||
**For bug fixes:**
|
||||
- A test exists that would have caught this bug
|
||||
- The fix addresses root cause, not symptom
|
||||
- Related code paths checked for the same issue
|
||||
|
||||
#### Section E: Language-Specific Checks
|
||||
[Populate this section based on the specified language. Examples below:]
|
||||
**For features:**
|
||||
- Acceptance criteria met
|
||||
- Edge cases handled (empty, large, concurrent)
|
||||
- Error paths tested, not just happy path
|
||||
- Telemetry/logging added for debugging
|
||||
|
||||
**Python:**
|
||||
- 🟡 Are type hints used on function signatures?
|
||||
- 🟡 Are exceptions caught specifically (not bare `except:`)?
|
||||
- 🟢 Does it follow PEP 8 (or the team's linter config)?
|
||||
**For refactors:**
|
||||
- Behaviour unchanged (tests still pass)
|
||||
- No scope creep — refactor only
|
||||
- Complexity reduced, not just moved
|
||||
|
||||
**TypeScript/JavaScript:**
|
||||
- 🔴 Are there any `any` types that should be properly typed?
|
||||
- 🟡 Are async/await patterns used consistently (no mixed Promise.then chains)?
|
||||
- 🟢 Are there unnecessary re-renders in React components?
|
||||
**For dependency upgrades:**
|
||||
- Breaking changes reviewed
|
||||
- Security advisories checked
|
||||
- License compatibility verified
|
||||
|
||||
**Go:**
|
||||
- 🔴 Are errors checked (not ignored with `_`)?
|
||||
- 🟡 Are goroutines properly managed to prevent leaks?
|
||||
- 🟢 Are exported functions documented?
|
||||
[Include only the section matching the stated change type]
|
||||
|
||||
#### Section F: PR Hygiene
|
||||
- 🟡 Is the PR a reasonable size? (>500 lines diff suggests it should be split)
|
||||
- 🟡 Does the PR description explain *why*, not just *what*?
|
||||
- 🟢 Are there linked tickets or context in the PR description?
|
||||
- 🟢 Are migration scripts or deployment notes included if needed?
|
||||
### 4. Risk-Appropriate Checks
|
||||
|
||||
---
|
||||
**Low risk:** basic correctness, style conventions, test coverage
|
||||
**Medium risk:** above + rollback plan, monitoring updates, performance considerations
|
||||
**High risk:** above + security implications, data migration safety, feature flag/gradual rollout
|
||||
**Critical risk:** above + staging validation plan, incident response plan, post-deploy verification checklist
|
||||
|
||||
### 3. Risk-Specific Additions
|
||||
### 5. Testing Adequacy
|
||||
- Unit tests cover new logic
|
||||
- Integration tests cover the contract changes
|
||||
- Edge cases tested
|
||||
- Failure modes tested
|
||||
- Performance tests if performance-sensitive
|
||||
|
||||
For **High risk** PRs, always add:
|
||||
- 🔴 Has this been tested in a staging environment?
|
||||
- 🔴 Is there a rollback plan?
|
||||
- 🔴 Has a second reviewer been assigned?
|
||||
### 6. Review Decision Framework
|
||||
|
||||
For **Infrastructure / DB changes**, always add:
|
||||
- 🔴 Are migrations backward-compatible?
|
||||
- 🔴 Has the migration been tested against production data volume?
|
||||
**Approve if:** [2-3 specific conditions based on this PR]
|
||||
**Request changes if:** [Specific blockers]
|
||||
**Comment (non-blocking) if:** [Items worth discussing but not blocking merge]
|
||||
|
||||
---
|
||||
### 7. Common Pitfalls for This Change Type
|
||||
Based on the change type and language, flag 2-3 things reviewers typically miss for this combination.
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Checklist is tailored to the specified language (not generic)
|
||||
- [ ] Risk level is reflected in the MUST vs SHOULD balance
|
||||
- [ ] Language-specific section covers the most common issues for that language
|
||||
- [ ] PR hygiene section is always present
|
||||
- [ ] High-risk additions are included when risk level = High
|
||||
- [ ] Checklist is tailored to the stated language (not generic)
|
||||
- [ ] Change-type-specific section is included
|
||||
- [ ] Risk-appropriate depth matches stated risk level
|
||||
- [ ] Decision framework is explicit
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Generate a code review checklist for a Python bug fix PR"
|
||||
- "Give me a review checklist for a high-risk TypeScript auth change"
|
||||
- "What should I check in this Go PR?"
|
||||
- "Create PR review standards for our team"
|
||||
- "Generate a code review checklist for [PR description]"
|
||||
- "What should I check in this pull request?"
|
||||
- "Give me a code review checklist for a [language] [change type]"
|
||||
- "Review checklist for a high-risk PR in [language]"
|
||||
@@ -0,0 +1,121 @@
|
||||
---
|
||||
name: docx-tracked-changes
|
||||
description: "Produce properly-formatted tracked changes for a Word document. Use when asked to redline a document, suggest edits to a contract or document, create tracked changes for review, or mark up a document with proposed revisions. Produces a complete redline with insertions, deletions, and margin comments that can be applied to the source document. Best used with Claude Opus 4.7 or newer for reliable tracked changes handling."
|
||||
---
|
||||
|
||||
# Word Doc Tracked Changes Skill
|
||||
|
||||
Produces properly-structured tracked changes for a Word document — insertions, deletions, replacements, and margin comments formatted so they can be applied directly to the source document. Built to leverage Opus 4.7 improvements in .docx redlining and tracked changes generation.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **The document** (paste the text or upload the .docx)
|
||||
- **Review type** (legal review / copy edit / substantive rewrite / compliance check / plain English rewrite)
|
||||
- **Review scope** (full document / specific sections / specific clause type)
|
||||
- **Reviewer role** (author / manager / legal counsel / subject matter expert)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Redline Summary
|
||||
|
||||
**Document:** [Name or identifier]
|
||||
**Review type:** [As stated]
|
||||
**Reviewer:** [Role]
|
||||
**Total changes:** [Insertions: N / Deletions: N / Comments: N]
|
||||
**Overall assessment:** [1-2 sentences — is this document close to final, or does it need substantial revision?]
|
||||
|
||||
### 2. Top-Level Changes
|
||||
|
||||
Changes that affect the meaning or structure of the document:
|
||||
|
||||
**Change N — [Section or paragraph reference]**
|
||||
- Original: "[Exact original text]"
|
||||
- Suggested: "[Proposed new text]"
|
||||
- Reason: [Why this change — substantive/legal/clarity]
|
||||
|
||||
### 3. Line-by-Line Tracked Changes
|
||||
|
||||
For each paragraph that needs changes, format as:
|
||||
|
||||
**[Paragraph reference — e.g. "Section 3, Paragraph 2"]**
|
||||
|
||||
Original:
|
||||
> [Exact original paragraph]
|
||||
|
||||
Tracked changes:
|
||||
> [Same paragraph with deletions marked as ~~strikethrough~~ and insertions marked as **bold**]
|
||||
|
||||
Clean version:
|
||||
> [Final clean text after applying changes]
|
||||
|
||||
### 4. Margin Comments
|
||||
|
||||
Comments that flag issues without proposing a specific wording change:
|
||||
|
||||
**Comment N — [Location]**
|
||||
"[Comment text — written as the reviewer would write it. Direct, specific, actionable.]"
|
||||
|
||||
Comments are for things like:
|
||||
- "This clause conflicts with Section 7 — please reconcile"
|
||||
- "Missing definition of [term] used throughout"
|
||||
- "Confirm figure with finance team"
|
||||
|
||||
### 5. Stylistic Edits
|
||||
|
||||
Line-level stylistic changes (if scope includes copy editing):
|
||||
|
||||
| Location | Before | After | Reason |
|
||||
|---|---|---|---|
|
||||
| Para 3 | [Text] | [Text] | [Readability/grammar/consistency] |
|
||||
|
||||
### 6. Pattern Flags
|
||||
|
||||
Issues that repeat across the document:
|
||||
|
||||
**[Pattern — e.g. "Passive voice overuse"]**
|
||||
- Instances: [count]
|
||||
- Examples: [2-3 specific locations]
|
||||
- Suggested approach: [How to address]
|
||||
|
||||
### 7. Review Completeness
|
||||
|
||||
| Review dimension | Covered |
|
||||
|---|---|
|
||||
| Grammar and syntax | Yes / No |
|
||||
| Clarity and readability | Yes / No |
|
||||
| Substantive accuracy | Yes / No / N/A |
|
||||
| Compliance/legal check | Yes / No / N/A |
|
||||
| Consistency with referenced documents | Yes / No / N/A |
|
||||
|
||||
### 8. How to Apply These Changes
|
||||
|
||||
Instructions for applying the redline:
|
||||
|
||||
**In Microsoft Word:**
|
||||
1. Enable Track Changes (Review tab → Track Changes)
|
||||
2. Apply the changes from Section 3 in order
|
||||
3. Add comments from Section 4 using Review → New Comment
|
||||
4. Send the redlined document back to the reviewer
|
||||
|
||||
**In Google Docs:**
|
||||
1. Switch to Suggesting mode (top right pencil icon)
|
||||
2. Apply the changes from Section 3
|
||||
3. Add comments using the comment button in the margin
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Every tracked change has the original text preserved exactly
|
||||
- [ ] Substantive changes are separated from stylistic changes
|
||||
- [ ] Comments are written as the reviewer would write them, not meta-commentary
|
||||
- [ ] Pattern issues identified separately from individual changes
|
||||
- [ ] Application instructions match the target platform
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Redline this contract"
|
||||
- "Create tracked changes for this document"
|
||||
- "Mark up this document with proposed edits"
|
||||
- "Review this and suggest changes in tracked changes format"
|
||||
- "Give me a redline version of this draft"
|
||||
|
||||
## Why This Works Better on Opus 4.7
|
||||
Tracked changes require the model to preserve source text exactly while suggesting alternatives — earlier models would paraphrase the original or lose track of which text was original vs suggested. Opus 4.7 improvements specifically target this workflow.
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: figma-design-qa
|
||||
description: "Run a pre-handoff QA checklist on any Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, review a design before engineering, or validate a Figma file is ready to build. Produces a structured QA checklist covering file hygiene, component usage, accessibility, and handoff readiness with pass/fail status."
|
||||
description: "Run a pre-handoff QA checklist on any Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, review a design before engineering, or validate a Figma file is ready to build. Produces a structured QA checklist covering file hygiene, component usage, accessibility, and handoff readiness with pass/fail status. Optimised for Opus 4.7 and newer models."
|
||||
---
|
||||
|
||||
# Figma Design QA Skill
|
||||
@@ -9,7 +9,8 @@ Runs a systematic pre-handoff QA check on a Figma design — catching issues tha
|
||||
|
||||
## Required Inputs
|
||||
|
||||
- **Feature or screen being QA-d**
|
||||
Ask the user for these if not provided:
|
||||
- **Feature or screen being QA-d** (describe what has been designed)
|
||||
- **Platform** (iOS / Android / Web)
|
||||
- **Design system** (custom / Material / HIG / None)
|
||||
- **Handoff tool** (Figma Inspect / Zeplin / Storybook / Direct link)
|
||||
|
||||
@@ -1,54 +1,107 @@
|
||||
---
|
||||
name: compliance-checklist
|
||||
description: "Generate a compliance checklist for any regulation, standard, or policy. Use when asked to create a compliance checklist, regulatory review, audit checklist, or policy adherence review. Covers GDPR, ISO 27001, FCA, HIPAA, SOC 2, and other frameworks. Produces a prioritised checklist with pass/fail assessment and remediation actions."
|
||||
description: "Generate a prioritised compliance checklist for GDPR, SOC 2, ISO 27001, FCA, HIPAA, or other frameworks with a gap analysis. Use when asked for a compliance checklist, gap analysis, readiness assessment, or audit preparation for any regulatory framework. Produces a structured checklist with prioritised gaps, quick wins, and evidence requirements. Optimised for Opus 4.7 and newer models. Not a substitute for legal or compliance professional advice."
|
||||
---
|
||||
|
||||
# Compliance Checklist Skill
|
||||
|
||||
Generates a structured compliance checklist for any regulatory framework with a prioritised gap analysis and remediation actions.
|
||||
Produces a prioritised compliance checklist for any regulatory framework — with gap analysis, evidence requirements, and quick wins identified.
|
||||
|
||||
ALWAYS include this disclaimer at the start of every response:
|
||||
"WARNING: This checklist is for informational and planning purposes only and does not constitute legal or compliance advice. Regulatory requirements change and vary by jurisdiction. Always engage a qualified compliance professional or solicitor before implementing compliance programmes or making regulatory claims."
|
||||
|
||||
## Required Inputs
|
||||
- **Framework or regulation** (e.g. GDPR, HIPAA, SOC 2, ISO 27001, FCA Consumer Duty, PCI DSS)
|
||||
- **Organisation type** (e.g. SaaS company, financial services, NHS trust, law firm)
|
||||
- **Scope** (e.g. data handling, customer onboarding, IT security, HR processes)
|
||||
- **Known gaps or concerns** (optional)
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Framework** (GDPR / SOC 2 Type I or II / ISO 27001 / FCA / HIPAA / PCI DSS / other)
|
||||
- **Organisation type** (SaaS / fintech / healthcare / professional services / retail)
|
||||
- **Organisation size** (startup / scaleup / mid-market / enterprise)
|
||||
- **Current maturity** (no compliance programme / some controls / formal programme)
|
||||
- **Deadline or driver** (upcoming audit / customer requirement / regulatory change / proactive)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Framework Overview
|
||||
- **Regulation/Standard:** [Name and version]
|
||||
- **Enforcement body:** [Regulator]
|
||||
- **Overall compliance status:** Red Gaps / Amber Partial / Green Compliant
|
||||
|
||||
### 2. Compliance Checklist
|
||||
**Framework:** [Name with version]
|
||||
**Applicable because:** [One sentence — why this framework applies to this organisation]
|
||||
**Typical timeline to readiness:** [From current maturity to certified/compliant]
|
||||
**Key stakeholders needed:** [Roles that must be involved]
|
||||
|
||||
| # | Requirement | Status | Priority | Action Required |
|
||||
### 2. Scope Definition
|
||||
|
||||
What is in scope for this checklist:
|
||||
- [Specific systems / processes / data types]
|
||||
|
||||
What is NOT in scope (explicit exclusions):
|
||||
- [Specific exclusions]
|
||||
|
||||
### 3. Control Categories
|
||||
|
||||
For each category relevant to the framework:
|
||||
|
||||
**[Category — e.g. "Access Control"]**
|
||||
|
||||
| Control | Current State | Gap | Priority | Effort |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [Plain English requirement] | Met / Gap / Partial / Unknown | Critical / High / Low | [Specific action] |
|
||||
| [Specific control requirement] | Not implemented / Partial / Full | [What is missing] | High/Med/Low | Days/Weeks/Months |
|
||||
|
||||
Priority definitions:
|
||||
- Critical: Regulatory breach risk. Remediate immediately.
|
||||
- High: Significant gap. Address within 30 days.
|
||||
- Low: Best practice. Address in next review cycle.
|
||||
### 4. Gap Analysis Summary
|
||||
|
||||
### 3. Critical Gaps Summary
|
||||
List only Critical items with: what is missing, regulatory requirement breached, recommended remediation and owner.
|
||||
| Priority | Count | Examples |
|
||||
|---|---|---|
|
||||
| Critical gaps (block certification) | N | [Top 3] |
|
||||
| High priority gaps | N | |
|
||||
| Medium priority gaps | N | |
|
||||
| Quick wins | N | |
|
||||
|
||||
### 4. Recommended Remediation Plan
|
||||
### 5. Quick Wins
|
||||
|
||||
| Action | Owner | Timeline | Effort |
|
||||
|---|---|---|---|
|
||||
| [Specific action] | [Team/role] | [Timeframe] | Low/Med/High |
|
||||
Controls that can be implemented in under 2 weeks with minimal resources:
|
||||
|
||||
### 5. Documentation Gaps
|
||||
Policies, records, or evidence needed to demonstrate compliance.
|
||||
1. **[Control]** — [Specific action] — [Owner] — [Days to complete]
|
||||
|
||||
---
|
||||
### 6. Evidence Requirements
|
||||
|
||||
WARNING: This checklist is a starting point based on publicly available guidance. It does not constitute legal or compliance advice.
|
||||
For each control area, what documentation will be needed:
|
||||
|
||||
| Control area | Evidence types | Where to source |
|
||||
|---|---|---|
|
||||
| [Area] | [Policies, logs, screenshots, training records] | [System or team] |
|
||||
|
||||
### 7. Implementation Roadmap
|
||||
|
||||
Phase 1 (Weeks 1-4): Critical gaps and quick wins
|
||||
- [Specific deliverables]
|
||||
|
||||
Phase 2 (Weeks 5-12): High-priority gaps
|
||||
- [Specific deliverables]
|
||||
|
||||
Phase 3 (Weeks 13+): Medium priority and continuous improvement
|
||||
- [Specific deliverables]
|
||||
|
||||
### 8. Ongoing Maintenance
|
||||
|
||||
Once certified/compliant, what needs to continue:
|
||||
- [Review frequencies]
|
||||
- [Periodic testing requirements]
|
||||
- [Annual audit expectations]
|
||||
- [Staff training cadence]
|
||||
|
||||
### 9. Common Pitfalls for This Framework
|
||||
|
||||
2-3 specific traps organisations commonly fall into when pursuing this certification — flagged based on the stated maturity level.
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Disclaimer included at start
|
||||
- [ ] Framework-specific controls (not generic)
|
||||
- [ ] Priorities align with organisation size and maturity
|
||||
- [ ] Quick wins clearly separated from complex implementations
|
||||
- [ ] Evidence requirements tied to specific controls
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Create a GDPR compliance checklist for our SaaS product"
|
||||
- "Generate a SOC 2 audit checklist"
|
||||
- "Review our compliance against FCA Consumer Duty"
|
||||
- "Build an ISO 27001 gap analysis"
|
||||
- "Create a GDPR compliance checklist for our SaaS"
|
||||
- "Generate a SOC 2 Type II readiness checklist"
|
||||
- "What do we need for ISO 27001 certification?"
|
||||
- "FCA compliance checklist for a fintech startup"
|
||||
- "HIPAA gap analysis for a healthtech scaleup"
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: chart-data-extractor
|
||||
description: "Extract pixel-level data from an image of a chart or graph and produce a structured data table. Use when asked to extract data from a chart image, transcribe numbers from a graph, digitise a chart, or turn a screenshot of data into a table. Produces a structured table with extracted values, confidence levels, and a reconstructed chart source. Best used with Claude Opus 4.7 or newer for reliable chart data extraction."
|
||||
---
|
||||
|
||||
# Chart Data Extractor Skill
|
||||
|
||||
Extracts data from images of charts and graphs — bar charts, line charts, pie charts, scatter plots, and tables in images — producing a structured data table that can be used in spreadsheets or rebuilt in any charting tool. Built to leverage Opus 4.7 pixel-level image analysis capabilities.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **The chart image** (upload a screenshot or image file)
|
||||
- **Chart type** (if ambiguous — bar / line / pie / scatter / other)
|
||||
- **What matters most** (approximate trends / precise values / specific data points / categorisation)
|
||||
- **Known axis values** (optional — if the user knows the max/min values to anchor the extraction)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Chart Identification
|
||||
|
||||
| Attribute | Value |
|
||||
|---|---|
|
||||
| Chart type | [Bar / Line / Pie / Scatter / Area / Other] |
|
||||
| Chart title (if visible) | [Title text] |
|
||||
| X-axis label | [Label + unit] |
|
||||
| Y-axis label | [Label + unit] |
|
||||
| Number of series | N |
|
||||
| Legend categories | [List] |
|
||||
| Data period (if time-based) | [Start — End] |
|
||||
|
||||
### 2. Extracted Data Table
|
||||
|
||||
| [X axis] | [Series 1] | [Series 2] | ... |
|
||||
|---|---|---|---|
|
||||
| [Value] | [Value] | [Value] | |
|
||||
|
||||
### 3. Confidence Levels
|
||||
|
||||
For each data point or series, flag confidence:
|
||||
|
||||
- **High confidence:** data points where the value is clearly readable against gridlines or labels
|
||||
- **Medium confidence:** data points where the value is interpolated between gridlines
|
||||
- **Low confidence:** data points where the value is ambiguous or overlaps with other elements
|
||||
|
||||
Low-confidence points should be explicitly listed — not silently included in the main table.
|
||||
|
||||
### 4. Notable Observations
|
||||
|
||||
Observations that the data itself reveals:
|
||||
- Peak value: [Value, when, in which series]
|
||||
- Lowest value: [Value, when, in which series]
|
||||
- Largest delta between series: [Details]
|
||||
- Any anomalies or outliers visible in the chart
|
||||
|
||||
### 5. Reconstructed Source
|
||||
|
||||
CSV format for direct use:
|
||||
|
||||
```csv
|
||||
[x_axis],[series_1],[series_2]
|
||||
[value],[value],[value]
|
||||
```
|
||||
|
||||
### 6. Assumptions and Caveats
|
||||
|
||||
- Grid resolution: [How precisely values could be read — e.g. "Y-axis has major gridlines every 10 units, minor every 2"]
|
||||
- Interpolation used: [Any values that required estimating between gridlines]
|
||||
- Unclear data: [Anything in the chart that could not be read reliably]
|
||||
- Axis scale: [Linear/logarithmic/etc — note if not obvious]
|
||||
|
||||
### 7. Follow-up Options
|
||||
|
||||
Ask the user which of these they want:
|
||||
- Rebuild the chart in a specified format (Excel formula, Python matplotlib, D3, etc.)
|
||||
- Produce a narrative description of what the chart shows
|
||||
- Compare this data against another chart or source
|
||||
- Flag potentially misleading visual choices in the original (truncated axes, misleading scales, etc.)
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Every extracted number specifies which series it belongs to
|
||||
- [ ] Confidence levels are explicit for ambiguous points
|
||||
- [ ] Low-confidence values are flagged separately, not silently included
|
||||
- [ ] Assumptions about axis scale and interpolation are stated
|
||||
- [ ] CSV output is clean and directly usable
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Extract the data from this chart"
|
||||
- "Transcribe the numbers in this graph"
|
||||
- "Turn this chart image into a spreadsheet"
|
||||
- "Digitise this chart so I can rebuild it"
|
||||
- "What are the exact values in this bar chart?"
|
||||
|
||||
## Why This Works Better on Opus 4.7
|
||||
Earlier models struggled with pixel-level data transcription from charts, often hallucinating values or misreading gridline positions. Opus 4.7 uses a higher image resolution (2576px vs 1568px) with coordinates mapping 1:1 to pixels, making chart data extraction reliable for practical use.
|
||||
@@ -1,114 +1,107 @@
|
||||
---
|
||||
name: code-review-checklist
|
||||
description: "Generate a tailored code review checklist for any PR, language, or risk level. Use when asked to create a code review checklist, review guidelines, PR standards, or quality gates for a codebase. Produces a structured, prioritised checklist adapted to the specific language, PR type, and risk level."
|
||||
description: "Generate a tailored code review checklist for any pull request based on the language, type of change, and risk level. Use when asked to review code, check a PR, review a pull request, or generate a code review checklist. Produces a focused checklist with language-specific checks, risk-level-appropriate depth, and a clear approve/request-changes recommendation. Optimised for Opus 4.7 and newer models."
|
||||
---
|
||||
|
||||
# Code Review Checklist Skill
|
||||
|
||||
This skill generates a structured, prioritised code review checklist tailored to a specific PR, language, and risk level. It helps reviewers be thorough without being bureaucratic.
|
||||
Produces a tailored code review checklist for a specific pull request — scaled to the language, type of change, and risk level. Not a generic template.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Programming language(s)** (e.g. Python, TypeScript, Go, Java)
|
||||
- **PR type** (new feature / bug fix / refactor / performance improvement / security patch / infrastructure change)
|
||||
- **Risk level** (Low: internal tooling, Low traffic / Medium: user-facing feature / High: payment, auth, data pipeline, public API)
|
||||
- **Team context** (optional: team size, seniority mix, any known recurring issues)
|
||||
- **Language and framework** (e.g. TypeScript + React / Python + FastAPI / Go)
|
||||
- **Type of change** (feature / bug fix / refactor / dependency upgrade / security patch / performance)
|
||||
- **Risk level** (low / medium / high / critical)
|
||||
- **PR description** (paste the description or link to the PR)
|
||||
- **Author context** (new starter / experienced / external contributor)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Checklist Header
|
||||
### 1. Review Summary
|
||||
**PR:** [Title or reference]
|
||||
**Scope assessment:** [Small / Medium / Large / Too large — should be split]
|
||||
**Recommended review depth:** [Skim / Standard / Deep dive]
|
||||
**Estimated review time:** [Minutes]
|
||||
|
||||
**PR:** [Title if provided]
|
||||
**Language:** [Language]
|
||||
**Type:** [PR Type]
|
||||
**Risk Level:** [Low / Medium / High]
|
||||
**Estimated review depth:** [Quick scan ~15 min / Standard ~30 min / Deep review ~60 min+]
|
||||
### 2. Correctness Checks
|
||||
|
||||
---
|
||||
Language-specific correctness checks — choose based on the language stated:
|
||||
|
||||
### 2. The Checklist
|
||||
**For TypeScript/JavaScript:**
|
||||
- Type definitions match actual usage
|
||||
- No implicit `any` in non-test code
|
||||
- Async/await used consistently; no unhandled promises
|
||||
- Null/undefined handling is explicit
|
||||
|
||||
Organise into sections. Mark each item with a priority indicator:
|
||||
- 🔴 **MUST** — Blocking. PR should not merge without this.
|
||||
- 🟡 **SHOULD** — Important. Address before merge unless there's a good reason not to.
|
||||
- 🟢 **CONSIDER** — Nice to have. Worth a comment but not blocking.
|
||||
**For Python:**
|
||||
- Type hints present on public functions
|
||||
- Exception handling is specific (no bare except)
|
||||
- Resources are closed (context managers, with blocks)
|
||||
|
||||
#### Section A: Correctness
|
||||
- 🔴 Does the code do what the ticket/requirement describes?
|
||||
- 🔴 Are edge cases handled? (nulls, empty arrays, zero values, max values)
|
||||
- 🔴 Are error states handled and surfaced appropriately?
|
||||
- 🟡 Does the happy path have adequate test coverage?
|
||||
- 🟡 Are failure paths tested?
|
||||
**For Go:**
|
||||
- Errors are handled or explicitly ignored with a comment
|
||||
- Context propagation is correct
|
||||
- Goroutine lifetimes are bounded
|
||||
|
||||
#### Section B: Security (scale with risk level — expand for High risk PRs)
|
||||
- 🔴 [High risk only] Is user input sanitised before use in queries or commands?
|
||||
- 🔴 [High risk only] Are auth/permission checks in place?
|
||||
- 🟡 Are secrets/credentials committed anywhere? (check .env handling)
|
||||
- 🟡 Are third-party dependencies known-safe versions?
|
||||
[Include only the section matching the stated language]
|
||||
|
||||
#### Section C: Performance
|
||||
- 🟡 Are there N+1 query patterns in database calls?
|
||||
- 🟡 Is there unnecessary work inside loops?
|
||||
- 🟢 Are database queries indexed appropriately?
|
||||
- 🟢 Is caching considered where appropriate?
|
||||
### 3. Change-Type-Specific Checks
|
||||
|
||||
#### Section D: Readability & Maintainability
|
||||
- 🟡 Are function and variable names clear without needing a comment to explain them?
|
||||
- 🟡 Are complex logic blocks explained with inline comments?
|
||||
- 🟢 Is the code consistent with existing patterns in the codebase?
|
||||
- 🟢 Are there any magic numbers that should be named constants?
|
||||
**For bug fixes:**
|
||||
- A test exists that would have caught this bug
|
||||
- The fix addresses root cause, not symptom
|
||||
- Related code paths checked for the same issue
|
||||
|
||||
#### Section E: Language-Specific Checks
|
||||
[Populate this section based on the specified language. Examples below:]
|
||||
**For features:**
|
||||
- Acceptance criteria met
|
||||
- Edge cases handled (empty, large, concurrent)
|
||||
- Error paths tested, not just happy path
|
||||
- Telemetry/logging added for debugging
|
||||
|
||||
**Python:**
|
||||
- 🟡 Are type hints used on function signatures?
|
||||
- 🟡 Are exceptions caught specifically (not bare `except:`)?
|
||||
- 🟢 Does it follow PEP 8 (or the team's linter config)?
|
||||
**For refactors:**
|
||||
- Behaviour unchanged (tests still pass)
|
||||
- No scope creep — refactor only
|
||||
- Complexity reduced, not just moved
|
||||
|
||||
**TypeScript/JavaScript:**
|
||||
- 🔴 Are there any `any` types that should be properly typed?
|
||||
- 🟡 Are async/await patterns used consistently (no mixed Promise.then chains)?
|
||||
- 🟢 Are there unnecessary re-renders in React components?
|
||||
**For dependency upgrades:**
|
||||
- Breaking changes reviewed
|
||||
- Security advisories checked
|
||||
- License compatibility verified
|
||||
|
||||
**Go:**
|
||||
- 🔴 Are errors checked (not ignored with `_`)?
|
||||
- 🟡 Are goroutines properly managed to prevent leaks?
|
||||
- 🟢 Are exported functions documented?
|
||||
[Include only the section matching the stated change type]
|
||||
|
||||
#### Section F: PR Hygiene
|
||||
- 🟡 Is the PR a reasonable size? (>500 lines diff suggests it should be split)
|
||||
- 🟡 Does the PR description explain *why*, not just *what*?
|
||||
- 🟢 Are there linked tickets or context in the PR description?
|
||||
- 🟢 Are migration scripts or deployment notes included if needed?
|
||||
### 4. Risk-Appropriate Checks
|
||||
|
||||
---
|
||||
**Low risk:** basic correctness, style conventions, test coverage
|
||||
**Medium risk:** above + rollback plan, monitoring updates, performance considerations
|
||||
**High risk:** above + security implications, data migration safety, feature flag/gradual rollout
|
||||
**Critical risk:** above + staging validation plan, incident response plan, post-deploy verification checklist
|
||||
|
||||
### 3. Risk-Specific Additions
|
||||
### 5. Testing Adequacy
|
||||
- Unit tests cover new logic
|
||||
- Integration tests cover the contract changes
|
||||
- Edge cases tested
|
||||
- Failure modes tested
|
||||
- Performance tests if performance-sensitive
|
||||
|
||||
For **High risk** PRs, always add:
|
||||
- 🔴 Has this been tested in a staging environment?
|
||||
- 🔴 Is there a rollback plan?
|
||||
- 🔴 Has a second reviewer been assigned?
|
||||
### 6. Review Decision Framework
|
||||
|
||||
For **Infrastructure / DB changes**, always add:
|
||||
- 🔴 Are migrations backward-compatible?
|
||||
- 🔴 Has the migration been tested against production data volume?
|
||||
**Approve if:** [2-3 specific conditions based on this PR]
|
||||
**Request changes if:** [Specific blockers]
|
||||
**Comment (non-blocking) if:** [Items worth discussing but not blocking merge]
|
||||
|
||||
---
|
||||
### 7. Common Pitfalls for This Change Type
|
||||
Based on the change type and language, flag 2-3 things reviewers typically miss for this combination.
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Checklist is tailored to the specified language (not generic)
|
||||
- [ ] Risk level is reflected in the MUST vs SHOULD balance
|
||||
- [ ] Language-specific section covers the most common issues for that language
|
||||
- [ ] PR hygiene section is always present
|
||||
- [ ] High-risk additions are included when risk level = High
|
||||
- [ ] Checklist is tailored to the stated language (not generic)
|
||||
- [ ] Change-type-specific section is included
|
||||
- [ ] Risk-appropriate depth matches stated risk level
|
||||
- [ ] Decision framework is explicit
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Generate a code review checklist for a Python bug fix PR"
|
||||
- "Give me a review checklist for a high-risk TypeScript auth change"
|
||||
- "What should I check in this Go PR?"
|
||||
- "Create PR review standards for our team"
|
||||
- "Generate a code review checklist for [PR description]"
|
||||
- "What should I check in this pull request?"
|
||||
- "Give me a code review checklist for a [language] [change type]"
|
||||
- "Review checklist for a high-risk PR in [language]"
|
||||
@@ -1,54 +1,107 @@
|
||||
---
|
||||
name: compliance-checklist
|
||||
description: "Generate a compliance checklist for any regulation, standard, or policy. Use when asked to create a compliance checklist, regulatory review, audit checklist, or policy adherence review. Covers GDPR, ISO 27001, FCA, HIPAA, SOC 2, and other frameworks. Produces a prioritised checklist with pass/fail assessment and remediation actions."
|
||||
description: "Generate a prioritised compliance checklist for GDPR, SOC 2, ISO 27001, FCA, HIPAA, or other frameworks with a gap analysis. Use when asked for a compliance checklist, gap analysis, readiness assessment, or audit preparation for any regulatory framework. Produces a structured checklist with prioritised gaps, quick wins, and evidence requirements. Optimised for Opus 4.7 and newer models. Not a substitute for legal or compliance professional advice."
|
||||
---
|
||||
|
||||
# Compliance Checklist Skill
|
||||
|
||||
Generates a structured compliance checklist for any regulatory framework with a prioritised gap analysis and remediation actions.
|
||||
Produces a prioritised compliance checklist for any regulatory framework — with gap analysis, evidence requirements, and quick wins identified.
|
||||
|
||||
ALWAYS include this disclaimer at the start of every response:
|
||||
"WARNING: This checklist is for informational and planning purposes only and does not constitute legal or compliance advice. Regulatory requirements change and vary by jurisdiction. Always engage a qualified compliance professional or solicitor before implementing compliance programmes or making regulatory claims."
|
||||
|
||||
## Required Inputs
|
||||
- **Framework or regulation** (e.g. GDPR, HIPAA, SOC 2, ISO 27001, FCA Consumer Duty, PCI DSS)
|
||||
- **Organisation type** (e.g. SaaS company, financial services, NHS trust, law firm)
|
||||
- **Scope** (e.g. data handling, customer onboarding, IT security, HR processes)
|
||||
- **Known gaps or concerns** (optional)
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Framework** (GDPR / SOC 2 Type I or II / ISO 27001 / FCA / HIPAA / PCI DSS / other)
|
||||
- **Organisation type** (SaaS / fintech / healthcare / professional services / retail)
|
||||
- **Organisation size** (startup / scaleup / mid-market / enterprise)
|
||||
- **Current maturity** (no compliance programme / some controls / formal programme)
|
||||
- **Deadline or driver** (upcoming audit / customer requirement / regulatory change / proactive)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Framework Overview
|
||||
- **Regulation/Standard:** [Name and version]
|
||||
- **Enforcement body:** [Regulator]
|
||||
- **Overall compliance status:** Red Gaps / Amber Partial / Green Compliant
|
||||
|
||||
### 2. Compliance Checklist
|
||||
**Framework:** [Name with version]
|
||||
**Applicable because:** [One sentence — why this framework applies to this organisation]
|
||||
**Typical timeline to readiness:** [From current maturity to certified/compliant]
|
||||
**Key stakeholders needed:** [Roles that must be involved]
|
||||
|
||||
| # | Requirement | Status | Priority | Action Required |
|
||||
### 2. Scope Definition
|
||||
|
||||
What is in scope for this checklist:
|
||||
- [Specific systems / processes / data types]
|
||||
|
||||
What is NOT in scope (explicit exclusions):
|
||||
- [Specific exclusions]
|
||||
|
||||
### 3. Control Categories
|
||||
|
||||
For each category relevant to the framework:
|
||||
|
||||
**[Category — e.g. "Access Control"]**
|
||||
|
||||
| Control | Current State | Gap | Priority | Effort |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [Plain English requirement] | Met / Gap / Partial / Unknown | Critical / High / Low | [Specific action] |
|
||||
| [Specific control requirement] | Not implemented / Partial / Full | [What is missing] | High/Med/Low | Days/Weeks/Months |
|
||||
|
||||
Priority definitions:
|
||||
- Critical: Regulatory breach risk. Remediate immediately.
|
||||
- High: Significant gap. Address within 30 days.
|
||||
- Low: Best practice. Address in next review cycle.
|
||||
### 4. Gap Analysis Summary
|
||||
|
||||
### 3. Critical Gaps Summary
|
||||
List only Critical items with: what is missing, regulatory requirement breached, recommended remediation and owner.
|
||||
| Priority | Count | Examples |
|
||||
|---|---|---|
|
||||
| Critical gaps (block certification) | N | [Top 3] |
|
||||
| High priority gaps | N | |
|
||||
| Medium priority gaps | N | |
|
||||
| Quick wins | N | |
|
||||
|
||||
### 4. Recommended Remediation Plan
|
||||
### 5. Quick Wins
|
||||
|
||||
| Action | Owner | Timeline | Effort |
|
||||
|---|---|---|---|
|
||||
| [Specific action] | [Team/role] | [Timeframe] | Low/Med/High |
|
||||
Controls that can be implemented in under 2 weeks with minimal resources:
|
||||
|
||||
### 5. Documentation Gaps
|
||||
Policies, records, or evidence needed to demonstrate compliance.
|
||||
1. **[Control]** — [Specific action] — [Owner] — [Days to complete]
|
||||
|
||||
---
|
||||
### 6. Evidence Requirements
|
||||
|
||||
WARNING: This checklist is a starting point based on publicly available guidance. It does not constitute legal or compliance advice.
|
||||
For each control area, what documentation will be needed:
|
||||
|
||||
| Control area | Evidence types | Where to source |
|
||||
|---|---|---|
|
||||
| [Area] | [Policies, logs, screenshots, training records] | [System or team] |
|
||||
|
||||
### 7. Implementation Roadmap
|
||||
|
||||
Phase 1 (Weeks 1-4): Critical gaps and quick wins
|
||||
- [Specific deliverables]
|
||||
|
||||
Phase 2 (Weeks 5-12): High-priority gaps
|
||||
- [Specific deliverables]
|
||||
|
||||
Phase 3 (Weeks 13+): Medium priority and continuous improvement
|
||||
- [Specific deliverables]
|
||||
|
||||
### 8. Ongoing Maintenance
|
||||
|
||||
Once certified/compliant, what needs to continue:
|
||||
- [Review frequencies]
|
||||
- [Periodic testing requirements]
|
||||
- [Annual audit expectations]
|
||||
- [Staff training cadence]
|
||||
|
||||
### 9. Common Pitfalls for This Framework
|
||||
|
||||
2-3 specific traps organisations commonly fall into when pursuing this certification — flagged based on the stated maturity level.
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Disclaimer included at start
|
||||
- [ ] Framework-specific controls (not generic)
|
||||
- [ ] Priorities align with organisation size and maturity
|
||||
- [ ] Quick wins clearly separated from complex implementations
|
||||
- [ ] Evidence requirements tied to specific controls
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Create a GDPR compliance checklist for our SaaS product"
|
||||
- "Generate a SOC 2 audit checklist"
|
||||
- "Review our compliance against FCA Consumer Duty"
|
||||
- "Build an ISO 27001 gap analysis"
|
||||
- "Create a GDPR compliance checklist for our SaaS"
|
||||
- "Generate a SOC 2 Type II readiness checklist"
|
||||
- "What do we need for ISO 27001 certification?"
|
||||
- "FCA compliance checklist for a fintech startup"
|
||||
- "HIPAA gap analysis for a healthtech scaleup"
|
||||
@@ -0,0 +1,121 @@
|
||||
---
|
||||
name: docx-tracked-changes
|
||||
description: "Produce properly-formatted tracked changes for a Word document. Use when asked to redline a document, suggest edits to a contract or document, create tracked changes for review, or mark up a document with proposed revisions. Produces a complete redline with insertions, deletions, and margin comments that can be applied to the source document. Best used with Claude Opus 4.7 or newer for reliable tracked changes handling."
|
||||
---
|
||||
|
||||
# Word Doc Tracked Changes Skill
|
||||
|
||||
Produces properly-structured tracked changes for a Word document — insertions, deletions, replacements, and margin comments formatted so they can be applied directly to the source document. Built to leverage Opus 4.7 improvements in .docx redlining and tracked changes generation.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **The document** (paste the text or upload the .docx)
|
||||
- **Review type** (legal review / copy edit / substantive rewrite / compliance check / plain English rewrite)
|
||||
- **Review scope** (full document / specific sections / specific clause type)
|
||||
- **Reviewer role** (author / manager / legal counsel / subject matter expert)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Redline Summary
|
||||
|
||||
**Document:** [Name or identifier]
|
||||
**Review type:** [As stated]
|
||||
**Reviewer:** [Role]
|
||||
**Total changes:** [Insertions: N / Deletions: N / Comments: N]
|
||||
**Overall assessment:** [1-2 sentences — is this document close to final, or does it need substantial revision?]
|
||||
|
||||
### 2. Top-Level Changes
|
||||
|
||||
Changes that affect the meaning or structure of the document:
|
||||
|
||||
**Change N — [Section or paragraph reference]**
|
||||
- Original: "[Exact original text]"
|
||||
- Suggested: "[Proposed new text]"
|
||||
- Reason: [Why this change — substantive/legal/clarity]
|
||||
|
||||
### 3. Line-by-Line Tracked Changes
|
||||
|
||||
For each paragraph that needs changes, format as:
|
||||
|
||||
**[Paragraph reference — e.g. "Section 3, Paragraph 2"]**
|
||||
|
||||
Original:
|
||||
> [Exact original paragraph]
|
||||
|
||||
Tracked changes:
|
||||
> [Same paragraph with deletions marked as ~~strikethrough~~ and insertions marked as **bold**]
|
||||
|
||||
Clean version:
|
||||
> [Final clean text after applying changes]
|
||||
|
||||
### 4. Margin Comments
|
||||
|
||||
Comments that flag issues without proposing a specific wording change:
|
||||
|
||||
**Comment N — [Location]**
|
||||
"[Comment text — written as the reviewer would write it. Direct, specific, actionable.]"
|
||||
|
||||
Comments are for things like:
|
||||
- "This clause conflicts with Section 7 — please reconcile"
|
||||
- "Missing definition of [term] used throughout"
|
||||
- "Confirm figure with finance team"
|
||||
|
||||
### 5. Stylistic Edits
|
||||
|
||||
Line-level stylistic changes (if scope includes copy editing):
|
||||
|
||||
| Location | Before | After | Reason |
|
||||
|---|---|---|---|
|
||||
| Para 3 | [Text] | [Text] | [Readability/grammar/consistency] |
|
||||
|
||||
### 6. Pattern Flags
|
||||
|
||||
Issues that repeat across the document:
|
||||
|
||||
**[Pattern — e.g. "Passive voice overuse"]**
|
||||
- Instances: [count]
|
||||
- Examples: [2-3 specific locations]
|
||||
- Suggested approach: [How to address]
|
||||
|
||||
### 7. Review Completeness
|
||||
|
||||
| Review dimension | Covered |
|
||||
|---|---|
|
||||
| Grammar and syntax | Yes / No |
|
||||
| Clarity and readability | Yes / No |
|
||||
| Substantive accuracy | Yes / No / N/A |
|
||||
| Compliance/legal check | Yes / No / N/A |
|
||||
| Consistency with referenced documents | Yes / No / N/A |
|
||||
|
||||
### 8. How to Apply These Changes
|
||||
|
||||
Instructions for applying the redline:
|
||||
|
||||
**In Microsoft Word:**
|
||||
1. Enable Track Changes (Review tab → Track Changes)
|
||||
2. Apply the changes from Section 3 in order
|
||||
3. Add comments from Section 4 using Review → New Comment
|
||||
4. Send the redlined document back to the reviewer
|
||||
|
||||
**In Google Docs:**
|
||||
1. Switch to Suggesting mode (top right pencil icon)
|
||||
2. Apply the changes from Section 3
|
||||
3. Add comments using the comment button in the margin
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Every tracked change has the original text preserved exactly
|
||||
- [ ] Substantive changes are separated from stylistic changes
|
||||
- [ ] Comments are written as the reviewer would write them, not meta-commentary
|
||||
- [ ] Pattern issues identified separately from individual changes
|
||||
- [ ] Application instructions match the target platform
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Redline this contract"
|
||||
- "Create tracked changes for this document"
|
||||
- "Mark up this document with proposed edits"
|
||||
- "Review this and suggest changes in tracked changes format"
|
||||
- "Give me a redline version of this draft"
|
||||
|
||||
## Why This Works Better on Opus 4.7
|
||||
Tracked changes require the model to preserve source text exactly while suggesting alternatives — earlier models would paraphrase the original or lose track of which text was original vs suggested. Opus 4.7 improvements specifically target this workflow.
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: figma-design-qa
|
||||
description: "Run a pre-handoff QA checklist on any Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, review a design before engineering, or validate a Figma file is ready to build. Produces a structured QA checklist covering file hygiene, component usage, accessibility, and handoff readiness with pass/fail status."
|
||||
description: "Run a pre-handoff QA checklist on any Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, review a design before engineering, or validate a Figma file is ready to build. Produces a structured QA checklist covering file hygiene, component usage, accessibility, and handoff readiness with pass/fail status. Optimised for Opus 4.7 and newer models."
|
||||
---
|
||||
|
||||
# Figma Design QA Skill
|
||||
@@ -9,7 +9,8 @@ Runs a systematic pre-handoff QA check on a Figma design — catching issues tha
|
||||
|
||||
## Required Inputs
|
||||
|
||||
- **Feature or screen being QA-d**
|
||||
Ask the user for these if not provided:
|
||||
- **Feature or screen being QA-d** (describe what has been designed)
|
||||
- **Platform** (iOS / Android / Web)
|
||||
- **Design system** (custom / Material / HIG / None)
|
||||
- **Handoff tool** (Figma Inspect / Zeplin / Storybook / Direct link)
|
||||
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
name: pptx-slide-auditor
|
||||
description: "Audit a PowerPoint presentation for layout issues, text overflow, visual hierarchy problems, and consistency gaps. Use when asked to review a slide deck, check a presentation before a meeting, audit slides for layout problems, or QA a deck before sharing. Produces a slide-by-slide report with issues ranked by severity and specific fixes. Best used with Claude Opus 4.7 or newer for reliable slide-level vision analysis."
|
||||
---
|
||||
|
||||
# PPTX Slide Auditor Skill
|
||||
|
||||
Runs a systematic visual and structural audit of a PowerPoint presentation — identifying layout issues, text overflow, inconsistent styling, weak visual hierarchy, and slides that will cause problems in a presentation setting. Built to leverage Opus 4.7 vision improvements for pixel-level layout analysis.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **The deck** (upload the .pptx file or individual slide screenshots)
|
||||
- **Audience** (internal team / executive / external client / conference / investor)
|
||||
- **Presentation mode** (presented live / sent to read / shared async on video)
|
||||
- **Areas of concern** (optional — e.g. "I think slide 12 is overcrowded")
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Deck Overview
|
||||
| Metric | Result |
|
||||
|---|---|
|
||||
| Total slides | N |
|
||||
| Overall status | Ready / Minor fixes needed / Major revisions required |
|
||||
| Readability score | /10 |
|
||||
| Visual consistency score | /10 |
|
||||
| Most common issue | [Pattern observed across multiple slides] |
|
||||
|
||||
### 2. Slide-by-Slide Audit
|
||||
|
||||
For each slide with issues:
|
||||
|
||||
**Slide N: [Slide title]**
|
||||
- Status: Ready / Fix before sending / Major revision
|
||||
- Issues found:
|
||||
- [Specific issue with exact location — e.g. "Body text extends beyond the text frame on the right side"]
|
||||
- [Issue 2]
|
||||
- Suggested fix: [Specific action — move element, reduce text, resize]
|
||||
|
||||
Slides with no issues: just list the slide numbers. Do not write anything else about them.
|
||||
|
||||
### 3. Pattern Issues Across the Deck
|
||||
|
||||
Issues that repeat across multiple slides:
|
||||
|
||||
**[Pattern title — e.g. "Inconsistent body text size"]**
|
||||
- Slides affected: [list]
|
||||
- Root cause: [master slide issue / manual overrides / mixed templates]
|
||||
- Fix: [Single action to resolve across all affected slides]
|
||||
|
||||
### 4. Visual Hierarchy Check
|
||||
|
||||
| Dimension | Status | Notes |
|
||||
|---|---|---|
|
||||
| Title consistency (size, font, colour) | Pass / Fail | |
|
||||
| Body text readability at presentation distance | Pass / Fail | |
|
||||
| Image placement alignment | Pass / Fail | |
|
||||
| Whitespace and breathing room | Pass / Fail | |
|
||||
| Data visualisation clarity | Pass / Fail / N/A | |
|
||||
|
||||
### 5. Audience-Specific Flags
|
||||
|
||||
Based on the stated audience:
|
||||
|
||||
- **Executive audience:** flag slides with too much text, complex tables, or unclear bottom-line messages
|
||||
- **External client:** flag slides with internal jargon, unfinished placeholder text, or confidentiality concerns
|
||||
- **Live presentation:** flag slides that will be hard to read from the back of a room
|
||||
- **Async/video:** flag slides that assume a presenter voiceover
|
||||
|
||||
### 6. Prioritised Fix List
|
||||
|
||||
| # | Fix | Slide | Effort | Impact |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [Specific fix] | Slide N | Low/Med/High | High |
|
||||
|
||||
Order by: fixes before handoff (critical) > consistency fixes (high) > polish (medium).
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Every issue references a specific slide number and location on the slide
|
||||
- [ ] Pattern issues are identified separately from slide-specific issues
|
||||
- [ ] Fix list is ordered by impact, not by slide order
|
||||
- [ ] Audience-appropriate concerns flagged explicitly
|
||||
- [ ] Slides without issues are listed briefly, not ignored
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Audit this slide deck before my board meeting"
|
||||
- "Review this PowerPoint for layout issues"
|
||||
- "Check this presentation for consistency problems"
|
||||
- "QA my deck before I send it to the client"
|
||||
- "What is wrong with slide 7 in this deck?"
|
||||
|
||||
## Why This Works Better on Opus 4.7
|
||||
Earlier models struggled with precise spatial analysis of slide layouts — they would hallucinate issues or miss obvious overflow problems. Opus 4.7 vision improvements mean coordinates map 1:1 to pixels, making slide-level issue detection reliable without manual screenshot annotation.
|
||||
Reference in New Issue
Block a user