@dedesfr/prompter 0.8.7 → 0.8.9

package/skills/feature-planner/SKILL.md

@@ -0,0 +1,305 @@
+---
+name: feature-planner
+description: Plan feature development on existing projects. Interview users about what they want to build, analyze the codebase to understand tech stack, patterns, and affected areas, then produce a structured implementation plan with phased tasks. Optionally scaffolds a Prompter change proposal. Use when a user wants to add a feature, make a change, or plan development work on a project that already exists.
+---
+
+# Feature Developer
+
+Interview the user about what they want to build, analyze the existing codebase, then produce a phased implementation plan with concrete tasks and file references.
+
+## Quick Start
+
+1. **DESCRIBE** -- Ask what the user wants to build and why
+2. **ANALYZE** -- Scan the codebase: structure, tech stack, patterns, existing specs
+3. **SCOPE** -- Present what's in/out of scope, identify affected files
+4. **PLAN** -- Break down into phased implementation tasks
+5. **REVIEW** -- Present the plan and iterate until approved
+6. **PROPOSAL** -- Optionally create a Prompter change proposal
+
+---
+
+## Before You Begin (REQUIRED)
+
+Before starting the interview:
+
+1. **Read `AGENTS.md`** at the project root (if it exists) to understand the tech stack, conventions, and architecture.
+2. **Read `prompter/project.md`** (if it exists) to understand project conventions.
+3. **Scan the project structure** using Glob to understand the directory layout and key files.
+
+Store what you learn -- you'll reference it when identifying affected files and patterns.
+
+---
+
+## Interactive Terminal Tool (REQUIRED)
+
+Use the `AskUserQuestion` tool for **every question** in the interview. This renders an interactive UI in the terminal.
+
+### How to Use AskUserQuestion
+
+- **Single-choice questions**: Set `multiSelect: false`. Use for yes/no, pick-one decisions.
+- **Multi-choice questions**: Set `multiSelect: true`. Use for checklists.
+- **Free-text input**: When you need the user to describe something open-ended (like the feature itself), ask as a plain message and wait for their response. Only use `AskUserQuestion` for structured choices.
+- **Keep options concise**: Labels should be 1-5 words. Add detail in the `description` field.
+
+---
+
+## Core Rules
+
+- Use `AskUserQuestion` for every structured question -- never ask choice questions as plain text.
+- Ask one question or one small grouped set at a time. Never overwhelm.
+- After every answer, acknowledge what you understood before moving on.
+- Ground every suggestion in what you observed in the codebase -- don't guess patterns.
+- If unsure about something, look at the code before asking the user.
+- Keep the interview short -- 3 to 5 questions max before producing the plan.
+
+---
+
+## Step 1: Feature Description (REQUIRED)
+
+Open with:
+
+```
+What feature or change do you want to build? Tell me:
+
+1. What it does (the user-visible behavior or system change)
+2. Why you need it (the problem it solves or value it adds)
+3. Any constraints or preferences (e.g., "must use existing auth system", "keep it simple")
+```
+
+Wait for the user's response. Summarize what you understood in 2-3 sentences.
+
+---
+
+## Step 2: Codebase Analysis (REQUIRED)
+
+After understanding the feature, **silently analyze the codebase**. Do NOT ask the user about the tech stack -- discover it yourself.
+
+### What to Analyze
+
+1. **Project structure** -- Use Glob to map the directory layout (e.g., `src/**`, `app/**`, `resources/**`)
+2. **Tech stack** -- Identify framework, language, database, styling from config files:
+   - `package.json`, `composer.json`, `Cargo.toml`, `go.mod`, `requirements.txt`
+   - Framework configs: `next.config.*`, `vite.config.*`, `artisan`, `convex/`
+   - Database: migrations folder, schema files, ORM config
+3. **Existing patterns** -- Read 2-3 files similar to what you'll need to create/modify:
+   - If adding an API endpoint, read an existing endpoint
+   - If adding a UI component, read an existing component
+   - If adding a model, read an existing model
+4. **Related code** -- Use Grep to find code related to the feature (e.g., if adding notifications, search for existing notification code)
+5. **Existing specs** -- Check `prompter/specs/` for relevant capability specs
+
+### Present Findings
+
+After analysis, present a brief summary:
+
+```
+Here's what I found in your codebase:
+
+**Stack**: [e.g., Laravel 12 + Filament + PostgreSQL + Docker]
+**Structure**: [e.g., Standard Laravel with domain-driven modules under app/Domains/]
+**Relevant patterns**:
+- [e.g., Controllers follow single-action pattern (app/Http/Controllers/)]
+- [e.g., All models use UUIDs as primary keys]
+- [e.g., Tests use Pest with factories]
+
+**Related existing code**:
+- [e.g., Similar notification system exists at app/Notifications/]
+- [e.g., No existing code for webhooks -- this is net new]
+```
+
+Then ask using `AskUserQuestion`:
+
+```json
+{
+  "questions": [
+    {
+      "question": "Does this look right? Anything I missed about how your project works?",
+      "header": "Codebase Analysis",
+      "multiSelect": false,
+      "options": [
+        { "label": "Looks correct", "description": "Move on to scoping" },
+        { "label": "Need to correct something", "description": "I'll clarify what's different" }
+      ]
+    }
+  ]
+}
+```
+
+If the user corrects something, update your understanding and move on.
+
+---
+
+## Step 3: Scope & Affected Areas
+
+Based on the feature description and codebase analysis, present the scope:
+
+```
+Here's what I'd include for this feature:
+
+**In scope:**
+- [change 1]
+- [change 2]
+- [change 3]
+
+**Out of scope (can do later):**
+- [deferred item 1] -- [reason]
+
+**Files that will be affected:**
+- `path/to/file.ext` -- [what changes: new / modify / delete]
+- `path/to/file.ext` -- [what changes]
+```
+
+Then ask:
+
+```json
+{
+  "questions": [
+    {
+      "question": "Does this scope match what you had in mind?",
+      "header": "Feature Scope",
+      "multiSelect": false,
+      "options": [
+        { "label": "Looks good", "description": "Proceed to implementation plan" },
+        { "label": "Too much", "description": "I want to trim the scope" },
+        { "label": "Missing something", "description": "I'll tell you what to add" }
+      ]
+    }
+  ]
+}
+```
+
+Iterate until the user confirms the scope.
+
+---
+
+## Step 4: Implementation Plan (REQUIRED)
+
+Produce the implementation plan using the template in `assets/implementation-plan-template.md`.
+
+### Planning Rules
+
+- **Phase tasks logically**: database/schema first, then backend logic, then frontend, then tests.
+- **Reference specific files**: Every task should mention the file path where the work happens. Use existing file paths for modifications; propose paths that follow existing conventions for new files.
+- **Follow existing patterns**: If the project uses a specific pattern (e.g., repository pattern, single-action controllers), your plan must follow it.
+- **Be concrete**: "Create UserNotification model with `user_id`, `type`, `message`, `read_at` columns" is better than "Create notification model".
+- **Include test tasks**: Always include at least one testing phase.
+- **Keep it achievable**: Aim for a plan that can be completed in a single session. If the feature is large, suggest splitting it and plan only the first part.
+
+### Present the Plan
+
+Output the filled-in implementation plan template, then ask:
+
+```json
+{
+  "questions": [
+    {
+      "question": "Does this implementation plan look correct?",
+      "header": "Plan Review",
+      "multiSelect": false,
+      "options": [
+        { "label": "Approved", "description": "Save the plan and optionally create a proposal" },
+        { "label": "Needs changes", "description": "I'll tell you what to adjust" }
+      ]
+    }
+  ]
+}
+```
+
+Iterate if the user requests changes.
+
+---
+
+## Step 5: Save & Next Steps (REQUIRED)
+
+Once approved, save the plan based on what's available in the project.
+
+### If Prompter is installed
+
+Check whether `prompter/core/proposal.md` exists using Glob.
+
+If it exists, ask:
+
+```json
+{
+  "questions": [
+    {
+      "question": "How would you like to proceed?",
+      "header": "Next Steps",
+      "multiSelect": false,
+      "options": [
+        { "label": "Create proposal", "description": "Scaffold a Prompter change proposal from this plan" },
+        { "label": "Start building", "description": "Jump straight into implementation using this plan" },
+        { "label": "Save plan only", "description": "Save the plan to a file for later" }
+      ]
+    }
+  ]
+}
+```
+
+**If "Create proposal"**: Read `prompter/core/proposal.md` and `prompter/AGENTS.md`, then follow their instructions to scaffold a full change proposal. Use the implementation plan as context to derive:
+- `change-id` (verb-led, kebab-case)
+- `proposal.md` (why, what changes, impact)
+- `tasks.md` (from the implementation phases)
+- `design.md` (only if needed per Prompter criteria)
+- Spec deltas under `specs/[capability]/spec.md`
+
+After scaffolding, run `prompter validate <change-id> --strict --no-interactive` and fix any issues.
+
+**If "Start building"**: Begin implementing the tasks from the plan sequentially. Read the plan as your checklist and complete each task in order.
+
+**If "Save plan only"**: Write the plan to `implementation-plan.md` in the project root.
+
+### If Prompter is NOT installed
+
+Ask:
+
+```json
+{
+  "questions": [
+    {
+      "question": "What would you like to do next?",
+      "header": "Next Steps",
+      "multiSelect": false,
+      "options": [
+        { "label": "Start building", "description": "Begin implementing the tasks now" },
+        { "label": "Save plan only", "description": "Save the plan to a file for later" }
+      ]
+    }
+  ]
+}
+```
+
+**If "Start building"**: Begin implementing tasks sequentially.
+
+**If "Save plan only"**: Write the plan to `implementation-plan.md` in the project root.
+
+---
+
+## Conversation Tips
+
+### Handling Large Features
+- Suggest splitting into multiple increments.
+- Plan only the first increment in detail.
+- Note follow-up work in the "Out of scope" section.
+- Use: "This is a big feature. I'd suggest we tackle [core part] first and add [extras] after."
+
+### Handling Vague Requests
+- Look at the codebase first to infer what the user might mean.
+- If still unclear after codebase analysis, ask ONE focused clarifying question.
+- Never ask more than 2 clarifying questions before producing a draft plan -- it's easier to iterate on a concrete plan than to keep asking questions.
+
+### Handling Technical Users
+- Skip obvious explanations.
+- Focus on file paths, patterns, and concrete decisions.
+- Be direct about tradeoffs.
+
+### Handling Unfamiliar Codebases
+- Spend more time in Step 2 (analysis).
+- Read more example files to understand patterns.
+- Be explicit about assumptions: "I'm assuming X based on what I see in Y -- correct me if wrong."
+
+---
+
+## Resources
+
+- **Implementation plan template**: [implementation-plan-template.md](assets/implementation-plan-template.md) -- Structured output format for the plan

package/skills/feature-planner/assets/implementation-plan-template.md

@@ -0,0 +1,85 @@
+# Implementation Plan: [Feature Name]
+
+## Feature Overview
+[1-2 sentence summary of what is being built and why]
+
+---
+
+## Scope
+
+### In Scope
+- [ ] [Change 1]
+- [ ] [Change 2]
+- [ ] [Change 3]
+
+### Out of Scope
+- [Deferred item 1] -- [reason]
+- [Deferred item 2] -- [reason]
+
+---
+
+## Codebase Analysis
+
+### Tech Stack Detected
+| Layer | Technology |
+|-------|-----------|
+| Frontend | [e.g., Next.js, React] |
+| Backend | [e.g., Laravel, Express] |
+| Database | [e.g., PostgreSQL, MySQL] |
+| Other | [e.g., Redis, Docker] |
+
+### Affected Files & Modules
+| File / Module | Change Type | Description |
+|---------------|-------------|-------------|
+| [path/to/file] | New / Modify / Delete | [What changes] |
+
+### Existing Patterns to Follow
+- [Pattern 1 observed in codebase -- e.g., "Controllers use single-action pattern"]
+- [Pattern 2 -- e.g., "All API responses use ApiResource wrapper"]
+- [Pattern 3 -- e.g., "Tests use factories with specific naming convention"]
+
+---
+
+## Data Model Changes
+> Skip this section if no database changes are needed.
+
+### New Tables / Collections
+- **[table_name]**: [key columns/fields]
+
+### Modified Tables / Collections
+- **[table_name]**: Add [column] ([type]) -- [reason]
+
+### New Relationships
+- [Entity A] has many [Entity B]
+
+---
+
+## Implementation Tasks
+
+### Phase 1: [Foundation / Database / Setup]
+- [ ] 1.1 [Task description] -- `path/to/file`
+- [ ] 1.2 [Task description] -- `path/to/file`
+
+### Phase 2: [Core Logic / Backend]
+- [ ] 2.1 [Task description] -- `path/to/file`
+- [ ] 2.2 [Task description] -- `path/to/file`
+
+### Phase 3: [Frontend / UI]
+- [ ] 3.1 [Task description] -- `path/to/file`
+- [ ] 3.2 [Task description] -- `path/to/file`
+
+### Phase 4: [Tests / Validation]
+- [ ] 4.1 [Task description] -- `path/to/file`
+- [ ] 4.2 [Task description] -- `path/to/file`
+
+---
+
+## Dependencies & Risks
+| Risk | Impact | Mitigation |
+|------|--------|------------|
+| [Risk 1] | [High/Med/Low] | [How to handle] |
+
+---
+
+## Notes
+- [Any additional context, edge cases, or decisions made during planning]

package/skills/gamma-builder/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: gamma-builder
+description: Transform documents, reports, articles, or unstructured text into polished, structured presentation outlines optimized for Gamma AI. Use this skill whenever the user wants to create a presentation, slide deck, or pitch from existing content — even if they don't mention "Gamma" explicitly. Trigger on phrases like "turn this into slides", "make a presentation from this", "create a deck", "slide outline", "presentation from this doc", or any request to convert text into presentation format.
+---
+
+# Gamma Builder
+
+Transform any document or text into a Gamma AI-ready presentation outline. The output is structured so it can be copy-pasted directly into Gamma AI's text input.
+
+## Workflow
+
+### Phase 1 — Clarification (always do this first)
+
+When the user provides a document or text, gather four parameters before generating anything. Use `AskUserQuestion` if available, otherwise ask inline. If the user already provided these details upfront, skip to Phase 2.
+
+Ask:
+
+1. **Output Language** — Which language for the presentation?
+   - `English`
+   - `Indonesian` (Bahasa Indonesia)
+
+2. **Presentation Length** — How many slides?
+   - 5 for brief overview, 10-12 for standard, 15-20 for in-depth
+
+3. **Tone** — Pick one:
+   - `Formal` — Corporate, polished, authoritative
+   - `Casual` — Conversational, approachable, friendly
+   - `Technical` — Data-driven, precise, jargon-appropriate
+   - `Inspirational` — Motivational, story-driven, energizing
+
+4. **Audience** — Who will view this?
+   - e.g., C-suite, investors, engineering team, marketing, students, clients
+
+5. **Visual Style** — How should slides feel?
+   - `Minimal` — Clean, whitespace-heavy, few words per slide
+   - `Data-heavy` — Charts, statistics, tables, metrics-focused
+   - `Image-focused` — Visual-first, imagery cues on every slide
+   - `Balanced` — Mix of text, data, and visual elements
+
+### Phase 2 — Content Transformation
+
+With all four parameters in hand, transform the source material through these steps:
+
+#### 1. Content Analysis
+- Read the entire document
+- Identify the core thesis / main message
+- Extract key arguments, data points, supporting evidence
+- Note quotes, statistics, or visual-worthy content
+- Identify the natural narrative arc
+
+#### 2. Information Architecture
+- Map content to the target slide count
+- Group related ideas into logical slide clusters
+- Prioritize based on the specified audience
+- Cut redundancies and filler
+- Follow this flow: **Hook → Context → Core Content → Evidence → Takeaway/CTA**
+
+#### 3. Tone Adaptation
+Rewrite all text to match the selected tone — this matters because the same content lands very differently depending on delivery:
+
+| Tone | Language Style |
+|------|---------------|
+| Formal | Precise language, third-person, no contractions |
+| Casual | "you/we" language, contractions, relatable phrasing |
+| Technical | Preserve jargon, include specs, data-first language |
+| Inspirational | Power verbs, rhetorical questions, story hooks |
+
+#### 4. Visual Style Integration
+Each style drives how much content goes on a slide and what visual placeholders to include:
+
+| Style | Content Rule | Visual Cues |
+|-------|-------------|-------------|
+| Minimal | Max 3 bullet points, short phrases only | Suggest whitespace |
+| Data-heavy | Include specific data throughout | `[Chart]`, `[Graph]`, `[Table]` placeholders with data descriptions |
+| Image-focused | Text supported by imagery | `[Image: description]` on every slide |
+| Balanced | Mix text blocks with visuals naturally | Mixed placeholders |
+
+## Output Format
+
+Generate the output in exactly this structure — it's designed for direct copy-paste into Gamma AI — then **save it to a markdown file** named after the presentation title (e.g., `my-presentation-title.md`) in the current working directory using the Write tool.
+
+```
+Title: [Presentation Title]
+Subtitle: [Subtitle or tagline]
+Target: [X] slides | Tone: [Selected Tone] | Audience: [Specified Audience] | Style: [Visual Style] | Language: [English/Indonesian]
+
+---
+
+Slide 1: [Slide Title]
+[Slide content — concise text, bullet points, or statement]
+[Image: description] or [Chart: description] (if applicable)
+Speaker Notes: [What the presenter should say/elaborate on]
+
+---
+
+Slide 2: [Slide Title]
+[Slide content]
+[Visual placeholder if applicable]
+Speaker Notes: [Notes]
+
+---
+
+(Continue for all slides...)
+
+---
+
+Slide [X]: [Closing Slide Title]
+[Call to action, summary, or closing statement]
+[Visual placeholder if applicable]
+Speaker Notes: [Final delivery notes]
+```
+
+## Quality Checklist
+
+These aren't arbitrary rules — each one exists because Gamma presentations fail when they're violated:
+
+- **Specific slide titles** — "Why Margins Dropped 12% in Q3" beats "Overview". Generic titles signal lazy thinking and lose the audience.
+- **Max 40 words per slide body** (unless Data-heavy style) — Gamma renders slides visually; walls of text break the layout and kill engagement.
+- **Strong opening hook** — The first slide must grab attention, not bore with an agenda. Lead with a provocative stat, question, or bold claim.
+- **Clear closing CTA** — End with what you want the audience to do or remember, not a generic "Thank you."
+- **Logical narrative flow** — A stranger should follow the story without the source document. Each slide should feel like it naturally leads to the next.
+- **Preserve all key data** — Statistics and data points from the source must survive the transformation. They're the evidence.
+- **Consistent tone** — A casual slide in a formal deck is jarring. Maintain the selected tone throughout.
+- **Hit the slide count** — Stay within ±1 of the target. Going way over or under means the information architecture is off.
+- **Self-contained content** — Never reference "the document" or "as mentioned." The presentation stands alone.
+
+## Important Constraints
+
+- **Rewrite, don't copy-paste.** Distill and restructure everything from the source. Raw paragraphs dropped into slides are not a presentation.
+- **Don't fabricate.** Only use information that's in or reasonably inferred from the source document.
+- **Include visual placeholders** with specific, descriptive prompts (e.g., `[Image: aerial view of solar farm at sunset]` not just `[Image: relevant photo]`). Gamma AI uses these to generate or find visuals. **Always write image prompts in English**, regardless of the selected output language.
+- **Create narrative arc** even from dry or unstructured source material. That's the whole point of the transformation.
+- If the source is **too short** for the requested slide count, tell the user and suggest a better count.
+- If the source is **too long**, prioritize the most impactful content and note what was condensed or omitted.