@kurokeita/add-skill 2.6.1 → 3.0.1

package/dist/skills/make-instruction/SKILL.md

@@ -1,68 +0,0 @@
----
-name: make-instruction
-description: Generates custom Copilot instruction files (.instructions.md) following official best practices. Use when you need to standardize code generation, reviews, or documentation for specific domains or file types.
----
-
-# Make Instruction
-
-This skill helps you generate custom instruction files for GitHub Copilot (`.github/instructions/*.instructions.md`) following the official "awesome-copilot" best practices.
-
-## When to Use
-
-Use this skill when you want to:
-
-- Create a reusable prompt or context for Copilot.
-- Standardize code generation for a specific language, framework, or library.
-- Define code review guidelines for specific file types.
-- Ensure consistent documentation styles.
-
-## Workflow
-
-1. **Identify the Need**: Determine what domain or specific task you need instructions for (e.g., "React Components", "Python Testing", "API Documentation").
-2. **Define Scope**: Decide which files these instructions should apply to (e.g., `**/*.tsx`, `tests/*.py`).
-3. **Generate Content**: using the template below, the agent will help you draft the content.
-
-## Template
-
-The generated file should look like this:
-
-```markdown
----
-description: 'Brief description of the instruction purpose and scope'
-applyTo: 'glob pattern (e.g., **/*.ts)'
----
-
-# [Title: e.g., React Component Guidelines]
-
-[Brief introduction explaining the purpose and scope]
-
-## General Instructions
-[High-level guidelines and principles]
-
-## Best Practices
-- [Be Specific]
-- [Show Why]
-
-## Code Standards
-[Naming conventions, formatting, style rules]
-
-## Examples
-
-### Good Example
-\`\`\`language
-// Recommended approach
-code example here
-\`\`\`
-
-### Bad Example
-\`\`\`language
-// Avoid this pattern
-code example here
-\`\`\`
-```
-
-## Tips for Success
-
-- **Be Specific**: Copilot works best with concrete examples.
-- **Use "applyTo" Correctly**: Ensure the glob pattern hits the right files.
-- **Keep it Updated**: As your project evolves, update these instructions.

package/dist/skills/make-prompt/SKILL.md

@@ -1,70 +0,0 @@
----
-name: make-prompt
-description: Generates custom Copilot prompt files (.prompt.md) following official best practices. Use when you need to create structured, reusable prompts for complex tasks, code generation, or architectural planning.
----
-
-# Make Prompt
-
-This skill helps you generate custom prompt files (`.prompt.md`) for GitHub Copilot following the official "awesome-copilot" best practices and the "Professional Prompt Builder" guide.
-
-## When to Use
-
-Use this skill when you want to:
-
-- Create structured, reusable prompts for complex tasks.
-- Define a specific persona or expertise level for Copilot.
-- Create blueprints, implementation plans, or specifications.
-- Ensure consistent output formats for code generation or analysis.
-
-## Workflow
-
-1. **Discovery**: Identify the Identity, Persona, Task, Context, Instructions, Output, Tools, and Validation criteria.
-2. **Generate**: Create the `.prompt.md` file using the template below.
-
-## Template
-
-The generated file should look like this:
-
-```markdown
----
-description: "[Clear, concise description from requirements]"
-agent: "[agent|ask|edit based on task type]"
-tools: ["[appropriate tools based on functionality]"]
-model: "[only if specific model required]"
----
-
-# [Prompt Title]
-
-[Persona definition - specific role and expertise]
-Example: "You are a senior .NET architect with 10+ years of experience..."
-
-## [Task Section]
-[Clear task description with specific requirements]
-
-## [Instructions Section]
-[Step-by-step instructions following established patterns]
-
-## [Context/Input Section] 
-[Variable usage and context requirements]
-Example: "Uses \${selection} and \${file}"
-
-## [Output Section]
-[Expected output format and structure]
-
-## [Quality/Validation Section]
-[Success criteria and validation steps]
-```
-
-## Checklist for Quality
-
-- ✅ **Clear Structure**: Logical flow.
-- ✅ **Specific Instructions**: Actionable directions.
-- ✅ **Proper Context**: All necessary info is included.
-- ✅ **Tool Integration**: Correct tools selected.
-- ✅ **Error Handling**: Guidance for edge cases.
-
-## Tools Reference
-
-- **File Operations**: `codebase`, `editFiles`, `search`, `problems`
-- **Execution**: `runCommands`, `runTasks`, `runTests`, `terminalLastCommand`
-- **External**: `fetch`, `githubRepo`, `openSimpleBrowser`

package/dist/skills/make-skill/SKILL.md

@@ -1,147 +0,0 @@
----
-name: make-skill
-description: 'Create new Agent Skills for GitHub Copilot from prompts or by duplicating this template. Use when asked to "create a skill", "make a new skill", "scaffold a skill", or when building specialized AI capabilities with bundled resources. Generates SKILL.md files with proper frontmatter, directory structure, and optional scripts/references/assets folders.'
----
-
-# Make Skill
-
-A meta-skill for creating new Agent Skills. Use this skill when you need to scaffold a new skill folder, generate a SKILL.md file, or help users understand the Agent Skills specification.
-
-## When to Use This Skill
-
-- User asks to "create a skill", "make a new skill", or "scaffold a skill"
-- User wants to add a specialized capability to their GitHub Copilot setup
-- User needs help structuring a skill with bundled resources
-- User wants to duplicate this template as a starting point
-
-## Prerequisites
-
-- Understanding of what the skill should accomplish
-- A clear, keyword-rich description of capabilities and triggers
-- Knowledge of any bundled resources needed (scripts, references, assets, templates)
-
-## Creating a New Skill
-
-### Step 1: Create the Skill Directory
-
-Create a new folder with a lowercase, hyphenated name:
-
-```
-skills/<skill-name>/
-└── SKILL.md          # Required
-```
-
-### Step 2: Generate SKILL.md with Frontmatter
-
-Every skill requires YAML frontmatter with `name` and `description`:
-
-```yaml
----
-name: <skill-name>
-description: '<What it does>. Use when <specific triggers, scenarios, keywords users might say>.'
----
-```
-
-#### Frontmatter Field Requirements
-
-| Field | Required | Constraints |
-|-------|----------|-------------|
-| `name` | **Yes** | 1-64 chars, lowercase letters/numbers/hyphens only, must match folder name |
-| `description` | **Yes** | 1-1024 chars, must describe WHAT it does AND WHEN to use it |
-| `license` | No | License name or reference to bundled LICENSE.txt |
-| `compatibility` | No | 1-500 chars, environment requirements if needed |
-| `metadata` | No | Key-value pairs for additional properties |
-| `allowed-tools` | No | Space-delimited list of pre-approved tools (experimental) |
-
-#### Description Best Practices
-
-**CRITICAL**: The `description` is the PRIMARY mechanism for automatic skill discovery. Include:
-
-1. **WHAT** the skill does (capabilities)
-2. **WHEN** to use it (triggers, scenarios, file types)
-3. **Keywords** users might mention in prompts
-
-**Good example:**
-
-```yaml
-description: 'Toolkit for testing local web applications using Playwright. Use when asked to verify frontend functionality, debug UI behavior, capture browser screenshots, or view browser console logs. Supports Chrome, Firefox, and WebKit.'
-```
-
-**Poor example:**
-
-```yaml
-description: 'Web testing helpers'
-```
-
-### Step 3: Write the Skill Body
-
-After the frontmatter, add markdown instructions. Recommended sections:
-
-| Section | Purpose |
-|---------|---------|
-| `# Title` | Brief overview |
-| `## When to Use This Skill` | Reinforces description triggers |
-| `## Prerequisites` | Required tools, dependencies |
-| `## Step-by-Step Workflows` | Numbered steps for tasks |
-| `## Troubleshooting` | Common issues and solutions |
-| `## References` | Links to bundled docs |
-
-### Step 4: Add Optional Directories (If Needed)
-
-| Folder | Purpose | When to Use |
-|--------|---------|-------------|
-| `scripts/` | Executable code (Python, Bash, JS) | Automation that performs operations |
-| `references/` | Documentation agent reads | API references, schemas, guides |
-| `assets/` | Static files used AS-IS | Images, fonts, templates |
-| `templates/` | Starter code agent modifies | Scaffolds to extend |
-
-## Example: Complete Skill Structure
-
-```
-my-awesome-skill/
-├── SKILL.md                    # Required instructions
-├── LICENSE.txt                 # Optional license file
-├── scripts/
-│   └── helper.py               # Executable automation
-├── references/
-│   ├── api-reference.md        # Detailed docs
-│   └── examples.md             # Usage examples
-├── assets/
-│   └── diagram.png             # Static resources
-└── templates/
-    └── starter.ts              # Code scaffold
-```
-
-## Quick Start: Duplicate This Template
-
-1. Copy the `make-skill-template/` folder
-2. Rename to your skill name (lowercase, hyphens)
-3. Update `SKILL.md`:
-   - Change `name:` to match folder name
-   - Write a keyword-rich `description:`
-   - Replace body content with your instructions
-4. Add bundled resources as needed
-5. Validate with `npm run skill:validate`
-
-## Validation Checklist
-
-- [ ] Folder name is lowercase with hyphens
-- [ ] `name` field matches folder name exactly
-- [ ] `description` is 10-1024 characters
-- [ ] `description` explains WHAT and WHEN
-- [ ] `description` is wrapped in single quotes
-- [ ] Body content is under 500 lines
-- [ ] Bundled assets are under 5MB each
-
-## Troubleshooting
-
-| Issue | Solution |
-|-------|----------|
-| Skill not discovered | Improve description with more keywords and triggers |
-| Validation fails on name | Ensure lowercase, no consecutive hyphens, matches folder |
-| Description too short | Add capabilities, triggers, and keywords |
-| Assets not found | Use relative paths from skill root |
-
-## References
-
-- Agent Skills official spec: <https://agentskills.io/specification>

package/dist/skills/prd-to-tasks/SKILL.md

@@ -1,164 +0,0 @@
----
-name: prd-to-tasks
-description: >
-  Break a local PRD into independently grabbable implementation tasks using vertical slices, then save them under
-  .prd/{prd-name}/tasks/ in the current workspace. Use when the user wants to convert a PRD to tasks, break a spec
-  into actionable work, slice a PRD, or create implementation tasks from a local planning document. Do NOT trigger
-  for: writing PRDs, reviewing PRDs without task creation, or remote work item management systems.
-argument-hint: "[prd-name]"
----
-
-# PRD to Tasks
-
-Break a local PRD into independently grabbable implementation tasks using vertical slices.
-
-Input location:
-
-- PRD directory: `.prd/{prd-name}/`
-- Source PRD: `.prd/{prd-name}/prd.md`
-
-Output location:
-
-- Tasks directory: `.prd/{prd-name}/tasks/`
-- Optional index: `.prd/{prd-name}/tasks/README.md`
-
-`{prd-name}` should be a filesystem-safe kebab-case slug. If the user provides a title instead, normalize it to a slug
-and state the slug you used.
-
-## Step 1: Locate the PRD
-
-If the user provided `$ARGUMENTS`, treat that as the PRD name and normalize it.
-
-If not, ask which PRD directory to use.
-
-Then:
-
-1. Confirm `.prd/{prd-name}/prd.md` exists
-2. Read it fully
-3. Check whether `.prd/{prd-name}/tasks/` already exists
-4. If task files already exist, summarize them and ask whether to overwrite, append, or regenerate selectively
-
-If the PRD does not exist, stop and tell the user exactly which path is missing.
-
-## Step 2: Explore the codebase
-
-If you have not already explored the relevant code in this conversation, do so now:
-
-1. Read top-level architecture guidance if present
-2. Search for code related to the PRD concepts
-3. Read nearby guidance files for affected subsystems
-4. Look for similar features and test patterns
-
-The PRD tells you *what* to build. The codebase tells you enough about *where* and *how* to create useful tasks.
-
-## Step 3: Draft vertical slices
-
-Break the PRD into **tracer bullet** tasks.
-
-### What is a tracer bullet?
-
-A tracer bullet is a thin vertical slice through the whole feature path. It proves that the relevant layers connect
-correctly end to end. It is not a horizontal "build all backend first, then all UI" slice.
-
-Prefer slices that are:
-
-- Independently verifiable
-- Demoable on their own
-- Thin and end to end
-- Ordered by dependency
-
-### HITL vs AFK
-
-Each slice should be marked:
-
-- `HITL`: needs human input, review, testing on real devices, design signoff, or external coordination
-- `AFK`: can be implemented and validated without waiting on a person
-
-### Vertical slice rules
-
-- Each slice should deliver a complete behavior, not one technical layer
-- Prefer many thin slices over a few broad ones
-- Use the PRD's module design to inform slicing, but do not create one task per module
-- Order slices so blockers come first
-
-## Step 4: Quiz the user
-
-Present the proposed slices as a numbered list. For each slice, include:
-
-- Title
-- Type: `HITL` or `AFK`
-- Blocked by
-- User stories covered
-
-Ask the user whether:
-
-- The granularity is right
-- The dependencies are correct
-- Any slices should be merged or split
-- The `HITL` versus `AFK` labels are accurate
-
-Iterate until approved.
-
-## Step 5: Write task files
-
-Only write files after the user approves the breakdown.
-
-Create `.prd/{prd-name}/tasks/` if needed.
-
-Create one Markdown file per task using zero-padded numeric prefixes:
-
-- `.prd/{prd-name}/tasks/01-{task-slug}.md`
-- `.prd/{prd-name}/tasks/02-{task-slug}.md`
-
-`{task-slug}` should be kebab-case and derived from the task title.
-
-Each task file should use this structure:
-
-```md
-# {Task title}
-
-- Type: AFK | HITL
-- Status: Proposed
-- Blocked by: None | 01-other-task
-- Source PRD: ../prd.md
-
-## What to Build
-
-Concise description of the vertical slice. Describe end-to-end behavior, not a layer-by-layer checklist.
-
-## Acceptance Criteria
-
-- [ ] Criterion 1
-- [ ] Criterion 2
-- [ ] Criterion 3
-
-## User Stories Addressed
-
-- User story 3
-- User story 7
-
-## Notes
-
-- Optional implementation hints grounded in the current codebase
-- Reference relevant modules or concepts, but avoid binding the task to fragile file-level details unless necessary
-```
-
-Also create or update `.prd/{prd-name}/tasks/README.md` with:
-
-- The PRD title
-- The approved slice list in dependency order
-- A short summary of each task
-
-## Important constraints
-
-- Do not modify `prd.md` unless the user asks
-- Do not delete existing task files unless the user explicitly approves replacement
-- If existing tasks overlap the proposed slices, call that out before writing duplicates
-
-## After writing
-
-Summarize:
-
-- The PRD slug used
-- The task files created or updated
-- Any existing task files that were preserved

package/dist/skills/react-native-async-patterns/SKILL.md

@@ -1,256 +0,0 @@
----
-name: react-native-async-patterns
-description: Async/await correctness in React Native with Zustand. Use when debugging race conditions, missing awaits, floating promises, or async timing issues in Expo/React Native apps.
----
-
-# React Native Async Patterns
-
-## Problem Statement
-
-Async bugs in React Native are insidious because they often work in development but fail under load or on slower devices. The most common issues: missing `await` on async functions, race conditions between state updates, and assuming operations complete in order.
-
----
-
-## Pattern: Floating Promise Detection
-
-**Problem:** Calling an async function without `await` causes it to run in the background. If subsequent code depends on its completion, you get a race condition.
-
-**Example (from retake bug):**
-
-```typescript
-// Before (buggy) - enableSkillAreaRetake is async but not awaited
-enableSkillAreaRetake(skillArea);         // Fire and forget ❌
-await clearSkillAreaAnswers(skillArea);   // Runs before enable completes
-
-// After (fixed)
-await enableSkillAreaRetake(skillArea);   // Wait for state update ✅
-await clearSkillAreaAnswers(skillArea);   // Now runs in correct order
-```
-
-**Why it's subtle:** Both functions might have `async` in their signature, but only one was awaited. The code "looks right" at a glance.
-
-**Detection:**
-
-```bash
-# Find potential floating promises - async calls without await
-grep -rn "^\s*[a-zA-Z]*\s*(" --include="*.ts" --include="*.tsx" | \
-grep -v "await\|return\|const\|let\|if\|else\|=>"
-```
-
-**Prevention:**
-
-1. ESLint rule `@typescript-eslint/no-floating-promises` - catches this at lint time
-2. Code review trigger: Any line calling a function that might be async without `await`, `return`, or assignment
-
----
-
-## Pattern: Post-Condition Validation
-
-**Problem:** Assuming an async call succeeded without verifying. The call might return early, throw silently, or fail to update state.
-
-**Example (from retake bug):**
-
-```typescript
-// Before (buggy) - assumed load worked
-await loadCompletedAssessmentAnswers(id);
-// Proceeded blindly with retake flow...
-
-// After (defensive)
-await loadCompletedAssessmentAnswers(id);
-const loaded = useAssessmentStore.getState().completedAssessmentAnswers;
-if (Object.keys(loaded).length === 0) {
-  throw new Error(
-    `Failed to load answers for assessment ${id} - cannot proceed with retake`
-  );
-}
-```
-
-**Principle:** Treat every async call as potentially failed until proven otherwise.
-
-**When to validate:**
-
-- After loading data that subsequent operations depend on
-- After state updates that must complete before continuing
-- Before irreversible operations (submissions, deletions)
-
-**Pattern template:**
-
-```typescript
-await someAsyncOperation();
-const result = getRelevantState();
-if (!isValid(result)) {
-  throw new Error(`[${functionName}] Post-condition failed: ${diagnosticContext}`);
-}
-```
-
----
-
-## Pattern: Async Function Identification
-
-**Problem:** Not all async functions look async. Zustand actions, callbacks, and promise-returning functions may not have obvious `async` keywords.
-
-**Hidden async patterns:**
-
-```typescript
-// Obvious async
-async function fetchData() { ... }
-
-// Less obvious - returns Promise
-function fetchData(): Promise<Data> { ... }
-
-// Hidden - Zustand action that's actually async
-const useStore = create((set, get) => ({
-  // This looks sync but calls async internally
-  enableRetake: (area: string) => {
-    someAsyncSetup().then(() => {  // ← Hidden async!
-      set({ retakeAreas: [...get().retakeAreas, area] });
-    });
-  },
-}));
-
-// Proper async Zustand action
-const useStore = create((set, get) => ({
-  enableRetake: async (area: string) => {
-    await someAsyncSetup();
-    set({ retakeAreas: [...get().retakeAreas, area] });
-  },
-}));
-```
-
-**Detection:** Check function signatures and implementations:
-
-```bash
-# Find functions returning Promise
-grep -rn "): Promise<" --include="*.ts" --include="*.tsx"
-
-# Find .then() chains that might need await
-grep -rn "\.then(" --include="*.ts" --include="*.tsx"
-```
-
----
-
-## Pattern: Sequential vs Parallel Async
-
-**Problem:** Running async operations sequentially when they could be parallel (slow), or parallel when they must be sequential (race condition).
-
-```typescript
-// Sequential - correct when order matters
-await enableSkillAreaRetake(skillArea);
-await clearSkillAreaAnswers(skillArea);
-await loadRetakeQuestions(skillArea);
-
-// Parallel - correct when operations are independent
-const [user, settings, history] = await Promise.all([
-  fetchUser(id),
-  fetchSettings(id),
-  fetchHistory(id),
-]);
-
-// WRONG - parallel when order matters
-await Promise.all([
-  enableSkillAreaRetake(skillArea),   // These have dependencies!
-  clearSkillAreaAnswers(skillArea),
-]);
-```
-
-**Decision framework:**
-
-| Operations share state? | Must run in order? | Pattern |
-| ------------------------ | ------------------- | --------- |
-| No | No | `Promise.all()` |
-| Yes | Yes | Sequential `await` |
-| Yes | No | Usually sequential to be safe |
-
----
-
-## Pattern: Async in useEffect
-
-**Problem:** `useEffect` callbacks can't be async directly. Common mistakes with cleanup and race conditions.
-
-```typescript
-// WRONG - useEffect can't be async
-useEffect(async () => {
-  const data = await fetchData();
-  setData(data);
-}, []);
-
-// CORRECT - async function inside
-useEffect(() => {
-  async function load() {
-    const data = await fetchData();
-    setData(data);
-  }
-  load();
-}, []);
-
-// BETTER - with cleanup for race conditions
-useEffect(() => {
-  let cancelled = false;
-
-  async function load() {
-    const data = await fetchData();
-    if (!cancelled) {
-      setData(data);
-    }
-  }
-  load();
-
-  return () => {
-    cancelled = true;
-  };
-}, [dependency]);
-```
-
----
-
-## ESLint Configuration
-
-Apply config from `configs/eslint-async.json` to catch these issues at lint time:
-
-```json
-{
-  "rules": {
-    "@typescript-eslint/no-floating-promises": "error",
-    "@typescript-eslint/require-await": "warn",
-    "@typescript-eslint/await-thenable": "error",
-    "@typescript-eslint/no-misused-promises": "error"
-  }
-}
-```
-
-**Required:** `@typescript-eslint/eslint-plugin` and proper TypeScript configuration.
-
----
-
-## Code Review Checklist
-
-When reviewing async code, check:
-
-- [ ] Every async function call is either `await`ed, `return`ed, or explicitly fire-and-forget with comment
-- [ ] Operations that depend on each other are sequenced with `await`
-- [ ] Post-conditions validated after critical async operations
-- [ ] `useEffect` with async uses the inner function pattern
-- [ ] Race conditions considered when component could unmount during async
-- [ ] Error handling exists for async failures
-
----
-
-## Quick Debugging
-
-When async timing issues occur:
-
-```typescript
-// Add timestamps to trace execution order
-console.log(`[${Date.now()}] Starting enableRetake`);
-await enableSkillAreaRetake(skillArea);
-console.log(`[${Date.now()}] Finished enableRetake`);
-console.log(`[${Date.now()}] Starting clearAnswers`);
-await clearSkillAreaAnswers(skillArea);
-console.log(`[${Date.now()}] Finished clearAnswers`);
-```
-
-Look for:
-
-- Operations finishing out of expected order
-- Operations starting before previous ones complete
-- Suspiciously fast "completions" (might not have awaited)