| name | using-agent-skills |
| description | Discovery and invocation of all skills, commands, and agents. Decision tree for task-to-skill mapping. Core operating behaviors for agents. Use when unsure which skill or agent to use. |
| metadata | {"category":"model-invoked"} |
Default output: return only the result, blockers, and required evidence. Omit preambles, process narration, repeated context, confidence scores, and follow-up offers. Use at most five bullets unless a required artifact or schema needs more.
Using Agent Skills
Overview
This is the meta-skill for discovering and invoking the right skill, command, or agent for any task. It includes a decision tree for task-to-skill mapping and core operating behaviors that all agents should follow.
When to Use
- Starting a new session and unsure which skill applies
- Task doesn't clearly match a single skill
- Need to understand the full capability landscape
- Debugging why an agent isn't following expected workflows
Decision Tree: Task to Skill Mapping
What are you trying to do?
DEFINE (understand the problem)
โ Writing requirements before coding?
โ spec-driven-development
PLAN (break down the work)
โ Decomposing a spec into implementable tasks?
โ planning-and-task-breakdown
โ Researching before planning?
โ comprehensive-research
โ Stress-testing a plan or design before committing?
โ grill-me
โ Grilling a plan and persisting the decisions as a document?
โ grill-with-docs
LEARN (teach and grow)
โ Interactive lessons over multiple sessions with a file-backed workspace?
โ teach
โ Week-by-week roadmap and milestones without lesson artifacts?
โ create-learning-path
โ Team knowledge base or domain map (not personal tutoring)?
โ knowledge-architecture
BUILD (write the code)
โ Implementing a feature across multiple files?
โ incremental-implementation
โ Writing tests first?
โ test-driven-development
โ Need the right documentation?
โ source-driven-development
VERIFY (prove it works)
โ Testing in the browser?
โ browser-testing-with-devtools
โ Something is broken?
โ debugging-and-error-recovery
REVIEW (improve code health)
โ Reviewing code before merge?
โ code-review-and-quality
โ Full repo health check or improvement plan?
โ repo-audit (or /ai-eng/repo-audit)
โ Code works but is hard to read?
โ code-simplification
โ Security concerns?
โ security-and-hardening
SHIP (deploy safely)
โ Preparing for production?
โ shipping-and-launch
โ Setting up CI/CD?
โ ci-cd-and-automation
SPECIALIZED
โ Building knowledge graphs?
โ graph-rag
โ Creating plugins/commands/skills?
โ plugin-dev
โ Building a harness workflow runner (Cursor, Claude, OpenCode, OpenAI, Pi)?
โ agents-sdk-dev (unified โ specify harness)
โ See agents/research-runner/ for reference implementations
โ Gemini workflow adapter (not shipped yet)?
โ gemini-agent-sdk
โ Large cloud multi-agent tree (/orchestrate)?
โ orchestrate (planned; use agents-sdk-dev with harness=cursor until scripts/cli.ts exists)
โ Optimizing prompts?
โ prompt-refinement
โ Cleaning up AI verbosity?
โ text-cleanup
โ Managing git worktrees?
โ git-worktree
โ Deploying to Coolify?
โ coolify-deploy
Core Operating Behaviors
1. Surface Assumptions
Before acting, state what you're assuming:
- "I'm assuming this is a new feature, not a bug fix"
- "I'm assuming we're using the existing auth pattern"
- "I'm assuming the database schema doesn't need changes"
2. Manage Confusion
When uncertain, say so explicitly:
- "I'm not sure which pattern applies here"
- "This could be interpreted two ways"
- "I need more context about the expected behavior"
3. Push Back
Challenge requirements when needed:
- "This approach will create tight coupling. Consider..."
- "The spec says X, but the existing code does Y. Which is correct?"
- "This change is too large for one commit. Should we split it?"
4. Enforce Simplicity
Prefer simple solutions:
- "Can we solve this with a function instead of a class?"
- "Do we need a new dependency, or can we use what we have?"
- "Is there a simpler way to handle this edge case?"
5. Scope Discipline
Stay within boundaries:
- "This is out of scope for the current task"
- "I'll note this as a follow-up, not implement it now"
- "The spec covers A and B, but not C. Should I expand scope?"
6. Verify
Always prove correctness:
- "Seems right" is never sufficient
- Run tests, check build output, verify runtime behavior
- Provide evidence: passing tests, screenshots, logs
Anti-Rationalization Table
| Excuse | Counter |
|---|
| "I'll add tests later" | Tests are proof. Without them, you have no evidence it works. Write tests first or alongside. |
| "This is simple enough to skip the spec" | Simple now, complex later. A 5-minute spec prevents 5-hour rewrites. |
| "I know this pattern, no need to check docs" | Frameworks change. Source-driven development prevents subtle bugs from outdated knowledge. |
| "The code works, no need to simplify" | Working code that's hard to read is technical debt. Future you (or teammates) will pay the cost. |
| "I'll fix the security issue in the next PR" | Security issues are stop-the-line. Fix now or create a tracked issue with severity. |
| "This only affects one file, no review needed" | Every change deserves review. Even small changes can have cascading effects. |
| "I'll document it later" | Undocumented code is a time bomb. Document the why, not the what, while it's fresh. |
Composition Rules
- Agents do NOT invoke other agents โ enforced by platform constraint
- Agents MAY invoke skills โ skills are instructions, not agents
- The user or a slash command is the orchestrator โ no router agents
- Skills auto-activate based on context โ no manual skill selection needed
- Teams cannot nest โ flat hierarchy only
References
references/orchestration-patterns.md โ Endorsed and anti-pattern orchestration approaches
references/testing-patterns.md โ Test structure, naming, mocking, examples
references/security-checklist.md โ Pre-commit checks, OWASP Top 10, secrets management
references/performance-checklist.md โ Core Web Vitals, frontend/backend checklists
references/accessibility-checklist.md โ Keyboard nav, screen readers, WCAG 2.1 AA