using-agent-skills
Discovers and invokes agent skills. Use when starting a session, or when you need to decide which skill or workflow applies to the piece of work at hand. This is the meta-skill that governs how all other skills are discovered and invoked.
- Installs
- 59.9K
- Last 24h
- +738
- Trending rank
- #472
- Security
- Warn
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/addyosmani/agent-skills --skill using-agent-skills- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads using-agent-skills automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
Security audits
Independent scans of the skill's instructions and bundled files.
SKILL.md
The instructions your agent reads when the skill is triggered.
Using Agent Skills
Overview
Agent Skills is a collection of engineering workflow skills organized by development phase. Each skill encodes a specific process that senior engineers follow. This meta-skill helps you discover and apply the right skill for your current task.
Skill Discovery
When a task arrives, identify the development phase and apply the corresponding skill:
Task arrives
│
├── Don't know what you want yet? ──────→ interview-me
├── Have a rough concept, need variants? → idea-refine
├── New project/feature/change? ──→ spec-driven-development
├── No quality bar written down? ──→ constraint-driven-development
├── Have a spec, need tasks? ──────→ planning-and-task-breakdown
├── Implementing code? ────────────→ incremental-implementation
│ ├── UI work? ─────────────────→ frontend-ui-engineering
│ ├── API work? ────────────────→ api-and-interface-design
│ ├── Need better context? ─────→ context-engineering
│ ├── Need doc-verified code? ───→ source-driven-development
│ └── Stakes high / unfamiliar code? ──→ doubt-driven-development
├── Writing/running tests? ────────→ test-driven-development
│ └── Browser-based? ───────────→ browser-testing-with-devtools
├── Something broke? ──────────────→ debugging-and-error-recovery
├── Reviewing code? ───────────────→ code-review-and-quality
│ ├── Too complex? ─────────────→ code-simplification
│ ├── Security concerns? ───────→ security-and-hardening
│ └── Performance concerns? ────→ performance-optimization
├── Committing/branching? ─────────→ git-workflow-and-versioning
├── CI/CD pipeline work? ──────────→ ci-cd-and-automation
├── Deprecating/migrating? ────────→ deprecation-and-migration
├── Writing docs/ADRs? ───────────→ documentation-and-adrs
├── Adding logs/metrics/alerts? ───→ observability-and-instrumentation
└── Deploying/launching? ─────────→ shipping-and-launch
Core Operating Behaviors
These behaviors apply at all times, across all skills. They are non-negotiable.
1. Surface Assumptions
Before implementing anything non-trivial, explicitly state your assumptions:
ASSUMPTIONS I'M MAKING:
1. [assumption about requirements]
2. [assumption about architecture]
3. [assumption about scope]
→ Correct me now or I'll proceed with these.
Don't silently fill in ambiguous requirements. The most common failure mode is making wrong assumptions and running with them unchecked. Surface uncertainty early — it's cheaper than rework.
2. Manage Confusion Actively
When you encounter inconsistencies, conflicting requirements, or unclear specifications:
- STOP. Do not proceed with a guess.
- Name the specific confusion.
- Present the tradeoff or ask the clarifying question.
- Wait for resolution before continuing.
Bad: Silently picking one interpretation and hoping it's right. Good: "I see X in the spec but Y in the existing code. Which takes precedence?"
3. Push Back When Warranted
You are not a yes-machine. When an approach has clear problems:
- Point out the issue directly
- Explain the concrete downside (quantify when possible — "this adds ~200ms latency" not "this might be slower")
- Propose an alternative
- Accept the human's decision if they override with full information
Sycophancy is a failure mode. "Of course!" followed by implementing a bad idea helps no one. Honest technical disagreement is more valuable than false agreement.
4. Enforce Simplicity
Your natural tendency is to overcomplicate. Actively resist it.
Before finishing any implementation, ask:
- Can this be done in fewer lines?
- Are these abstractions earning their complexity?
- Would a staff engineer look at this and say "why didn't you just..."?
If you build 1000 lines and 100 would suffice, you have failed. Prefer the boring, obvious solution. Cleverness is expensive.
5. Maintain Scope Discipline
Touch only what you're asked to touch.
Do NOT:
- Remove comments you don't understand
- "Clean up" code orthogonal to the task
- Refactor adjacent systems as a side effect
- Delete code that seems unused without explicit approval
- Add features not in the spec because they "seem useful"
Your job is surgical precision, not unsolicited renovation.
6. Verify, Don't Assume
Every skill includes a verification step. A task is not complete until verification passes. "Seems right" is never sufficient — there must be evidence (passing tests, build output, runtime data).
Per-skill verification is the local check. The project-wide bar that applies to every change, regardless of which skill is active, is the Definition of Done: tests pass, no regressions, behavior verified at runtime, docs updated. See ../../references/definition-of-done.md. It complements each task's acceptance criteria rather than replacing them.
Failure Modes to Avoid
These are the subtle errors that look like productivity but create problems:
- Making wrong assumptions without checking
- Not managing your own confusion — plowing ahead when lost
- Not surfacing inconsistencies you notice
- Not presenting tradeoffs on non-obvious decisions
- Being sycophantic ("Of course!") to approaches with clear problems
- Overcomplicating code and APIs
- Modifying code or comments orthogonal to the task
- Removing things you don't fully understand
- Building without a spec because "it's obvious"
- Skipping verification because "it looks right"
Skill Rules
-
Check for an applicable skill before starting work. Skills encode processes that prevent common mistakes.
-
Skills are workflows, not suggestions. Follow the steps in order. Don't skip verification steps.
-
Multiple skills can apply. A feature implementation might involve
idea-refine→spec-driven-development→planning-and-task-breakdown→incremental-implementation→test-driven-development→code-review-and-quality→code-simplification→shipping-and-launchin sequence. -
When in doubt, start with a spec. If the task is non-trivial and there's no spec, begin with
spec-driven-development.
Lifecycle Sequence
For a complete feature, the typical skill sequence is:
1. interview-me → Extract what the user actually wants
2. idea-refine → Refine vague ideas
3. spec-driven-development → Define what we're building
4. planning-and-task-breakdown → Break into verifiable chunks
5. context-engineering → Load the right context
6. source-driven-development → Verify against official docs
7. incremental-implementation → Build slice by slice
8. observability-and-instrumentation → Instrument as you build (runs parallel with 7-9, not after)
9. doubt-driven-development → Cross-examine non-trivial decisions in-flight
10. test-driven-development → Prove each slice works
11. code-review-and-quality → Review before merge
12. code-simplification → Reduce unnecessary complexity while preserving behavior
13. git-workflow-and-versioning → Clean commit history
14. documentation-and-adrs → Document decisions
15. deprecation-and-migration → Retire old systems and move users safely when needed
16. shipping-and-launch → Deploy safely
Not every task needs every skill. A bug fix might only need: debugging-and-error-recovery → test-driven-development → code-review-and-quality.
Quick Reference
| Phase | Skill | One-Line Summary |
|---|---|---|
| Define | interview-me | Surface what the user actually wants before any plan, spec, or code exists |
| Define | idea-refine | Refine ideas through structured divergent and convergent thinking |
| Define | spec-driven-development | Requirements and acceptance criteria before code |
| Plan | planning-and-task-breakdown | Decompose into small, verifiable tasks |
| Build | incremental-implementation | Thin vertical slices, test each before expanding |
| Build | source-driven-development | Verify against official docs before implementing |
| Build | doubt-driven-development | Adversarial fresh-context review of every non-trivial decision |
| Build | context-engineering | Right context at the right time |
| Build | frontend-ui-engineering | Production-quality UI with accessibility |
| Build | api-and-interface-design | Stable interfaces with clear contracts |
| Verify | test-driven-development | Failing test first, then make it pass |
| Verify | browser-testing-with-devtools | Chrome DevTools MCP for runtime verification |
| Verify | debugging-and-error-recovery | Reproduce → localize → fix → guard |
| Review | code-review-and-quality | Five-axis review with quality gates |
| Review | code-simplification | Preserve behavior while reducing unnecessary complexity |
| Review | security-and-hardening | OWASP prevention, input validation, least privilege |
| Review | performance-optimization | Measure first, optimize only what matters |
| Ship | git-workflow-and-versioning | Atomic commits, clean history |
| Ship | ci-cd-and-automation | Automated quality gates on every change |
| Ship | deprecation-and-migration | Remove old systems and migrate users safely |
| Ship | documentation-and-adrs | Document the why, not just the what |
| Ship | observability-and-instrumentation | Structured logs, RED metrics, traces, symptom-based alerts |
| Ship | shipping-and-launch | Pre-launch checklist, monitoring, rollback plan |
FAQ
What does the using-agent-skills skill do?
Discovers and invokes agent skills. Use when starting a session, or when you need to decide which skill or workflow applies to the piece of work at hand. This is the meta-skill that governs how all other skills are discovered and invoked.
How do I install using-agent-skills?
Run npx skills add https://github.com/addyosmani/agent-skills --skill using-agent-skills in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/using-agent-skills/ (personal) or .claude/skills/using-agent-skills/ (project).
Which AI agents can use using-agent-skills?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is using-agent-skills safe to install?
Security partners have reviewed it: Gen Agent Trust Hub passed; Socket passed; Snyk passed; Runlayer flagged items to review; ZeroLeaks passed. As with any skill, read the SKILL.md and bundled scripts before installing.
Who maintains using-agent-skills?
It is published by addyosmani in addyosmani/agent-skills. It has 59,884 recorded installs.
More from addyosmani/agent-skills
code-review-and-quality
addyosmani/agent-skills
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch. Use when asked to review a diff or a pull request, even when the diff is pasted inline.
security-and-hardening
addyosmani/agent-skills
Hardens code against vulnerabilities. Use when auditing an input handler for vulnerabilities, when handling user input, authentication, data storage, or external integrations, or when checking a login flow is safe against the OWASP Top Ten. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Use when auditing dependencies for known vulnerabilities, triaging package-manager audit findings, or assessing supply-chain risk in a new package. Use when personal data or privacy compliance (GDPR, CCPA) is involved.
frontend-ui-engineering
addyosmani/agent-skills
Builds production-quality, accessible, responsive user-facing UIs. Use when building or modifying interfaces and pages, creating components, implementing layouts, meeting WCAG accessibility requirements, managing state, or when the output needs to look and feel production-quality rather than AI-generated.
performance-optimization
addyosmani/agent-skills
Optimizes application performance across frontend, backend, queries, and databases. Use when performance requirements exist, when you suspect performance regressions, when Core Web Vitals or load times need improvement, when N+1 query patterns need fixing, or when profiling reveals bottlenecks.
spec-driven-development
addyosmani/agent-skills
Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when drafting a PRD or requirements document with objectives and scope, or when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying.
planning-and-task-breakdown
addyosmani/agent-skills
Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.
Popular ai & agents skills
google-agents-cli-publish
google/agents-cli
This skill should be used when the user wants to "publish an agent", "publish my ADK agent", "register an agent with Gemini", "publish to Gemini" (formerly Gemini Enterprise), or needs guidance on the agents-cli publish gemini command. Also use when the user wants to "manage agents in Agent Registry", "list/update/delete registered agents", or "register an MCP server". Covers ADK vs A2A registration modes, programmatic and interactive usage, flag reference, auto-detection from deployment metadata, Agent Registry fleet management, and troubleshooting. Part of the agents-cli skills suite. Do NOT use for deployment (use google-agents-cli-deploy).
google-agents-cli-eval
google/agents-cli
This skill should be used when the user wants to "run an evaluation", "evaluate my agent", "evaluate my ADK agent", "write an eval dataset", "analyze eval failures", "compare eval results", "optimize agent", or needs guidance on the Gemini platform eval methodology and the Quality Flywheel. Covers eval metrics, dataset schema, LLM-as-judge scoring, and common failure causes. Applies to any agents-cli project, whatever framework the agent is written in. Do NOT use for agent API code patterns (ADK: use google-agents-cli-adk-code), deployment (use google-agents-cli-deploy), or project scaffolding (use google-agents-cli-scaffold).
skill-creator
anthropics/skills
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
codex-pet
prime-skills/runcomfy-agent-skills
Codex Pet generator on RunComfy. Build a Codex-compatible Codex Pet spritesheet.webp + pet.json from a single reference image, drop it into ${CODEXHOME:-$HOME/.codex}/pets/ / and Codex picks it up as a custom Codex Pet next to the 8 built-ins. This skill produces the exact Codex Pet atlas Codex expects (1536x1872 PNG/WebP, 8 cols x 9 rows, 192x208 cells, 9 animation states — idle, running-right, running-left, waving, jumping, failed, waiting, running, review). Calls OpenAI GPT Image 2 edit ONCE via the local RunComfy CLI as runcomfy run openai/gpt-image-2/edit to produce a canonical Codex Pet pose, then assembles all 9 animation rows programmatically with ImageMagick micro-transforms — no Codex Pro, no $imagegen, no OPENAIAPIKEY required, only RUNCOMFYTOKEN. Triggers on "codex pet", "create codex pet", "make codex pet", "hatch codex pet", "/hatch image", "desktop pet codex", "codex pets", "spritesheet.webp", or any explicit ask to build a custom pet for OpenAI Codex.
full-output-enforcement
leonxlnx/taste-skill
Overrides default LLM truncation behavior. Enforces complete code generation, bans placeholder patterns, and handles token-limit splits cleanly. Apply to any task requiring exhaustive, unabridged output.
executing-plans
obra/superpowers
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available