agents-templated 2.2.19 → 2.2.21

package/templates/agents/skills/app-hardening/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: app-hardening
+description: Applies risk-based application hardening guidance including obfuscation decisions, integrity controls, and release evidence.
+---
+
+# App Hardening
+
+Use this skill for security hardening of distributed applications and sensitive client-side logic.
+
+## Trigger Conditions
+
+- User asks for hardening, anti-tamper, reverse-engineering resistance, or secure release posture.
+- Project includes mobile/desktop/browser-delivered code with high-value logic.
+
+## Decision Matrix
+
+Apply hardening when:
+- Threat model includes tampering/repackaging/hooking, or
+- Client runtime is untrusted, or
+- Business/IP impact is high.
+
+Keep baseline controls regardless:
+- AuthN/AuthZ, validation, secrets hygiene, monitoring.
+
+## Workflow
+
+1. Define threat model and assets at risk.
+2. Select hardening profile by risk tier.
+3. Choose controls (obfuscation, integrity checks, runtime protections).
+4. Integrate into build/release pipeline.
+5. Run post-hardening functional + performance validation.
+6. Produce release evidence and rollback path.
+
+## Required Evidence
+
+- Hardening profile selection rationale
+- Verification results (functional + performance)
+- Symbol/mapping artifact access policy
+- Rollback steps and trigger conditions
+
+## Guardrails
+
+- Never treat obfuscation as a standalone security solution.
+- Never store secrets in client code.
+- Block release when hardening-required profile lacks evidence.

package/templates/agents/skills/bug-triage/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: bug-triage
+description: Reproduction-first bug workflow for reliable root-cause isolation, minimal patching, and regression protection.
+---
+
+# Bug Triage
+
+Use this skill for defects, crashes, unexpected behavior, and regressions.
+
+## Trigger Conditions
+
+- User reports bug symptoms ("broken", "fails", "crash", "not working").
+- There is a failing test or reproducible scenario.
+
+## Workflow
+
+1. Capture reproducible steps and expected vs actual behavior.
+2. Confirm failure reproduction locally or from evidence.
+3. Isolate probable subsystem and narrow root cause.
+4. Apply smallest safe patch in bounded scope.
+5. Add or run regression tests.
+6. Validate fix and report residual risks.
+
+## Output Contract
+
+- Defect summary and reproduction
+- Root cause hypothesis/finding
+- Patch summary
+- Validation evidence
+- Regression coverage update
+
+## Guardrails
+
+- Do not patch without reproduction evidence unless explicitly approved.
+- Avoid broad refactors in bug-fix flow.
+- Block when scope or acceptance criteria are unsafe/unclear.

package/templates/agents/skills/debug-skill/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: debug-skill
+description: Enables breakpoint-driven debugging workflows with execution tracing, state inspection, and root-cause proof before patching.
+---
+
+# Debug Skill
+
+Use this skill when the user is stuck on a bug and needs debugger-style investigation instead of print-guessing.
+
+## Trigger Conditions
+
+- User asks to debug, set breakpoints, step through code, or inspect runtime state.
+- A bug is intermittent, difficult to localize, or likely branch/state dependent.
+- Existing logs are insufficient to prove root cause.
+
+## Workflow
+
+1. Confirm a reproducible scenario and expected vs actual behavior.
+2. Define a checkpoint plan (breakpoints/log points/frames).
+3. Trace execution order across checkpoints.
+4. Capture variable-state transitions at failure boundaries.
+5. Prove root cause with execution evidence.
+6. Apply the smallest safe patch and run focused regressions.
+
+## Output Contract
+
+- Reproduction summary
+- Checkpoint plan
+- Execution trace highlights
+- State snapshots at critical steps
+- Root-cause finding
+- Minimal patch plan
+- Regression checks and residual risk
+
+## Guardrails
+
+- Do not ship speculative fixes without trace-backed evidence.
+- Do not skip regression validation after state-sensitive fixes.
+- If reproduction fails, stop and request missing runtime context.

package/templates/agents/skills/emilkowalski-skill/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: emilkowalski-skill
+description: Frontend interaction and motion quality checks for polished, minimal UI.
+---
+
+# Emil Kowalski Frontend Polish
+
+Use this skill when refining frontend motion, interaction quality, and visual clarity.
+
+## Trigger Conditions
+
+- User asks to improve UI quality, animations, or perceived smoothness.
+- User wants cleaner interactions without heavy redesign.
+- Interface feels functional but not polished.
+
+## Workflow
+
+1. Baseline the current interaction quality.
+2. Remove accidental motion (janky or decorative-only animation).
+3. Define motion hierarchy: page, section, element, micro-interaction.
+4. Tune timing and easing with consistency.
+5. Validate accessibility: reduced-motion support and focus visibility.
+6. Verify mobile and desktop interaction parity.
+
+## Frontend Quality Checklist
+
+- Animation duration is intentional and consistent.
+- Entry and exit transitions communicate state changes.
+- Hover/focus/active states are visually distinct.
+- Touch targets remain accessible on mobile.
+- Layout and typography remain readable during motion.
+
+## Output Contract
+
+- Interaction problems found
+- Priority fixes (high/medium/low)
+- Motion system decisions (duration, easing, delay)
+- Accessibility checks performed
+- Before/after verification notes
+
+## Guardrails
+
+- Do not add animation where no UX value exists.
+- Prefer CSS/transform-based transitions over layout-thrashing properties.
+- Always provide a reduced-motion fallback.
+- Keep performance budget visible (FPS, input latency, layout shifts).
+
+## Upstream Reference
+
+- Original package command:
+  - npx skills add emilkowalski/skill

package/templates/agents/skills/error-patterns/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: error-patterns
+description: >
+  Activate this skill whenever something is broken, failing, erroring, or crashing, especially
+  for build errors, type errors, database/migration failures, API/auth issues, and UI bugs.
+  Also activate when the user says "fix this", "it's broken", "I'm getting an error", or
+  "this keeps happening".
+---
+
+# Error Patterns
+
+You are debugging with persistent memory. Every fix should be recorded so it does not need to be solved twice.
+
+## Step 1 - Check Lessons First (Always)
+
+Before writing any fix, read `.claude/rules/lessons-learned.md`.
+
+- Search for symptoms that match the current error.
+- If a match is found, apply the known fix directly and state that the known fix was used.
+- If no match is found, continue to Step 2.
+
+## Step 2 - Diagnose by Category
+
+### [BUILD] Build / Type Errors
+- Read the full error trace, not just the first line.
+- Check for version mismatches, missing imports, circular dependencies, and config issues.
+- Verify lock file and dependency sync.
+
+### [DB] Database / Migration Errors
+- Check whether the migration already ran.
+- Verify DB URL and environment target.
+- Check for schema drift between model and database.
+- Avoid destructive migrations without a backup.
+
+### [API/AUTH] API / Auth Errors
+- Check token expiry, missing headers, and wrong scopes.
+- Verify environment variables for keys/secrets.
+- Check CORS and middleware order.
+- Log request/response safely (no secrets).
+
+### [UI] Frontend / UI Bugs
+- Check hydration mismatches.
+- Verify null/undefined guards and prop contracts.
+- Check list keys and class conflicts.
+- Confirm loading and error states are handled.
+
+## Step 3 - Apply the Fix
+
+- Make the minimum safe change needed.
+- Do not expand scope beyond the reported error.
+
+## Step 4 - Record the Lesson (Mandatory)
+
+After every successful fix, append to `.claude/rules/lessons-learned.md` using:
+
+```markdown
+### [CATEGORY] Short title of the error
+- **Symptom**: What the error looked like (message, behavior)
+- **Root Cause**: Why it happened
+- **Fix**: Exact steps or code that resolved it
+- **Avoid**: What NOT to do next time
+- **Date**: YYYY-MM-DD
+```
+
+## Step 5 - User Confirmation Message
+
+After fixing and recording, respond with one of:
+
+- `Fixed. I've saved this to lessons-learned so we won't have to solve it again.`
+- `Found this in lessons-learned and applied the known fix.`

package/templates/agents/skills/feature-delivery/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: feature-delivery
+description: Converts vague feature requests into scoped execution contracts with acceptance criteria, risk controls, and validation steps.
+---
+
+# Feature Delivery
+
+Use this skill when users describe features informally and need a systematic execution path.
+
+## Trigger Conditions
+
+- User asks to "build", "add", "create", or "implement" a feature.
+- Requirements are partial, broad, or non-technical.
+- Scope and acceptance criteria are not explicit.
+
+## Workflow
+
+1. Parse objective from user language.
+2. Define scope boundaries (in/out).
+3. Generate acceptance criteria (2-5 concrete checks).
+4. Derive implementation units in dependency order.
+5. Define validation plan (unit/integration/e2e where relevant).
+6. Identify risks and rollback notes.
+
+## Output Contract
+
+- Objective summary
+- Scope boundaries
+- Acceptance criteria
+- Execution steps
+- Verification steps
+- Risks and assumptions
+
+## Guardrails
+
+- Ask minimal clarifications only when blocked.
+- Do not execute destructive or broad changes without explicit scope.
+- Keep plans deterministic and auditable.

package/templates/agents/skills/feature-forge/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: feature-forge
+description: Turns vague feature requests into execution-ready requirements, acceptance criteria, and validation plans before coding starts.
+---
+
+# Feature Forge
+
+Use this skill before implementation when feature requests are high-level, ambiguous, or under-specified.
+
+## Trigger Conditions
+
+- User says build/add/create/implement without a full spec.
+- Requirements are broad or mixed between business and technical language.
+- Scope boundaries and acceptance criteria are unclear.
+
+## Workflow
+
+1. Restate objective and target user outcome.
+2. Define in-scope and out-of-scope boundaries.
+3. Convert asks into concrete functional requirements.
+4. Produce testable acceptance criteria.
+5. Split work into dependency-ordered slices.
+6. Define validation approach and rollback notes.
+
+## Output Contract
+
+- Objective summary
+- Scope in/out
+- Functional requirements
+- Acceptance criteria
+- Implementation slices
+- Validation plan
+- Risks, assumptions, and rollback notes
+
+## Guardrails
+
+- Do not move to implementation planning without explicit scope boundaries.
+- Keep acceptance criteria measurable and testable.
+- Raise blockers when requirements conflict or remain ambiguous.

package/templates/agents/skills/find-skills/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: find-skills
+description: Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
+---
+
+# Find Skills
+
+This skill helps you discover and install skills from the open agent skills ecosystem.
+
+## When to Use This Skill
+
+Use this skill when the user:
+
+- Asks "how do I do X" where X might be a common task with an existing skill
+- Says "find a skill for X" or "is there a skill for X"
+- Asks "can you do X" where X is a specialized capability
+- Expresses interest in extending agent capabilities
+- Wants to search for tools, templates, or workflows
+- Mentions they wish they had help with a specific domain (design, testing, deployment, etc.)
+
+## What is the Skills CLI?
+
+The Skills CLI (`npx skills`) is the package manager for the open agent skills ecosystem. Skills are modular packages that extend agent capabilities with specialized knowledge, workflows, and tools.
+
+**Key commands:**
+
+- `npx skills find [query]` - Search for skills interactively or by keyword
+- `npx skills add <package>` - Install a skill from GitHub or other sources
+- `npx skills check` - Check for skill updates
+- `npx skills update` - Update all installed skills
+
+**Browse skills at:** https://skills.sh/
+
+## How to Help Users Find Skills
+
+### Step 1: Understand What They Need
+
+When a user asks for help with something, identify:
+
+1. The domain (e.g., React, testing, design, deployment)
+2. The specific task (e.g., writing tests, creating animations, reviewing PRs)
+3. Whether this is a common enough task that a skill likely exists
+
+### Step 2: Search for Skills
+
+Run the find command with a relevant query:
+
+```bash
+npx skills find [query]
+```
+
+For example:
+
+- User asks "how do I make my React app faster?" → `npx skills find react performance`
+- User asks "can you help me with PR reviews?" → `npx skills find pr review`
+- User asks "I need to create a changelog" → `npx skills find changelog`
+
+The command will return results like:
+
+```
+Install with npx skills add <owner/repo@skill>
+
+vercel-labs/agent-skills@vercel-react-best-practices
+└ https://skills.sh/vercel-labs/agent-skills/vercel-react-best-practices
+```
+
+### Step 3: Present Options to the User
+
+When you find relevant skills, present them to the user with:
+
+1. The skill name and what it does
+2. The install command they can run
+3. A link to learn more at skills.sh
+
+Example response:
+
+```
+I found a skill that might help! The "vercel-react-best-practices" skill provides
+React and Next.js performance optimization guidelines from Vercel Engineering.
+
+To install it:
+npx skills add vercel-labs/agent-skills@vercel-react-best-practices
+
+Learn more: https://skills.sh/vercel-labs/agent-skills/vercel-react-best-practices
+```
+
+### Step 4: Offer to Install
+
+If the user wants to proceed, you can install the skill for them:
+
+```bash
+npx skills add <owner/repo@skill> -g -y
+```
+
+The `-g` flag installs globally (user-level) and `-y` skips confirmation prompts.
+
+## Common Skill Categories
+
+When searching, consider these common categories:
+
+| Category        | Example Queries                          |
+| --------------- | ---------------------------------------- |
+| Web Development | react, nextjs, typescript, css, tailwind |
+| Testing         | testing, jest, playwright, e2e           |
+| DevOps          | deploy, docker, kubernetes, ci-cd        |
+| Documentation   | docs, readme, changelog, api-docs        |
+| Code Quality    | review, lint, refactor, best-practices   |
+| Design          | ui, ux, design-system, accessibility     |
+| Productivity    | workflow, automation, git                |
+
+## Tips for Effective Searches
+
+1. **Use specific keywords**: "react testing" is better than just "testing"
+2. **Try alternative terms**: If "deploy" doesn't work, try "deployment" or "ci-cd"
+3. **Check popular sources**: Many skills come from `vercel-labs/agent-skills` or `ComposioHQ/awesome-claude-skills`
+
+## When No Skills Are Found
+
+If no relevant skills exist:
+
+1. Acknowledge that no existing skill was found
+2. Offer to help with the task directly using your general capabilities
+3. Suggest the user could create their own skill with `npx skills init`
+
+Example:
+
+```
+I searched for skills related to "xyz" but didn't find any matches.
+I can still help you with this task directly! Would you like me to proceed?
+
+If this is something you do often, you could create your own skill:
+npx skills init my-xyz-skill
+```

package/templates/agents/skills/llm-integration/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: llm-integration
+description: LLM integration patterns — prompt engineering, RAG pipelines, tool use, evaluation harnesses, and prompt injection defense.
+---
+
+# LLM Integration
+
+Use this skill when building, debugging, or reviewing AI/LLM-powered features.
+
+## Trigger Conditions
+
+- User is integrating an LLM (OpenAI, Anthropic, Gemini, local models) into an application.
+- Prompt engineering, system prompt design, or output parsing is discussed.
+- RAG (retrieval-augmented generation) architecture is needed.
+- Evaluation, benchmarking, or quality measurement of an LLM feature is requested.
+- Prompt injection risks are identified or suspected.
+- Tool use / function calling patterns are being designed.
+
+## Workflow
+
+### Prompt Engineering
+
+1. Separate system prompt (policy/persona) from user content (data) — never merge them raw.
+2. Use structured output formats (JSON mode, XML tags) for parseable responses.
+3. Specify output constraints explicitly: length, format, forbidden content.
+4. Test prompts against adversarial and edge-case inputs before shipping.
+
+### RAG Pipeline
+
+1. Chunk source documents at semantic boundaries (paragraph, section heading).
+2. Embed chunks with a consistent model; store in a vector DB with source metadata.
+3. At query time: embed query → retrieve top-k chunks → score → discard below threshold.
+4. Inject retrieved chunks into prompt with clear source attribution markers.
+5. Cite sources in final output — never present retrieved facts as model knowledge.
+
+### Tool Use / Function Calling
+
+1. Define tool schemas with strict input types (JSON Schema).
+2. Validate all tool call arguments before executing — treat as untrusted input.
+3. Never expose filesystem paths, shell commands, or credentials via tool definitions.
+4. Log all tool invocations for auditability.
+
+### Evaluation
+
+1. Define an eval set (minimum 20 examples) with inputs and expected outputs before launch.
+2. Track: accuracy, latency p50/p95, token cost per request, failure rate.
+3. Run evals on every prompt change before deploying to production.
+4. Block production promotion if accuracy regresses > 5% vs. baseline.
+
+## Output Contract
+
+- Prompt template with annotated sections (system / context / user)
+- RAG pipeline diagram or pseudocode (if applicable)
+- Tool schema definitions (if applicable)
+- Evaluation plan with metrics and pass/fail thresholds
+- Identified injection risks and mitigations
+
+## Guardrails
+
+- Never interpolate raw user input into system prompts without sanitization and clear structural delimiting.
+- Never execute LLM-generated code without a human or automated review gate.
+- Always set explicit token limits — never rely on model defaults.
+- Never log payloads that may contain PII or credentials.
+- Apply `agents/rules/ai-integration.mdc` for all cost, fallback, and safety decisions.

package/templates/agents/skills/raphaelsalaja-userinterface-wiki/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: raphaelsalaja-userinterface-wiki
+description: UI and UX best-practice playbook for stronger information architecture, readability, and usability.
+---
+
+# User Interface Wiki Playbook
+
+Use this skill when improving UI clarity, hierarchy, and interaction ergonomics.
+
+## Trigger Conditions
+
+- User requests a frontend cleanup or UX review.
+- Interface has weak visual hierarchy or navigation confusion.
+- Product needs consistent UI patterns across pages.
+
+## Workflow
+
+1. Audit hierarchy: headings, spacing, grouping, and contrast.
+2. Audit navigation and task flow for top user goals.
+3. Standardize component patterns (cards, forms, tables, dialogs).
+4. Tighten copy and labels for faster comprehension.
+5. Validate responsive behavior at mobile, tablet, and desktop widths.
+6. Validate accessibility semantics and keyboard flow.
+
+## Interface Quality Checklist
+
+- Primary action is obvious in each view.
+- Navigation labels are unambiguous.
+- Form errors are clear, contextual, and actionable.
+- Empty/loading/error states are explicit.
+- Density and spacing are consistent across sections.
+
+## Output Contract
+
+- UX issues grouped by severity
+- IA and layout improvements
+- Component consistency decisions
+- Accessibility and responsiveness findings
+- Validation steps and acceptance criteria
+
+## Guardrails
+
+- Avoid visual changes that break existing design-system tokens.
+- Keep interaction patterns predictable and learnable.
+- Optimize for readability before decoration.
+- Confirm improvements with at least one critical user journey.
+
+## Upstream Reference
+
+- Original package command:
+  - npx skills add raphaelsalaja/userinterface-wiki

package/templates/agents/skills/secure-code-guardian/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: secure-code-guardian
+description: Enforces secure-by-default implementation for auth, credentials, and untrusted input paths with OWASP-aligned controls.
+---
+
+# Secure Code Guardian
+
+Use this skill when building or reviewing features that touch authentication, secrets, session logic, or user-controlled input.
+
+## Trigger Conditions
+
+- User asks for secure implementation, auth, JWT, password handling, or OWASP checks.
+- New endpoints, forms, or integrations expose untrusted input boundaries.
+- A feature handles sensitive data, identity, or permissions.
+
+## Workflow
+
+1. Map trust boundaries, actors, and attack surface.
+2. Define authentication and authorization requirements.
+3. Apply input validation and injection defenses at boundaries.
+4. Enforce credential/secrets handling and safe logging rules.
+5. Add abuse protection controls (rate limiting, lockouts, replay defenses where relevant).
+6. Define security tests and residual risk before ship recommendation.
+
+## Output Contract
+
+- Attack surface map
+- Security requirements
+- Applied controls by boundary
+- OWASP alignment notes
+- Security validation checklist
+- Residual risks and mitigations
+- Ship/block recommendation
+
+## Guardrails
+
+- Never trust client-side validation alone.
+- Never expose secrets, credentials, or sensitive payloads in logs.
+- Block release recommendation if critical controls are missing.