Skills using-agent-skills
git clone https://github.com/TerminalSkills/skills
T=$(mktemp -d) && git clone --depth=1 https://github.com/TerminalSkills/skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/using-agent-skills" ~/.claude/skills/terminalskills-skills-using-agent-skills && rm -rf "$T"
skills/using-agent-skills/SKILL.mdUsing 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.
Instructions
Skill Discovery
When a task arrives, identify the development phase and apply the corresponding skill:
Task arrives ├── Vague idea/need refinement? ──→ idea-refine ├── New project/feature/change? ──→ spec-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 ├── Writing/running tests? ────────→ test-driven-development ├── Something broke? ──────────────→ debugging-and-error-recovery ├── Reviewing code? ───────────────→ code-review-and-quality ├── Committing/branching? ─────────→ git-workflow-and-versioning ├── Writing docs/ADRs? ───────────→ documentation-and-adrs └── Deploying/launching? ─────────→ shipping-and-launch
Core Operating Behaviors
1. Surface Assumptions — Before implementing anything non-trivial:
ASSUMPTIONS I'M MAKING: 1. [assumption about requirements] 2. [assumption about architecture] → Correct me now or I'll proceed with these.
2. Manage Confusion Actively — When encountering inconsistencies:
- STOP — don't proceed with a guess
- Name the specific confusion
- Present the tradeoff or ask the clarifying question
- Wait for resolution
3. Push Back When Warranted — Point out issues directly, explain concrete downsides, propose alternatives. Sycophancy is a failure mode.
4. Enforce Simplicity — Before finishing any implementation, ask:
- Can this be done in fewer lines?
- Are these abstractions earning their complexity?
- Would a staff engineer say "why didn't you just..."?
5. Maintain Scope Discipline — Touch only what you're asked to touch. Don't "clean up" adjacent code, remove comments you don't understand, or add unspecified features.
6. Verify, Don't Assume — A task is not complete until verification passes. "Seems right" is never sufficient — there must be evidence.
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.
- Multiple skills can apply. Chain them in sequence.
- When in doubt, start with a spec.
Lifecycle Sequence
For a complete feature, the typical sequence:
1. idea-refine → Refine vague ideas 2. spec-driven-development → Define what we're building 3. planning-and-task-breakdown → Break into verifiable chunks 4. context-engineering → Load the right context 5. incremental-implementation → Build slice by slice 6. test-driven-development → Prove each slice works 7. code-review-and-quality → Review before merge 8. documentation-and-adrs → Document decisions 9. shipping-and-launch → Deploy safely
Not every task needs every skill. A bug fix might only need: debugging → testing → review.
Examples
Quick Reference
| Phase | Skill | Summary |
|---|---|---|
| Define | idea-refine | Divergent and convergent thinking |
| Define | spec-driven-development | Requirements before code |
| Plan | planning-and-task-breakdown | Small, verifiable tasks |
| Build | incremental-implementation | Thin vertical slices |
| Build | context-engineering | Right context at right time |
| Verify | test-driven-development | Failing test first |
| Review | code-review-and-quality | Five-axis quality review |
| Ship | git-workflow-and-versioning | Atomic commits, clean history |
| Ship | documentation-and-adrs | Document the why |
Guidelines
Failure Modes to Avoid
- Making wrong assumptions without checking
- Plowing ahead when confused
- Not surfacing inconsistencies you notice
- Being sycophantic to approaches with clear problems
- Overcomplicating code and APIs
- Modifying code 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"
Red Flags
- Starting implementation without checking for applicable skills
- Skipping verification steps within a skill
- Silently guessing when requirements are ambiguous
- No spec exists for non-trivial work
- Agent output doesn't match project conventions