agents-templated 2.2.21 → 2.2.22

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

@@ -1,45 +0,0 @@
----
-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

@@ -1,36 +0,0 @@
----
-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

@@ -1,39 +0,0 @@
----
-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

@@ -1,51 +0,0 @@
----
-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

@@ -1,70 +0,0 @@
----
-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

@@ -1,38 +0,0 @@
----
-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

@@ -1,39 +0,0 @@
----
-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

@@ -1,133 +0,0 @@
----
-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

@@ -1,64 +0,0 @@
----
-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

@@ -1,51 +0,0 @@
----
-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

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