@dedesfr/prompter 0.8.22 → 0.9.0

package/skills/product-brief/SKILL.md

@@ -0,0 +1,141 @@
+---
+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

package/skills/project-orchestrator/SKILL.md

@@ -305,13 +305,13 @@ When Docker is used and a web server or reverse proxy is needed (e.g., for Larav
 - For local development, Caddy serves HTTP by default -- no certificate setup needed.
 - Mention Caddy in the final plan summary under the Docker/web server row and in the recommended next steps.
 
-**Always use a standalone host-level Caddy** -- do NOT embed Caddy inside a project's `docker-compose.yml`. Even for a single project today, users commonly add more projects later, and a per-project Caddy would conflict on ports 80/443.
+**Always install Caddy directly on the host** (via the OS package manager) -- do NOT run Caddy inside Docker. Running Caddy on the host avoids Docker network overhead, survives Docker daemon restarts, and is managed by systemd automatically. Do NOT embed Caddy in any project's `docker-compose.yml`.
 
 The correct setup:
 
-1. **One standalone Caddy on the host** (installed directly or in its own `docker-compose.yml` folder) owns ports 80/443 and terminates TLS for all domains.
+1. **Caddy installed on the host** via `apt install caddy` (Ubuntu/Debian) or equivalent. Systemd manages it -- starts on boot, restarts on failure.
 2. **Each project exposes only an internal port** (e.g., `3001`, `3002`) -- no `ports: - "80:80"` in their `docker-compose.yml`.
-3. The host Caddyfile routes by domain:
+3. The host Caddyfile (`/etc/caddy/Caddyfile`) routes by domain:
 
 ```caddy
 project-a.com {
@@ -323,10 +323,18 @@ project-b.com {
 }
 ```
 
-During Step 9 (Deployment), ask whether Caddy is already running on the VPS:
+4. After editing the Caddyfile, reload with `sudo systemctl reload caddy`.
 
-- **Yes** -- skip installing Caddy. Just add a new block to the existing host Caddyfile for the new domain, then run `caddy reload`. Include only this step in the recommended next steps.
-- **No** -- include the full Caddy install and Caddyfile setup in the recommended next steps.
+During Step 9 (Deployment), ask whether Caddy is already installed on the VPS:
+
+- **Yes** -- skip installing Caddy. Just add a new block to `/etc/caddy/Caddyfile` for the new domain, then run `sudo systemctl reload caddy`. Include only this step in the recommended next steps.
+- **No** -- include the full Caddy install in the recommended next steps:
+  ```bash
+  sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
+  curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
+  curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
+  sudo apt update && sudo apt install caddy
+  ```
 
 Include the appropriate Caddy setup in the final plan summary and recommended next steps.
 
@@ -476,3 +484,4 @@ If the user agrees, read `prompter/core/proposal.md` and `prompter/AGENTS.md` an
 ## Resources
 
 - **Plan summary template**: [plan-summary-template.md](assets/plan-summary-template.md) -- Structured output format for the final verified plan
+- **Caddy VPS setup guide**: [caddy-vps-setup.md](assets/caddy-vps-setup.md) -- Step-by-step guide for installing and managing Caddy on a VPS (share this with users who are unfamiliar with VPS operations)

package/skills/project-orchestrator/assets/caddy-vps-setup.md

@@ -0,0 +1,180 @@
+# Caddy Setup on a VPS (Step-by-Step)
+
+This guide walks you through installing and managing Caddy as a reverse proxy on a Ubuntu/Debian VPS. Caddy automatically handles HTTPS for all your domains — no manual SSL certificate setup needed.
+
+---
+
+## Prerequisites
+
+Before starting, make sure:
+
+1. You have a VPS running **Ubuntu 22.04 or Debian 12** (or newer).
+2. You have SSH access to the VPS as a user with `sudo` privileges.
+3. Your domain's **A record points to your VPS IP address** (set this in your domain registrar's DNS panel). DNS changes can take up to 30 minutes to propagate.
+
+---
+
+## Step 1: Connect to Your VPS
+
+Open a terminal and connect via SSH:
+
+```bash
+ssh your-user@your-vps-ip
+```
+
+---
+
+## Step 2: Install Caddy
+
+Run these commands one by one:
+
+```bash
+sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
+
+curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' \
+  | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
+
+curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' \
+  | sudo tee /etc/apt/sources.list.d/caddy-stable.list
+
+sudo apt update && sudo apt install caddy
+```
+
+Verify the install:
+
+```bash
+caddy version
+```
+
+You should see a version number like `v2.x.x`.
+
+---
+
+## Step 3: Check That Caddy Is Running
+
+Caddy starts automatically after install. Confirm it's active:
+
+```bash
+sudo systemctl status caddy
+```
+
+Look for `Active: active (running)`. If it's not running, start it:
+
+```bash
+sudo systemctl start caddy
+sudo systemctl enable caddy   # make it start on boot
+```
+
+---
+
+## Step 4: Open Firewall Ports
+
+Allow HTTP and HTTPS traffic:
+
+```bash
+sudo ufw allow 80
+sudo ufw allow 443
+sudo ufw allow 22    # keep SSH open
+sudo ufw enable
+sudo ufw status
+```
+
+---
+
+## Step 5: Configure Your First Domain
+
+The Caddy config file lives at `/etc/caddy/Caddyfile`. Open it:
+
+```bash
+sudo nano /etc/caddy/Caddyfile
+```
+
+Replace the default content with:
+
+```caddy
+your-domain.com {
+    reverse_proxy localhost:3001
+}
+```
+
+> Replace `your-domain.com` with your actual domain, and `3001` with the port your app is running on.
+
+Save and close: press `Ctrl+X`, then `Y`, then `Enter`.
+
+---
+
+## Step 6: Reload Caddy
+
+Apply the new config without downtime:
+
+```bash
+sudo systemctl reload caddy
+```
+
+Caddy will automatically obtain an SSL certificate for your domain. Visit `https://your-domain.com` — it should work with HTTPS out of the box.
+
+---
+
+## Adding a New Project Later
+
+When you deploy a new project on the same VPS, just add a new block to the Caddyfile:
+
+```bash
+sudo nano /etc/caddy/Caddyfile
+```
+
+Add below the existing block:
+
+```caddy
+your-domain.com {
+    reverse_proxy localhost:3001
+}
+
+another-project.com {
+    reverse_proxy localhost:3002
+}
+```
+
+Then reload:
+
+```bash
+sudo systemctl reload caddy
+```
+
+Each project gets its own SSL certificate automatically.
+
+---
+
+## Common Commands
+
+| Task | Command |
+|------|---------|
+| Check Caddy status | `sudo systemctl status caddy` |
+| Reload after config change | `sudo systemctl reload caddy` |
+| Restart Caddy | `sudo systemctl restart caddy` |
+| View live logs | `sudo journalctl -u caddy -f` |
+| Validate config before reload | `caddy validate --config /etc/caddy/Caddyfile` |
+| View current config | `cat /etc/caddy/Caddyfile` |
+
+---
+
+## Troubleshooting
+
+**HTTPS not working / certificate error**
+- Check that your domain's A record points to the VPS IP: `dig your-domain.com`
+- Make sure ports 80 and 443 are open: `sudo ufw status`
+- Check Caddy logs for errors: `sudo journalctl -u caddy -f`
+
+**502 Bad Gateway**
+- Your app is not running or not listening on the expected port.
+- Check that your Docker containers are up: `docker compose ps`
+- Verify the port in your Caddyfile matches the port your app exposes.
+
+**Port already in use**
+- Another process (e.g., Apache or Nginx) may be using port 80/443.
+- Check: `sudo ss -tlnp | grep -E ':80|:443'`
+- Stop the conflicting service: `sudo systemctl stop nginx` or `sudo systemctl stop apache2`
+
+**Config change not taking effect**
+- Always run `sudo systemctl reload caddy` after editing the Caddyfile.
+- Validate first to catch syntax errors: `caddy validate --config /etc/caddy/Caddyfile`

package/skills/proposal/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: proposal
+description: Create a new change proposal with spec deltas
+---
+
+<!-- PROMPTER:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `prompter/AGENTS.md` (located inside the `prompter/` directory—run `ls prompter` if you don't see it) if you need additional Prompter conventions or clarifications.
+- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
+- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.
+
+**Steps**
+1. Review `prompter/project.md`, run `prompter list` and `prompter list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
+2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `prompter/changes/<id>/`.
+3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
+4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
+5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
+6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
+7. Validate with `prompter validate <id> --strict` and resolve every issue before sharing the proposal.
+
+**Reference**
+- Use `prompter show <id> --json --deltas-only` or `prompter show <spec> --type spec` to inspect details when validation fails.
+- Search existing requirements with `rg -n "Requirement:|Scenario:" prompter/specs` before writing new ones.
+- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
+<!-- PROMPTER:END -->
+

package/skills/qa-test-scenario/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: qa-test-scenario
+description: Generate focused QA test scenarios from PRD
+---
+
+# Role & Expertise
+You are a Senior QA Architect and Test Strategy Expert with extensive experience in creating focused, actionable test plans. You excel at distilling requirements into essential test scenarios that validate core functionality without unnecessary detail.
+
+# Context
+You will receive a Product Requirements Document (PRD) that outlines features and requirements. Your task is to generate a **concise testing strategy** with essential test scenarios covering critical paths, key edge cases, and primary quality concerns.
+
+# Primary Objective
+Create a focused testing document that covers the most important functional requirements, critical user flows, high-risk edge cases, and key quality attributes. Prioritize clarity and actionability over exhaustive coverage.
+
+# Process
+
+## 1. PRD Analysis (Focus on Essentials)
+- Identify **core features** and **critical user flows**
+- Extract **must-have acceptance criteria** only
+- Note **high-risk areas** and integration points
+- Skip minor edge cases and cosmetic details
+
+## 2. Test Scenario Generation (Strategic Coverage)
+
+Generate only:
+
+**Critical Happy Path** (2-3 scenarios per feature)
+- Primary user journey validation
+- Core functionality verification
+
+**High-Risk Edge Cases** (1-2 per feature)
+- Data boundary conditions
+- Error states that impact functionality
+- Integration failure points
+
+**Key Quality Checks** (as needed)
+- Performance bottlenecks
+- Security vulnerabilities
+- Critical usability issues
+
+**Skip:** Low-priority edge cases, cosmetic issues, obvious validations
+
+## 3. Scenario Documentation (Streamlined Format)
+Each scenario includes only:
+- **ID & Story**: TS-[#] | [Feature Name]
+- **Type**: Functional, Edge Case, Performance, Security
+- **Priority**: CRITICAL or HIGH only
+- **Test Steps**: 3-5 key actions
+- **Expected Result**: One clear outcome
+- **Notes**: Only if critical context needed
+
+# Input Specifications
+- **PRD Document**: User stories, features, acceptance criteria
+- **Format**: Any structured or narrative format
+- **Focus**: Extract essential requirements only
+
+# Output Requirements
+
+## Concise Format Structure
+
+### Test Coverage Summary (Compact)
+
+## Test Coverage Overview
+- **Features Covered**: [#] core features
+- **Total Scenarios**: [X] (targeting 20-30 scenarios max for typical features)
+- **Critical Path**: [X] scenarios
+- **High-Risk Edge Cases**: [X] scenarios
+- **Priority Distribution**: CRITICAL: [X] | HIGH: [X]
+
+---
+
+### Essential Test Scenarios
+
+| ID | Feature | Scenario | Type | Priority | Steps | Expected Result |
+|----|---------|----------|------|----------|-------|-----------------|
+| TS-01 | [Name] | [Brief description] | Functional | CRITICAL | 1. [Action]<br>2. [Action]<br>3. [Verify] | [Clear outcome] |
+| TS-02 | [Name] | [Brief description] | Edge Case | HIGH | 1. [Action]<br>2. [Action]<br>3. [Verify] | [Clear outcome] |
+
+---
+
+### Performance & Environment Notes (If Applicable)
+
+**Performance Criteria:**
+- [Key metric]: [Threshold]
+- [Key metric]: [Threshold]
+
+**Test Environments:**
+- [Platform 1]: [Critical versions only]
+- [Platform 2]: [Critical versions only]
+
+---
+
+### Test Data Requirements (Essential Only)
+
+- [Critical data type]: [Min specification]
+- [Edge case data]: [Key examples]
+
+---
+
+### Execution Notes
+
+**Prerequisites:**
+- [Essential setup only]
+
+**Key Dependencies:**
+- [Critical blockers only]
+
+# Quality Standards
+
+- **Focus on risk**: Cover high-impact scenarios, skip obvious validations
+- **Be concise**: 3-5 test steps maximum per scenario
+- **Prioritize ruthlessly**: Only CRITICAL and HIGH priority items
+- **Target scope**: 15-30 scenarios for typical features, 30-50 for complex products
+- **Clear outcomes**: One measurable result per scenario
+
+# Special Instructions
+
+## Brevity Rules
+- **Omit** detailed preconditions unless critical
+- **Omit** low-priority scenarios entirely
+- **Omit** obvious test data specifications
+- **Omit** exhaustive device/browser matrices (note key platforms only)
+- **Combine** related scenarios where logical
+
+## Prioritization (Strict)
+Include only:
+- **CRITICAL**: Core functionality, security, data integrity
+- **HIGH**: Primary user flows, high-risk integrations
+- **OMIT**: Medium/Low priority items
+
+## Smart Assumptions
+- Standard validation (email format, required fields) is assumed tested
+- Basic UI functionality is assumed working
+- Focus on **what could break** or **what's unique** to this feature
+
+# Output Delivery
+
+Generate a **concise** testing document (targeting 50-150 lines for simple features, 150-300 for complex features). Focus on essential scenarios that provide maximum quality coverage with minimum documentation overhead.
+
+## WORKFLOW STEPS
+1. Read the user's input (PRD or requirements)
+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 QA test scenarios following all requirements above
+5. Save the test scenarios to `prompter/<slug>/qa-test-scenarios.md`
+6. Report the saved file path
+
+## REFERENCE
+- Read `prompter/project.md` for project context if needed