@dedesfr/prompter 0.8.12 → 0.8.14

package/skills/ai-context-generator/references/overlays/laravel.md

@@ -0,0 +1,44 @@
+<!--
+LARAVEL OVERLAY — append verbatim to AGENTS.md when the project is Laravel.
+Detection: `composer.json` includes `laravel/framework`, OR `artisan` exists at repo root.
+Place this block AFTER `## Behavioral guidelines` and BEFORE end of file.
+-->
+
+## Laravel safety rules (mandatory)
+
+These rules are non-negotiable and override speed/convenience. They exist because destructive DB commands have repeatedly destroyed local and shared data on this project.
+
+### Confirmation required before any destructive command
+
+Always ask for explicit yes/no confirmation before running any of:
+
+- **Schema drops:** `Schema::drop`, `Schema::dropIfExists`, raw `DROP TABLE`, `DROP DATABASE`, `php artisan db:wipe`.
+- **Bulk data deletion:** `Model::truncate()`, `DB::table(...)->truncate()`, `DB::table(...)->delete()` without a `where`, `Model::query()->delete()`, `forceDelete` on collections, mass cleanup jobs/commands.
+- **Fresh rebuild:** `php artisan migrate:fresh`, `php artisan migrate:fresh --seed`, `php artisan migrate:refresh`, `php artisan schema:dump --prune`. (User may call this "migrateg --fresh" — same thing.)
+- **Production-targeted destructive ops:** anything above with `--force`, or `--env=production`, or against a non-local `DB_CONNECTION`.
+- **Seeders that truncate:** any `DatabaseSeeder` or seeder containing `truncate()` / `delete()` calls.
+- **Tinker:** destructive operations via `php artisan tinker` (treat the same as direct execution).
+
+### Required confirmation format
+
+Before running, state:
+
+1. **Command:** the exact invocation (with all flags, env, and target connection).
+2. **Why destructive:** what it deletes/drops.
+3. **Scope:** which DB connection, which env (`APP_ENV`, `DB_CONNECTION`, `DB_DATABASE`), how many rows/tables affected if knowable.
+4. **Safer alternative:** name one (e.g. `php artisan migrate` instead of `migrate:fresh`; a targeted `where()->delete()` instead of `truncate()`).
+
+Then ask: *"Run this? (yes/no)"* — wait for an explicit yes. Implicit consent does not count.
+
+### Default safe behavior
+
+- No confirmation → do not run. Do not retry with a different flag.
+- Prefer non-destructive first: `migrate` over `migrate:fresh`; new migration over editing a merged one; targeted update over truncate-and-reseed.
+- If approved, run **only** the confirmed scope. Do not chain extra commands ("while I'm here, also...").
+- After running, report: command run, rows/tables affected, current migration status.
+
+### Hard rules (never, even with confirmation, unless user explicitly names the command)
+
+- Never run any destructive command against a connection that isn't `sqlite` in-memory or a database whose name contains `local`, `dev`, or `test` — without the user typing the actual command themselves.
+- Never use `--force` in any environment without an explicit user instruction containing `--force`.
+- Never `DROP DATABASE` or `db:wipe` without the user typing it.

package/skills/ui-ux-pro-v2/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ui-ux-pro-v2
-description: Design and revise UI/UX like a senior designer. Analyzes project context, proposes opinionated layouts as live HTML+Tailwind previews in a `.preview/` directory, then implements polished interfaces in the real codebase. Use for new pages, redesigns, component design, or design audits.
+description: Design and revise UI/UX like a senior designer. Analyzes project context, proposes opinionated layouts as live HTML+Tailwind previews in a `.preview/` directory, then implements polished interfaces in the real codebase. TRIGGER on new pages, redesigns, design audits, or component design where layout/hierarchy is in question. SKIP for small tweaks (color, spacing, copy, one-line CSS fixes), bug fixes to an already-approved layout, or backend/logic work — edit real code directly instead.
 ---
 
 # UI UX Pro v2
@@ -11,23 +11,21 @@ Act as a senior UI/UX designer. Make opinionated design decisions based on proje
 
 ## Critical Rules (Read First)
 
-These are the most commonly violated rules — internalize before proceeding:
+The failure modes to internalize — full context lives in the Workflow section below:
 
-1. **Diagnose redesigns yourself** — never ask "what feels wrong?" Analyze the page, surface 3–4 findings, then build the low-fi. Users can't answer design questions in design vocabulary.
-2. **Low-fi before high-fi, always** — get layout approval in grayscale before applying color, type, or polish. Never skip to high-fi.
-3. **Preview before real code** — never write to the actual codebase until the user approves the preview direction.
-4. **Tailwind CDN in previews, always** — even if the project uses shadcn/Material/etc. Previews are disposable; don't entangle them with the build system.
-5. **Section comments required** — every major HTML block needs `<!-- Section: Name -->` so users can give spatial feedback without knowing HTML.
-6. **Default one variant** — build one recommended design, then offer: *"I can show 1–2 alternatives if you want to compare."* Don't push a menu upfront.
-7. **Always include a recommendation** — every choice you present must name a preferred option with a one-line reason.
-8. **Don't delete `.preview/`** — user keeps these as reference. Never auto-clean.
-9. **Tell user to verify in browser** — do not attempt to run the dev server yourself.
+1. **Diagnose redesigns yourself** — never ask "what feels wrong?" Surface findings, then yield for the user's reply before building.
+2. **Low-fi before high-fi; preview before real code.** No skipping tiers.
+3. **Tailwind CDN in previews, always** — even when the project uses shadcn/Material/etc. Previews stay disposable.
+4. **Section comments required** — every major HTML block gets `<!-- Section: Name -->` so users can give spatial feedback without reading code.
+5. **Default one variant with a stated recommendation.** Offer alternatives only if asked.
+6. **Never auto-delete `.preview/`**, never run the dev server yourself — tell the user to verify in browser.
+7. **Mobile, tablet, desktop from Pass 1.** A layout that breaks on mobile is not done.
 
 ---
 
 ## Workflow
 
-`Step 0: Read context → Step 1: Discovery → Step 2: Low-fi preview → [approval] → Step 3: High-fi → [approval] → Step 4: Implement → Step 5: Iterate`
+`Step 0: Read context → Step 1: Decide mock vs. edit → Step 2: Discovery → Step 3: Low-fi → [approval] → Step 4: High-fi → [approval] → Step 5: Implement → Step 6: Iterate`
 
 ---
 
@@ -42,11 +40,28 @@ Before designing, silently gather — do not ask the user:
 
 ---
 
-## Step 1: Discovery
+## Step 1: Decide Mock vs. Edit
+
+Before discovery, decide the path. **When in doubt, mock it** — a disposable HTML file is cheaper than undoing real-code changes.
+
+### Build a preview (continue to Step 2):
+- New page or feature
+- Major redesign
+- Multiple directions are plausible
+- User is non-technical and needs to see before reacting
+
+### Edit real code directly (skip to Step 5):
+- Small tweak (color, spacing, copy)
+- Fixing a specific bug the user pointed at
+- Adding one element to an already-approved layout
+- Developer user asking for a specific change
+
+---
+
+## Step 2: Discovery
 
 ### New designs
-1. Ask: *"What is this for?"* — page/feature, audience, goal
-2. Ask one optional: *"Any vibe or reference in mind? (totally optional)"* — proceed regardless
+Ask one combined question: *"What is this for — page/feature, audience, and goal? Any vibe or reference is optional."* Proceed regardless of whether they give a vibe.
 
 ### Redesigns and audits
 Do NOT ask open-ended questions. Most users cannot articulate design problems.
@@ -54,14 +69,14 @@ Do NOT ask open-ended questions. Most users cannot articulate design problems.
 1. Silently analyze the existing page — read the code or screenshot
 2. Present a short diagnostic (3–4 bullets, plain language):
    ```
-   Here's what I noticed before I start:
+   Here's what I noticed:
    - Weak hierarchy — CTA competes with secondary content
    - Inconsistent spacing — no clear scale
    - Low contrast on the action button (likely fails WCAG AA)
    - Font sizes too uniform — headlines don't feel distinct
    ```
-3. Ask one soft optional: *"Anything to keep, or a vibe/reference in mind? (I'll proceed either way)"*
-4. Build the low-fi immediately — with or without their answer
+3. Ask: *"Anything to keep, or a vibe/reference in mind? Say go and I'll start the low-fi."*
+4. **Yield to the user here.** End your turn after the diagnostic + question. Do not continue into preview construction in the same turn.
 
 ### Never ask:
 - "What feels wrong?" — diagnose it yourself
@@ -72,7 +87,7 @@ Do NOT ask open-ended questions. Most users cannot articulate design problems.
 
 ---
 
-## Step 2: Preview (REQUIRED Before Any Real Code)
+## Step 3: Preview (REQUIRED Before Any Real Code)
 
 ### File structure
 ```
@@ -84,7 +99,7 @@ Do NOT ask open-ended questions. Most users cannot articulate design problems.
 ```
 
 - Files must be standalone, openable with `file://`
-- Add `.preview/` to `.gitignore` if not ignored (ask first if repo tracks it)
+- Add `.preview/` to `.gitignore` if not ignored (ask first if repo tracks it). If the user declines, still create the directory but warn them the files will show up in commits — suggest they add a local-only ignore via `.git/info/exclude`.
 
 ### CSS in previews
 Always use Tailwind CDN (`<script src="https://cdn.tailwindcss.com"></script>`), even if the project uses shadcn/Material. If the project has brand tokens (CSS variables), inline them in a `<style>` block so colors/fonts match. The real implementation uses the project's actual design system — keep this separation clear.
@@ -94,6 +109,7 @@ Always use Tailwind CDN (`<script src="https://cdn.tailwindcss.com"></script>`),
 - System font only — no custom typography
 - No shadows, gradients, or decorative effects
 - Focus: layout, hierarchy, spacing, content flow
+- **Include basic responsive behavior** — at minimum, the layout must not break on mobile. Use Tailwind responsive prefixes (`sm:`, `md:`, `lg:`) from the start.
 - File: `<feature>-lowfi.html`
 
 Present, wait for layout approval before proceeding.
@@ -103,6 +119,9 @@ Present, wait for layout approval before proceeding.
 - Add hover/focus states, responsive breakpoints
 - File: `<feature>-v1.html`
 
+### Delegating to `frontend-design` Skill
+If the `frontend-design` skill is available in the session, delegate the actual HTML markup construction to it — pass your layout decisions, section structure, and brand tokens, let it produce the markup. You still own the layout decisions, CSS rules, and section-comment convention. If not available, build the markup yourself.
+
 ### Variations
 Default to one. Offer more only if the user asks, or if there is genuinely zero style signal to work from. Max 3. When building multiple, create a `variations.html` hub that links or iframes all variants side-by-side. Always mark one as **Recommended ⭐** with a one-line reason.
 
@@ -122,25 +141,7 @@ Does the layout work? I can adjust any section before moving to high-fi.
 
 ---
 
-## Step 3: Mock vs. Edit
-
-### Build a preview when:
-- New page or feature
-- Major redesign
-- Multiple directions are plausible
-- User is non-technical and needs to see before reacting
-
-### Edit real code directly when:
-- Small tweak (color, spacing, copy)
-- Fixing a specific bug the user pointed at
-- Adding one element to an already-approved layout
-- User is a developer who asked for a specific change
-
-**When in doubt — mock it.** A disposable HTML file costs little; undoing rejected real-code changes costs more.
-
----
-
-## Step 4: Implementation (After Preview Approved)
+## Step 5: Implementation (After Preview Approved)
 
 ### Order
 1. Layout structure and spacing
@@ -168,7 +169,7 @@ When done: tell the user to open the page in their browser to verify.
 
 ---
 
-## Step 5: Iteration
+## Step 6: Iteration
 
 | User says | You do |
 |---|---|

package/src/cli/index.ts

@@ -18,7 +18,7 @@ const program = new Command();
 program
   .name('prompter')
   .description('Enhance prompts directly in your AI coding workflow')
-  .version('0.8.12');
+  .version('0.8.14');
 
 program
   .command('init')

package/src/commands/init.ts

@@ -86,7 +86,7 @@ export class InitCommand {
             },
             {
                 name: '📝 Documentation',
-                skills: ['doc-builder', 'document-translator', 'agents-md-generator', 'meeting-notes']
+                skills: ['doc-builder', 'document-translator', 'ai-context-generator', 'meeting-notes']
             },
             {
                 name: '✨ Content & Productivity',

package/skills/agents-md-generator/SKILL.md

@@ -1,238 +0,0 @@
----
-name: agents-md-generator
-description: Generate or update an AGENTS.md file in any project's root directory. Creates a comprehensive, well-structured AGENTS.md following industry best practices from analysis of 2,500+ repositories. Works from existing project docs (README, package.json, config files), codebase analysis, or direct user input. Use this skill whenever the user wants to create an AGENTS.md, update an existing one, improve AI agent instructions for a project, or mentions setting up agent context for any codebase. Also trigger when users mention wanting better AI coding assistant results, agent configuration, or project onboarding for AI tools.
----
-
-# AGENTS.md Generator
-
-Generate or update a project's AGENTS.md file — the standard open-format file that gives AI coding agents the context they need to work effectively in a codebase.
-
-## Why AGENTS.md matters
-
-AGENTS.md is the "README for AI agents." Unlike README files written for humans, AGENTS.md provides the specific, structured context that AI coding agents need: exact commands with flags, concrete code examples, clear boundaries on what to never touch, and project-specific conventions that aren't obvious from the code alone. A well-written AGENTS.md dramatically improves the quality of AI-generated code by reducing hallucinated endpoints, mismatched coding styles, and violations of project constraints.
-
-## Step 0: Determine Mode
-
-Present these options to the user:
-
-**What would you like to do?**
-
-1. **Generate new AGENTS.md** — Create from scratch by analyzing the project
-2. **Update existing AGENTS.md** — Improve or add sections to an existing file
-3. **Generate from docs** — Build AGENTS.md from existing documentation (README, wiki, docs/)
-
-Wait for the user's selection before proceeding.
-
-## Step 1: Gather Project Context
-
-The quality of the AGENTS.md depends entirely on understanding the project. Collect context from these sources, in priority order:
-
-### 1.1 Automatic Discovery (always do this)
-
-Scan the project root for context signals:
-
-- **Package manifest**: `package.json`, `Cargo.toml`, `pyproject.toml`, `go.mod`, `composer.json`, `Gemfile`, `pom.xml`, `build.gradle`
-- **Config files**: `tsconfig.json`, `.eslintrc*`, `.prettierrc*`, `tailwind.config.*`, `vite.config.*`, `webpack.config.*`, `docker-compose.yml`
-- **CI/CD**: `.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile`
-- **Existing docs**: `README.md`, `CONTRIBUTING.md`, `docs/`, `wiki/`
-- **Existing AI config**: `CLAUDE.md`, `.cursorrules`, `.github/copilot-instructions.md`, `.windsurfrules`
-- **Test setup**: test directories, test config files, test scripts in package manifest
-- **Git history**: recent commit patterns, active contributors
-
-Read these files to extract:
-- Tech stack and versions
-- Build/test/lint commands
-- Project structure patterns
-- Coding conventions
-- Architecture decisions
-
-### 1.2 User-Provided Docs (if mode is "Generate from docs")
-
-Ask the user to point to their documentation:
-- "Which docs should I use as source material? (paths, URLs, or paste content directly)"
-
-Read and synthesize the provided documentation into AGENTS.md sections.
-
-### 1.3 Interactive Interview (fill gaps)
-
-After automatic discovery, identify what's still missing and ask the user targeted questions. Don't ask about things you already know from the codebase. Focus on:
-
-- **Project purpose**: What does this project do? (if not clear from README)
-- **Architecture decisions**: Any non-obvious patterns or constraints?
-- **Boundaries**: What should AI agents never touch? (secrets, vendor dirs, generated files, production configs)
-- **Domain vocabulary**: Any project-specific terms agents need to know?
-- **Common pitfalls**: What mistakes do new contributors (or AI agents) commonly make?
-- **Testing requirements**: Any specific testing patterns or requirements?
-
-Keep the interview short — 3-5 questions max, focused on what you genuinely couldn't determine from the code.
-
-## Step 2: Structure the AGENTS.md
-
-Use the template at `assets/agents-md-template.md` as a starting point. The template has 18 sections — not all are required for every project. Include a section only if you have substantive content for it. An empty or placeholder section ("Not specified") is worse than omitting it entirely.
-
-### Section Priority
-
-**Always include** (these are the highest-value sections based on empirical analysis):
-1. **Project Summary** — What this project does, in 2-3 sentences
-2. **Tech Stack** — Languages, frameworks, runtime versions
-3. **Commands** — Build, test, lint, deploy commands with exact flags
-4. **Folder Structure** — Key directories and their purposes
-5. **Coding Conventions** — Real code examples, not verbal descriptions
-6. **Development Rules for AI Agents** — Boundaries and constraints
-
-**Include when relevant:**
-7. **Architecture Overview** — Module structure, data flow
-8. **Core Business Logic** — Domain rules that aren't obvious from code
-9. **Data Models** — Key entities and relationships
-10. **Domain Vocabulary** — Project-specific terms
-11. **Security/Privacy Rules** — Auth flows, sensitive data handling
-12. **Testing Strategy** — Frameworks, patterns, coverage expectations
-13. **Integration Map** — External services, APIs, third-party tools
-
-**Include only if substantive:**
-14. **Target Users** — Who uses this and how
-15. **UI/UX Principles** — Design patterns and constraints
-16. **Roadmap** — Active initiatives
-17. **Known Issues** — Current limitations
-18. **Troubleshooting** — Common problems and fixes
-19. **Ownership Map** — Who owns what
-
-### Writing Guidelines
-
-Follow these principles — they come from analysis of what actually makes AGENTS.md effective:
-
-**Be specific, not vague.**
-```markdown
-# Bad
-- Use TypeScript
-- Follow best practices
-
-# Good
-- TypeScript 5.4 with strict mode enabled
-- ESM imports with explicit `.js` extensions in compiled output
-- Prefer `interface` over `type` for object shapes
-```
-
-**Lead with executable commands.**
-```markdown
-# Commands
-npm run build          # Compile TypeScript to dist/
-npm test               # Run vitest test suite
-npm run lint           # ESLint with --fix
-npm run typecheck      # tsc --noEmit
-```
-
-**Show code examples for conventions.**
-```markdown
-# Component pattern
-export function UserCard({ user }: { user: User }) {
-  // Components use named exports, PascalCase
-  // Props defined inline for simple cases
-}
-```
-
-**Use three-tier boundaries.**
-```markdown
-## Development Rules for AI Agents
-### Always do:
-- Run `npm run typecheck` before committing
-- Use existing utility functions from `src/utils/`
-
-### Ask first:
-- Adding new dependencies
-- Modifying database schemas
-- Changes to CI/CD pipelines
-
-### Never do:
-- Commit `.env` files or secrets
-- Modify `vendor/` or generated files
-- Run destructive database commands
-- Invent API endpoints that don't exist
-```
-
-**Include file-scoped commands** for common per-file operations:
-```markdown
-# File-scoped commands
-npx vitest run src/utils/parse.test.ts    # Run single test file
-npx eslint --fix src/components/Card.tsx   # Lint single file
-npx tsc --noEmit src/types.ts              # Type-check single file
-```
-
-## Step 3: Generate or Update
-
-### For new AGENTS.md (Mode 1 or 3)
-
-1. Read the template from `assets/agents-md-template.md`
-2. Fill in each section with discovered and user-provided content
-3. Remove sections that have no substantive content
-4. Write to `AGENTS.md` in the project root
-
-### For updating existing AGENTS.md (Mode 2)
-
-1. Read the existing `AGENTS.md`
-2. Identify which sections exist and their quality
-3. Ask the user what they want to improve:
-   - "Add missing sections"
-   - "Update outdated information"
-   - "Improve specific sections" (let them pick)
-   - "Full refresh" (regenerate while preserving custom content)
-4. Make targeted updates, preserving any custom content the user has added
-5. If the file has managed markers (like `<!-- PROMPTER:START -->`), preserve those sections untouched
-
-### Monorepo Support
-
-For monorepos or multi-package projects, offer to create nested AGENTS.md files:
-
-```
-project-root/
-├── AGENTS.md              # Project-wide context
-├── packages/
-│   ├── frontend/
-│   │   └── AGENTS.md      # Frontend-specific context
-│   └── backend/
-│       └── AGENTS.md      # Backend-specific context
-```
-
-The root AGENTS.md should reference subdirectory files and provide shared context. Subdirectory files should focus on package-specific details.
-
-## Step 4: Validate and Review
-
-Before finalizing, check:
-
-- [ ] No placeholder text remains ("Not specified", "TODO", "TBD")
-- [ ] Commands are accurate and runnable
-- [ ] File paths referenced actually exist in the project
-- [ ] Tech stack versions match what's in config files
-- [ ] No sensitive information included (API keys, internal URLs, credentials)
-- [ ] Sections are ordered by value (most useful first)
-- [ ] Code examples match the project's actual coding style
-
-Present a summary to the user:
-- Which sections were generated
-- Any sections skipped (and why)
-- Suggestions for sections they could add later
-
-## Step 5: Save
-
-Save the AGENTS.md to the project root path (or the path the user specifies).
-
-Print a summary:
-```
-AGENTS.md generated at <path>
-Sections: <count> of 18
-Sources used: <list of files analyzed>
-Suggested improvements: <any sections that could be enhanced with more info>
-```
-
-## Edge Cases
-
-- **No package manifest found**: Ask the user about the tech stack directly
-- **Multiple languages**: Create sections for each, clearly labeled
-- **Existing CLAUDE.md / .cursorrules**: Offer to consolidate into AGENTS.md (which is the cross-tool standard) or keep both
-- **Very large project**: Focus on the most important directories and patterns rather than trying to document everything
-- **No README**: The interview step becomes more important — ask more questions
-
-## Resources
-
-- Template: `assets/agents-md-template.md`
-- Best practices reference: `references/best-practices.md`

package/skills/agents-md-generator/assets/agents-md-template.md

@@ -1,81 +0,0 @@
-# AGENTS — Project Knowledge Base
-
-## 1. Project Summary
-{{PROJECT_SUMMARY}}
-
-## 2. Tech Stack
-{{TECH_STACK}}
-
-## 3. Architecture Overview
-{{ARCHITECTURE_OVERVIEW}}
-
-## 4. Folder Structure & Important Files
-{{FOLDER_STRUCTURE}}
-
-## 5. Commands
-```bash
-# Build
-{{BUILD_COMMAND}}
-
-# Test
-{{TEST_COMMAND}}
-
-# Lint / Format
-{{LINT_COMMAND}}
-
-# Type check
-{{TYPECHECK_COMMAND}}
-
-# File-scoped commands
-{{FILE_SCOPED_COMMANDS}}
-```
-
-## 6. Core Business Logic & Domain Rules
-{{BUSINESS_LOGIC}}
-
-## 7. Data Models / Entities
-{{DATA_MODELS}}
-
-## 8. Domain Vocabulary / Glossary
-{{DOMAIN_VOCABULARY}}
-
-## 9. Target Users & Personas
-{{TARGET_USERS}}
-
-## 10. UI/UX Principles
-{{UI_UX_PRINCIPLES}}
-
-## 11. Security / Privacy Rules
-{{SECURITY_RULES}}
-
-## 12. Coding Conventions & Standards
-{{CODING_CONVENTIONS}}
-
-## 13. Development Rules for AI Agents
-
-### Always do:
-{{ALWAYS_DO_RULES}}
-
-### Ask first:
-{{ASK_FIRST_RULES}}
-
-### Never do:
-{{NEVER_DO_RULES}}
-
-## 14. Integration Map
-{{INTEGRATION_MAP}}
-
-## 15. Testing Strategy
-{{TESTING_STRATEGY}}
-
-## 16. Roadmap & Future Plans
-{{ROADMAP}}
-
-## 17. Known Issues / Limitations
-{{KNOWN_ISSUES}}
-
-## 18. Troubleshooting Guide
-{{TROUBLESHOOTING}}
-
-## 19. Ownership / Responsibility Map
-{{OWNERSHIP_MAP}}