@maggit/claude-workspace 0.1.1

package/assets/skills/explain/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: explain
+description: "Explain code, architecture, or system behavior in detail. Use when the user says /explain, asks to explain a file, function, module, pattern, or wants to understand how something works in the codebase. Triggers: explain, what does this do, how does this work, walk me through, understand, clarify."
+---
+
+# Code Explainer
+
+Explain code clearly at the right level of detail.
+
+## Workflow
+
+1. **Identify the target:**
+   - Specific function, class, file, module, or architectural pattern.
+   - If the user points at a file, read it fully before explaining.
+
+2. **Determine the audience level:**
+   - If not specified, default to an intermediate developer familiar with the language.
+   - Adjust terminology and depth accordingly.
+
+3. **Provide a layered explanation:**
+
+### Layer 1: One-line summary
+What does this code do in plain English?
+
+### Layer 2: High-level overview
+- Purpose and responsibility.
+- Where it fits in the larger system (caller/callee relationships).
+- Key inputs and outputs.
+
+### Layer 3: Step-by-step walkthrough
+- Walk through the logic sequentially.
+- Explain non-obvious decisions and patterns used.
+- Note any side effects.
+
+### Layer 4: Details (on request)
+- Edge cases handled.
+- Performance characteristics (time/space complexity).
+- Potential issues or technical debt.
+
+4. **Add context:**
+   - Show how other parts of the codebase use this code.
+   - Reference related files or modules.
+   - Mention relevant design patterns by name.
+
+## Guidelines
+
+- Use the code's own variable and function names in the explanation.
+- If the code is poorly written or confusing, say so constructively with improvement suggestions.
+- Use analogies for complex concepts when helpful.
+- For long files, provide a table of contents / map before diving into details.
+- Include a visual diagram (ASCII or Mermaid) for complex data flows or architectures.
+- Don't just restate the code in English — explain the *why*, not just the *what*.

package/assets/skills/landing-page-copy/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: landing-page-copy
+description: "Write landing page copy. Use when the user says /landing-page-copy, asks to write landing page content, create conversion copy, or draft page copy for a product or service. Triggers: landing-page-copy, landing page, conversion copy, page copy, hero copy, sales page, marketing copy."
+---
+
+# Landing Page Copy
+
+## Purpose
+
+Write conversion-focused landing page copy that clearly communicates value, builds trust, and drives visitors toward a specific action. The output is ready-to-use copy organized by page section.
+
+## When to Use
+
+- Launching a new product, feature, or service
+- Creating a campaign-specific landing page
+- Rewriting an underperforming page to improve conversion
+- Drafting copy for design mockups or wireframes
+
+## Inputs
+
+- **Product or service**: What is being offered
+- **Target audience**: Who this page is for (demographics, pain points, goals)
+- **Primary CTA**: The single most important action visitors should take
+- **Key differentiators**: What makes this offering unique (optional)
+- **Tone**: Professional, casual, bold, technical, etc. (optional, defaults to clear and confident)
+- **Proof points**: Testimonials, stats, logos, case studies available (optional)
+
+## Output Format
+
+Produce a markdown document with copy for each page section:
+
+### 1. Hero Section
+- **Headline**: One sentence, 6-12 words. Communicate the core value or transformation. Lead with the benefit, not the feature.
+- **Subheadline**: 1-2 sentences expanding on the headline. Add specificity or address a key objection.
+- **Primary CTA button text**: 2-5 words. Action-oriented, specific to the offer.
+- **Supporting text**: Optional one-liner near the CTA (e.g., "No credit card required").
+
+### 2. Problem Section
+2-3 short paragraphs or bullets articulating the pain the audience feels. Use the audience's own language. Make the reader feel understood before offering the solution.
+
+### 3. Value Propositions
+3-4 value propositions, each with:
+- **Heading**: Benefit-driven, 4-8 words
+- **Body**: 2-3 sentences explaining the value and how it is delivered
+- **Optional icon/visual suggestion**: A brief note on what visual could accompany this
+
+### 4. Features and Benefits
+A section connecting features to outcomes. Format each as:
+- **Feature name**: What it is (one phrase)
+- **Benefit**: Why it matters to the user (one sentence)
+
+Include 4-6 features. Lead with benefits, support with features.
+
+### 5. Social Proof Section
+Provide copy frameworks for:
+- **Testimonial block**: A placeholder structure with guidance on what makes a strong testimonial (specific result, named person, relevant role)
+- **Stats bar**: 3-4 metrics to highlight (e.g., "10,000+ teams", "99.9% uptime", "4.8/5 rating")
+- **Logo bar**: Guidance on which customer logos to feature and a suggested label (e.g., "Trusted by teams at")
+
+### 6. How It Works
+3-4 numbered steps explaining the user's journey from signup to value. Keep each step to one sentence. Make the process feel simple.
+
+### 7. Objection Handling
+2-3 short blocks addressing common concerns or hesitations. Frame as reassurance, not defensiveness.
+
+### 8. FAQ Section
+5-7 frequently asked questions with concise answers. Cover:
+- Pricing or cost concerns
+- Getting started or setup
+- Comparison to alternatives
+- Security or data concerns
+- Support availability
+
+### 9. Final CTA Section
+- **Headline**: Reinforce the core value or create urgency
+- **Body**: 1-2 sentences summarizing why to act now
+- **CTA button text**: Same as or variation of the primary CTA
+- **Supporting text**: Risk reversal (guarantee, free trial, easy cancellation)
+
+## Example
+
+**Input**: "Landing page for a project management tool aimed at remote teams of 10-50 people. CTA is starting a free trial. Key differentiator is async-first design with built-in time zone awareness."
+
+**Output**: Hero headline: "Project management built for teams that don't share a time zone." Subheadline addressing async collaboration pain. Value propositions around async updates, time zone-aware scheduling, and reduced meeting load. Features connecting async standups, smart notifications, and deadline adjustment to benefits. Social proof structure with suggested metrics. How it works in 3 steps (create workspace, invite team, run your first async standup). Objection handling for migration concerns, learning curve, and integration with existing tools. FAQ covering pricing, security, Jira comparison, and onboarding support. Final CTA reinforcing the free trial offer.
+
+## Guidelines
+
+- Write for scanners: most visitors will not read every word, so make headings and bold text carry the message
+- One page, one goal -- every section should support the primary CTA
+- Use concrete language over abstractions ("save 5 hours a week" beats "boost productivity")
+- Avoid jargon unless the audience expects it
+- Keep paragraphs short: 2-3 sentences maximum
+- Social proof is most effective when it is specific and verifiable
+- The FAQ section does real conversion work -- treat it as objection handling, not an afterthought
+- Write multiple headline options when possible so stakeholders can test

package/assets/skills/meeting-notes/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: meeting-notes
+description: "Create structured meeting notes. Use when the user says /meeting-notes, asks to organize meeting notes, structure a meeting transcript, or document a meeting. Triggers: meeting-notes, meeting notes, meeting recap, meeting summary, organize notes, document meeting."
+---
+
+# Meeting Notes
+
+## Purpose
+
+Structure raw meeting content into clear, actionable notes that participants and non-participants can quickly scan. Capture decisions, action items, and follow-ups so nothing falls through the cracks.
+
+## When to Use
+
+- Organizing notes during or after a meeting
+- Processing a meeting transcript into a shareable format
+- Creating a record of decisions for future reference
+
+## Inputs
+
+- **Meeting content**: Transcript, rough notes, or a description of what was discussed
+- **Meeting metadata**: Title, date, attendees (optional but recommended)
+- **Meeting type**: Standup, planning, retrospective, 1:1, stakeholder review, etc. (optional)
+
+## Output Format
+
+Produce a markdown document with the following structure:
+
+### Header Block
+
+```
+# Meeting: [Title]
+**Date**: [Date]
+**Attendees**: [List of names/roles]
+**Duration**: [Length if known]
+**Meeting type**: [Type if known]
+```
+
+### 1. Agenda
+Numbered list of topics that were planned or actually covered. Mark any skipped items.
+
+### 2. Discussion Points
+For each major topic discussed, create a subsection:
+
+#### [Topic Name]
+- Summary of the discussion (2-5 bullets)
+- Key arguments or perspectives raised
+- Any data or evidence referenced
+
+### 3. Decisions
+Numbered list of decisions made during the meeting:
+1. **[Decision]** -- [Brief rationale]. Agreed by [who, if noted].
+
+If no decisions were made, state: "No formal decisions were made in this meeting."
+
+### 4. Action Items
+Table format for clear ownership and tracking:
+
+| # | Action Item | Owner | Due Date | Status |
+|---|-------------|-------|----------|--------|
+| 1 |             |       |          | Open   |
+
+### 5. Follow-ups
+- Topics deferred to future meetings
+- Information someone agreed to look up or share
+- Meetings or discussions that need to be scheduled
+
+### 6. Parking Lot
+Items raised but intentionally set aside for later. These prevent good ideas from being lost while keeping the current meeting focused.
+
+## Example
+
+**Input**: Rough notes from a sprint planning meeting: "talked about auth bugs -- maria will fix the token refresh issue by wednesday. discussed new search feature, agreed to use elasticsearch over solr. need to figure out timeline for search. jake mentioned concerns about test coverage. pushed mobile discussion to next week."
+
+**Output**:
+- Header: Sprint Planning, today's date, attendees mentioned
+- Discussion Points: Auth bugs (token refresh identified as root cause), Search feature (Elasticsearch vs Solr debate), Test coverage concerns, Mobile (deferred)
+- Decisions: Use Elasticsearch for search implementation
+- Action Items: Maria to fix token refresh by Wednesday, team to determine search timeline
+- Follow-ups: Mobile discussion next week, Jake to propose test coverage targets
+- Parking Lot: Mobile app planning
+
+## Guidelines
+
+- Capture the substance of discussions, not a verbatim transcript
+- Every action item must have an owner -- if none was assigned, flag it as "Owner: TBD"
+- Keep discussion summaries neutral; do not editorialize
+- When the input is a rough transcript, clean up language but preserve meaning
+- Group related discussion points rather than listing them chronologically
+- Distinguish between decisions (firm commitments) and sentiments (general agreement without a firm commitment)
+- If attendees are not provided, infer from names mentioned and note that the list may be incomplete

package/assets/skills/migration/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: migration
+description: "Generate database or code migration scripts. Use when the user says /migration, asks to create a migration, add a database column, change a schema, migrate data, or refactor code across a codebase. Triggers: migration, migrate, schema change, add column, alter table, database migration, data migration, code migration, upgrade path."
+---
+
+# Migration Generator
+
+Generate safe, reversible migration scripts for databases and code.
+
+## Workflow
+
+1. **Detect the migration framework:**
+   - **SQL/ORM migrations**: Prisma, Drizzle, Knex, TypeORM, Sequelize, Alembic, Django, Rails ActiveRecord, Flyway, Liquibase, golang-migrate.
+   - **Schema files**: Check for `prisma/schema.prisma`, `drizzle/`, `migrations/`, `alembic/`, `db/migrate/`, etc.
+   - If no framework detected, generate raw SQL migrations.
+
+2. **Understand the change:**
+   - What is being added, modified, or removed?
+   - What existing data needs to be preserved or transformed?
+   - Are there foreign key or index implications?
+
+3. **Generate the migration:**
+
+### For Schema Migrations (DDL)
+
+- **Up migration**: Apply the change.
+- **Down migration**: Reverse the change (when possible).
+- Use the framework's migration generator if available (e.g., `npx prisma migrate dev`, `rails generate migration`).
+
+### For Data Migrations
+
+- Batch large updates to avoid locking.
+- Include progress logging for long-running migrations.
+- Handle null values and edge cases.
+- Make data migrations idempotent when possible.
+
+4. **Safety checks:**
+   - Will this lock a large table? Warn about downtime.
+   - Is the migration reversible? If not, document why.
+   - Does it handle zero-downtime deployment? (e.g., add column → backfill → add constraint, not all at once).
+   - Are there dependent migrations that need to run first?
+
+5. **Generate a migration plan** for complex changes:
+
+```
+Step 1: Add new nullable column (no downtime)
+Step 2: Backfill data (background job)
+Step 3: Update application code to write to new column
+Step 4: Add NOT NULL constraint
+Step 5: Remove old column (next release)
+```
+
+## Guidelines
+
+- Always generate both up and down migrations when the framework supports it.
+- Use transactions where supported (PostgreSQL, not MySQL DDL).
+- Name migrations descriptively: `add_email_verified_to_users`, not `migration_042`.
+- For destructive changes (drop column, drop table), add a confirmation warning.
+- Consider the deploy strategy: can the old and new code run simultaneously?
+- Test migrations against a copy of production data when possible.
+- Include comments explaining *why* the migration exists.

package/assets/skills/openpr/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: openpr
+description: "Generate a PR description and open a pull request. Use when the user says /openpr, asks to open a PR, create a pull request, or push and open a PR. Triggers: openpr, open pr, pull request, create pr, push and pr."
+---
+
+# Open PR
+
+Generate a comprehensive pull request description based on all commits on the current branch (compared to the default base branch), then open the PR using the GitHub CLI (`gh`).
+
+## Workflow
+
+### 1. Detect the Base Branch
+
+```bash
+# Try to detect the default branch (main or master)
+git remote show origin | grep "HEAD branch" | awk '{print $NF}'
+```
+
+Store the result as `BASE_BRANCH`.
+
+### 2. Get the Current Branch Name
+
+```bash
+git branch --show-current
+```
+
+Store the result as `CURRENT_BRANCH`. If the current branch is the same as `BASE_BRANCH`, stop and inform the user they need to be on a feature branch.
+
+### 3. Gather Commit History
+
+```bash
+git log ${BASE_BRANCH}..${CURRENT_BRANCH} --pretty=format:"%h %s" --reverse
+```
+
+This gives the list of all commits on this branch that are not on the base branch, in chronological order.
+
+### 4. Gather the Full Diff Summary
+
+```bash
+git diff ${BASE_BRANCH}...${CURRENT_BRANCH} --stat
+```
+
+This gives a summary of files changed, insertions, and deletions.
+
+### 5. Optionally Read Detailed Diffs
+
+If the diff is small enough (under ~2000 lines), also read the full diff for richer context:
+
+```bash
+git diff ${BASE_BRANCH}...${CURRENT_BRANCH}
+```
+
+If the diff is too large, rely on the commit messages and `--stat` output only.
+
+### 6. Generate the PR Title
+
+- Derive a concise, descriptive PR title from the overall theme of the changes.
+- Format: imperative mood, no prefix, max ~72 characters.
+- Examples: `Add user authentication flow`, `Fix race condition in job scheduler`, `Refactor database connection pooling`.
+
+### 7. Generate the PR Description
+
+Use the following markdown template. Fill in every section thoughtfully based on the commits and diff:
+
+```markdown
+## Summary
+
+<!-- 2-4 sentence high-level overview of what this PR does and why -->
+
+## Changes
+
+<!-- Grouped list of meaningful changes. Group by area/theme, not by commit.
+     Each item should describe WHAT changed and WHY, not just repeat commit messages. -->
+
+- **Area/Module**: Description of change
+- **Area/Module**: Description of change
+
+## How to Test
+
+<!-- Step-by-step instructions a reviewer can follow to verify the changes work -->
+
+1. Step one
+2. Step two
+
+## Notes for Reviewers
+
+<!-- Optional: anything reviewers should pay attention to, open questions,
+     trade-offs made, or follow-up work planned -->
+```
+
+**Guidelines for the description:**
+
+- **Summary**: Explain the motivation and the approach. A reviewer who reads only this section should understand the PR.
+- **Changes**: Group related changes together by theme or module. Do NOT just list commits verbatim — synthesize them into meaningful bullets. If a commit was a fixup or correction of a previous commit on the branch, merge them into one bullet.
+- **How to Test**: Be specific. Include commands, URLs, or user flows. If there are automated tests, mention how to run them.
+- **Notes for Reviewers**: Include anything unusual — risky areas, things you're unsure about, intentional shortcuts, or planned follow-ups. If there's nothing noteworthy, omit this section.
+
+### 8. Confirm with the User
+
+Before opening the PR, display the generated title and description to the user and ask for confirmation or edits.
+
+### 9. Push and Open the PR
+
+Once confirmed:
+
+```bash
+# Ensure the branch is pushed
+git push -u origin ${CURRENT_BRANCH}
+
+# Open the PR via GitHub CLI
+gh pr create --title "<GENERATED_TITLE>" --body "<GENERATED_DESCRIPTION>" --base ${BASE_BRANCH}
+```
+
+If `gh` is not installed or not authenticated, inform the user and provide the generated title and description so they can copy/paste it manually.
+
+### 10. Share the PR Link
+
+After the PR is created, display the PR URL to the user.
+
+## Edge Cases
+
+- **No commits on branch**: Inform the user there are no changes to open a PR for.
+- **Unpushed base branch changes**: Warn the user if the local base branch is behind remote.
+- **Draft PRs**: If the user says `/openpr draft`, add the `--draft` flag to `gh pr create`.
+- **Existing PR**: If a PR already exists for this branch, inform the user and provide the link. Check with `gh pr view --json url`.
+- **Merge conflicts**: If the branch has conflicts with base, warn the user but still allow PR creation.
+
+## Dependencies
+
+- `git` (required)
+- `gh` — GitHub CLI (required for automatic PR creation; graceful fallback if missing)
+
+## Examples
+
+**User input:**
+```
+/openpr
+```
+
+**User input (draft):**
+```
+/openpr draft
+```

package/assets/skills/opentodos/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: opentodos
+description: "Show the latest open TODO items for review and discussion. Use when the user says /opentodos, asks to see pending todos, review open tasks, what's left to do, or wants to pick what to work on next. Triggers: opentodos, open todos, pending tasks, what's left, remaining tasks, show todos, review tasks, backlog."
+---
+
+# Open TODOs
+
+Retrieve and display the latest open (unchecked) TODO items from `ContextDB/todos/` so the user can decide what to work on.
+
+## Workflow
+
+1. **List all TODO files:**
+   - List files in `ContextDB/todos/`.
+   - **Immediately skip** files prefixed with `completed-` — these are fully done.
+   - Sort remaining files by date (newest first), extracted from the filename `YYYY-MM-DD-*-todo.md`.
+
+2. **Collect open items (up to 10):**
+   - Starting from the **most recent** active file, read it and extract all `- [ ]` lines.
+   - Collect open items into a list, tracking which file each came from.
+   - If the current file yields fewer than 10 open items, move to the **next most recent** file and continue.
+   - Stop once you have 10 open items, or you've exhausted all active files.
+
+3. **Handle fully-completed files found during scanning:**
+   - If while reading a file you discover it has **zero** `- [ ]` items (all are `- [x]`), rename it:
+     - From: `2026-02-05-backend-todo.md`
+     - To: `completed-2026-02-05-backend-todo.md`
+   - Log this to the user: "Archived `2026-02-05-backend-todo.md` — all items completed."
+   - Continue scanning the next file.
+
+4. **Present the open items:**
+
+```
+## Open TODOs (10 most recent)
+
+### From `2026-02-07-auth-refactor-todo.md` (3 open)
+1. [ ] Add login endpoint in `app/api/auth/route.ts`
+2. [ ] Create JWT utility in `lib/jwt.ts`
+3. [ ] Write auth integration tests
+
+### From `2026-02-06-general-todo.md` (4 open)
+4. [ ] Set up CI/CD pipeline
+5. [ ] Configure staging environment
+6. [ ] Add error monitoring (Sentry)
+7. [ ] Review PR #42
+
+### From `2026-02-05-ui-todo.md` (3 open)
+8. [ ] Implement dark mode toggle
+9. [ ] Fix mobile nav breakpoint
+10. [ ] Add loading skeletons to dashboard
+
+---
+Showing 10 of 15 open items across 3 files.
+Use `/opentodos` again to see the next batch, or tell me which items to work on.
+```
+
+5. **Prompt the user for a decision:**
+   - Ask which items they want to tackle now.
+   - They can refer to items by number, description, or file.
+   - Once they pick, proceed with the work (or create a focused plan).
+
+## Pagination
+
+- Each invocation shows **10 open items**.
+- If the user asks to "see more" or "next page", skip the first 10 and show the next 10.
+- Track the offset by counting items shown so far in the conversation.
+
+## Edge Cases
+
+- **No open items at all:** "All TODOs are completed! No open items found in `ContextDB/todos/`."
+- **No TODO files exist:** "No TODO files found in `ContextDB/todos/`. Use `/createtodo` to create one."
+- **Only completed files exist:** Same as no open items — mention that all files have been archived.
+
+## Guidelines
+
+- Present items clearly with numbers for easy reference.
+- Show which file each item comes from so the user has context.
+- Don't modify any items during this read-only operation (except renaming fully-completed files).
+- If an item has priority markers (`[P0]`, `[P1]`) or categories (`**backend**`), preserve them in the display.
+- Keep the output scannable — the user should be able to pick a task in under 30 seconds.

package/assets/skills/perf/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: perf
+description: "Analyze and optimize code performance. Use when the user says /perf, asks about performance, wants to optimize slow code, profile a bottleneck, reduce memory usage, or improve response times. Triggers: perf, performance, slow, optimize, bottleneck, profile, memory, latency, throughput, speed up."
+---
+
+# Performance Analyzer
+
+Identify and resolve performance bottlenecks.
+
+## Workflow
+
+1. **Understand the problem:**
+   - What is slow? (startup, specific endpoint, rendering, query, build)
+   - What are the symptoms? (high latency, high CPU, high memory, timeouts)
+   - What is the target? (e.g., "under 200ms", "half the memory")
+
+2. **Profile before optimizing:**
+   - Identify the hotspot. Never optimize blindly.
+   - Use language-appropriate profiling:
+     - **Python**: `cProfile`, `py-spy`, `memory_profiler`, `time.perf_counter`
+     - **Node.js**: `--prof`, `clinic.js`, `console.time`, `perf_hooks`
+     - **Go**: `pprof`, `go test -bench`
+     - **Rust**: `cargo bench`, `flamegraph`
+     - **General**: `time` command, `hyperfine` for benchmarks
+
+3. **Analyze the code for common issues:**
+
+### Common Performance Issues
+
+| Category | What to look for |
+|----------|-----------------|
+| **Algorithm** | O(n^2) or worse where O(n log n) exists, unnecessary sorting |
+| **Database** | N+1 queries, missing indexes, SELECT *, no pagination |
+| **I/O** | Sequential where parallel is possible, no batching, no streaming |
+| **Memory** | Large object copies, no generators/iterators, memory leaks, unbounded caches |
+| **Caching** | Repeated expensive computations, no memoization, cache stampede |
+| **Rendering** | Unnecessary re-renders, large DOM, no virtualization |
+| **Network** | No compression, no connection pooling, chatty APIs |
+| **Build** | No tree-shaking, large bundles, no code splitting |
+
+4. **Propose fixes ranked by impact:**
+   - Estimate improvement for each fix.
+   - Start with the highest-impact, lowest-effort changes.
+   - Include before/after benchmarks when possible.
+
+5. **Verify improvements:**
+   - Run benchmarks before and after.
+   - Check for regressions in correctness.
+   - Monitor for changes in memory usage.
+
+## Guidelines
+
+- Measure first, optimize second. Show numbers.
+- The biggest gains are usually algorithmic, not micro-optimizations.
+- Consider trade-offs: readability vs speed, memory vs CPU, latency vs throughput.
+- Don't optimize code that runs rarely — focus on hot paths.
+- Suggest caching strategies where appropriate but warn about invalidation complexity.
+- For database issues, show the query plan (`EXPLAIN ANALYZE`).

package/assets/skills/prd/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: prd
+description: "Generate a Product Requirements Document. Use when the user says /prd, asks to create a PRD, define product requirements, or spec out a feature. Triggers: prd, product requirements, product spec, feature spec, requirements document."
+---
+
+# Product Requirements Document (PRD)
+
+## Purpose
+
+Generate a structured Product Requirements Document that clearly defines what needs to be built, why it matters, and how success will be measured. The PRD serves as the source of truth aligning product, engineering, and design.
+
+## When to Use
+
+- Kicking off a new feature or product initiative
+- Formalizing a rough idea into a concrete proposal
+- Aligning stakeholders before engineering work begins
+
+## Inputs
+
+- **Product or feature name**: What is being built
+- **Problem context**: Background on the user pain point or business need
+- **Target audience**: Who this is for
+- **Any existing constraints**: Technical limitations, timeline, budget (optional)
+
+## Output Format
+
+Produce a markdown document with the following sections:
+
+### 1. Overview
+A one-paragraph summary of the feature or product and its purpose.
+
+### 2. Problem Statement
+Describe the problem from the user's perspective. Include evidence or context that validates the problem exists. Be specific about who is affected and how.
+
+### 3. User Stories
+List 3-8 user stories in the format:
+> As a [role], I want [capability] so that [benefit].
+
+Prioritize each story as P0 (must-have), P1 (should-have), or P2 (nice-to-have).
+
+### 4. Functional Requirements
+Numbered list of specific behaviors the system must support. Each requirement should be testable and unambiguous.
+
+### 5. Non-Functional Requirements
+Cover relevant areas: performance targets, scalability, security, accessibility, compliance, and reliability expectations.
+
+### 6. Success Metrics
+Define 3-5 measurable outcomes that indicate the feature is working. Use the format: Metric | Target | Measurement Method.
+
+### 7. Scope
+Clearly state what is **in scope** and **out of scope** for this initiative. Call out deferred items explicitly.
+
+### 8. Timeline Considerations
+Note any deadlines, phasing suggestions, or dependencies that affect scheduling. If unknown, state that timeline is TBD and list factors that will influence it.
+
+### 9. Open Questions
+List unresolved questions that need stakeholder input before finalizing.
+
+## Example
+
+**Input**: "We need a way for users to export their dashboard data as PDF reports."
+
+**Output**: A full PRD document covering the problem (users cannot share dashboard insights with stakeholders who lack platform access), user stories (export single dashboard, schedule recurring exports, customize report branding), functional requirements (PDF generation, template selection, email delivery), non-functional requirements (generation under 30 seconds, support for dashboards up to 50 widgets), success metrics (adoption rate, export completion rate, support ticket reduction), and clear scope boundaries (v1 excludes CSV export and API-based generation).
+
+## Guidelines
+
+- Write requirements that are specific and testable, not vague aspirations
+- Separate what the system does from how it does it -- leave implementation to the eng spec
+- Flag assumptions explicitly rather than embedding them silently
+- Keep the document scannable: use bullets, tables, and short paragraphs
+- Default to a single-phase scope unless the user requests phasing