fix(skills): add Anti-Patterns and fix descriptions for remaining skills (batch 3)
Processed 27 skills: teaching-lesson-plan through feature-prioritisation and all figma skills. Added Anti-Patterns sections to all 27 skills. Added Quality Checks section to financial-due-diligence (was missing entirely). Converted user-research-synthesis Quality Standards to binary checkbox format. Rewrote descriptions for figma-design-critique-pm, figma-design-qa, figma-design-review, team-health-check, and user-interview-synthesis. https://claude.ai/code/session_01MuGKn3a3Gbqoe8uM5Lmuqt
This commit is contained in:
Mohit
@@ -118,3 +118,11 @@ Recommend building: all Basic features first → Performance features for key us
|
||||
- [ ] Assumptions used in scoring are documented
|
||||
- [ ] Stakeholder politics or personal preferences are separated from framework score
|
||||
- [ ] Prioritisation is anchored to a specific scope (sprint / quarter / launch)
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not score items against different goals — every item in a prioritisation session must be scored against the same objective
|
||||
- [ ] Do not omit deprioritised items — explicitly listing what was cut and why is as important as the ranked list
|
||||
- [ ] Do not let stakeholder politics override framework scores without documenting the override and reason
|
||||
- [ ] Do not mix RICE, ICE, or MoSCoW scores across frameworks in a single session — pick one framework per prioritisation exercise
|
||||
- [ ] Do not treat the output as final without documenting the assumptions used in scoring — assumptions change, and the list must be revisitable
|
||||
|
||||
@@ -56,6 +56,14 @@ Touch targets, screen reader labels, focus order, colour contrast, motion prefer
|
||||
- [ ] Empty states specified
|
||||
- [ ] Edge cases listed as actionable questions
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not annotate only the happy path — error states, loading states, and empty states must all be documented
|
||||
- [ ] Do not use vague spacing descriptions like "some padding" — specify exact pixel values or token names
|
||||
- [ ] Do not skip accessibility annotations — focus order, ARIA labels, and colour contrast ratios must be included
|
||||
- [ ] Do not leave interaction behaviour undescribed — every interactive element needs a documented response
|
||||
- [ ] Do not produce annotations without edge cases — developers need to know what happens at boundaries
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write dev annotations for this Figma screen"
|
||||
- "Create developer handoff notes for [screen/component]"
|
||||
|
||||
@@ -66,6 +66,14 @@ Naming convention to enforce:
|
||||
- [ ] Fix plan is ordered by impact-to-effort ratio
|
||||
- [ ] Variant completeness covers all interactive states
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not flag naming issues without providing a specific, consistent naming convention to adopt
|
||||
- [ ] Do not audit only visual consistency — also check for missing interactive states and accessibility compliance
|
||||
- [ ] Do not list all issues at equal priority — group by impact (Critical / Major / Minor) so the fix plan is actionable
|
||||
- [ ] Do not omit variant completeness — every interactive component must cover all required states
|
||||
- [ ] Do not leave coverage gaps without recommending specific missing components to add
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Audit my Figma component library"
|
||||
- "Review our design system for consistency issues"
|
||||
|
||||
@@ -60,6 +60,14 @@ Feature, PM, Designer, Platform, Design due, Dev handoff dates.
|
||||
- [ ] Constraints include accessibility requirements
|
||||
- [ ] Open questions have owners
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write a design brief that describes the solution — the brief must describe the problem and constraints, not the design answer
|
||||
- [ ] Do not skip the success criteria — designers need to know what "done" looks like before starting
|
||||
- [ ] Do not omit existing components to reuse — briefs that ignore the design system lead to inconsistent implementations
|
||||
- [ ] Do not leave open questions unresolved — escalate them before design work starts, not during it
|
||||
- [ ] Do not confuse requirements with design instructions — the brief defines what, not how
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a design brief for [feature]"
|
||||
- "Turn this PRD into a Figma design brief"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: figma-design-critique-pm
|
||||
description: "Run a PM-perspective design critique focused on product outcomes, user goals, and business requirements — not aesthetics. Use when asked for a PM design critique, a product review of a design, feedback on a Figma design from a product perspective, or when you want to critique a design without being a designer. Produces structured outcome-based feedback tied to user goals and business metrics."
|
||||
description: "Runs a PM-perspective design critique focused on product outcomes and user goals, not aesthetics. Use when asked for a PM design critique, a product review of a Figma design, or feedback from a product perspective without needing to be a designer. Produces structured outcome-based feedback tied to user goals, business metrics, and requirement coverage."
|
||||
---
|
||||
|
||||
# Figma Design Critique — PM Perspective Skill
|
||||
@@ -68,6 +68,14 @@ Approve / Approve with changes (list) / Revise and re-review (one focus area onl
|
||||
- [ ] PM recommendation is explicit
|
||||
- [ ] Evidence basis stated honestly
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not critique visual aesthetics — PM feedback must focus on product outcomes, user goals, and business requirements
|
||||
- [ ] Do not provide feedback without stating the evidence basis — distinguish between observed design facts and assumed user behaviour
|
||||
- [ ] Do not give vague feedback like "the flow feels confusing" — every concern must reference a specific screen state or interaction
|
||||
- [ ] Do not ignore what is working — balanced critique includes explicit acknowledgment of design decisions that are well-executed
|
||||
- [ ] Do not critique without knowing the design constraints — always ask about technical, time, or resource limitations before judging decisions
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Give me a PM critique of this design"
|
||||
- "Review this design from a product perspective"
|
||||
|
||||
@@ -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. Optimised for Opus 4.7 and newer models."
|
||||
description: "Runs a pre-handoff QA checklist on a Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, or validate a Figma file is ready to build. Produces a structured QA report covering file hygiene, component usage, accessibility, and handoff readiness with explicit pass/fail status per item. Optimised for Opus 4.7 and newer models."
|
||||
---
|
||||
|
||||
# Figma Design QA Skill
|
||||
@@ -81,6 +81,14 @@ Status, signed off by, date.
|
||||
- [ ] Blocking issues separated from minor ones
|
||||
- [ ] Handoff decision is explicit
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not produce a partial QA — every checklist category must be evaluated, not just the ones that are obviously problematic
|
||||
- [ ] Do not leave the handoff decision ambiguous — the output must explicitly state pass, pass with conditions, or fail
|
||||
- [ ] Do not skip accessibility checks — colour contrast, tap target size, and screen reader labels are required, not optional
|
||||
- [ ] Do not report issues without specifying which screen or component they appear on
|
||||
- [ ] Do not approve a design if any component is detached from the library without a documented reason
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "QA this Figma design before handoff"
|
||||
- "Run a pre-handoff check on [feature] design"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: figma-design-review
|
||||
description: "Run a structured PM design review against product requirements. Use when asked to review a Figma design, check a design against requirements, do a PM design review, or assess whether a design meets the product spec. Produces a requirements coverage check, UX concerns, open questions, and explicit approval status."
|
||||
description: "Runs a structured PM design review against product requirements. Use when asked to review a Figma design, check a design against requirements, or assess whether a design meets the product spec. Produces a requirements coverage check, UX concerns, open questions, and an explicit approval status — approved, approved with conditions, or not approved."
|
||||
---
|
||||
|
||||
# Figma Design Review Skill
|
||||
@@ -60,6 +60,14 @@ Approved / Approved with changes (list) / Needs revision (focus area + next revi
|
||||
- [ ] Open questions have owners
|
||||
- [ ] Approval status is explicit
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not review a design without a list of requirements to check against — always ask for the PRD, design brief, or acceptance criteria first
|
||||
- [ ] Do not give a vague approval status — the decision must be explicitly "approved", "approved with conditions", or "not approved"
|
||||
- [ ] Do not conflate requirements gaps with UX concerns — track them separately so engineers and designers can act independently
|
||||
- [ ] Do not raise concerns without suggesting what information is needed to resolve them
|
||||
- [ ] Do not skip open questions — unresolved assumptions at review time become bugs after engineering handoff
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Review this Figma design against the requirements"
|
||||
- "Do a PM design review for [feature]"
|
||||
|
||||
@@ -76,6 +76,14 @@ Success when: [Specific trigger]
|
||||
- [ ] Success criteria defined for each task
|
||||
- [ ] Reset process defined for between participants
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not prototype everything — scope must be limited to the interactions that answer the specific research questions
|
||||
- [ ] Do not design prototype flows without also writing the test task scripts — the two must align exactly
|
||||
- [ ] Do not skip the reset process between participants — unsettled prototype state contaminates results
|
||||
- [ ] Do not plan a prototype without specifying which interactions are clickable vs static — ambiguity causes scope creep
|
||||
- [ ] Do not scope a prototype without first defining the research questions it needs to answer
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Plan the Figma prototype for our user test on [feature]"
|
||||
- "What interactions do I need to build for this prototype?"
|
||||
|
||||
@@ -69,6 +69,14 @@ Desktop (1440px): 12 columns, margin [value], gutter [value], max content width
|
||||
- [ ] Component conventions cover common decisions
|
||||
- [ ] Figma implementation steps included
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not create a spacing scale with arbitrary values — the scale must follow a consistent mathematical ratio (e.g. 4px base, 8-4-2 system)
|
||||
- [ ] Do not define spacing tokens without Figma implementation instructions — token names alone are not actionable
|
||||
- [ ] Do not create a spacing system that doesn't account for component-level spacing conventions — global tokens and component usage must both be documented
|
||||
- [ ] Do not skip grid definitions — spacing without a grid system is incomplete layout foundation documentation
|
||||
- [ ] Do not produce a spacing system that ignores responsive behaviour — define how spacing adapts across breakpoints
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Create a spacing system for our Figma design system"
|
||||
- "Define our spacing tokens for Figma"
|
||||
|
||||
@@ -68,6 +68,14 @@ Feature name/
|
||||
- [ ] Out-of-scope section is explicit
|
||||
- [ ] Figma file structure matches screen map
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not plan only the happy path — all error states, empty states, and edge cases must be mapped before designing starts
|
||||
- [ ] Do not produce a flow map that doesn't match the Figma file structure — the page structure must reflect the flow map
|
||||
- [ ] Do not define screens without specifying all required states — a screen without its variants is an incomplete design scope
|
||||
- [ ] Do not start designing before entry and exit points are fully documented — unclear boundaries cause scope creep
|
||||
- [ ] Do not plan user flows without tying each step back to a user goal — every screen must justify its existence
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Plan the user flow for [feature] in Figma"
|
||||
- "What screens do I need to design for [feature]?"
|
||||
|
||||
@@ -70,6 +70,14 @@ For each state, list only what changes from Default:
|
||||
- [ ] Token mapping covers all visual properties
|
||||
- [ ] Disabled state uses layer-level properties not opacity
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not create a variant matrix with properties that overlap or conflict — each property must be independently variable
|
||||
- [ ] Do not use opacity for disabled states — disabled states must use layer-level properties, not opacity
|
||||
- [ ] Do not enumerate every mathematical combination if many are invalid — document only valid, buildable combinations
|
||||
- [ ] Do not define variants without considering responsive behaviour — specify which properties change across screen sizes
|
||||
- [ ] Do not produce a matrix without Figma implementation guidance — variant naming conventions must follow Figma's property system
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Define the variants for a [component] in Figma"
|
||||
- "What states does my [component] need?"
|
||||
|
||||
@@ -70,6 +70,22 @@ Produces a structured financial due diligence framework — document request lis
|
||||
- Balance sheet risk: [Assessment]
|
||||
- Overall: Green Strong / Amber Acceptable / Red Material concerns
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Document request list is tailored to the transaction type and stage — not a generic template
|
||||
- [ ] Red flags checklist covers revenue quality, margins, cash conversion, and balance sheet risk
|
||||
- [ ] Every analytical question connects to a specific risk the transaction presents
|
||||
- [ ] Summary output template is completed with an overall RAG assessment
|
||||
- [ ] Disclaimer that this is a framework and does not substitute for qualified financial or legal advice
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not present the checklist without tailoring it to the specific transaction type and stage of diligence
|
||||
- [ ] Do not overlook revenue concentration risk — customer concentration above 20–30% is a material risk that must be flagged
|
||||
- [ ] Do not confuse EBITDA with cash — always check cash conversion and identify non-cash items
|
||||
- [ ] Do not skip the related-party transaction review — undisclosed related-party dealings are a common due diligence failure point
|
||||
- [ ] Do not produce output without noting this is a framework and qualified financial and legal advice is required
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Give me a financial due diligence checklist for [company type]"
|
||||
- "What documents should I request for financial DD?"
|
||||
|
||||
@@ -110,6 +110,14 @@ By the end of this session, participants will be able to:
|
||||
- [ ] Differentiation is specified for both support and extension
|
||||
- [ ] Timing adds up to session length
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not design a lesson plan without explicitly stating the learning objectives — activities must trace back to outcomes
|
||||
- [ ] Do not allocate timing that does not add up to the total session length — the plan must be time-feasible
|
||||
- [ ] Do not create activities with no assessment component — learning must be measurable, not just delivered
|
||||
- [ ] Do not ignore differentiation — a plan with no accommodation for different learning levels or abilities is incomplete
|
||||
- [ ] Do not front-load all content delivery without interactive breaks — passive listening degrades retention after 15–20 minutes
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a lesson plan on [topic] for [audience]"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: team-health-check
|
||||
description: "Run a structured team health assessment. Use when asked to run a team health check, assess team morale, facilitate a team retrospective on ways of working, or evaluate team dynamics. Produces a health assessment across key dimensions with RAG status, underlying signals, and prioritised improvement actions."
|
||||
description: "Runs a structured team health assessment across key dimensions. Use when asked to run a team health check, assess team morale, facilitate a retrospective on ways of working, or evaluate team dynamics. Produces a health assessment with RAG status per dimension, underlying signals, and prioritised improvement actions with named owners."
|
||||
---
|
||||
|
||||
# Team Health Check Skill
|
||||
@@ -253,6 +253,14 @@ Use this template to document results after the session or survey.
|
||||
- [ ] Results are shared with the team, not kept by management
|
||||
- [ ] Trend data is tracked across cycles to show improvement or regression
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not run a health check without first establishing psychological safety — without it, scores reflect fear, not reality
|
||||
- [ ] Do not treat a single health check as a trend — one data point cannot show improvement or regression
|
||||
- [ ] Do not keep results with management without sharing them with the team — transparency is a prerequisite for trust
|
||||
- [ ] Do not generate action items that are vague commitments like "improve communication" — every action must be specific and verifiable
|
||||
- [ ] Do not assign actions to "the team" — each improvement action needs a single named owner
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Run a team health check for my engineering squad"
|
||||
|
||||
@@ -136,6 +136,14 @@ Template for the summary document to send within 48 hours:
|
||||
- [ ] Each working session has a stated output
|
||||
- [ ] Agenda has social/informal time built in
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not fill the entire agenda with structured sessions — unstructured social time is essential for team bonding and must be built in
|
||||
- [ ] Do not schedule more than 90 minutes of intensive working sessions without a break
|
||||
- [ ] Do not design an offsite without clearly linking each session to the stated goals — purpose must be explicit
|
||||
- [ ] Do not neglect logistics — venue, travel, dietary requirements, and accessibility must be confirmed before the agenda is finalised
|
||||
- [ ] Do not plan without an energy management arc — high-energy collaboration sessions should not appear directly after lunch
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Plan a 1-day offsite for my team of [size]"
|
||||
|
||||
@@ -288,3 +288,11 @@ This log records every ring movement since the radar's first edition. Use it to
|
||||
- [ ] Maintenance process includes: nomination channel, review cadence, who decides, and ring-change criteria
|
||||
- [ ] Technologies identified as "strategic bets" in the inputs are placed in Adopt (if proven) or Trial (if being rolled out)
|
||||
- [ ] Technologies identified for deprecation are in Hold with a rationale that references the replacement
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not place a technology in Adopt without evidence it is proven at the team's scale — aspirational placements mislead engineers
|
||||
- [ ] Do not add a blip without a written rationale paragraph — table rows without context are unusable
|
||||
- [ ] Do not create a Hold entry without specifying a concrete migration path or target technology
|
||||
- [ ] Do not skip the maintenance process — a radar with no process for updates becomes stale within two quarters
|
||||
- [ ] Do not omit ring definitions — engineers need to know what they should do in response to each ring, not just what the ring means
|
||||
|
||||
@@ -258,3 +258,11 @@ Items where the cost of remediation currently exceeds the business value, accept
|
||||
- [ ] Accepted/deferred items have a review date and a named owner — no permanently deferred items
|
||||
- [ ] The register distinguishes between debt (deliberate or accumulated shortcuts) and bugs (unintended defects)
|
||||
- [ ] Items are closed as resolved only when acceptance criteria are met — not when the PR is merged
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not score debt items arbitrarily — priority scores must be calculated using the documented formula
|
||||
- [ ] Do not conflate technical debt (deliberate shortcuts) with bugs (unintended defects) — they require different remediation strategies
|
||||
- [ ] Do not underrate security and dependency items because they feel abstract — score based on actual business impact
|
||||
- [ ] Do not create "permanently deferred" items — every accepted item must have a review date and named owner
|
||||
- [ ] Do not include resolution plans that are vague descriptions — each plan must have specific, ticketable steps
|
||||
|
||||
@@ -147,3 +147,11 @@ Error codes: [list]
|
||||
- [ ] At least 2 alternative approaches are documented with reasons for rejection
|
||||
- [ ] Security and privacy section is completed for any feature touching user data
|
||||
- [ ] All open questions have a named owner and due date (not "TBD")
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not include solution language in the problem statement — the problem must be described independently of the proposed solution
|
||||
- [ ] Do not omit alternatives considered — a spec that considers only one approach has not been properly evaluated
|
||||
- [ ] Do not leave open questions as "TBD" without a named owner and due date — unresolved questions are blockers
|
||||
- [ ] Do not skip security and privacy sections for any feature that touches user data
|
||||
- [ ] Do not write a non-goals section that is empty — always list at least two things that might be assumed in scope
|
||||
|
||||
@@ -122,6 +122,14 @@ Testing is complete when:
|
||||
- [ ] Each test type names a concrete tool (not "some testing framework")
|
||||
- [ ] Definition of Done is measurable (not "tests are done when QA is happy")
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write a test strategy without a risk table that drives test priority — generic coverage targets are not a strategy
|
||||
- [ ] Do not leave the "out of scope" section blank — every test strategy must explicitly name what is not being tested and why
|
||||
- [ ] Do not specify test types without naming a concrete tool for each — "some testing framework" is not actionable
|
||||
- [ ] Do not define a Definition of Done that is not measurable — "QA is happy" is not a completion criterion
|
||||
- [ ] Do not create P0 risk areas without corresponding P0 test cases — risk rating must map to test coverage
|
||||
|
||||
## Usage Examples
|
||||
- "Write a test strategy for [feature]" + [paste spec or PRD]
|
||||
- "Create a test plan for [system]"
|
||||
|
||||
@@ -587,6 +587,14 @@ Before marking the task complete, verify each item:
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not generate thumbnails without incorporating brand colours and style specs when provided — off-brand outputs must be regenerated
|
||||
- [ ] Do not skip the evaluation step — all candidates must be scored before being presented to the user
|
||||
- [ ] Do not present only one thumbnail candidate — always generate multiple options for comparison
|
||||
- [ ] Do not include the full image generation prompts in a separate document — they must be included in the evaluation report for iteration reference
|
||||
- [ ] Do not claim a thumbnail is final without offering an iteration round
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Create thumbnails for this article"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: user-interview-synthesis
|
||||
description: "Synthesise user interview transcripts into structured research findings. Use when asked to analyse interview notes, synthesise qualitative research, identify themes from user interviews, or turn raw interview data into actionable product insights. Produces a themed synthesis with supporting quotes, 'so what' implications, and recommended next steps."
|
||||
description: "Synthesises user interview transcripts into structured research findings. Use when asked to analyse interview notes, synthesise qualitative research, identify themes from interviews, or turn raw interview data into actionable product insights. Produces a themed synthesis with supporting quotes per theme, 'so what' implications, and recommended next steps."
|
||||
---
|
||||
|
||||
# User Interview Synthesis Skill
|
||||
@@ -50,3 +50,11 @@ Ask the user for these if not provided:
|
||||
- [ ] Researcher bias check: no leading language, findings don't all support one hypothesis
|
||||
- [ ] Single-source signals are flagged separately, not mixed into main themes
|
||||
- [ ] Research questions from the study brief are each addressed (even if the answer is "inconclusive")
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not mix single-source signals into main themes — insights cited by only one participant must be flagged separately
|
||||
- [ ] Do not write implications that are observations restated rather than product decisions enabled
|
||||
- [ ] Do not include themes that only support the project hypothesis — contradictory findings must be surfaced, not omitted
|
||||
- [ ] Do not present findings without quotes — every theme requires verbatim evidence from at least 3 participants
|
||||
- [ ] Do not leave research questions unanswered — each question from the study brief must be explicitly addressed, even if the answer is inconclusive
|
||||
|
||||
@@ -123,21 +123,21 @@ Research gaps identified:
|
||||
- Quantify when possible ("7 out of 10 users...")
|
||||
- Connect themes to business objectives
|
||||
|
||||
## Quality Standards
|
||||
## Quality Checks
|
||||
|
||||
✅ **Good Synthesis:**
|
||||
- Identifies patterns, not just individual responses
|
||||
- Connects insights to product decisions
|
||||
- Includes supporting evidence for each claim
|
||||
- Separates observations from interpretations
|
||||
- Prioritizes findings by impact
|
||||
- [ ] Themes identify patterns across multiple participants, not individual responses
|
||||
- [ ] Insights connect to specific product decisions, not just observations
|
||||
- [ ] Each claim includes supporting evidence (quotes, counts, or examples)
|
||||
- [ ] Observations and interpretations are clearly separated
|
||||
- [ ] Findings are prioritised by impact, not just listed
|
||||
|
||||
❌ **Poor Synthesis:**
|
||||
- Lists every individual comment
|
||||
- Lacks evidence or examples
|
||||
- Makes unsupported leaps
|
||||
- Focuses on solutions before understanding problems
|
||||
- Ignores contradictory data
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not list every individual comment — synthesis must identify patterns across participants
|
||||
- [ ] Do not make interpretive leaps without supporting evidence from the data
|
||||
- [ ] Do not focus on feature requests before understanding the underlying problem — always identify the job-to-be-done first
|
||||
- [ ] Do not ignore contradictory data — conflicting findings must be surfaced and noted
|
||||
- [ ] Do not present results without quantifying prevalence — state how many participants held each view
|
||||
|
||||
## Example Theme
|
||||
|
||||
|
||||
@@ -209,6 +209,14 @@ Then the export contains only invoices from Jan 2026 — not all invoices
|
||||
- [ ] Out of scope is documented — not assumed
|
||||
- [ ] Stories are independent — they can be shipped individually without depending on unreleased work (except where explicitly noted)
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write user stories from a technical perspective — every story must be from the user's point of view and state their goal
|
||||
- [ ] Do not write acceptance criteria that are untestable — every criterion must have a clear pass/fail condition
|
||||
- [ ] Do not create stories that are too large to complete in a single sprint — break epics into estimable, independently deliverable stories
|
||||
- [ ] Do not omit edge cases — unhappy paths and error states are required, not optional
|
||||
- [ ] Do not skip the Definition of Done — without it, "done" means different things to different people
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write user stories for [feature] from this brief"
|
||||
|
||||
@@ -152,6 +152,14 @@ For each insight: "This means we should [design/product implication]" or "This c
|
||||
- [ ] Synthesis framework is included
|
||||
- [ ] Incentive recommendation is included
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write a research plan without clearly stated research objectives — every methodology choice must flow from the objectives
|
||||
- [ ] Do not design a plan that mixes generative and evaluative research without clearly separating them
|
||||
- [ ] Do not omit screener criteria — recruiting unqualified participants invalidates the research
|
||||
- [ ] Do not write discussion guide questions that are leading — questions must be neutral and open-ended
|
||||
- [ ] Do not skip the incentive recommendation — uncompensated research has lower participant quality and completion rates
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a research plan for [feature or product area]"
|
||||
|
||||
@@ -73,6 +73,14 @@ Security: ISO 27001 / SOC 2 certified? Where is data stored? Breach notification
|
||||
- [ ] Runner-up rationale explains why they lost (enables future conversations)
|
||||
- [ ] Contract terms to negotiate are specified
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not weight all evaluation criteria equally — the scorecard must reflect the relative importance of each criterion
|
||||
- [ ] Do not evaluate vendors only on features — security, support, contract terms, and financial stability matter too
|
||||
- [ ] Do not produce a recommendation without explaining why the runner-up lost — this enables future vendor conversations
|
||||
- [ ] Do not skip contract terms to negotiate — identifying leverage points is part of the procurement decision
|
||||
- [ ] Do not recommend a vendor without stating the conditions under which the recommendation would change
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Help me evaluate vendors for [procurement]"
|
||||
- "Create a vendor scorecard for [software/service]"
|
||||
|
||||
@@ -388,6 +388,14 @@ Apply the hook formulas and content structures from above to these topic angles:
|
||||
- [ ] Testing system is set up — 48-hour signal tracked for every post
|
||||
- [ ] CTA asks for a specific action, not a generic "like and share"
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not create a single generic framework — hook formulas and content structures must be platform-specific
|
||||
- [ ] Do not confuse reach with virality — high reach alone is not viral; content must drive sharing, saves, or resharing
|
||||
- [ ] Do not produce hook formulas without testing guidance — frameworks without a testing system produce one-off results
|
||||
- [ ] Do not ignore the shareability trigger — all content must have a clear reason why someone would send it to another person
|
||||
- [ ] Do not design hooks that work only once — the framework must be repeatable, not a collection of one-time tactics
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Build a viral content framework for [brand / creator]"
|
||||
|
||||
@@ -140,6 +140,14 @@ End every session with:
|
||||
- [ ] Parking lot is used actively (not a graveyard)
|
||||
- [ ] Close captures decisions and actions before the room empties
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not design a workshop without explicitly linking every activity to a session goal — purposeless activities waste participant time
|
||||
- [ ] Do not schedule more than 90 minutes of continuous structured activity without a break
|
||||
- [ ] Do not close a workshop without capturing decisions and actions before the room empties — post-session follow-up is too late
|
||||
- [ ] Do not plan a workshop without considering psychological safety for sensitive topics — establish ground rules at the start
|
||||
- [ ] Do not underestimate timing — add 20% buffer to all activity estimates, especially for groups over 8 people
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Design a workshop for [goal] with [group]"
|
||||
|
||||
Reference in New Issue
Block a user