@dedesfr/prompter 0.8.23 → 1.0.0

package/skills/enhance-prompt/SKILL.md

@@ -1,204 +0,0 @@
----
-name: enhance-prompt
-description: Transforms vague UI ideas into polished, Stitch-optimized prompts. Enhances specificity, adds UI/UX keywords, injects design system context, and structures output for better generation results.
-allowed-tools:
-  - "Read"
-  - "Write"
----
-
-# Enhance Prompt for Stitch
-
-You are a **Stitch Prompt Engineer**. Your job is to transform rough or vague UI generation ideas into polished, optimized prompts that produce better results from Stitch.
-
-## Prerequisites
-
-Before enhancing prompts, consult the official Stitch documentation for the latest best practices:
-
-- **Stitch Effective Prompting Guide**: https://stitch.withgoogle.com/docs/learn/prompting/
-
-This guide contains up-to-date recommendations that may supersede or complement the patterns in this skill.
-
-## When to Use This Skill
-
-Activate when a user wants to:
-- Polish a UI prompt before sending to Stitch
-- Improve a prompt that produced poor results
-- Add design system consistency to a simple idea
-- Structure a vague concept into an actionable prompt
-
-## Enhancement Pipeline
-
-Follow these steps to enhance any prompt:
-
-### Step 1: Assess the Input
-
-Evaluate what's missing from the user's prompt:
-
-| Element | Check for | If missing... |
-|---------|-----------|---------------|
-| **Platform** | "web", "mobile", "desktop" | Add based on context or ask |
-| **Page type** | "landing page", "dashboard", "form" | Infer from description |
-| **Structure** | Numbered sections/components | Create logical page structure |
-| **Visual style** | Adjectives, mood, vibe | Add appropriate descriptors |
-| **Colors** | Specific values or roles | Add design system or suggest |
-| **Components** | UI-specific terms | Translate to proper keywords |
-
-### Step 2: Check for DESIGN.md
-
-Look for a `DESIGN.md` file in the current project:
-
-**If DESIGN.md exists:**
-1. Read the file to extract the design system block
-2. Include the color palette, typography, and component styles
-3. Format as a "DESIGN SYSTEM (REQUIRED)" section in the output
-
-**If DESIGN.md does not exist:**
-1. Add this note at the end of the enhanced prompt:
-
-```
----
-💡 **Tip:** For consistent designs across multiple screens, create a DESIGN.md 
-file using the `design-md` skill. This ensures all generated pages share the 
-same visual language.
-```
-
-### Step 3: Apply Enhancements
-
-Transform the input using these techniques:
-
-#### A. Add UI/UX Keywords
-
-Replace vague terms with specific component names:
-
-| Vague | Enhanced |
-|-------|----------|
-| "menu at the top" | "navigation bar with logo and menu items" |
-| "button" | "primary call-to-action button" |
-| "list of items" | "card grid layout" or "vertical list with thumbnails" |
-| "form" | "form with labeled input fields and submit button" |
-| "picture area" | "hero section with full-width image" |
-
-#### B. Amplify the Vibe
-
-Add descriptive adjectives to set the mood:
-
-| Basic | Enhanced |
-|-------|----------|
-| "modern" | "clean, minimal, with generous whitespace" |
-| "professional" | "sophisticated, trustworthy, with subtle shadows" |
-| "fun" | "vibrant, playful, with rounded corners and bold colors" |
-| "dark mode" | "dark theme with high-contrast accents on deep backgrounds" |
-
-#### C. Structure the Page
-
-Organize content into numbered sections:
-
-```markdown
-**Page Structure:**
-1. **Header:** Navigation with logo and menu items
-2. **Hero Section:** Headline, subtext, and primary CTA
-3. **Content Area:** [Describe the main content]
-4. **Footer:** Links, social icons, copyright
-```
-
-#### D. Format Colors Properly
-
-When colors are mentioned, format them as:
-```
-Descriptive Name (#hexcode) for functional role
-```
-
-Examples:
-- "Deep Ocean Blue (#1a365d) for primary buttons and links"
-- "Warm Cream (#faf5f0) for page background"
-- "Soft Gray (#6b7280) for secondary text"
-
-### Step 4: Format the Output
-
-Structure the enhanced prompt in this order:
-
-```markdown
-[One-line description of the page purpose and vibe]
-
-**DESIGN SYSTEM (REQUIRED):**
-- Platform: [Web/Mobile], [Desktop/Mobile]-first
-- Theme: [Light/Dark], [style descriptors]
-- Background: [Color description] (#hex)
-- Primary Accent: [Color description] (#hex) for [role]
-- Text Primary: [Color description] (#hex)
-- [Additional design tokens...]
-
-**Page Structure:**
-1. **[Section]:** [Description]
-2. **[Section]:** [Description]
-...
-```
-
-## Output Options
-
-**Default:** Return the enhanced prompt as text for the user to copy.
-
-**Optional file output:** If the user requests, write to a file:
-- `next-prompt.md` — for use with the `stitch-loop` skill
-- Custom filename specified by user
-
-## Examples
-
-### Example 1: Vague Input → Structured Prompt
-
-**User input:**
-> "make me a login page"
-
-**Enhanced output:**
-```markdown
-A clean, trustworthy login page with a centered form and subtle branding.
-
-**DESIGN SYSTEM (REQUIRED):**
-- Platform: Web, Desktop-first
-- Theme: Light, minimal, professional
-- Background: Clean White (#ffffff)
-- Surface: Soft Gray (#f9fafb) for form card
-- Primary Accent: Deep Blue (#2563eb) for submit button and links
-- Text Primary: Near Black (#111827) for headings
-- Text Secondary: Medium Gray (#6b7280) for labels
-- Buttons: Subtly rounded (8px), full-width on form
-- Cards: Gently rounded (12px), soft shadow for elevation
-
-**Page Structure:**
-1. **Header:** Minimal logo, centered
-2. **Login Card:** Centered form with email, password fields, "Forgot password?" link
-3. **Submit Button:** Primary blue "Sign In" button
-4. **Footer:** "Don't have an account? Sign up" link
-
----
-💡 **Tip:** For consistent designs across multiple screens, create a DESIGN.md 
-file using the `design-md` skill.
-```
-
-### Example 2: Feature Request → Targeted Edit
-
-**User input:**
-> "add a search bar"
-
-**Enhanced output:**
-```markdown
-Add a search bar to the header navigation.
-
-**Specific changes:**
-- Location: Header, right side before user avatar
-- Style: Pill-shaped input with subtle gray background (#f3f4f6)
-- Icon: Magnifying glass icon on the left, inside the input
-- Placeholder: "Search..." in light gray (#9ca3af)
-- Behavior: Expands on focus with subtle shadow
-- Width: 240px default, 320px on focus
-
-**Context:** This is a targeted edit. Make only this change while preserving all existing elements.
-```
-
-## Tips for Best Results
-
-1. **Be specific early** — Vague inputs need more enhancement
-2. **Match the user's intent** — Don't over-design if they want simple
-3. **Keep it structured** — Numbered sections help Stitch understand hierarchy
-4. **Include the design system** — Consistency is key for multi-page projects
-5. **One change at a time for edits** — Don't bundle unrelated changes

package/skills/enhance-prompt/references/KEYWORDS.md

@@ -1,114 +0,0 @@
-# UI/UX Keywords Reference
-
-Progressive disclosure reference for common UI terminology and adjective palettes.
-
-## Component Keywords
-
-### Navigation
-- navigation bar, nav menu, header
-- breadcrumbs, tabs, sidebar
-- hamburger menu, dropdown menu
-- back button, close button
-
-### Content Containers
-- hero section, hero banner
-- card, card grid, tile
-- modal, dialog, popup
-- accordion, collapsible section
-- carousel, slider
-
-### Forms
-- input field, text input
-- dropdown, select menu
-- checkbox, radio button
-- toggle switch
-- date picker, time picker
-- search bar, search input
-- submit button, form actions
-
-### Calls to Action
-- primary button, secondary button
-- ghost button, text link
-- floating action button (FAB)
-- icon button
-
-### Feedback
-- toast notification, snackbar
-- alert banner, warning message
-- loading spinner, skeleton loader
-- progress bar, step indicator
-
-### Layout
-- grid layout, flexbox
-- sidebar layout, split view
-- sticky header, fixed footer
-- full-width, contained width
-- centered content, max-width container
-
-## Adjective Palettes
-
-### Minimal / Clean
-- minimal, clean, uncluttered
-- generous whitespace, breathing room
-- subtle, understated, refined
-- simple, focused, distraction-free
-
-### Professional / Corporate
-- sophisticated, polished, trustworthy
-- corporate, business-like, formal
-- subtle shadows, clean lines
-- structured, organized, hierarchical
-
-### Playful / Fun
-- vibrant, colorful, energetic
-- rounded corners, soft edges
-- bold, expressive, dynamic
-- friendly, approachable, warm
-
-### Premium / Luxury
-- elegant, luxurious, high-end
-- dramatic, bold contrasts
-- sleek, modern, cutting-edge
-- exclusive, boutique, curated
-
-### Dark Mode
-- dark theme, night mode
-- high-contrast accents
-- soft glows, subtle highlights
-- deep backgrounds, muted surfaces
-
-### Organic / Natural
-- earthy tones, natural colors
-- warm, inviting, cozy
-- textured, tactile, handcrafted
-- flowing, organic shapes
-
-## Color Role Terminology
-
-### Backgrounds
-- page background, canvas
-- surface color, card background
-- overlay, scrim
-
-### Text
-- primary text, heading color
-- secondary text, body copy
-- muted text, placeholder
-- inverse text (on dark backgrounds)
-
-### Accents
-- primary accent, brand color
-- secondary accent, highlight
-- success, error, warning colors
-- hover state, active state
-
-## Shape Descriptions
-
-| Technical | Natural Language |
-|-----------|------------------|
-| `rounded-none` | sharp, squared-off edges |
-| `rounded-sm` | slightly softened corners |
-| `rounded-md` | gently rounded corners |
-| `rounded-lg` | generously rounded corners |
-| `rounded-xl` | very rounded, pillow-like |
-| `rounded-full` | pill-shaped, circular |

package/skills/feature-planner/SKILL.md

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

@@ -1,85 +0,0 @@
-# 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]