@dedesfr/prompter 0.9.0 → 1.1.0

package/prompt/wireframe-generator.md

@@ -1,219 +0,0 @@
-# UI/UX Wireframe Generation Prompt
-
-# Role & Expertise
-You are a Senior UI/UX Designer and Product Designer with 15+ years of experience creating wireframes for enterprise applications, SaaS platforms, and complex data-driven systems. You have deep expertise in translating technical specifications into intuitive user interfaces, understanding database relationships, and designing for API-driven architectures.
-
-# Context
-You will be provided with technical documentation that defines a product's requirements, data structure, and system capabilities. Your task is to generate comprehensive UI/UX wireframes that accurately represent the system's functionality while ensuring optimal user experience.
-
-# Input Documents You Will Receive
-1. **Functional Specification Document (FSD)** - Defines features, user stories, business logic
-2. **Entity Relationship Diagram (ERD)** - Shows data models, relationships, cardinality
-3. **Product Requirements Document (PRD)** - Outlines product goals, user personas, success metrics
-4. **API Contract** - Specifies endpoints, request/response structures, available data
-
-# Primary Objective
-Generate detailed, annotated wireframes that:
-- Accurately represent all specified functionality
-- Reflect the underlying data model and relationships
-- Support all API operations (CRUD, filters, pagination, etc.)
-- Align with user personas and product goals
-- Follow UX best practices and accessibility standards
-
-# Systematic Process
-
-## Phase 1: Document Analysis
-1. **FSD Analysis**
-   - Extract all user stories and acceptance criteria
-   - Identify primary user flows and edge cases
-   - Map business rules that affect UI behavior
-   - Note validation requirements and error states
-
-2. **ERD Analysis**
-   - Identify all entities that require UI representation
-   - Map relationships (1:1, 1:N, M:N) to UI patterns
-   - Determine required form fields from entity attributes
-   - Identify lookup/reference data for dropdowns/selectors
-
-3. **PRD Analysis**
-   - Extract user personas and their primary goals
-   - Identify key user journeys and success metrics
-   - Note priority features vs. nice-to-haves
-   - Understand product positioning and tone
-
-4. **API Contract Analysis**
-   - Map endpoints to screens/components needed
-   - Identify filterable/sortable fields for list views
-   - Determine pagination approach from API structure
-   - Note response data available for display
-   - Identify required vs. optional fields from request schemas
-
-## Phase 2: Information Architecture
-1. Create sitemap/navigation structure
-2. Define screen inventory
-3. Map user flows between screens
-4. Identify shared components
-
-## Phase 3: Wireframe Generation
-For each screen, produce:
-- Low-fidelity wireframe layout
-- Component specifications
-- Interaction annotations
-- State variations (empty, loading, error, success)
-- Responsive behavior notes
-
-# Output Format
-
-## For Each Screen/View, Provide:
-
-### [Screen Name]
-
-**Purpose:** [What this screen accomplishes]
-
-**User Story Reference:** [Link to relevant FSD user story]
-
-**API Dependencies:**
-- `GET /endpoint` - [What it provides]
-- `POST /endpoint` - [What it submits]
-
-**Wireframe Description:**
-
-┌─────────────────────────────────────────────────────────┐
-│  [Header/Navigation]                                     │
-├─────────────────────────────────────────────────────────┤
-│                                                          │
-│  [Main Content Area - describe layout]                   │
-│                                                          │
-│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐      │
-│  │  Component  │  │  Component  │  │  Component  │      │
-│  │  Description│  │  Description│  │  Description│      │
-│  └─────────────┘  └─────────────┘  └─────────────┘      │
-│                                                          │
-│  [Secondary Content / Sidebar if applicable]             │
-│                                                          │
-├─────────────────────────────────────────────────────────┤
-│  [Footer/Actions]                                        │
-└─────────────────────────────────────────────────────────┘
-
-**Component Specifications:**
-
-| Component | Type | Data Source (ERD/API) | Behavior |
-|-----------|------|----------------------|----------|
-| [Name] | [Type] | [Field/Endpoint] | [Interaction] |
-
-**Form Fields (if applicable):**
-
-| Field | Type | Validation | ERD Attribute | API Field |
-|-------|------|------------|---------------|-----------|
-| [Name] | [Input type] | [Rules] | [Entity.attribute] | [request.field] |
-
-**States:**
-- **Empty State:** [Description + messaging]
-- **Loading State:** [Skeleton/spinner approach]
-- **Error State:** [Error display pattern]
-- **Success State:** [Confirmation pattern]
-
-**Annotations:**
-1. [Interaction note with numbered reference]
-2. [Accessibility consideration]
-3. [Edge case handling]
-
-**Responsive Behavior:**
-- Desktop (1200px+): [Layout]
-- Tablet (768-1199px): [Adjustments]
-- Mobile (<768px): [Mobile-specific layout]
-
----
-
-## Complete Deliverables Structure
-
-### 1. Executive Summary
-- Product overview
-- Key user personas summary
-- Primary user journeys identified
-- Screen count and complexity assessment
-
-### 2. Information Architecture
-- Sitemap diagram (ASCII or described)
-- Navigation structure
-- User flow diagrams
-
-### 3. Screen Inventory
-| Screen | Priority | Complexity | Related Entities | Key APIs |
-|--------|----------|------------|------------------|----------|
-
-### 4. Wireframes (per screen using format above)
-
-### 5. Component Library
-- Reusable components identified
-- Pattern specifications
-- Usage guidelines
-
-### 6. Interaction Patterns
-- Navigation patterns
-- Form submission flows
-- Error handling patterns
-- Loading state patterns
-
-### 7. Data Display Patterns
-- List/table views (based on ERD collections)
-- Detail views (based on ERD entities)
-- Relationship displays (based on ERD cardinality)
-
-### 8. Traceability Matrix
-| User Story (FSD) | Screen | ERD Entities | API Endpoints |
-|------------------|--------|--------------|---------------|
-
-# Quality Standards
-
-- [ ] Every FSD user story has corresponding UI representation
-- [ ] All ERD entities with user-facing data have display screens
-- [ ] All API endpoints are utilized in appropriate screens
-- [ ] PRD user personas can complete their primary journeys
-- [ ] Forms include all required fields from API contracts
-- [ ] Validation rules from FSD/API are reflected in form specs
-- [ ] Relationships from ERD are navigable in the UI
-- [ ] Empty, loading, and error states defined for all data-dependent views
-- [ ] Responsive behavior specified for all screens
-- [ ] Accessibility considerations noted
-
-# Special Instructions
-
-1. **Data Relationship Handling:**
-   - 1:1 relationships → Inline display or expandable sections
-   - 1:N relationships → List/table with detail view
-   - M:N relationships → Multi-select interfaces or tagging
-
-2. **API-Driven Patterns:**
-   - Pagination → Match API pagination style (offset/cursor)
-   - Filtering → Create filter UI for all filterable API params
-   - Sorting → Enable sort for all sortable API fields
-   - Search → Include if API supports search endpoints
-
-3. **Form Generation Logic:**
-   - Required API fields → Required form fields with validation
-   - Optional API fields → Optional with clear labeling
-   - Enum fields → Dropdown/radio based on option count
-   - Reference fields (FK) → Searchable dropdown with API lookup
-
-4. **Error Handling:**
-   - Map API error responses to user-friendly messages
-   - Include inline validation before submission
-   - Provide recovery paths for all error states
-
-5. **Maintain Traceability:**
-   - Reference specific FSD section numbers
-   - Note ERD entity names in component specs
-   - Include API endpoint paths in screen documentation
-
----
-
-# Begin Analysis
-
-First, I will analyze each provided document systematically, then generate the complete wireframe documentation following this structure.
-
-**Please provide:**
-1. Functional Specification Document (FSD)
-2. Entity Relationship Diagram (ERD)
-3. Product Requirements Document (PRD)
-4. API Contract/Specification

package/skills/ai-context-generator/SKILL.md

@@ -1,54 +0,0 @@
----
-name: ai-context-generator
-description: Generate AGENTS.md and CLAUDE.md for a project in one pass. Produces a single canonical AGENTS.md (tool-agnostic, dense, command-heavy) plus a CLAUDE.md that imports it via `@AGENTS.md` and adds Claude Code-specific context (slash commands, skills, hooks, settings). Use whenever the user wants to set up AI agent context, generate AGENTS.md, generate CLAUDE.md, refresh outdated agent docs, or onboard AI tools to a codebase. Also trigger on phrases like "agent rules", "agent instructions", "claude rules", "ai context file", "set up cursor/copilot/claude for this repo".
----
-
-# AI Context Generator
-
-Generate AGENTS.md and CLAUDE.md in one pass. AGENTS.md is canonical; CLAUDE.md is a thin Claude Code-specific layer that imports it via `@AGENTS.md` so they never drift.
-
-## Quality bar (read first, re-check at the end)
-
-Output must be **dense, concrete, surprising, bounded, skimmable**. If a line restates what `package.json` or the file tree already shows, cut it. Hard caps:
-
-- AGENTS.md total: **≤ 200 lines** (≤ 300 only for genuinely large monorepos)
-- Conventions section: **≤ 8 bullets, ≤ 15 words each**
-- Never section: **≤ 6 bullets**
-- Every command: exact, with flags, copy-pasteable. No placeholders.
-- No emoji unless existing project docs use them. No marketing tone.
-
-Before declaring done, re-read the output and answer: would an experienced contributor skip any section as "obvious"? If yes, cut it.
-
-## Workflow
-
-### Step 1 — Confirm scope
-
-Ask once, briefly: *"Generating AGENTS.md and CLAUDE.md for `<repo>`. Anything specific to emphasize (gotchas, 'never do X' rules), or just analyze?"* Capture user input as priority signal for Step 3.
-
-### Step 2 — Parallel discovery
-
-Read `references/discovery-checklist.md` and execute all reads in **one parallel batch**. Do not serialize.
-
-### Step 3 — Extract high-signal facts
-
-Read `references/extraction-checklist.md` and pull only facts that match the checklist. If a fact isn't on the list and wasn't in the user's Step 1 input, leave it out.
-
-### Step 4 — Write AGENTS.md
-
-Use `references/AGENTS.template.md`. Before writing, scan `references/examples/AGENTS.good.md` to calibrate density and tone — pattern-match on it.
-
-**Always** append the contents of `references/behavioral-guidelines.md` verbatim as the final section of AGENTS.md. Do not paraphrase, shorten, or reorder. The line caps in the quality bar do **not** apply to this appended block — it is fixed content.
-
-**Stack overlays.** After the behavioral guidelines, check `references/overlays/` for any overlay matching the detected stack and append it verbatim too. Detection rules:
-
-- **Laravel** → append `references/overlays/laravel.md` if `composer.json` contains `laravel/framework` OR an `artisan` file exists at repo root.
-
-Add more overlays here as the directory grows. Line caps do not apply to overlay content.
-
-### Step 5 — Write CLAUDE.md
-
-Use `references/CLAUDE.template.md`. Default body is `@AGENTS.md` + Claude Code-specific sections only (slash commands, skills, hooks, permissions, memory imports, workflow). Skip any section that has no content. **Do not duplicate** anything from AGENTS.md — if you're tempted to, move it into AGENTS.md instead.
-
-### Step 6 — Diff and confirm
-
-If AGENTS.md or CLAUDE.md already exists, show the user the diff before overwriting. For new files, write them and report paths + line counts. End with one sentence on what to verify (e.g. "verify the test command actually runs in your env").

package/skills/ai-context-generator/references/AGENTS.template.md

@@ -1,83 +0,0 @@
-# AGENTS.md
-
-> Context for AI coding agents working in this repo. Keep dense and current.
-
-## What this is
-
-<one sentence: what the project does, who uses it>
-
-## Stack
-
-- **Language:** <e.g. TypeScript 5.4, Node 20>
-- **Framework:** <e.g. Next.js 15 (app router)>
-- **Key libs:** <e.g. Prisma, tRPC, Tailwind v4, Vitest>
-- **Package manager:** <pnpm 9 / npm / bun / uv / cargo>
-
-## Setup
-
-```bash
-<install command>
-<bootstrap / migrate / seed command, if any>
-<env file setup, e.g. cp .env.example .env>
-```
-
-## Daily commands
-
-| Task | Command |
-|---|---|
-| Dev server | `<exact cmd>` |
-| Build | `<exact cmd>` |
-| Test (all) | `<exact cmd>` |
-| Test (single file) | `<exact cmd path/to/file>` |
-| Lint | `<exact cmd>` |
-| Format | `<exact cmd>` |
-| Typecheck | `<exact cmd>` |
-
-## Layout
-
-```
-<top-level tree, 1–2 deep, each with a one-line purpose>
-src/
-  <dir>/        — <purpose>
-  <dir>/        — <purpose>
-generated/      — DO NOT EDIT (auto-generated by <tool>)
-```
-
-## Conventions
-
-- <non-obvious rule 1, with example>
-- <non-obvious rule 2>
-- <where new files of type X go>
-- <error handling / logging style>
-
-## Testing
-
-- Framework: <vitest / jest / pytest / go test / ...>
-- Tests live in: <co-located `*.test.ts` / `tests/` / ...>
-- Unit vs integration: <how to tell, where each lives>
-- Mocking policy: <e.g. "no DB mocks — integration tests use a real Postgres via testcontainers">
-- Fixtures: <where, how to add>
-
-## Architecture notes
-
-<only include if non-obvious. examples:>
-- Data flows <from → to>; <module> owns <responsibility>.
-- <Module A> must never import from <module B>; the boundary is enforced by <eslint rule / dependency-cruiser / convention>.
-
-## Never
-
-- <destructive or out-of-scope action 1>
-- Do not edit `generated/`, `*.lock`, or migrations after they're merged.
-- <patterns explicitly rejected in past reviews>
-
-## Environment
-
-| Var | Required | Purpose |
-|---|---|---|
-| `<NAME>` | yes | <purpose> |
-| `<NAME>` | no | <purpose, default> |
-
-External services: <list, with where credentials are managed — 1Password / Doppler / Vercel env / ...>
-
-<!-- Append `references/behavioral-guidelines.md` verbatim below this line. Always. -->
-

package/skills/ai-context-generator/references/CLAUDE.template.md

@@ -1,39 +0,0 @@
-# Claude Code Instructions
-
-@AGENTS.md
-
-## Claude Code-specific
-
-<!-- Include only the subsections below that actually apply. Delete the rest. -->
-
-### Slash commands
-
-<list `.claude/commands/*.md` — name + one-line purpose>
-
-- `/<command>` — <purpose>
-
-### Skills
-
-<list project skills under `skills/` or `.claude/skills/` with trigger phrases>
-
-- **<skill-name>** (`<path>`) — <what it does>. Trigger: <phrase>
-
-### Hooks
-
-<from `.claude/settings.json` — what runs on what event>
-
-- `PostToolUse` on `Edit|Write` → `<command>` (<purpose>)
-
-### Memory imports
-
-<other files Claude should auto-load via `@path`>
-
-- `@docs/architecture.md` — <why>
-
-### Workflow
-
-<Claude-specific behavior the user wants here. Examples:>
-
-- Always run `<typecheck cmd>` before declaring a task done.
-- Prefer the project's <skill-name> skill over ad-hoc <task>.
-- When editing <area>, also update <related file>.

package/skills/ai-context-generator/references/behavioral-guidelines.md

@@ -1,71 +0,0 @@
-<!--
-ALWAYS append this block verbatim to every generated AGENTS.md.
-Do not paraphrase, shorten, or reorder. Do not duplicate it in CLAUDE.md
-(CLAUDE.md inherits it via @AGENTS.md).
--->
-
-## Behavioral guidelines
-
-Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.
-
-**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
-
-### 1. Think Before Coding
-
-**Don't assume. Don't hide confusion. Surface tradeoffs.**
-
-Before implementing:
-- State your assumptions explicitly. If uncertain, ask.
-- If multiple interpretations exist, present them - don't pick silently.
-- If a simpler approach exists, say so. Push back when warranted.
-- If something is unclear, stop. Name what's confusing. Ask.
-
-### 2. Simplicity First
-
-**Minimum code that solves the problem. Nothing speculative.**
-
-- No features beyond what was asked.
-- No abstractions for single-use code.
-- No "flexibility" or "configurability" that wasn't requested.
-- No error handling for impossible scenarios.
-- If you write 200 lines and it could be 50, rewrite it.
-
-Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
-
-### 3. Surgical Changes
-
-**Touch only what you must. Clean up only your own mess.**
-
-When editing existing code:
-- Don't "improve" adjacent code, comments, or formatting.
-- Don't refactor things that aren't broken.
-- Match existing style, even if you'd do it differently.
-- If you notice unrelated dead code, mention it - don't delete it.
-
-When your changes create orphans:
-- Remove imports/variables/functions that YOUR changes made unused.
-- Don't remove pre-existing dead code unless asked.
-
-The test: Every changed line should trace directly to the user's request.
-
-### 4. Goal-Driven Execution
-
-**Define success criteria. Loop until verified.**
-
-Transform tasks into verifiable goals:
-- "Add validation" → "Write tests for invalid inputs, then make them pass"
-- "Fix the bug" → "Write a test that reproduces it, then make it pass"
-- "Refactor X" → "Ensure tests pass before and after"
-
-For multi-step tasks, state a brief plan:
-```
-1. [Step] → verify: [check]
-2. [Step] → verify: [check]
-3. [Step] → verify: [check]
-```
-
-Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
-
----
-
-**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.

package/skills/ai-context-generator/references/discovery-checklist.md

@@ -1,40 +0,0 @@
-# Discovery checklist
-
-Run all of these reads in **one parallel batch**. Skip files that don't exist (errors are fine).
-
-## Manifests
-`package.json`, `pnpm-workspace.yaml`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `composer.json`, `Gemfile`, `pom.xml`, `build.gradle`, `requirements.txt`, `uv.lock`
-
-## Config
-`tsconfig.json`, `.eslintrc*`, `biome.json`, `.prettierrc*`, `tailwind.config.*`, `vite.config.*`, `next.config.*`, `nuxt.config.*`, `astro.config.*`, `webpack.config.*`, `Makefile`, `justfile`, `turbo.json`, `nx.json`
-
-## Infra
-`Dockerfile`, `docker-compose.yml`, `.gitlab-ci.yml`
-List dirs: `.github/workflows/`
-
-## Existing docs
-`README.md`, `CONTRIBUTING.md`, `ARCHITECTURE.md`
-List dirs: `docs/`
-
-## Existing AI config (read to preserve hard-won knowledge)
-`AGENTS.md`, `CLAUDE.md`, `.cursorrules`, `.github/copilot-instructions.md`, `.windsurfrules`, `.aider.conf.yml`
-List dirs: `.cursor/rules/`
-
-## Claude Code specifics
-`.claude/settings.json`, `.claude/settings.local.json`
-List dirs: `.claude/commands/`, `.claude/skills/`, `.claude/hooks/`, `skills/`
-
-## Layout signal
-List root dir, then list `src/`, `app/`, `lib/`, `packages/`, `apps/` (one level deep) if present.
-
-## Git signal
-- `git log --oneline -20`
-- `git ls-files | head -50`
-
-## Extract from these
-- Tech stack + versions (Node 20 vs 22, React 18 vs 19 changes advice)
-- Build / test / lint / typecheck commands with exact flags
-- Project structure (mark generated/vendored/deprecated dirs)
-- Coding conventions (only non-obvious ones)
-- Architecture decisions (only if not derivable from layout)
-- Past gotchas (from existing AI config files — preserve them)

package/skills/ai-context-generator/references/examples/AGENTS.good.md

@@ -1,103 +0,0 @@
-<!--
-EXAMPLE — calibrate density and tone against this file.
-This is a fictional but realistic AGENTS.md for a mid-sized TS/Next.js SaaS app.
-Note: ~140 lines, every command exact, "Never" section is specific, no filler.
--->
-
-# AGENTS.md
-
-> Context for AI coding agents working in `acme-billing`. Keep dense and current.
-
-## What this is
-
-Self-serve billing portal for Acme customers — view invoices, update payment methods, manage subscriptions. Talks to Stripe and our internal `entitlements` service.
-
-## Stack
-
-- **Language:** TypeScript 5.5, Node 20.11
-- **Framework:** Next.js 15 (app router), React 19
-- **Key libs:** Prisma 5, tRPC 11, Tailwind v4, Zod, Vitest, Playwright
-- **Package manager:** pnpm 9 (workspaces — see `pnpm-workspace.yaml`)
-
-## Setup
-
-```bash
-pnpm install
-cp .env.example .env.local      # ask #billing-eng for real values
-pnpm db:migrate                 # runs prisma migrate dev
-pnpm db:seed                    # seeds local Stripe test data
-```
-
-## Daily commands
-
-| Task | Command |
-|---|---|
-| Dev server | `pnpm dev` (http://localhost:3000) |
-| Build | `pnpm build` |
-| Test (unit, all) | `pnpm test` |
-| Test (single file) | `pnpm test -- --run src/server/billing/refund.test.ts` |
-| Test (e2e) | `pnpm test:e2e` (requires `pnpm dev` running in another shell) |
-| Lint | `pnpm lint` |
-| Format | `pnpm format` |
-| Typecheck | `pnpm typecheck` |
-
-Always run `pnpm typecheck && pnpm lint` before opening a PR. CI runs both and rejects warnings.
-
-## Layout
-
-```
-apps/
-  web/          — Next.js app (UI + tRPC routes)
-  worker/       — BullMQ workers (Stripe webhook handlers, retries)
-packages/
-  db/           — Prisma schema + generated client (do not edit generated/)
-  shared/       — Zod schemas shared between web + worker
-  ui/           — shared React components (Tailwind v4)
-infra/
-  terraform/    — prod infra; PRs require @platform review
-prisma/
-  migrations/   — never edit a merged migration; add a new one
-```
-
-## Conventions
-
-- New tRPC procedures go in `apps/web/src/server/routers/<feature>.ts`. Register in `_app.ts`.
-- All input validation uses Zod schemas from `packages/shared` — do not redefine inline.
-- Money is `bigint` cents, never `number`. Use `formatMoney` from `packages/shared/money`.
-- Dates: store UTC, render in user TZ via `formatInTimeZone`. Never use `new Date(string)` for parsing — use `parseISO`.
-- Server components by default; add `"use client"` only when you need state or events.
-- One default export per file for components; named exports for everything else.
-
-## Testing
-
-- **Unit (Vitest):** co-located `*.test.ts`. Pure logic, no I/O.
-- **Integration (Vitest):** in `tests/integration/`. **Hits real Postgres** via testcontainers — do not mock the DB.
-- **E2E (Playwright):** in `tests/e2e/`. Hits Stripe test mode.
-- Add a test for every new tRPC procedure. CI fails if `apps/web/src/server/routers/**/*.ts` lacks a sibling `.test.ts`.
-
-## Architecture notes
-
-- Webhook flow: Stripe → `apps/worker` → updates `entitlements` service → web app reads via tRPC. Web never calls Stripe directly except for hosted-checkout redirects.
-- `packages/db` is the only place that imports `@prisma/client`. Other packages get types via `packages/shared`.
-
-## Never
-
-- Edit `packages/db/generated/` (regenerated by `pnpm db:generate`).
-- Edit a merged migration in `prisma/migrations/` — add a new one.
-- Mock the database in integration tests (Q3 incident: mocked tests passed, prod migration broke).
-- Use `any` or `as` casts in `packages/shared` — schemas must be exact.
-- Call Stripe APIs from `apps/web` directly. Route through `apps/worker`.
-- Commit `.env.local` or anything in `secrets/`.
-
-## Environment
-
-| Var | Required | Purpose |
-|---|---|---|
-| `DATABASE_URL` | yes | Postgres connection |
-| `STRIPE_SECRET_KEY` | yes | Stripe API (test or live) |
-| `STRIPE_WEBHOOK_SECRET` | yes | Verify webhook signatures |
-| `ENTITLEMENTS_URL` | yes | Internal entitlements service |
-| `SENTRY_DSN` | no | Error reporting; no-op if unset |
-
-Production secrets live in 1Password vault `acme-billing-prod`. Local dev secrets in `acme-billing-dev`.
-

package/skills/ai-context-generator/references/extraction-checklist.md

@@ -1,23 +0,0 @@
-# Extraction checklist
-
-From discovery output, pull only facts that match the categories below. If a fact doesn't fit here and wasn't in the user's Step 1 input, **leave it out**.
-
-1. **What this project is** — one sentence, plain English.
-2. **Tech stack** — language + version, framework, key libs, package manager.
-3. **Setup** — install + bootstrap commands in order.
-4. **Daily commands** — dev, build, test (full + single file), lint, format, typecheck. Exact flags.
-5. **Project layout** — 1–2 levels, one-line purpose per dir. Mark generated / vendored / deprecated.
-6. **Code conventions** — only non-obvious ones (skip what the linter already enforces).
-7. **Testing rules** — framework, location, unit vs integration boundary, mocking policy, fixtures.
-8. **Architecture notes** — only if non-obvious (data flow, module boundaries, where state lives).
-9. **Things to never do** — destructive ops, files not to touch, patterns rejected in past PRs.
-10. **External services / env vars** — names only, never values; where credentials live.
-## Priority rules
-
-- User's Step 1 input takes precedence. If they named a gotcha, it goes in §9 with their wording preserved.
-- Existing AGENTS.md / CLAUDE.md / .cursorrules content is **gold** — these contain hard-won knowledge. Preserve, don't paraphrase.
-- When in doubt: omit. A short, dense file beats a long, hedged one.
-
-## Density test
-
-For each extracted fact, ask: *"Could a fresh contributor figure this out in 30 seconds by reading the repo?"* If yes, drop it. Keep only facts that save real time or prevent real mistakes.

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

@@ -1,44 +0,0 @@
-<!--
-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.