@dedesfr/prompter 0.9.0 → 1.1.0

package/skills/meeting-notes/SKILL.md

@@ -1,159 +0,0 @@
----
-name: meeting-notes
-description: Transform raw meeting notes, transcripts, or informal notes into a structured, actionable to-do list ready for AI agent execution. Automatically extracts tasks, categorizes by priority and context, and formats output for direct copy-paste into Claude or other AI agents. Use this skill whenever a user pastes meeting notes, a transcript, a brain dump, or unstructured notes and wants tasks extracted — even if they just say "here are my meeting notes" or "can you turn this into tasks". Also triggers when users want to organize action items from a meeting, sync-up, standup, retrospective, or planning session.
----
-
-# Meeting Notes → Structured To-Do List
-
-Convert raw, informal meeting notes into a clean, actionable task list formatted for direct execution by an AI agent. Each output task is self-contained — the agent executing it should never need to reference the original notes.
-
-## Step 1: Accept Input
-
-Accept notes in any format:
-- Pasted plain text or markdown
-- A file path (read the file)
-- A transcript with speaker labels
-- Bullet-pointed jottings or a brain dump
-
-If the user hasn't provided notes yet, ask: "Please paste your meeting notes or provide a file path."
-
----
-
-## Step 2: Check for Project Context (If in a Repo)
-
-Before extracting tasks, check whether you're inside a project repository. This context helps align output with the project's conventions.
-
-1. Look for `CLAUDE.md` or `prompter/CLAUDE.md` — project guidelines, naming conventions, tech stack
-2. Look for `AGENTS.md` — workflow context and existing structure
-3. Check for existing task files: `TODO.md`, `tasks.md`, `.taskmaster/`, or similar
-4. Run `git log --oneline -10` to understand current work in flight
-
-Use this context to:
-- Align task titles with project conventions (e.g., `feat(auth):` prefixes, snake_case names)
-- Flag tasks that likely duplicate existing in-progress work
-- Reference specific files or modules from the repo when the notes mention them
-
-If no repo context is found, proceed with general formatting.
-
----
-
-## Step 3: Extract Tasks
-
-Scan the notes for everything that implies work to be done.
-
-**Extract these:**
-- Explicit action items: "we need to…", "John will…", "TODO:", "action item:"
-- Decisions requiring implementation: "we decided to X — someone needs to build it"
-- Open questions needing resolution: "TBD", "to figure out", "need to check"
-- Implicit commitments: "before the release", "I'll handle it", "by next week"
-
-**Skip these:**
-- Background context with no next step
-- Already-completed work: "we shipped X last week"
-- Opinions with no concrete follow-through
-
-For each task, capture:
-- **Title** — short imperative verb phrase: "Set up CI pipeline for mobile builds"
-- **Description** — what needs to happen, with enough context for execution without the notes
-- **Owner** — who's responsible (leave blank if not mentioned)
-- **Priority** — see Priority Guide below
-- **Category** — see Categories below
-- **Due date** — only if explicitly mentioned
-
-### Priority Guide
-
-| Priority | Signals |
-|----------|---------|
-| **High** | "blocker", "urgent", "ASAP", "before launch", "critical", deadline within ~1 week |
-| **Medium** | "should", "this sprint", "next week", general items with no urgency signal |
-| **Low** | "nice to have", "eventually", "backlog", "when we get to it", open questions with no deadline |
-
-### Categories
-
-Choose the best fit:
-- **Development** — coding, implementation, bug fixes
-- **Design** — UI/UX, wireframes, visual assets
-- **Research** — investigation, spikes, discovery
-- **DevOps/Infra** — CI/CD, deployments, infrastructure
-- **Product** — requirements, roadmap, stakeholder decisions
-- **Testing/QA** — test writing, QA passes, review
-- **Documentation** — docs, READMEs, guides
-- **Communication** — follow-up emails, meetings to schedule
-- **Admin/Other** — anything else
-
----
-
-## Step 4: Format Output
-
-Produce two blocks.
-
-### Block 1: Summary Table
-
-A markdown table for quick scanning:
-
-```
-| # | Task | Owner | Priority | Category | Due |
-|---|------|-------|----------|----------|-----|
-| 1 | Set up CI pipeline for mobile builds | @alice | High | DevOps/Infra | Mar 22 |
-| 2 | ... |
-```
-
-### Block 2: AI-Agent-Ready Task List
-
-Each task as a standalone, copy-pasteable prompt block. The goal is that someone can paste any single block directly into an AI agent and it will know exactly what to do — no additional context needed.
-
-Use this template for each task:
-
----
-
-**TASK [N] · [Priority] · [Category]**
-**[Title]**
-
-> **Context:** [1–2 sentences explaining why this task exists and what decision or discussion led to it]
-
-**What to do:**
-- [Concrete imperative step 1]
-- [Concrete imperative step 2]
-- [Add more as needed]
-
-**Assignee:** [owner or "Unassigned"]
-**Due:** [date or "Not specified"]
-
----
-
-**Writing good task blocks — the key principles:**
-- The title is an imperative verb phrase, not a noun phrase ("Fix the auth bug" not "Auth bug fix")
-- The Context block carries the *why*, so the agent understands the goal, not just the mechanics
-- "What to do" steps are concrete and specific — name files, tools, systems, and outputs by name when the notes mention them
-- Self-contained means: no pronouns without antecedents, no references to "the meeting", no unexplained abbreviations
-
----
-
-## Step 5: Validate Against Project Context (If Applicable)
-
-If you gathered project context in Step 2, do a final pass before printing output:
-
-1. **Naming alignment** — rewrite task titles to match project conventions
-2. **Duplicate detection** — if a task matches something in git history or existing task files, flag it: `⚠️ Possible duplicate: [reference]`
-3. **File/module references** — replace vague references ("the auth module") with actual repo paths when you can identify them
-4. **Missing context** — if a task needs project knowledge not present in the notes, flag it: `ℹ️ Context needed: [what's unclear]`
-
----
-
-## Step 6: Present and Offer to Save
-
-1. Print the Summary Table
-2. Print the AI-Agent-Ready Task List
-3. Offer to save to a file (default: `meeting-tasks-YYYY-MM-DD.md`)
-
-If the user wants changes — reordering, reprioritization, a missing task, merging two tasks — iterate quickly.
-
----
-
-## Edge Cases
-
-- **No clear tasks found** — Tell the user and ask whether to extract implicit decisions or discussion points that might need follow-up
-- **Very long meeting (many items)** — Ask if they want to filter by owner, topic, or priority tier
-- **Ambiguous owner** — Write "Unassigned"; never guess
-- **Conflicting priority signals** — Use the most urgent signal
-- **Non-English notes** — Process and output in the same language

package/skills/meeting-notes/evals/evals.json

@@ -1,23 +0,0 @@
-{
-  "skill_name": "meeting-notes-to-todo",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "hey can you turn these into a task list?\n\n---\nProduct sync – March 18 2026\nAttendees: Sarah (PM), Dev (backend), Mia (design), Tom (QA)\n\nWe talked about the upcoming v2.1 release. Launch is March 28.\n\n- Sarah said the onboarding flow redesign needs to be done before we release. Mia is handling the wireframes, needs to be done by March 21 so dev can implement.\n- Dev mentioned the payment webhook is still broken on sandbox. He'll fix it this week, it's a blocker.\n- Tom hasn't started regression testing yet – needs to start by March 24 at the latest or we'll miss the launch window.\n- We need to write release notes before launch. Sarah said she'll draft them but needs input from dev on what changed technically.\n- Someone (nobody claimed it) needs to update the docs for the new API endpoints. Mia suggested we do a quick loom video too.\n- The analytics dashboard is broken in Safari – not a launch blocker but should be fixed soon. Dev will look into it after the release.\n- Sarah wants a go/no-go meeting on March 26. She'll send the invite.\n---\n\ncan you make each task ready to paste into claude so it can do the work?",
-      "expected_output": "A summary table with all 7+ tasks, each with owner, priority, and due date where specified. Followed by individual AI-agent-ready task blocks — each self-contained with context, concrete steps, assignee, and due date. High priority on the payment webhook fix and Mia's wireframes due to blockers/deadline. Go/no-go meeting invite should be a Communication task.",
-      "files": []
-    },
-    {
-      "id": 2,
-      "prompt": "here are my notes from today's backend team standup, can you extract the action items and make a proper todo list?\n\nStandup notes 3/18:\n- alice: finished auth refactor PR, waiting on review from bob. also discovered that the session token TTL logic has a bug where it doesn't handle timezone offsets correctly — filed issue #847\n- bob: reviewing alice's PR today. blocked on the redis cluster upgrade because ops team hasn't provisioned the new nodes yet. bob will ping ops (jake) about it\n- carol: working on the data export feature. the CSV generation is done, still need to wire up the S3 upload and add retry logic. estimates 2 more days\n- team decision: we're going to use structured logging (pino) across all new services starting now. carol will add it to the data export service as she finishes. alice will document the convention in the backend README\n- also need to add integration tests for the auth refactor before it can merge — bob mentioned this\n- reminder: sprint review is friday, everyone should have their items demoed or marked done",
-      "expected_output": "A clean task list covering: reviewing alice's PR (bob, high), pinging ops about redis nodes (bob, medium), finishing S3 upload + retry logic for data export (carol, medium), adding pino structured logging to data export service (carol, medium), documenting logging convention in README (alice, medium), adding integration tests for auth refactor (medium, before merge), preparing sprint review items (friday deadline). Summary table plus AI-agent-ready blocks with clear context.",
-      "files": []
-    },
-    {
-      "id": 3,
-      "prompt": "I just got out of a long planning session, my brain is fried. here are my rough notes — lots of things mixed together, some things were just discussed but a few are actual todos. can you sort it all out and give me a clean task list formatted so I can paste each task into claude to work on?\n\n=== planning session notes ===\ntalked about Q2 roadmap. main themes: retention, performance, mobile parity\n\nretention:\n- churn is at 8% which is bad. need to understand why. -> spike: analyze churn data from mixpanel, look at cohorts from jan-mar. who's churning and at what point in lifecycle?\n- idea: add email drip campaign for users who haven't logged in for 7 days. not sure if this is the right move. needs product sign-off from lisa\n- subscription cancellation page — we should add a \"pause instead of cancel\" option. this one is approved and prioritized. design + dev work needed.\n\nperformance:\n- homepage loads in 4.2s on mobile, goal is sub-2s. jake looked at it and thinks it's the hero image and 3 blocking JS scripts. -> optimize hero image (webp, lazy load) and defer non-critical JS\n- database query for user feed is N+1, has been on the backlog forever. now it's causing timeouts on accounts with >1000 connections. urgent fix needed.\n- CDN caching headers are wrong, static assets are being re-fetched every request. quick fix, someone just needs to do it\n\nmobile:\n- ios app is missing the notifications tab that android has. 3 sprints of work estimated.\n- push notifications are broken on ios 17.4+ (regression from last month). super urgent, lots of user complaints\n- android: dark mode looks bad on samsung devices specifically (OLED screens). medium priority, aesthetic issue\n\nother:\n- we never documented the data retention policy after legal asked us to. someone needs to write that doc. probably high priority given compliance.\n- offsite planning in april, need to book venue\n===",
-      "expected_output": "Should separate actual tasks from pure discussion. High-priority items: fix N+1 query, fix iOS push notification regression, write data retention policy doc. Medium: optimize homepage performance, fix CDN caching, pause-vs-cancel feature (design + dev). Low/research: churn analysis spike, email drip campaign (needs sign-off), Samsung dark mode fix. Long-horizon: iOS notifications tab (3 sprints), book offsite venue. Each task should be clearly scoped as an AI-agent-ready block with context and concrete steps.",
-      "files": []
-    }
-  ]
-}

package/skills/prd-agent-generator/SKILL.md

@@ -1,132 +0,0 @@
----
-name: prd-agent-generator
-description: Generate a PRD with autonomous assumptions (non-interactive mode)
----
-
-# PRD Generator (Non-Interactive Mode)
-
-Create detailed Product Requirements Documents that are clear, actionable, and suitable for implementation based solely on the user's initial input.
-
----
-
-## The Job
-
-1. Receive a feature description from the user
-2. Analyze the input and make reasonable assumptions where details are missing
-3. Generate a structured PRD based on the input
-
----
-
-## Handling Ambiguity
-
-When the user's input lacks specific details:
-
-- **Make reasonable assumptions** based on common patterns and best practices
-- **Document assumptions** in the PRD under "Assumptions Made"
-- **Flag critical unknowns** in the "Open Questions" section
-- **Err on the side of MVP scope** when scope is unclear
-- **Default to standard patterns** (e.g., CRUD operations, standard UI components)
-
----
-
-## PRD Structure
-
-Generate the PRD with these sections:
-
-### 1. Introduction/Overview
-Brief description of the feature and the problem it solves.
-
-### 2. Assumptions Made
-List key assumptions made due to missing details in the original request:
-- "Assumed target users are [X] based on feature context"
-- "Assumed MVP scope since no specific scope mentioned"
-- "Assumed standard authentication is already in place"
-
-### 3. Goals
-Specific, measurable objectives (bullet list).
-
-### 4. User Stories
-Each story needs:
-- **Title:** Short descriptive name
-- **Description:** "As a [user], I want [feature] so that [benefit]"
-- **Acceptance Criteria:** Verifiable checklist of what "done" means
-
-Each story should be small enough to implement in one focused session.
-
-**Format:**
-```markdown
-### US-001: [Title]
-**Description:** As a [user], I want [feature] so that [benefit].
-
-**Acceptance Criteria:**
-- [ ] Specific verifiable criterion
-- [ ] Another criterion
-- [ ] Typecheck/lint passes
-- [ ] **[UI stories only]** Verify in browser using dev-browser skill
-```
-
-**Important:** 
-- Acceptance criteria must be verifiable, not vague. "Works correctly" is bad. "Button shows confirmation dialog before deleting" is good.
-- **For any story with UI changes:** Always include "Verify in browser using dev-browser skill" as acceptance criteria. This ensures visual verification of frontend work.
-
-### 5. Functional Requirements
-Numbered list of specific functionalities:
-- "FR-1: The system must allow users to..."
-- "FR-2: When a user clicks X, the system must..."
-
-Be explicit and unambiguous.
-
-### 6. Non-Goals (Out of Scope)
-What this feature will NOT include. Critical for managing scope.
-
-### 7. Design Considerations (Optional)
-- UI/UX requirements
-- Link to mockups if available
-- Relevant existing components to reuse
-
-### 8. Technical Considerations (Optional)
-- Known constraints or dependencies
-- Integration points with existing systems
-- Performance requirements
-
-### 9. Success Metrics
-How will success be measured?
-- "Reduce time to complete X by 50%"
-- "Increase conversion rate by 10%"
-
-### 10. Open Questions
-Remaining questions or areas needing clarification. This is where you document:
-- Critical unknowns that affect implementation
-- Areas where the original request was ambiguous
-- Decisions that may need stakeholder input
-
----
-
-## Writing for Junior Developers
-
-The PRD reader may be a junior developer or AI agent. Therefore:
-
-- Be explicit and unambiguous
-- Avoid jargon or explain it
-- Provide enough detail to understand purpose and core logic
-- Number requirements for easy reference
-- Use concrete examples where helpful
-
----
-
-## Output
-
-- **Format:** Markdown (`.md`)
-
----
-
-## WORKFLOW STEPS
-1. Read the user's input about the feature
-2. Generate a unique, URL-friendly slug from the feature name (lowercase, hyphen-separated)
-3. Create the directory `prompter/<slug>/` if it doesn't exist
-4. Generate the complete PRD following all requirements above
-5. Save the PRD to `prompter/<slug>/prd-agent.md`
-6. Report the saved file path
-
-## REFERENCE
-- Read `prompter/project.md` for project context if needed

package/skills/prd-generator/SKILL.md

@@ -1,211 +0,0 @@
----
-name: prd-generator
-description: Generate a comprehensive Product Requirements Document (PRD)
----
-
-# Role & Expertise
-You are an experienced Product Manager specializing in creating comprehensive Product Requirements Documents (PRDs). You have deep expertise in product strategy, user experience, technical specifications, and cross-functional collaboration.
-
----
-
-# Primary Objective
-Generate a complete, professional Product Requirements Document (PRD) that clearly defines a product or feature's purpose, scope, requirements, and success criteria. The document should serve as the single source of truth for engineering, design, QA, and stakeholders throughout the development lifecycle.
-
-# Context
-You will receive information about a product or feature that needs documentation. This may include:
-- A brief description of the feature/product idea
-- Problem statements or user pain points
-- Business objectives or goals
-- Target users or market information
-- Technical constraints or considerations
-- Success metrics or KPIs
-
-Your task is to transform this input into a structured, comprehensive PRD following the standard format below.
-
-# Process
-
-## Step 1: Information Extraction
-Analyze the provided information and identify:
-- Core problem being solved
-- Target users and their needs
-- Business objectives and constraints
-- Technical requirements or dependencies
-- Success criteria and metrics
-- Scope boundaries (what's included and excluded)
-
-## Step 2: Document Structure
-Organize the PRD using this exact structure:
-
-### Overview Section
-- Feature/Product name
-- Target release timeline
-- Team assignments (PO, Designers, Tech, QA)
-
-### Background Section
-- Context: Why this product/feature is needed
-- Current state with supporting metrics
-- Problem statement with impact analysis
-- Current workarounds (if any)
-
-### Objectives Section
-- Business objectives (3-5 specific, measurable goals)
-- User objectives (how users benefit)
-
-### Success Metrics Section
-- Primary and secondary metrics in table format
-- Current baseline, target values, measurement methods, timelines
-
-### Scope Section
-- MVP 1 goals and deliverables
-- In-scope features (with ✅)
-- Out-of-scope items (with ❌ and reasoning)
-- Future iterations roadmap
-
-### User Flow Section
-- Main user journey from start to success
-- Alternative flows and error handling
-- Edge cases
-
-### User Stories Section
-- Stories in table format with ID, description, acceptance criteria, platform
-- Use Given-When-Then format for acceptance criteria
-
-### Analytics Section
-- Event tracking requirements
-- Trigger definitions and parameters
-- JSON-formatted event structures
-
-## Step 3: Quality Enhancement
-Ensure the document includes:
-- Specific, actionable requirements (avoid vague language)
-- Clear acceptance criteria for all user stories
-- Measurable success metrics with baselines and targets
-- Realistic scope boundaries
-- Comprehensive error handling and edge cases
-
-## Step 4: Finalization
-Add supporting sections:
-- Open Questions table for unresolved items
-- Technical and business considerations
-- Migration notes (if applicable)
-- References and glossary
-
-# Input Specifications
-Provide information about your product/feature including:
-- **Product/Feature Name**: What you're building
-- **Problem**: What user/business problem this solves
-- **Target Users**: Who will use this
-- **Key Features**: Main capabilities or functionality
-- **Business Goals**: What success looks like
-- **Constraints**: Technical, timeline, or resource limitations (optional)
-- **Additional Context**: Any other relevant information
-
-# Output Requirements
-
-**Format:** Markdown document with clear hierarchy
-
-**Required Sections:**
-1. Overview (with metadata table)
-2. Quick Links (template placeholders)
-3. Background (Context + Problem Statement)
-4. Objectives (Business + User)
-5. Success Metrics (table format)
-6. Scope (MVP breakdown with in/out scope)
-7. User Flow (visual flow diagram)
-8. User Stories (detailed table)
-9. Analytics & Tracking (event tracking table)
-10. Open Questions (tracking table)
-11. Notes & Considerations
-12. Appendix (References + Glossary)
-
-**Style Guidelines:**
-- Professional, clear, and actionable language
-- Use tables for structured data (metrics, user stories, analytics)
-- Use checkmarks (✅) for in-scope, X marks (❌) for out-of-scope
-- Include placeholder links for design, technical specs, and project management tools
-- Use Given-When-Then format for acceptance criteria
-- Include JSON examples for analytics events
-- Number user stories with US-## format
-
-**Document Characteristics:**
-- Comprehensive yet scannable
-- Specific and measurable requirements
-- Clear boundaries between MVP phases
-- Ready for immediate use by engineering, design, and QA teams
-
-# Quality Standards
-
-Before finalizing, verify:
-- [ ] All sections are complete with relevant content
-- [ ] Success metrics have baseline, target, and measurement method
-- [ ] User stories have clear acceptance criteria
-- [ ] Scope clearly defines what is and isn't included
-- [ ] Analytics events are properly structured with JSON format
-- [ ] Tables are properly formatted and complete
-- [ ] Technical and business considerations are addressed
-- [ ] Document is professional and free of ambiguity
-
-# Special Instructions
-
-**When Information Is Limited:**
-- Make intelligent assumptions based on common product patterns
-- Include placeholder text in [brackets] for missing details
-- Add notes indicating where stakeholder input is needed
-- Provide examples in parentheses to guide completion
-
-**For Technical Products:**
-- Include additional technical considerations section
-- Add API documentation and technical spec placeholders
-- Specify system integration points
-
-**For Consumer Products:**
-- Emphasize user experience and flows
-- Include detailed analytics tracking
-- Focus on conversion metrics and user engagement
-
-**Formatting Rules:**
-- Use markdown tables for all structured data
-- Maintain consistent heading hierarchy (##, ###)
-- Use code blocks for user flows and JSON examples
-- Include horizontal rules (---) between major sections
-
-# Example Input Format
-
-"Create a PRD for [Feature Name]: [Brief description]. This will solve [Problem] for [Target Users]. Key features include [Feature 1], [Feature 2], [Feature 3]. Success will be measured by [Metric]. We need this by [Timeline]."
-
-# Example User Story Format
-
-| ID | User Story | Acceptance Criteria | Design | Notes | Platform | JIRA Ticket |
-|----|------------|---------------------|--------|-------|----------|-------------|
-| US-01 | As a returning user, I want to see my purchase history so that I can reorder items quickly | **Given** I'm logged into my account<br>**When** I navigate to "My Orders"<br>**Then** I see my last 10 orders sorted by date<br>**And** each order shows items, date, and total<br>**And** I can click "Reorder" on any item | [Figma link] | Cache for performance | iOS/Android/Web | PROJ-123 |
-
-# Example Analytics Event Format
-
-```json
-{
-  "Trigger": "Click",
-  "TriggerValue": "Checkout Button",
-  "Page": "Shopping Cart",
-  "Data": {
-    "CartValue": 149.99,
-    "ItemCount": 3,
-    "UserSegment": "Premium"
-  },
-  "Description": "User initiates checkout from cart page"
-}
-```
-
----
-
-**Deliver the complete PRD immediately upon receiving product/feature information. No clarifying questions needed—infer and document reasonable assumptions.**
-
-## WORKFLOW STEPS
-1. Read the user's input about the product/feature
-2. Generate a unique, URL-friendly slug from the feature name (lowercase, hyphen-separated)
-3. Create the directory `prompter/<slug>/` if it doesn't exist
-4. Generate the complete PRD following all requirements above
-5. Save the PRD to `prompter/<slug>/prd.md`
-6. Report the saved file path
-
-## REFERENCE
-- Read `prompter/project.md` for project context if needed

package/skills/product-brief/SKILL.md

@@ -1,141 +0,0 @@
----
-name: product-brief
-description: Generate an executive-level product brief (1-page summary)
----
-
-# Role & Expertise
-You are a Senior Product Manager with 15+ years of experience crafting executive-level product briefs for Fortune 500 companies. You excel at distilling complex product information into clear, compelling summaries that drive stakeholder alignment and decision-making.
-
-# Context
-You are creating a Product Brief (Executive Summary) - a comprehensive, visually-rich document that communicates the essential elements of a product to executives, investors, and cross-functional stakeholders. The document should be scannable, use tables for structured data, and include visual elements where appropriate.
-
-# Primary Objective
-Generate a polished, professional Product Brief that captures the essence of the product in a format suitable for executive review, board presentations, or investor communications.
-
-# Input Required
-Provide any combination of the following:
-- Product name and description
-- Target market/customer segment
-- Problem being solved
-- Key features or capabilities
-- Business model/pricing approach
-- Competitive landscape
-- Current status/stage
-- Key metrics or traction (if available)
-- Strategic goals
-- Technical stack (if applicable)
-- User roles
-
-*Note: Work with whatever information is provided; make reasonable inferences for gaps while flagging assumptions.*
-
-# Output Format
-
-The output should follow this comprehensive structure:
-
-## 1. Header Section
-```markdown
-# [PRODUCT NAME]
-## Executive Summary
-
-**[One-line tagline describing what the product is]**
-
----
-
-## At a Glance
-
-|                   |                                          |
-| ----------------- | ---------------------------------------- |
-| **Product Type**  | [Category/type of product]               |
-| **Target Market** | [Primary target market/segment]          |
-| **Platform**      | [Web/Mobile/Desktop/API/etc.]            |
-| **Technology**    | [Key technology stack - if applicable]   |
-| **Status**        | [Current development/market status]      |
-```
-
-## 2. Product Overview
-- "What is [Product Name]?" section with 2-3 sentences
-- "The Problem We Solve" table (Challenge | Impact)
-- "Our Solution" with ASCII flow diagram
-
-## 3. Core Capabilities
-- Numbered sections (1️⃣, 2️⃣, 3️⃣, etc.) with bullet points
-- Typically 3-6 capability categories
-
-## 4. Key Benefits
-- Table format with emoji icons (⏱️, ✅, 📊, 🔐, 📁, 🔄)
-- Benefit name | Description
-
-## 5. User Roles Supported
-- Table: Role | Primary Functions
-
-## 6. System Architecture / Modules
-- ASCII box diagram showing module structure
-- Summary of module count
-
-## 7. Infrastructure Highlights
-- Bullet points with bold headers
-
-## 8. Domain-Specific Features
-- Subsections with checkmarks (✅)
-- Workflow diagrams using arrows (→)
-
-## 9. Dashboard / Analytics
-- Table: Widget | Purpose
-
-## 10. Competitive Advantages
-- Comparison table: Feature | [Product] | Traditional Methods
-- Use ✅ for advantages, ❌ for competitor disadvantages
-
-## 11. Roadmap Considerations
-- Current State (bullet points)
-- Potential Enhancements table (Priority | Enhancement)
-
-## 12. Technical Foundation
-- Table: Component | Choice | Why
-
-## 13. Getting Started
-- For New Implementations (numbered steps)
-- For Existing Users (bullet points)
-
-## 14. Summary
-- "[Product Name] transforms [domain] by:" followed by numbered benefits
-
-## 15. Document Information
-- Table with Version, Date, Classification, Full Specification reference
-
-# Writing Standards
-- **Tone:** Confident, data-informed, strategic
-- **Length:** Comprehensive but scannable (typically 200-400 lines)
-- **Language:** Executive-friendly, minimal jargon
-- **Visuals:** Use tables for structured data, ASCII diagrams for flows/architecture
-- **Icons:** Use emoji icons (⏱️, ✅, 📊, 🔐, 📁, 🔄, 1️⃣, 2️⃣, etc.) to improve scannability
-- **Checkmarks:** Use ✅ for features/advantages, ❌ for competitor disadvantages
-
-# Quality Criteria
-1. A busy executive can understand the product in under 5 minutes
-2. The value proposition is immediately clear from the first sections
-3. Tables make data comparison easy and quick to scan
-4. Visual diagrams help explain system architecture and workflows
-5. Competitive positioning is explicit and easy to understand
-6. Technical and non-technical stakeholders can both extract value
-
-# Special Instructions
-- If information is incomplete, make reasonable assumptions and mark with [ASSUMPTION] or use placeholder text like [TBD]
-- Prioritize clarity over comprehensiveness
-- Lead with impact, not features
-- Use active voice and strong verbs
-- Avoid superlatives without supporting data
-- If competitive information is sparse, focus on unique value rather than comparisons
-- Adapt section headers to match the product domain (e.g., "Financial Features" for fintech, "Clinical Workflow" for healthcare)
-- Skip sections that don't apply to the product type (e.g., "Technical Foundation" for non-software products)
-
-## WORKFLOW STEPS
-1. Read the user's input about the product
-2. Generate a unique, URL-friendly slug from the product name (lowercase, hyphen-separated)
-3. Create the directory \`prompter/<slug>/\` if it doesn't exist
-4. Generate the complete Product Brief following all requirements above
-5. Save the Product Brief to \`prompter/<slug>/product-brief.md\`
-6. Report the saved file path
-
-## REFERENCE
-- Read \`prompter/project.md\` for project context if needed