@complexthings/superpowers-agent 9.2.1 → 10.0.1

package/skills/finding-skills/SKILL.md

@@ -1,101 +0,0 @@
----
-name: finding-skills
-description: Use when you need to discover what skills are available before starting any task, find a skill for a specific problem, search by keyword or topic, or understand which skill to use. Always check for skills at the start of any conversation or before beginning a task — if a skill exists for what you're doing, you must use it.
----
-
-# Finding Skills
-
-## Overview
-
-Before starting any task, discover what skills are available so you don't reinvent solved problems. Skills encode proven workflows — using them prevents known mistakes and saves time.
-
-## When to Use
-
-- Starting a new task or conversation (always check first)
-- Looking for guidance on a specific problem (debugging, testing, planning, etc.)
-- Unsure whether a skill exists for something you're about to do
-- Asked "is there a skill for X?" or "what skills are available?"
-
-## How to Find Skills
-
-### Native Skill Tool (Primary Method — All Platforms)
-
-Most AI coding assistants expose a native skill or tool mechanism. Use it first:
-
-- **If your platform has a native `skill` tool**: use it to list or load skills by name — this is the fastest path
-- **If skills appear in your system context** (e.g., an `<available_skills>` block or similar): scan that list before starting any task
-- **If your platform supports `@skill` mentions or tool invocations**: use those to activate a skill directly
-
-When in doubt, check whatever mechanism your platform provides to discover available skills before doing anything else.
-
-### CLI: superpowers-agent find-skills
-
-```bash
-superpowers-agent find-skills
-```
-
-This shows all skills from superpowers-managed locations with their names and descriptions.
-
-**Filter by piping to grep:**
-```bash
-# Find testing-related skills
-superpowers-agent find-skills | grep -i test
-
-# Find debugging skills
-superpowers-agent find-skills | grep -i debug
-
-# Find skills about a topic
-superpowers-agent find-skills | grep -i brainstorm
-```
-
-**Get the path to a specific skill:**
-```bash
-superpowers-agent path <skill-name>
-```
-
-**Load and execute a skill directly:**
-```bash
-superpowers-agent execute <skill-name>
-```
-
-## Skill Locations and Priority
-
-Skills are discovered from multiple locations. Higher priority overrides lower when names conflict:
-
-| Priority | Location | Scope |
-|----------|----------|-------|
-| 1 (highest) | `.agents/skills/` in project | Project-specific |
-| 1 (highest) | Platform project skill dir (e.g. `.claude/skills/`) | Project-specific |
-| 2 | `~/.agents/skills/` | Personal, cross-project |
-| 3 | Platform system skill directory | Platform system skills |
-| 4 (lowest) | `~/.agents/superpowers/skills/` | Superpowers community skills |
-
-Project skills always win. When a project skill and a system skill share the same name, the project version is used.
-
-## After Finding a Skill
-
-Once you identify a relevant skill:
-
-1. Load it using your platform's native skill tool, or via `superpowers-agent execute <name>`
-2. Announce: "Using Skill: [name] to [purpose]"
-3. Follow the skill's instructions exactly
-
-If a skill exists for your task, using it is not optional — skills encode solutions to known problems.
-
-## Common Mistakes
-
-**Don't:**
-- Skip checking for skills because "this is simple" — simple tasks are exactly when you're most likely to miss that a skill exists
-- Assume you remember what skills are available — the list changes, check fresh each time
-- Search only by exact name — grep descriptions too, skills may use different terminology
-
-**Do:**
-- Check at the start of every task, before writing code or asking clarifying questions
-- Search broadly (e.g., `grep -i plan` finds `writing-plans`, `executing-plans`, etc.)
-- If in doubt whether a skill applies, load it and check — it costs little to verify
-
-## Related Skills
-
-- **using-a-skill** - How to load and apply a skill once found
-- **using-superpowers** - Introduction to the full skills system
-- **writing-skills** - Create new skills using TDD

package/skills/finding-skills/skill.json

@@ -1,8 +0,0 @@
-{
-    "version": "1.0.0",
-    "name": "superpowers:finding-skills",
-    "title": "finding-skills",
-    "aliases": [
-        "finding-skills"
-    ]
-}

package/skills/meta/create-agents-md/SKILL.md

@@ -1,182 +0,0 @@
----
-name: create-agents-md
-description: Analyzes a codebase and creates or improves an AGENTS.md file at the repo root — the open-standard instruction file that AI coding agents (Claude Code, Codex, Cursor, Copilot, Gemini CLI, Aider, and others) read for build/test commands, code style, and conventions. Use whenever the user asks to create, generate, write, update, or improve an AGENTS.md, onboard agents to a repo, document build/test/lint commands for AI tools, or consolidate scattered agent instruction files (CLAUDE.md, .cursorrules, .cursor/rules, .github/copilot-instructions.md) into one. Use even if the user only says "make an agents file" or "document this repo for AI agents".
-metadata:
-  version: 1.0.0
----
-
-# Create AGENTS.md
-
-## Overview
-
-`AGENTS.md` is an open, cross-tool standard (https://agents.md/): a "README for agents" placed at the repo root that gives AI coding agents the build steps, test commands, and conventions they need to work in a repository. 20+ tools read it, including Claude Code, OpenAI Codex, Cursor, GitHub Copilot, Gemini CLI, Aider, Jules, and Zed.
-
-This skill produces that file by **reading the actual repository** and writing down what is true of it — never boilerplate, never invented conventions.
-
-**Core principle: facts only.** Every command, style rule, and convention in the output must come from a file you actually read. If you can't verify it, don't write it. A short AGENTS.md that is 100% accurate beats a long one padded with plausible guesses — agents will run the commands you list, and a wrong command wastes their time.
-
-## When NOT to use this skill
-
-- The user wants a human-facing project README → that's `README.md`, not AGENTS.md.
-- The user wants to set up the superpowers skills system → use `setup-skills`.
-- The user wants to audit/improve a subagent prompt file → use `enhance-agent-prompts`.
-
-## Workflow
-
-Copy this checklist and track progress as you go:
-
-```
-AGENTS.md Progress:
-- [ ] Step 1: Detect ecosystem and locate inputs
-- [ ] Step 2: Read existing instruction files (don't replace blindly)
-- [ ] Step 3: Extract verifiable commands (build, lint, test, single test)
-- [ ] Step 4: Infer code style and conventions from real source
-- [ ] Step 5: Decide scope — single file vs. nested (monorepo)
-- [ ] Step 6: Write or improve AGENTS.md
-- [ ] Step 7: Self-review against the accuracy checklist
-```
-
-Use `leveraging-cli-tools` throughout — prefer `rg`, `fd`, `bat`, `jq`, and `ast-grep` over slower alternatives. The detection commands below assume them.
-
-### Step 1: Detect ecosystem and locate inputs
-
-Identify the stack before reading anything in depth. This tells you which config files matter.
-
-```bash
-# Manifests and lockfiles reveal the package manager and language
-fd -H -d 2 '^(package\.json|pnpm-lock\.yaml|yarn\.lock|package-lock\.json|bun\.lockb|Cargo\.toml|go\.mod|pyproject\.toml|requirements\.txt|Gemfile|composer\.json|pom\.xml|build\.gradle)$'
-```
-
-The lockfile is the source of truth for the package manager: `pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, `bun.lockb` → bun, otherwise `package-lock.json` → npm. Use the right one in every command you document — telling an agent to run `npm test` in a pnpm repo is a factual error.
-
-### Step 2: Read existing instruction files
-
-Read each of these if present. The goal is to **improve, not overwrite** — preserve still-accurate content and fold in scattered rules.
-
-```bash
-fd -H -d 3 '^(AGENTS\.md|CLAUDE\.md|GEMINI\.md|\.cursorrules|copilot-instructions\.md)$'
-fd -H -t f . .cursor/rules 2>/dev/null   # Cursor rules live here as .mdc files
-```
-
-- **Existing `AGENTS.md`** — treat as the base. Keep what's correct, fix what's stale, fill gaps.
-- **`.cursor/rules/*.mdc`, `.cursorrules`, `.github/copilot-instructions.md`, `CLAUDE.md`, `GEMINI.md`** — extract real rules (style, conventions, do/don'ts) and incorporate them verbatim or tightly summarized. Note their source so the user can later consolidate (see [Consolidating instruction files](#consolidating-instruction-files)).
-
-### Step 3: Extract verifiable commands
-
-These are the highest-value content — agents run them directly. Pull them from config, don't guess.
-
-```bash
-# Node: the scripts block IS the command list
-jq '.scripts' package.json 2>/dev/null
-
-# Other ecosystems: read the real task definitions
-bat Makefile justfile Taskfile.yml 2>/dev/null
-rg -n '\[tool\.(poetry|hatch|pdm)\.|^\[project\.scripts\]' pyproject.toml 2>/dev/null
-```
-
-Capture: **build**, **lint**, **lint:fix/format**, **typecheck**, **test**, and crucially **how to run a single test in isolation** (e.g. `vitest run path/to/file.test.ts -t "name"`, `pytest path::test_name`, `go test ./pkg -run TestName`). Single-test invocation is the one agents most often get wrong, so derive it from the actual test runner rather than assuming.
-
-If a command isn't defined anywhere, say how the tool is normally invoked for that runner — but only if the runner is actually present in the manifest.
-
-### Step 4: Infer code style and conventions
-
-Read formatter/linter config first (these are authoritative), then confirm against a representative sample of real source files.
-
-```bash
-fd -H -d 2 '^(\.eslintrc.*|eslint\.config\.*|\.prettierrc.*|prettier\.config\.*|biome\.json|\.editorconfig|ruff\.toml|\.rubocop\.yml|rustfmt\.toml|tsconfig\.json)$'
-```
-
-Confirm by reading several source files in the primary language — don't document a rule the config implies but the code contradicts. Cover what an agent needs to match the house style:
-
-- **Imports** — ordering, named vs. default, file extensions, path aliases.
-- **Formatting** — quotes, semicolons, indentation, line length (usually settled by the formatter config — cite it).
-- **Types** — strictness, annotation expectations, `any` policy.
-- **Naming** — files, functions, variables, constants, components, CSS classes.
-- **Error handling** — the pattern actually used (Result types, exceptions, error-wrapping helpers) and anything the codebase clearly avoids.
-
-For naming/error patterns, prefer `ast-grep` or `rg` over eyeballing one file, so the convention you state reflects the codebase, not a single example.
-
-### Step 5: Decide scope — single file vs. nested
-
-AGENTS.md supports **nested files**: an agent reads the nearest one in the directory tree, so the closest file wins. For a monorepo, a per-package AGENTS.md often beats one bloated root file.
-
-- **Single package** → one root `AGENTS.md`.
-- **Monorepo** (workspaces in `package.json`, `pnpm-workspace.yaml`, Nx/Turbo/Lerna, multiple manifests) → write a root file with shared/global instructions, and offer to add per-package files where commands or conventions genuinely differ. Don't duplicate identical content into every package.
-
-### Step 6: Write or improve AGENTS.md
-
-Write to `AGENTS.md` at the repo root (or the relevant package root for nested files). It's plain Markdown with no required schema — use clear headings. Default to the structure below, dropping any section you have no real content for.
-
-Keep it precise and scannable, written for an agent audience, with no prose padding. **~150 lines is a ceiling, not a goal** — let the real content set the length. A small library might warrant only 30–40 lines; a large monorepo more. If you find yourself adding material to fill space, stop: a short, fully accurate file is the win, and padding directly violates the facts-only principle.
-
-```markdown
-# AGENTS.md
-
-Short orienting line: what this project is and the primary language/framework.
-
-## Setup
-- Install: `<exact command for this repo's package manager>`
-- Env/prereqs: `<only if real — node version from .nvmrc/engines, services, etc.>`
-
-## Commands
-- Build: `<cmd>`
-- Dev: `<cmd>`
-- Lint: `<cmd>`  |  Fix: `<cmd>`  |  Typecheck: `<cmd>`
-- Test (all): `<cmd>`
-- Test (single): `<exact single-test invocation>`
-
-## Code style
-- Imports: `<order, named/default, extensions, aliases>`
-- Formatting: `<quotes, semicolons, indent, width — cite the formatter>`
-- Types: `<strictness, annotation rules, any policy>`
-
-## Naming conventions
-- Files / functions / variables / constants / components / CSS — only the rules that hold
-
-## Error handling
-- The pattern this codebase uses; what to avoid
-
-## <Project-specific rules pulled from Cursor/Copilot/CLAUDE files>
-- Folded-in rules, kept verbatim or tightly summarized
-
-## PR / commit guidelines
-- Only if the repo evidences a convention (commitlint, CONTRIBUTING.md, PR template, git log pattern)
-```
-
-Adapt headings to the project. Sourced rules from `.cursor/rules`, Copilot, etc. should be merged into the relevant section above rather than ghettoized — but keep a short note of provenance if it helps the user consolidate later.
-
-### Step 7: Self-review against the accuracy checklist
-
-Before declaring done, re-read the file and verify every line:
-
-```
-- [ ] Every command was copied from a real script/task/config — not assumed
-- [ ] The package manager matches the lockfile in every command
-- [ ] A single-test invocation is present and correct for the actual runner
-- [ ] Every style/naming/error rule traces to config or observed source
-- [ ] Rules from Cursor/Copilot/CLAUDE files are incorporated, not lost
-- [ ] No invented conventions, no aspirational rules, no generic filler
-- [ ] An existing AGENTS.md was improved, not blindly replaced
-- [ ] Length is set by real content, not a quota (≤ ~150 lines); agent-audience tone; scannable
-```
-
-If anything fails, fix it before finishing.
-
-## Consolidating instruction files
-
-A common (community, not part of the official spec) convention is to make AGENTS.md the single source of truth and symlink tool-specific files to it, so every tool reads the same content:
-
-```bash
-ln -sf AGENTS.md CLAUDE.md
-ln -sf AGENTS.md GEMINI.md
-ln -sf AGENTS.md .github/copilot-instructions.md
-```
-
-Only do this if the user asks. Flag it as optional and confirm first — it's a destructive change to existing files, and some teams deliberately keep tool-specific instructions separate.
-
-## Edge cases
-
-- **Empty or near-empty repo** — document only the scaffolding that exists (e.g. the manifest and its scripts). Don't pad.
-- **Polyglot repo** — lead with the primary language; give each significant language its own command block.
-- **Conflicting rules across instruction files** — prefer what the code and config actually do; note the conflict for the user rather than silently picking one.
-- **No build/test tooling at all** — keep the file minimal and say so plainly, rather than inventing commands.

package/skills/meta/create-agents-md/skill.json

@@ -1,9 +0,0 @@
-{
-  "version": "1.0.0",
-  "name": "superpowers:meta/create-agents-md",
-  "title": "create-agents-md",
-  "aliases": [
-    "create-agents-md",
-    "meta/create-agents-md"
-  ]
-}

package/skills/meta/creating-prompts/SKILL.md

@@ -1,349 +0,0 @@
----
-name: creating-prompts
-description: Create structured prompts for Do/Plan/Research/Refine workflows with dependency management
-metadata:
-  when_to_use: when you need to create focused, reusable prompts for specific tasks, research, planning, or refinement workflows
-  version: 5.1.0
-  languages: all
----
-
-# Creating Prompts
-
-## Overview
-
-Create structured, reusable prompts for agent workflows. Prompts are focused instructions for specific tasks (Do), strategic planning (Plan), information gathering (Research), or iterative improvement (Refine).
-
-**Core principle:** Prompts are lightweight, self-contained instructions that can be chained together through dependencies.
-
-**Announce at start:** "I'm using the Creating Prompts skill to create a {purpose} prompt."
-
-## When to Use
-
-**Use this skill when:**
-- Creating focused task instructions for agents
-- Building multi-stage workflows (research → plan → implement)
-- Need reusable prompts that can be executed independently
-- Want to chain prompts with explicit dependencies
-
-**When NOT to use:**
-- For comprehensive implementation plans (use `writing-plans` skill instead)
-- For features >100 LOC (use `writing-plans` for full roadmaps)
-- One-off instructions (just give the instruction directly)
-
-**Decision flowchart:**
-
-```
-Need instructions for agent?
-├─ One-time task → Give instruction directly
-├─ <100 LOC, focused → Create Prompt (this skill)
-└─ >100 LOC, comprehensive → Use writing-plans skill
-```
-
-## Integration with Other Skills
-
-**Before creating prompts:**
-- For complex features → Use `brainstorming` skill to refine requirements first
-- Unsure of approach → Start with Research prompt, then Plan, then Do
-
-**After creating prompts:**
-- Validate clarity → Use `testing-skills-with-subagents` to verify prompt works
-- Execute prompts → Follow execution guidance (see below)
-
-**Prompts vs Plans:**
-- **Prompts**: Lightweight, focused, single-purpose (this skill)
-- **Plans**: Comprehensive, multi-phase, detailed implementation (`writing-plans`)
-
-See skills/collaboration/writing-plans for full implementation plans.
-See skills/collaboration/brainstorming for design refinement before prompting.
-
-## Configuration
-
-Prompts are saved to configured directory (default: `.agents/prompts/`).
-
-**Read config:**
-```bash
-superpowers-agent get-config prompts_dir
-```
-
-**Override globally:** `~/.agents/config.json`
-```json
-{
-  "prompts_dir": "custom/prompts"
-}
-```
-
-**Override per-project:** `.agents/config.json`
-```json
-{
-  "prompts_dir": ".my-prompts"
-}
-```
-
-Priority: Project config > Global config > Default (`.agents/prompts/`)
-
-## Prompt Types
-
-### 1. DO Prompts - Execute and Produce
-
-**When:** Implement feature, fix bug, create document, build component
-
-**Output:** Code files, documentation, configurations, designs
-
-**Template:** `skills/meta/creating-prompts/templates/do-template.md`
-
-**Example:** `skills/meta/creating-prompts/examples/do-example.md`
-
-### 2. PLAN Prompts - Strategy and Roadmap
-
-**When:** Design architecture, plan refactoring, decide approach
-
-**Output:** Structured plans with phases, dependencies, decisions
-
-**Template:** `skills/meta/creating-prompts/templates/plan-template.md`
-
-**Example:** `skills/meta/creating-prompts/examples/plan-example.md`
-
-### 3. RESEARCH Prompts - Gather Information
-
-**When:** Understand library, explore patterns, analyze options
-
-**Output:** Findings with confidence levels, recommendations, open questions
-
-**Template:** `skills/meta/creating-prompts/templates/research-template.md`
-
-**Example:** `skills/meta/creating-prompts/examples/research-example.md`
-
-### 4. REFINE Prompts - Iterative Improvement
-
-**When:** Deepen research, strengthen plan, address gaps
-
-**Output:** Updated version with changelog, archived previous version
-
-**Template:** `skills/meta/creating-prompts/templates/refine-template.md`
-
-**Example:** `skills/meta/creating-prompts/examples/refine-example.md`
-
-## Quick Reference
-
-| Prompt Type | Purpose | Output | Common Chain |
-|-------------|---------|--------|--------------|
-| Research | Gather info | Findings + recommendations | Research → Plan → Do |
-| Plan | Strategy | Phases + decisions | Plan → Do |
-| Do | Execute | Artifacts (code/docs) | Standalone or after Plan |
-| Refine | Improve | Updated version | After any type |
-
-## Workflow Checklist
-
-**IMPORTANT: Use TodoWrite to create todos for EACH checklist item below.**
-
-### Phase 1: Preparation
-- [ ] Determine prompt purpose (Do/Plan/Research/Refine)
-- [ ] If complex feature → Consider using `/brainstorm` first
-- [ ] If >100 LOC implementation → Consider `writing-plans` skill instead
-- [ ] Identify topic for naming (kebab-case: auth, stripe-integration)
-- [ ] Check for existing prompts to reference (creates dependencies)
-
-### Phase 2: Creation
-- [ ] Get next number: `skills/meta/creating-prompts/scripts/get-next-number.sh`
-- [ ] Get prompts directory: `superpowers-agent get-config prompts_dir`
-- [ ] Load appropriate template from `skills/meta/creating-prompts/templates/`
-- [ ] Fill in template with specific details (no placeholders)
-- [ ] Add frontmatter metadata (number, topic, purpose, dependencies)
-- [ ] Reference existing outputs with `@` syntax if chained
-
-### Phase 3: Quality Checks
-- [ ] Objective is clear and specific (not vague)
-- [ ] Context includes all necessary background
-- [ ] Requirements are testable/verifiable
-- [ ] Output specification is concrete
-- [ ] Success criteria are measurable
-- [ ] For Research/Plan: includes confidence/assumptions/open questions
-
-### Phase 4: Validation (Recommended)
-- [ ] Test prompt with subagent (see `testing-skills-with-subagents`)
-- [ ] Verify subagent understands requirements
-- [ ] Check output matches expected structure
-
-### Phase 5: Save and Execute
-- [ ] Create directory: `{prompts_dir}/{number}-{topic}-{purpose}/`
-- [ ] Create `completed/` subdirectory
-- [ ] Save prompt: `{number}-{topic}-{purpose}.md`
-- [ ] Execute prompt (agent reads and follows instructions)
-- [ ] Agent creates output: `{topic}-{purpose}-output.md`
-- [ ] Agent creates `SUMMARY.md` with findings/decisions/next steps
-- [ ] Move prompt to `completed/` after execution
-
-## File Structure
-
-```
-.agents/prompts/                              # Configured location
-├── 001-auth-research/
-│   ├── 001-auth-research.md                  # The prompt
-│   ├── completed/
-│   │   └── 001-auth-research.md              # After execution
-│   ├── auth-research-output.md               # Agent's output
-│   └── SUMMARY.md                            # Executive summary
-├── 002-auth-plan/
-│   ├── 002-auth-plan.md
-│   ├── completed/
-│   ├── auth-plan-output.md
-│   └── SUMMARY.md
-└── 003-auth-do/
-    ├── 003-auth-do.md
-    ├── completed/
-    ├── auth-do-output.md
-    └── SUMMARY.md
-```
-
-## Naming Convention
-
-**Format:** `{number}-{topic}-{purpose}.md`
-
-**Examples:**
-- `001-auth-research.md` - Research authentication options
-- `002-auth-plan.md` - Plan auth implementation
-- `003-stripe-integration-do.md` - Implement Stripe
-- `004-auth-research-refine.md` - Deepen auth research
-
-**Topic naming:**
-- Use kebab-case
-- Be specific but concise
-- Examples: `auth`, `stripe-integration`, `user-profile`, `api-refactor`
-
-## Dependency Detection
-
-Prompts can reference other prompt outputs to create chains.
-
-**Syntax:** `@.agents/prompts/{folder}/{file}-output.md`
-
-**Example in prompt:**
-```markdown
-<context>
-Based on research: @.agents/prompts/001-auth-research/auth-research-output.md
-Based on plan: @.agents/prompts/002-auth-plan/auth-plan-output.md
-</context>
-```
-
-**Frontmatter dependencies:**
-```yaml
----
-number: 003
-topic: auth-do
-purpose: do
-dependencies: [001, 002]  # Must execute 001 and 002 first
-created: 2025-11-21
----
-```
-
-## SUMMARY.md Template
-
-Every prompt execution should create a `SUMMARY.md`:
-
-```markdown
-# {Topic} {Purpose} Summary
-
-**One-liner:** [Substantive description of outcome, not generic]
-
-## Key Findings
-- [Actionable takeaway 1]
-- [Actionable takeaway 2]
-- [Actionable takeaway 3]
-
-## Decisions Needed
-- [What requires user input or approval]
-- Or: "None"
-
-## Blockers
-- [External impediments preventing progress]
-- Or: "None"
-
-## Next Step
-[Concrete forward action - what to do next]
-```
-
-## Execution Guidance
-
-**How agents execute prompts:**
-
-1. **Read the prompt** - Load `{number}-{topic}-{purpose}.md`
-2. **Check dependencies** - Ensure referenced prompts completed first
-3. **Follow instructions** - Execute according to prompt sections
-4. **Create output** - Save to `{topic}-{purpose}-output.md`
-5. **Create summary** - Save `SUMMARY.md` with findings
-6. **Archive prompt** - Move to `completed/` subfolder
-
-**For agents with Task/subagent capabilities:**
-- Spawn fresh agent with prompt as instruction
-- Agent produces output and summary
-- Main agent reviews and archives
-
-**For manual execution:**
-- Open prompt in editor
-- Follow instructions step-by-step
-- Create output and summary files
-- Move prompt to completed/
-
-## Common Mistakes
-
-### ❌ Vague objectives
-```markdown
-<objective>
-Research authentication
-</objective>
-```
-
-### ✅ Specific objectives
-```markdown
-<objective>
-Research JWT authentication libraries for Node.js Express API to determine best option for TypeScript project with security focus
-</objective>
-```
-
-### ❌ Missing context
-```markdown
-<context>
-Current codebase
-</context>
-```
-
-### ✅ Concrete context
-```markdown
-<context>
-Express API in src/server.js, routes in src/routes/
-Currently no authentication, all endpoints public
-Must integrate with existing PostgreSQL user table
-@src/server.js
-@src/routes/api.js
-</context>
-```
-
-### ❌ Generic requirements
-```markdown
-<requirements>
-Should work well
-Be secure
-</requirements>
-```
-
-### ✅ Testable requirements
-```markdown
-<requirements>
-- Verify JWT tokens in Authorization header
-- Return 401 for invalid tokens
-- Return 403 for expired tokens
-- Extract user ID and attach to req.user
-- No performance impact >10ms per request
-</requirements>
-```
-
-## Credits
-
-This skill is an agent-agnostic adaptation of TÂCHES' excellent [`create-meta-prompts` skill](https://github.com/glittercowboy/taches-cc-resources/tree/main/skills/create-meta-prompts).
-
-TÂCHES pioneered the concept of structured prompt-to-prompt workflows with dependency management and multi-stage execution. This adaptation maintains the core concepts while making them accessible across all AI coding assistants (OpenCode, GitHub Copilot, Cursor, Gemini, Claude, etc.).
-
-**Original author:** TÂCHES ([@glittercowboy](https://github.com/glittercowboy))
-
-**Original repository:** https://github.com/glittercowboy/taches-cc-resources
-
-Thank you to TÂCHES for the innovative work on meta-prompt patterns!