@kurokeita/add-skill 2.6.1 → 3.0.1

package/dist/skills/write-prd/SKILL.md

@@ -1,162 +0,0 @@
----
-name: write-prd
-description: >
-  Create a developer-focused PRD through user interview, codebase exploration, and module design, then save it
-  under .prd/{prd-name}/ in the current workspace. Use when the user wants to write a PRD, create a product
-  requirements document, plan a new feature, spec out work, or define requirements for implementation. Also
-  trigger when the user says things like "let's plan this feature", "I need a spec for...", "write requirements
-  for...", or "create a PRD for...". Do NOT trigger for: reviewing existing PRDs, creating child tasks from a PRD,
-  or general project management outside the local PRD directory.
-argument-hint: "[prd-name]"
----
-
-# Write a PRD
-
-Create a developer-focused Product Requirements Document and save it to the local workspace instead of a remote tracker.
-The PRD captures the *what* and *why* of a feature, not line-level implementation details.
-
-During the interview phase, explicitly use the `grill-me` skill if it is available in the current workspace. Treat
-that skill as the driver for the questioning loop, while this skill remains responsible for codebase exploration,
-module design, PRD drafting, and filesystem output.
-
-Output location:
-
-- Directory: `.prd/{prd-name}/`
-- Primary document: `.prd/{prd-name}/prd.md`
-- Optional notes captured during planning: `.prd/{prd-name}/notes.md`
-
-`{prd-name}` should be a filesystem-safe kebab-case slug. If the user provides a title with spaces or punctuation,
-normalize it to kebab-case and tell the user which slug you used.
-
-You may skip steps if they are clearly unnecessary, but do not rush. The value of this skill is in forcing clarity.
-
-## Step 1: Establish the PRD target
-
-If the user provided `$ARGUMENTS`, treat that as the intended PRD name and normalize it to a slug.
-
-If not, ask for the PRD name before writing files.
-
-Before creating files:
-
-- Check whether `.prd/{prd-name}/` already exists
-- If it exists, read `prd.md` if present and summarize the current state
-- Ask whether the user wants to overwrite the PRD, revise it in place, or create a new slug
-
-## Step 2: Get the problem description
-
-Ask the user for a long, detailed description of the problem they want to solve and any candidate solutions they already
-have in mind.
-
-If an existing `.prd/{prd-name}/prd.md` exists, summarize it first so the user can correct or extend it instead of repeating
-context.
-
-## Step 3: Explore the codebase
-
-Before interviewing, ground yourself in the actual codebase:
-
-1. Read the top-level `README.md`, `AGENTS.md`, or other architectural guidance if present
-2. Search broadly for relevant terms, domain concepts, and adjacent implementations
-3. Read area-specific guidance files when relevant
-4. Look for similar features, patterns, and existing terminology
-
-Do not try to read everything. Use search-driven exploration to understand the current state well enough to ask informed
-questions and write an accurate PRD.
-
-## Step 4: Interview relentlessly
-
-Invoke the `grill-me` skill for this phase if available, then interview the user until you reach shared understanding.
-Walk down each branch of the design tree and resolve dependencies one by one.
-
-Ask one question at a time. Keep going until ambiguity is removed.
-
-Ask about:
-
-- Edge cases and failure scenarios
-- Existing behavior that must be preserved
-- What success looks like from the user's perspective
-- Who the end users are
-- Constraints from architecture, rollout, compatibility, or operations
-
-Continue exploring the codebase while interviewing. If a question can be answered by inspecting code, inspect code instead
-of asking the user.
-
-### Scope check
-
-If it becomes clear the work is too large for one PRD, tell the user and ask whether to narrow the scope or continue with
-a larger document that will later be split into multiple execution tracks.
-
-## Step 5: Sketch module design
-
-Sketch the major conceptual modules to build or modify. Look for opportunities to define **deep modules**:
-
-- Interfaces simpler than the implementation they hide
-- Testable in isolation
-- Internals can change without rippling outward
-
-Check that these modules match the user's expectations and ask which ones need stronger test coverage.
-
-## Step 6: Draft the PRD and get approval
-
-Write the PRD and show it to the user for approval before saving or overwriting `prd.md`.
-
-The PRD should be durable:
-
-- Do describe conceptual modules, responsibilities, interfaces, and data flow
-- Do describe architectural patterns and decisions
-- Do not reference specific file paths, class names, or step-by-step implementation procedures
-- Do not include code snippets unless the user explicitly asks for them
-
-Use this structure:
-
-```md
-# {Human-readable PRD title}
-
-## Problem Statement
-
-## Solution
-
-## User Stories
-1. As a ...
-
-## Module Design
-### {Module name}
-- Responsibility:
-- Interface:
-- Status: new | existing
-- Depth: deep | shallow
-
-## Implementation Decisions
-
-## Testing Decisions
-
-## Out of Scope
-
-## Open Questions
-```
-
-Omit `Open Questions` if none remain.
-
-## Step 7: Save to the filesystem
-
-Only save after the user approves the PRD.
-
-Create `.prd/{prd-name}/` if it does not exist.
-
-Write:
-
-- `.prd/{prd-name}/prd.md`: the approved PRD
-
-Optionally write:
-
-- `.prd/{prd-name}/notes.md`: short working notes, unresolved investigation points, or source references gathered during
-  discovery. Keep this concise and operational, not user-facing.
-
-Do not create extra files unless they add real value.
-
-## After saving
-
-Tell the user:
-
-- The slug used
-- The files created or updated
-- Whether this was a new PRD or a revision of an existing directory

package/dist/workflows/brainstorm.md

@@ -1,113 +0,0 @@
----
-description: Structured brainstorming for projects and features. Explores multiple options before implementation.
----
-
-# /brainstorm - Structured Idea Exploration
-
-$ARGUMENTS
-
----
-
-## Purpose
-
-This command activates BRAINSTORM mode for structured idea exploration. Use when you need to explore options before committing to an implementation.
-
----
-
-## Behavior
-
-When `/brainstorm` is triggered:
-
-1. **Understand the goal**
-   - What problem are we solving?
-   - Who is the user?
-   - What constraints exist?
-
-2. **Generate options**
-   - Provide at least 3 different approaches
-   - Each with pros and cons
-   - Consider unconventional solutions
-
-3. **Compare and recommend**
-   - Summarize tradeoffs
-   - Give a recommendation with reasoning
-
----
-
-## Output Format
-
-```markdown
-## 🧠 Brainstorm: [Topic]
-
-### Context
-[Brief problem statement]
-
----
-
-### Option A: [Name]
-[Description]
-
-✅ **Pros:**
-- [benefit 1]
-- [benefit 2]
-
-❌ **Cons:**
-- [drawback 1]
-
-📊 **Effort:** Low | Medium | High
-
----
-
-### Option B: [Name]
-[Description]
-
-✅ **Pros:**
-- [benefit 1]
-
-❌ **Cons:**
-- [drawback 1]
-- [drawback 2]
-
-📊 **Effort:** Low | Medium | High
-
----
-
-### Option C: [Name]
-[Description]
-
-✅ **Pros:**
-- [benefit 1]
-
-❌ **Cons:**
-- [drawback 1]
-
-📊 **Effort:** Low | Medium | High
-
----
-
-## 💡 Recommendation
-
-**Option [X]** because [reasoning].
-
-What direction would you like to explore?
-```
-
----
-
-## Examples
-
-```
-/brainstorm authentication system
-/brainstorm state management for complex form
-/brainstorm database schema for social app
-/brainstorm caching strategy
-```
-
----
-
-## Key Principles
-
-- **No code** - this is about ideas, not implementation
-- **Visual when helpful** - use diagrams for architecture
-- **Honest tradeoffs** - don't hide complexity
-- **Defer to user** - present options, let them decide

package/dist/workflows/create.md

@@ -1,60 +0,0 @@
----
-description: Create new application command. Triggers App Builder skill and starts interactive dialogue with user.
----
-
-# /create - Create Application
-
-$ARGUMENTS
-
----
-
-## Task
-
-This command starts a new application creation process.
-
-### Steps
-
-1. **Request Analysis**
-   - Understand what the user wants
-   - If information is missing, use `conversation-manager` skill to ask
-
-2. **Project Planning**
-   - Use `project-planner` agent for task breakdown
-   - Determine tech stack
-   - Plan file structure
-   - Create plan file and proceed to building
-
-3. **Application Building (After Approval)**
-   - Orchestrate with `app-builder` skill
-   - Coordinate expert agents:
-     - `database-architect` → Schema
-     - `backend-specialist` → API
-     - `frontend-specialist` → UI
-
-4. **Preview**
-   - Start with `auto_preview.py` when complete
-   - Present URL to user
-
----
-
-## Usage Examples
-
-```
-/create blog site
-/create e-commerce app with product listing and cart
-/create todo app
-/create Instagram clone
-/create crm system with customer management
-```
-
----
-
-## Before Starting
-
-If request is unclear, ask these questions:
-
-- What type of application?
-- What are the basic features?
-- Who will use it?
-
-Use defaults, add details later.

package/dist/workflows/debug.md

@@ -1,107 +0,0 @@
----
-description: Debugging command. Activates DEBUG mode for systematic problem investigation.
----
-
-# /debug - Systematic Problem Investigation
-
-$ARGUMENTS
-
----
-
-## Purpose
-
-This command activates DEBUG mode for systematic investigation of issues, errors, or unexpected behavior.
-
----
-
-## Behavior
-
-When `/debug` is triggered:
-
-1. **Gather information**
-   - Error message
-   - Reproduction steps
-   - Expected vs actual behavior
-   - Recent changes
-
-2. **Form hypotheses**
-   - List possible causes
-   - Order by likelihood
-
-3. **Investigate systematically**
-   - Test each hypothesis
-   - Check logs, data flow
-   - Use elimination method
-
-4. **Fix and prevent**
-   - Apply fix
-   - Explain root cause
-   - Add prevention measures
-
----
-
-## Output Format
-
-```markdown
-## 🔍 Debug: [Issue]
-
-### 1. Symptom
-[What's happening]
-
-### 2. Information Gathered
-- Error: `[error message]`
-- File: `[filepath]`
-- Line: [line number]
-
-### 3. Hypotheses
-1. ❓ [Most likely cause]
-2. ❓ [Second possibility]
-3. ❓ [Less likely cause]
-
-### 4. Investigation
-
-**Testing hypothesis 1:**
-[What I checked] → [Result]
-
-**Testing hypothesis 2:**
-[What I checked] → [Result]
-
-### 5. Root Cause
-🎯 **[Explanation of why this happened]**
-
-### 6. Fix
-```[language]
-// Before
-[broken code]
-
-// After
-[fixed code]
-```
-
-### 7. Prevention
-
-🛡️ [How to prevent this in the future]
-
-```
-
----
-
-## Examples
-
-```
-
-/debug login not working
-/debug API returns 500
-/debug form doesn't submit
-/debug data not saving
-
-```
-
----
-
-## Key Principles
-
-- **Ask before assuming** - get full error context
-- **Test hypotheses** - don't guess randomly
-- **Explain why** - not just what to fix
-- **Prevent recurrence** - add tests, validation

package/dist/workflows/deploy.md

@@ -1,178 +0,0 @@
----
-description: Deployment command for production releases. Pre-flight checks and deployment execution.
----
-
-# /deploy - Production Deployment
-
-$ARGUMENTS
-
----
-
-## Purpose
-
-This command handles production deployment with pre-flight checks, deployment execution, and verification.
-
----
-
-## Sub-commands
-
-```
-/deploy            - Interactive deployment wizard
-/deploy check      - Run pre-deployment checks only
-/deploy preview    - Deploy to preview/staging
-/deploy production - Deploy to production
-/deploy rollback   - Rollback to previous version
-```
-
----
-
-## Pre-Deployment Checklist
-
-Before any deployment:
-
-```markdown
-## 🚀 Pre-Deploy Checklist
-
-### Code Quality
-- [ ] No TypeScript errors (`npx tsc --noEmit`)
-- [ ] ESLint passing (`npx eslint .`)
-- [ ] All tests passing (`npm test`)
-
-### Security
-- [ ] No hardcoded secrets
-- [ ] Environment variables documented
-- [ ] Dependencies audited (`npm audit`)
-
-### Performance
-- [ ] Bundle size acceptable
-- [ ] No console.log statements
-- [ ] Images optimized
-
-### Documentation
-- [ ] README updated
-- [ ] CHANGELOG updated
-- [ ] API docs current
-
-### Ready to deploy? (y/n)
-```
-
----
-
-## Deployment Flow
-
-```
-┌─────────────────┐
-│  /deploy        │
-└────────┬────────┘
-         │
-         ▼
-┌─────────────────┐
-│  Pre-flight     │
-│  checks         │
-└────────┬────────┘
-         │
-    Pass? ──No──► Fix issues
-         │
-        Yes
-         │
-         ▼
-┌─────────────────┐
-│  Build          │
-│  application    │
-└────────┬────────┘
-         │
-         ▼
-┌─────────────────┐
-│  Deploy to      │
-│  platform       │
-└────────┬────────┘
-         │
-         ▼
-┌─────────────────┐
-│  Health check   │
-│  & verify       │
-└────────┬────────┘
-         │
-         ▼
-┌─────────────────┐
-│  ✅ Complete    │
-└─────────────────┘
-```
-
----
-
-## Output Format
-
-### Successful Deploy
-
-```markdown
-## 🚀 Deployment Complete
-
-### Summary
-- **Version:** v1.2.3
-- **Environment:** production
-- **Duration:** 47 seconds
-- **Platform:** Vercel
-
-### URLs
-- 🌐 Production: https://app.example.com
-- 📊 Dashboard: https://vercel.com/project
-
-### What Changed
-- Added user profile feature
-- Fixed login bug
-- Updated dependencies
-
-### Health Check
-✅ API responding (200 OK)
-✅ Database connected
-✅ All services healthy
-```
-
-### Failed Deploy
-
-```markdown
-## ❌ Deployment Failed
-
-### Error
-Build failed at step: TypeScript compilation
-
-### Details
-```
-
-error TS2345: Argument of type 'string' is not assignable...
-
-```
-
-### Resolution
-1. Fix TypeScript error in `src/services/user.ts:45`
-2. Run `npm run build` locally to verify
-3. Try `/deploy` again
-
-### Rollback Available
-Previous version (v1.2.2) is still active.
-Run `/deploy rollback` if needed.
-```
-
----
-
-## Platform Support
-
-| Platform | Command | Notes |
-|----------|---------|-------|
-| Vercel | `vercel --prod` | Auto-detected for Next.js |
-| Railway | `railway up` | Needs Railway CLI |
-| Fly.io | `fly deploy` | Needs flyctl |
-| Docker | `docker compose up -d` | For self-hosted |
-
----
-
-## Examples
-
-```
-/deploy
-/deploy check
-/deploy preview
-/deploy production --skip-tests
-/deploy rollback
-```

package/dist/workflows/enhance.md

@@ -1,64 +0,0 @@
----
-description: Add or update features in existing application. Used for iterative development.
----
-
-# /enhance - Update Application
-
-$ARGUMENTS
-
----
-
-## Task
-
-This command adds features or makes updates to existing application.
-
-### Steps
-
-1. **Understand Current State**
-   - Load project state with `python .agent/scripts/session_manager.py info`
-   - Understand existing features, tech stack
-
-2. **Plan Changes**
-   - Determine what will be added/changed
-   - Detect affected files
-   - Check dependencies
-
-3. **Present Plan to User** (for major changes)
-
-   ```
-   "To add admin panel:
-   - I'll create 15 new files
-   - Update 8 files
-   - Takes ~10 minutes
-   
-   Should I start?"
-   ```
-
-4. **Apply**
-   - Call relevant agents
-   - Make changes
-   - Test
-
-5. **Update Preview**
-   - Hot reload or restart
-
----
-
-## Usage Examples
-
-```
-/enhance add dark mode
-/enhance build admin panel
-/enhance integrate payment system
-/enhance add search feature
-/enhance edit profile page
-/enhance make responsive
-```
-
----
-
-## Caution
-
-- Get approval for major changes
-- Warn on conflicting requests (e.g., "use Firebase" when project uses PostgreSQL)
-- Commit each change with git