Cursor

Analyzes design image files or Figma links (when Figma MCP is available) and generates a structured design context document. Handles three output formats: (1) User Flow Document — sequential multi-screen journeys with screen-by-screen breakdowns, state transitions, and error handling; (2) Design Description — screen/component documentation covering visual design, layout, and interaction behavior; (3) Context Summary — structured six-context analysis (Business/Product/UX) used as input for requirements generation. Use when given design images, Figma URLs, or asked to document a screen, flow, or feature from mockups.

Generates Mermaid.js diagrams in FigJam from requirements documents, user flows, state descriptions, or verbal input. Supports flowcharts, sequence diagrams, state diagrams, and gantt charts via the Figma MCP generate_diagram tool. Applies client-reviewed flow modeling conventions (shape vocabulary, actor naming, audit nodes, cross-system handoffs). Runs a 6-priority verification gate (accuracy, clarity, readability, completeness, conciseness, structure) before generating. Use when asked to: create a FigJam diagram, generate a user flow in FigJam, create a flowchart from requirements, build a sequence diagram, generate a state diagram, visualize a user flow, or any request involving Mermaid diagrams in FigJam.

Scans any document for stale content, contradictions, unresolved markers, and broken cross-references. Detects [PENDING], [TBD], and [UNKNOWN] markers that are already answered elsewhere in the document or conversation. Flags contradictions between sections, orphaned references, and notes left over from earlier drafts. Use after iterative editing rounds, after incorporating meeting feedback, or as a final quality gate before sharing a document.

Converts meeting transcripts (.vtt, .docx, .md, .txt) into structured meeting summaries. Uses a single unified template for all meeting types (discovery, engineering, technical). Outputs a Discovery Summary with decisions table, topic-by-topic findings with traceability, know/don't-know analysis, assumptions, open questions, and next steps. Topic internal structure adapts based on meeting type. Use when given a transcript file or asked to summarize a meeting, call, sync, or session.

Interactively walks users through findings from any audit or validation report (validate-requirements, document-audit, or future skills). Reads the report file, detects its format, presents findings via AskQuestion for user decisions, and produces a resolution summary. Use after any skill that generates a findings report, or standalone against any structured findings markdown file.

Propagates corrections, new information, terminology changes, and scope changes across multiple related documents. Structures changes, verifies with user, performs impact analysis, presents a change manifest for approval, applies edits preserving each document's format and tone, and runs verification as a final consistency check (validate-requirements for requirements docs, document-audit for all others). Use when a fact, assumption, or decision changes and multiple documents need updating, or when new information (e.g., from a design review, stakeholder feedback, or discovery session) must be reflected across a document set.

Defines a release — its goal, scope, timeline, team, and constraints — then produces a formal Release Definition and multi-sprint plan. Assesses context across six dimensions, collaboratively builds each section, sizes features, maps dependencies, assigns work to sprints, and iterates until the plan is balanced and agreed. Use when asked to: create a release plan, plan the release, define the release, break this down into sprints, update the plan, rebalance sprints, or adjust scope/timeline.

Takes a sprint's planned work (from a release plan, ticket board, or verbal list) and produces a structured Sprint Planning Session document. Normalizes any ticket format, groups work into logical areas, validates against the sprint goal, runs guardrails, and generates a document that gives the team clarity on what they're building, why, and what 'done' looks like. Use when asked to: create a sprint planning doc, plan a sprint, organize sprint tickets, write a sprint kickoff document, or prepare for sprint planning.

Creates a snapshot of where the sprint stands — planned vs actual. Surfaces risks early. Feeds data into the sprint review and next sprint planning. Use when asked to: check sprint progress, mid-sprint check, close out the sprint, what's the sprint status, or generate a progress report.

Creates a sprint review document for the sprint demo. Stakeholder-facing artifact answering: What did we build? Did we hit our goal? What did we learn? What's next? Serves two audiences: stakeholders (top sections, jargon-free) and team/PM (full detail). Use when asked to: create a sprint review, prepare the sprint demo doc, write the sprint review, or summarize what we shipped.

Identify and structure risky assumptions for a feature using multi-perspective analysis (PM, Designer, Engineer) across four risk areas (Value, Usability, Viability, Feasibility). Outputs assumptions in structured format with STATUS, VALIDATE WITH, BY WHEN, and RISK IF WRONG — consistent with the transcript-to-meeting-notes assumption format. Use when stress-testing a feature idea, preparing for stakeholder review, or running assumptions analysis as part of a requirements pipeline.

Generates Feature Requirements documentation from any combination of inputs -- PRDs, design files/Figma URLs, meeting transcripts, or verbal descriptions. Focuses exclusively on requirements; API contracts and system flows are generated separately after requirements are finalized. Runs in Quick mode (3 contexts, ~15 min) for MVPs/small features or Comprehensive mode (6 contexts, ~30 min) for production/complex features. Use when asked to: generate requirements, write a feature spec, create a PRD, or document a feature.

A 9-stage discovery and analysis pipeline that takes messy, early-stage inputs — rough ideas, transcripts, designs, legal docs, hypotheses — and produces a production-ready requirements document. Handles brainstorming, scenario mapping, assumption analysis, user flows, and risk analysis with mandatory human checkpoints. Calls complementary skills at each stage. Use when asked to: run the requirements pipeline, build requirements from scratch, start from rough ideas or a transcript, or work through a feature from discovery to requirements.

Validates requirements documents using 15 checks across 2 dimensions: semantic accuracy (11 checks — source truth, inference detection, requirement purity, over-generalization, scope boundaries, testability, ambiguity, assumption dependencies, negative paths, actor capability, intra-document consistency) and structural integrity (4 checks — staleness, contradictions, cross-references, completeness). Supports incremental mode: when a prior validation report is provided, only re-runs checks whose inputs have changed, carries forward findings that remain valid, and detects resolved findings — cutting re-validation effort by 40-60%. Produces a unified report with clear Semantic vs Structural grouping. Use after generating requirements, before sharing with stakeholders, when suspecting inaccuracies, or as a periodic quality sweep.

Generates a client-ready UAT test plan from a release-summary-by-feature report or a manual ticket list. Reads local GitHub issue files, extracts Acceptance Criteria, comments, and test steps, then produces a requirement-pure UAT document in table format. Use when asked to: create a UAT plan, generate UAT scenarios, build a test plan for client testing, prepare UAT from tickets, or create acceptance testing scripts.

Takes decisions from a meeting (sprint demo, retro, stakeholder call, team sync) and applies them to the release plan and related artifacts. The 'decisions become actions' bridge. Use when asked to: apply meeting decisions, update the plan from meeting notes, integrate feedback, or cascade changes from a meeting.

Creates structured epic documents from requirements documentation or verbal descriptions. Extracts business goals, success criteria, scope boundaries, and dependencies. Produces a single Epic-[Feature].md file ready for story decomposition. Use when asked to: create an epic, write an epic, generate an epic, or document a feature as an epic.

Transforms an internal feature requirements document into a client-ready version suitable for all stakeholder types — business, product, UX, technology, and executive — in a single shared document. Strips internal source citations (SRC codes), process metadata, pipeline stage references, and internal assumption codes. Reframes blocker/risk language, cleans change history, and adds a formatted Sources & Reference Materials section. Use when asked to: produce a client-ready requirements doc, prepare requirements for stakeholder review, create a clean version of a feature spec, strip internal references from a requirements document, or share requirements with a client.

Decomposes features into story concepts using the WAHZURT framework, then creates detailed INVEST-compliant user stories one-at-a-time with quality gates. Supports 4 modes: create (standard), create (quick/draft), modify existing stories, or decompose-only. Use when asked to: create user stories, write stories, generate stories, decompose an epic, break down a feature, plan stories, write acceptance criteria, modify a story, improve a story, enhance a story, or update a story.

Audits existing user stories against 12 validation categories (9 per-story + 2 cross-story + 1 practitioner readability) and fixes failures. Builds a fresh registry from actual story files — never trusts existing registries. Works on any story set regardless of how stories were created. Use when asked to: validate stories, check stories, review stories, audit stories, fix stories, or improve story quality.

Transforms an internal feature requirements document into a streamlined Securitas client-ready version. Produces an 8-section (or 7-section for net-new features) document by removing redundant context sections, merging scattered constraint/risk information, and stripping internal process scaffolding. Designed for a client who already knows the context and needs a focused, review-friendly document. Use when asked to: produce a Securitas client requirements doc, streamline requirements for Lauren/Securitas review, create a focused version of a feature spec, or prepare requirements for Securitas stakeholder review.