@dedesfr/prompter 0.8.23 → 1.0.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/project-orchestrator/SKILL.md

@@ -1,487 +0,0 @@
----
-name: project-orchestrator
-description: Interview users to define and verify a software project plan through a structured conversation. Collects project description, MVP scope, user roles, features, tech stack, integrations, and deployment preferences. Asks minimal clarifying questions grouped logically, provides tailored recommendations after each answer, and produces a verified project plan summary. Use when a user wants to plan a new software project, define MVP scope, choose a tech stack, or create a project brief.
----
-
-# Project Orchestrator
-
-Interview the user to define a verified software project plan. Guide them through scope, features, tech stack, and deployment with minimal, focused questions. Provide a recommendation after every answer.
-
-## Quick Start
-
-1. **COLLECT** -- Ask for project description + top 3 MVP features
-2. **VERIFY** -- Walk through scope, roles, data, integrations, non-functional needs
-3. **SELECT STACK** -- Present bundled stack options, resolve sub-choices
-4. **CONFIGURE** -- Docker preference, deployment, environments
-5. **SUMMARIZE** -- Output the verified plan using the final summary template
-6. **CONFIRM** -- Ask the user to approve or correct the plan
-
----
-
-## Before You Begin (REQUIRED)
-
-Before starting the interview, **always read `prompter/AGENTS.md`** and follow its instructions. This ensures the final output is structured as a proper spec that integrates with the Prompter workflow.
-
----
-
-## Interactive Terminal Tool (REQUIRED)
-
-Use the `AskUserQuestion` tool for **every question** in the interview. This renders an interactive UI in the terminal instead of plain text, making it easier for the user to respond.
-
-### How to Use AskUserQuestion
-
-- **Single-choice questions**: Set `multiSelect: false`. Use for mutually exclusive picks (e.g., stack selection, database choice, Docker yes/no).
-- **Multi-choice questions**: Set `multiSelect: true`. Use for checklists (e.g., integrations, roles, features).
-- **Keep options concise**: Labels should be 1–5 words. Add detail in the `description` field.
-- **Always include an "Unsure" option** when the user may not know. Handle it by recommending a default.
-- **Group related sub-choices** into one `AskUserQuestion` call with multiple `questions` when they are always asked together and order doesn't matter.
-
-### Example: Stack Selection
-
-```json
-{
-  "questions": [
-    {
-      "question": "Which tech stack bundle fits your project best?",
-      "header": "Stack",
-      "multiSelect": false,
-      "options": [
-        { "label": "JS/TS Full-Stack", "description": "React or Next.js + Drizzle + Express or NestJS + PostgreSQL/MySQL" },
-        { "label": "React + Convex", "description": "React (Vite or Next.js) + Convex (real-time backend + built-in DB)" },
-        { "label": "Laravel Classic", "description": "Laravel + Blade + Tailwind + PostgreSQL/MySQL" },
-        { "label": "Laravel + React", "description": "Laravel + Inertia.js (React) + PostgreSQL/MySQL" },
-        { "label": "Laravel + Filament", "description": "Laravel + Filament (admin panel & CRUD) + Tailwind + PostgreSQL/MySQL" },
-        { "label": "Unsure", "description": "I'll recommend based on your project needs" }
-      ]
-    }
-  ]
-}
-```
-
-### Example: Integrations Checklist
-
-```json
-{
-  "questions": [
-    {
-      "question": "Which integrations or capabilities does your MVP need?",
-      "header": "Integrations",
-      "multiSelect": true,
-      "options": [
-        { "label": "Caching", "description": "e.g., Redis for fast data access" },
-        { "label": "Queues / Jobs", "description": "e.g., sending emails, processing uploads" },
-        { "label": "Real-Time", "description": "e.g., live chat, notifications, WebSockets" },
-        { "label": "File Storage", "description": "e.g., S3, local uploads" }
-      ]
-    }
-  ]
-}
-```
-
----
-
-## Core Rules
-
-- Use `AskUserQuestion` for every question -- never ask interview questions as plain text.
-- Ask one question or one small grouped set at a time. Never overwhelm.
-- After every answer (or group), provide a short recommendation tailored to what the user said.
-- Use plain language. Only introduce jargon if the user shows technical comfort.
-- If the user says "unsure", recommend a pragmatic default and explain briefly.
-- Keep optional topics gated -- only go deeper if the user says yes or unsure.
-
----
-
-## Project Setup Commands (PRIORITY)
-
-Always use these exact commands when scaffolding projects. Include the correct command in the final summary's "Recommended Next Steps" based on the chosen stack.
-
-| Technology | Command |
-|------------|---------|
-| React (Vite) | `npm create vite@latest` |
-| Next.js | `npx create-next-app@latest {project_name} --yes` |
-| Express | `npm install express --save` |
-| NestJS | `npm i -g @nestjs/cli && nest new {project_name}` |
-| Laravel 12 | `composer create-project laravel/laravel:^12.0 {project_name}` |
-| Filament | `composer require filament/filament && php artisan filament:install --panels` |
-| React + Convex | `npm create convex@latest` |
-
-**Rules:**
-- Always include the matching setup command(s) as the first recommended next step in the final plan.
-- For Bundle 1 (JS/TS Full-Stack): include the frontend command (React via Vite or Next.js) AND the backend command (Express or NestJS).
-- For Bundle 2 (React + Convex): include only `npm create convex@latest` -- it scaffolds both the React frontend and Convex backend in one step.
-- For Bundles 3 and 4 (Laravel): include only the Laravel command -- Blade, Inertia, and Tailwind are configured within the Laravel project.
-- For Bundle 5 (Laravel + Filament): include the Laravel command first, then the Filament install command (`composer require filament/filament && php artisan filament:install --panels`).
-- Never invent or substitute alternative installation commands. Use these exactly as shown.
-
----
-
-## Step 1: Project Description (REQUIRED)
-
-Open with:
-
-```
-Let's define your project. To start, tell me:
-
-1. What problem does your project solve, and who is it for?
-2. What is the desired outcome (e.g., a web app, mobile app, SaaS platform)?
-3. What are your top 3 MVP features -- the minimum needed to launch?
-```
-
-Wait for the user's response. Summarize what you understood and give a brief recommendation (e.g., "This sounds like a good fit for a standard web app with auth and a dashboard. Let's verify the details.").
-
----
-
-## Step 2: MVP Scope Confirmation
-
-Based on the user's description, present a draft scope:
-
-```
-Here's what I'd put in scope for the MVP:
-
-**In scope:**
-- [feature 1]
-- [feature 2]
-- [feature 3]
-
-**Out of scope (for later):**
-- [deferred item 1]
-- [deferred item 2]
-
-Does this match your expectations? Anything to add or move?
-```
-
-Recommendation: Briefly explain why you deferred certain items (e.g., "Reporting dashboards add complexity -- better to ship core functionality first and add analytics in v2.").
-
----
-
-## Step 3: Users & Roles
-
-Ask:
-
-```
-Who will use this application? For example:
-- Public visitors (unauthenticated)
-- Registered users
-- Admins
-- Other roles (e.g., moderators, vendors, managers)
-
-Which roles does the MVP need?
-```
-
-Recommendation: Suggest a minimal role set (e.g., "For MVP, I'd recommend just User + Admin. You can add granular roles later without rearchitecting.").
-
----
-
-## Step 4: Data & Content Types
-
-Ask:
-
-```
-What are the main things your app manages? For example:
-- Users / profiles
-- Products / listings
-- Orders / bookings
-- Posts / articles
-- Messages / notifications
-
-List the key entities your MVP needs to store and manage.
-```
-
-Recommendation: Sketch a quick high-level data model (e.g., "So we'd have Users, Products, and Orders as core entities, with Orders linking Users to Products.").
-
----
-
-## Step 5: Integrations & Optional Capabilities
-
-Present optional topics as a checklist. Do NOT deep-dive unless the user says yes or unsure.
-
-```
-Do you need any of the following? (Yes / No / Unsure for each)
-
-1. Caching (e.g., Redis for fast data access)
-2. Queues / background jobs (e.g., sending emails, processing uploads)
-3. Real-time features (e.g., live chat, notifications, WebSockets)
-4. Full-text search (e.g., Elasticsearch, Algolia, Meilisearch)
-5. File storage / uploads (e.g., S3, local storage)
-6. Email or SMS notifications
-7. Analytics / event tracking
-8. Payments (e.g., Stripe, PayPal)
-9. Third-party integrations (e.g., social login, maps, calendar)
-```
-
-For each "yes" or "unsure":
-- Ask which service they prefer (or recommend one).
-- Give a 1-2 sentence recommendation (e.g., "For queues, Redis with a simple job runner is the easiest starting point. You can scale to dedicated queue services later.").
-
-For each "no": Move on. Don't push.
-
----
-
-## Step 6: Non-Functional Requirements
-
-Ask as a grouped set:
-
-```
-A few quick questions about non-functional needs:
-
-1. **Security**: Any specific requirements beyond standard auth? (e.g., 2FA, encryption at rest, compliance like GDPR/HIPAA)
-2. **Performance**: Expected traffic volume? (e.g., <1k users, 1k-10k, 10k+)
-3. **SEO**: Does this app need to rank in search engines? (important for stack choice)
-```
-
-Recommendation: Tailor to their answers (e.g., "With SEO needs, server-side rendering will matter -- that'll influence our stack choice next." or "At <1k users, you won't need to worry about caching or CDN right away.").
-
----
-
-## Step 7: Tech Stack Selection (REQUIRED)
-
-Present exactly these bundled options:
-
-```
-Let's pick your tech stack. Here are four proven bundles:
-
-1. **JS/TS Full-Stack**: React or Next.js + Drizzle ORM + Express or NestJS + MySQL or PostgreSQL
-2. **React + Convex**: React (Vite or Next.js) + Convex (real-time backend + built-in document DB, no SQL setup needed)
-3. **Laravel Classic**: Laravel + Blade + Tailwind CSS + MySQL or PostgreSQL
-4. **Laravel + React**: Laravel + Inertia.js (React) + MySQL or PostgreSQL
-5. **Laravel + Filament**: Laravel + Filament (admin panel & CRUD generator) + Tailwind CSS + MySQL or PostgreSQL
-
-Which bundle fits your project best? (Pick 1-5, or say "unsure")
-```
-
-If unsure: Recommend based on what you've learned (e.g., "Since you need SEO and prefer a simpler setup, I'd go with Laravel Classic -- it's fast to build, great for server-rendered pages, and has excellent built-in tooling." Or "If you want real-time features out of the box with minimal backend setup, React + Convex is a great choice." Or "If your app is primarily an admin panel, back-office tool, or data management system, Laravel + Filament gives you a complete CRUD interface with minimal custom frontend work.").
-
-### Sub-Choices
-
-After the user picks a bundle, ask ONLY the necessary sub-choices:
-
-**Bundle 1 sub-choices:**
-- Next.js vs React SPA? (Recommend Next.js if SEO matters or if they want SSR; React SPA if it's a dashboard/internal tool)
-- Express vs NestJS? (Recommend Express for simplicity and speed; NestJS if they want structure and the app is complex)
-- MySQL vs PostgreSQL? (Recommend PostgreSQL as the default -- richer features, JSON support, better for most new projects. Recommend MySQL if team is already familiar or hosting is MySQL-only)
-
-**Bundle 2 sub-choices:**
-- Next.js vs React (Vite)? (Recommend Next.js if SEO matters; Vite if it's a dashboard or real-time app where SSR isn't needed)
-- No database sub-choice needed -- Convex includes a built-in document database with real-time sync.
-- **Convex hosting**: Convex Cloud (managed, easiest) vs Self-Hosted (Docker, full control)? (Recommend Convex Cloud for most projects -- zero infrastructure overhead. Recommend Self-Hosted if the user needs data sovereignty, air-gapped environments, or wants to avoid vendor lock-in.)
-- **Convex storage backend** (Self-Hosted only): SQLite vs Postgres?
-  - **SQLite** — single file on disk, zero config. Fine for dev/hobby projects up to ~1–2 GB data on a single server. Back up by copying the file.
-  - **Postgres** — networked database. Required for production: handles concurrent connections, proper backups (`pg_dump` to S3/R2), point-in-time recovery, and horizontal scaling. Add a `postgres` service to `docker-compose.yml` and pass `DATABASE_URL` to Convex.
-  - **Important framing**: Postgres is Convex's *storage engine*, not your application database. You never write SQL or query Postgres directly — Convex reads/writes its own internal format there. You only touch Postgres for ops: running the container and taking backups.
-  - Recommend Postgres for any self-hosted project with real users. Recommend SQLite only for solo dev environments or throwaway prototypes.
-
-**Bundle 3 sub-choices:**
-- MySQL vs PostgreSQL? (Same guidance as above)
-
-**Bundle 4 sub-choices:**
-- MySQL vs PostgreSQL? (Same guidance as above)
-
-**Bundle 5 sub-choices:**
-- MySQL vs PostgreSQL? (Same guidance as above)
-- Filament panels: Admin only, or also a user-facing app panel? (Recommend admin-only for MVP -- add a user-facing panel later if needed. If the user needs a public-facing frontend beyond Filament, suggest combining with Blade or consider Bundle 4 instead.)
-
-Provide a brief recommendation for each sub-choice based on the project's stated needs.
-
----
-
-## Step 8: Docker Preference (REQUIRED)
-
-Always ask:
-
-```
-Do you want Docker for this project? (Yes / No / Unsure)
-
-Quick context: Docker makes it easy to set up identical dev environments across machines and simplifies deployment. The tradeoff is a small learning curve and slightly more setup upfront.
-```
-
-If unsure: Recommend based on team size and deployment target (e.g., "For a solo project deploying to a single VPS, Docker is optional. For a team or cloud deployment, I'd recommend it.").
-
-### Web Server / Reverse Proxy Guidelines
-
-When Docker is used and a web server or reverse proxy is needed (e.g., for Laravel, Express, NestJS, or a Dockerized frontend):
-
-- **Always use Caddy** as the web server and reverse proxy -- do NOT use or recommend Nginx or Apache.
-- Caddy automatically handles HTTPS (via Let's Encrypt or ZeroSSL) in production with zero extra configuration.
-- 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 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. **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 (`/etc/caddy/Caddyfile`) routes by domain:
-
-```caddy
-project-a.com {
-    reverse_proxy localhost:3001
-}
-
-project-b.com {
-    reverse_proxy localhost:3002
-}
-```
-
-4. After editing the Caddyfile, reload with `sudo systemctl reload caddy`.
-
-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.
-
-### Laravel + Docker Guidelines
-
-When the user chooses a Laravel stack (Bundle 3, 4, or 5) with Docker:
-
-- **Use regular Docker and Docker Compose** -- do NOT use or recommend Laravel Sail. Set up a standard `Dockerfile` and `docker-compose.yml` with services for the app, database, and any other dependencies (e.g., Redis).
-- **Use Supervisor** for managing background processes inside the container. Laravel workers like `php artisan queue:work` must run continuously -- Supervisor ensures they stay alive and restart on failure. Include a `supervisord.conf` that manages:
-  - `php artisan queue:work` (queue worker)
-  - Any other long-running processes the project needs (e.g., scheduler via `php artisan schedule:work`)
-- Mention this in the final plan summary under the Docker row and in the recommended next steps.
-
-### Convex Self-Hosted Guidelines
-
-When the user chooses React + Convex (Bundle 2) with **self-hosted** deployment:
-
-- **Storage backend**: Include in `docker-compose.yml` based on what the user chose:
-  - **SQLite** (dev/hobby): No extra service needed — Convex stores data in a local SQLite file inside the container. Mount a volume to persist it across restarts.
-  - **Postgres** (production): Add a `postgres` service (e.g., `postgres:16`) and pass `DATABASE_URL` to the Convex container. Postgres is Convex's internal filing cabinet — the user's data lives in `document_json` columns managed by Convex, not in SQL tables they'd recognize. The user never writes SQL; they only run `pg_dump` for backups.
-- **Use Docker Compose** with two Convex services:
-  - `convex` — backend image `ghcr.io/get-convex/convex-backend:latest`
-  - `convex-dashboard` — dashboard image `ghcr.io/get-convex/convex-dashboard:latest`
-- **Two environment files** are required:
-  - `.env.dev` (Docker Compose config) — contains `CONVEX_PORT`, `CONVEX_DASHBOARD_PORT`, `CONVEX_DASHBOARD_UI_PORT`, `VITE_CONVEX_URL`, `CONVEX_ADMIN_KEY`, `CONVEX_CLOUD_ORIGIN`, `CONVEX_SITE_ORIGIN`
-  - `.env.local` (CLI and frontend, never committed) — contains `VITE_CONVEX_URL`, `CONVEX_SELF_HOSTED_URL`, `CONVEX_SELF_HOSTED_ADMIN_KEY`
-- **Admin key generation**: After starting the backend, generate the CLI admin key from the running container:
-  ```bash
-  docker compose --env-file .env.dev exec convex ./generate_admin_key.sh
-  ```
-  Copy the printed `convex-self-hosted|...` value into `.env.local` as `CONVEX_SELF_HOSTED_ADMIN_KEY`. Never use a random string or the Docker `CONVEX_ADMIN_KEY` value directly for CLI use.
-- **Add a deploy script** to `package.json`:
-  ```json
-  "deploy:selfhosted": "convex deploy --url $CONVEX_SELF_HOSTED_URL --admin-key $CONVEX_SELF_HOSTED_ADMIN_KEY"
-  ```
-- **Reserved index names**: Self-hosted Convex does not allow reserved index names such as `by_id`. Rename them to non-reserved names (e.g., `by_external_id`) before deploying.
-- **Frontend wiring**: The frontend reads `VITE_CONVEX_URL` at build time. Ensure this value is reachable by the browser and is passed as a Docker build argument when building the frontend image.
-- Mention this setup in the final plan summary under the Docker/Convex row and in the recommended next steps.
-
----
-
-## Step 9: Deployment & Hosting
-
-Ask:
-
-```
-Where do you plan to deploy?
-
-Common options:
-- **VPS** (e.g., DigitalOcean, Hetzner, Linode) -- most flexible, you manage the server
-- **PaaS** (e.g., Railway, Render, Fly.io) -- easier, less control
-- **Cloud** (e.g., AWS, GCP, Azure) -- most scalable, most complex
-- **Shared hosting** (e.g., cPanel) -- cheapest, limited
-
-Also: do you need separate environments? (e.g., dev / staging / production)
-```
-
-Recommendation: Match to their context (e.g., "For an MVP with a small team, a VPS or PaaS like Railway keeps things simple. You can migrate to AWS later if you need to scale.").
-
----
-
-## Step 10: Final Summary (REQUIRED)
-
-After all questions are answered, produce the verified plan using the template in `assets/plan-summary-template.md`.
-
-Present it to the user and ask (using `AskUserQuestion`):
-
-```json
-{
-  "questions": [
-    {
-      "question": "Does this project plan look correct?",
-      "header": "Plan Review",
-      "multiSelect": false,
-      "options": [
-        { "label": "Looks good", "description": "Approve and save the plan" },
-        { "label": "Needs changes", "description": "I'll tell you what to correct" }
-      ]
-    }
-  ]
-}
-```
-
-Iterate if the user requests changes. The plan is final only when the user confirms.
-
-### Save the Plan (REQUIRED)
-
-Once the user approves, **write the final plan to `prompter/project-plan.md`** using the Write tool. Use the filled-in plan summary template as the file content.
-
-```
-Write the approved plan content to: prompter/project-plan.md
-```
-
-After saving, confirm to the user:
-
-```
-Your project plan has been saved to prompter/project-plan.md.
-```
-
-### Proposal Creation (Conditional)
-
-After confirming the plan is saved, check whether the proposal feature is installed by verifying that `prompter/core/proposal.md` exists (use the Glob tool). If the file does not exist, skip this section entirely.
-
-If the file exists, ask the user using `AskUserQuestion`:
-
-```json
-{
-  "questions": [
-    {
-      "question": "Would you like to create a Prompter change proposal based on this project plan?",
-      "header": "Create Proposal",
-      "multiSelect": false,
-      "options": [
-        { "label": "Yes, create a proposal", "description": "Scaffold a change proposal using the project plan as context" },
-        { "label": "No, skip", "description": "I'll create the proposal manually later" }
-      ]
-    }
-  ]
-}
-```
-
-If the user agrees, read `prompter/core/proposal.md` and `prompter/AGENTS.md` and follow their instructions to scaffold the proposal. Use the approved project plan from `prompter/project-plan.md` as the source of context (e.g., to derive the change-id, capabilities, requirements, and tasks).
-
----
-
-## Conversation Tips
-
-### Handling "I don't know" / "Unsure"
-- Always recommend a sensible default.
-- Explain the recommendation in 1-2 sentences.
-- Frame it as: "You can always change this later."
-
-### Handling Overly Complex Requests
-- Gently suggest deferring non-essential features.
-- Use: "That's a great v2 feature. For MVP, I'd recommend [simpler alternative]."
-
-### Handling Very Technical Users
-- Skip basic explanations if the user demonstrates expertise.
-- Engage at their level -- discuss tradeoffs, not definitions.
-
-### Handling Non-Technical Users
-- Avoid jargon. Use analogies when helpful.
-- Make decisions for them when they're stuck, but always explain why.
-
----
-
-## 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)