justin/pm-claude-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Opus 4.7 release — 3 new vision/document skills, 3 updated skills (v5.2.0, 93 skills)

Browse Source
This commit is contained in:
mohitagw15856
2026-04-17 12:07:27 +01:00
parent 7dbf5a47a3
commit 34b0f780e6
19 changed files with 1113 additions and 326 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plugins/.DS_Store
Vendored
BIN
View File
Binary file not shown.
plugins/create-plugin-json-pm-figma.sh
Executable
+36
View File
@@ -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"
plugins/pm-data/skills/chart-data-extractor/SKILL.md
+95
View File
@@ -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.
plugins/pm-delivery/.DS_Store
Vendored
BIN
View File
Binary file not shown.
plugins/pm-delivery/skills/.DS_Store
Vendored
BIN
View File
Binary file not shown.
plugins/pm-delivery/skills/pptx-slide-auditor/SKILL.md
+93
View File
@@ -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.
plugins/pm-engineering/skills/code-review-checklist/SKILL.md
+72 -79
View File
@@ -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]"
plugins/pm-essentials/skills/docx-tracked-changes/SKILL.md
+121
View File
@@ -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.
plugins/pm-figma/skills/figma-design-qa/SKILL.md
+3 -2
View File
@@ -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)
plugins/pm-legal/skills/compliance-checklist/SKILL.md
+83 -30
View File
@@ -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"