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
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.
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]"
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"
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.
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)
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.