using-agent-skills

Name: using-agent-skills
Author: addyosmani

byaddyosmani· 31 skills

Installs

15k

Stars

80k

Forks

8.7k

How to install using-agent-skills?

addyosmani/agent-skills/using-agent-skills

$npx -y skills add addyosmani/agent-skills --skill using-agent-skills

Installs into the current project.

›Prefer a prompt? Paste this to your agent

Use this skill

Run `npx skills use "https://github.com/addyosmani/agent-skills" --skill "addyosmani/agent-skills/using-agent-skills"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the whole pack

Use the skills in "https://github.com/addyosmani/agent-skills" that are relevant to the current task. Run `npx skills add "https://github.com/addyosmani/agent-skills"` and select the relevant skills, then follow their instructions.

Files · 1

View on GitHub

SKILL.md

1	# Using Agent Skills
2
3	## Overview
4
5	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.
6
7	## Skill Discovery
8
9	When a task arrives, identify the development phase and apply the corresponding skill:
10
11	```
12	Task arrives
13	│
14	├── Don't know what you want yet? ──────→ interview-me
15	├── Have a rough concept, need variants? → idea-refine
16	├── New project/feature/change? ──→ spec-driven-development
17	├── Have a spec, need tasks? ──────→ planning-and-task-breakdown
18	├── Implementing code? ────────────→ incremental-implementation
19	│ ├── UI work? ─────────────────→ frontend-ui-engineering
20	│ ├── API work? ────────────────→ api-and-interface-design
21	│ ├── Need better context? ─────→ context-engineering
22	│ ├── Need doc-verified code? ───→ source-driven-development
23	│ └── Stakes high / unfamiliar code? ──→ doubt-driven-development
24	├── Writing/running tests? ────────→ test-driven-development
25	│ └── Browser-based? ───────────→ browser-testing-with-devtools
26	├── Something broke? ──────────────→ debugging-and-error-recovery
27	├── Reviewing code? ───────────────→ code-review-and-quality
28	│ ├── Too complex? ─────────────→ code-simplification
29	│ ├── Security concerns? ───────→ security-and-hardening
30	│ └── Performance concerns? ────→ performance-optimization
31	├── Committing/branching? ─────────→ git-workflow-and-versioning
32	├── CI/CD pipeline work? ──────────→ ci-cd-and-automation
33	├── Deprecating/migrating? ────────→ deprecation-and-migration
34	├── Writing docs/ADRs? ───────────→ documentation-and-adrs
35	├── Adding logs/metrics/alerts? ───→ observability-and-instrumentation
36	└── Deploying/launching? ─────────→ shipping-and-launch
37	```
38
39	## Core Operating Behaviors
40
41	These behaviors apply at all times, across all skills. They are non-negotiable.
42
43	### 1. Surface Assumptions
44
45	Before implementing anything non-trivial, explicitly state your assumptions:
46
47	```
48	ASSUMPTIONS I'M MAKING:
49	1. [assumption about requirements]
50	2. [assumption about architecture]
51	3. [assumption about scope]
52	→ Correct me now or I'll proceed with these.
53	```
54
55	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.
56
57	### 2. Manage Confusion Actively
58
59	When you encounter inconsistencies, conflicting requirements, or unclear specifications:
60
61	1. STOP. Do not proceed with a guess.
62	2. Name the specific confusion.
63	3. Present the tradeoff or ask the clarifying question.
64	4. Wait for resolution before continuing.
65
66	Bad: Silently picking one interpretation and hoping it's right.
67	Good: "I see X in the spec but Y in the existing code. Which takes precedence?"
68
69	### 3. Push Back When Warranted
70
71	You are not a yes-machine. When an approach has clear problems:
72
73	- Point out the issue directly
74	- Explain the concrete downside (quantify when possible — "this adds ~200ms latency" not "this might be slower")
75	- Propose an alternative
76	- Accept the human's decision if they override with full information
77
78	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.
79
80	### 4. Enforce Simplicity
81
82	Your natural tendency is to overcomplicate. Actively resist it.
83
84	Before finishing any implementation, ask:
85	- Can this be done in fewer lines?
86	- Are these abstractions earning their complexity?
87	- Would a staff engineer look at this and say "why didn't you just..."?
88
89	If you build 1000 lines and 100 would suffice, you have failed. Prefer the boring, obvious solution. Cleverness is expensive.
90
91	### 5. Maintain Scope Discipline
92
93	Touch only what you're asked to touch.
94
95	Do NOT:
96	- Remove comments you don't understand
97	- "Clean up" code orthogonal to the task
98	- Refactor adjacent systems as a side effect
99	- Delete code that seems unused without explicit approval
100	- Add features not in the spec because they "seem useful"
101
102	Your job is surgical precision, not unsolicited renovation.
103
104	### 6. Verify, Don't Assume
105
106	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).
107
108	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.
109
110	## Failure Modes to Avoid
111
112	These are the subtle errors that look like productivity but create problems:
113
114	1. Making wrong assumptions without checking
115	2. Not managing your own confusion — plowing ahead when lost
116	3. Not surfacing inconsistencies you notice
117	4. Not presenting tradeoffs on non-obvious decisions
118	5. Being sycophantic ("Of course!") to approaches with clear problems
119	6. Overcomplicating code and APIs
120	7. Modifying code or comments orthogonal to the task
121	8. Removing things you don't fully understand
122	9. Building without a spec because "it's obvious"
123	10. Skipping verification because "it looks right"
124
125	## Skill Rules
126
127	1. Check for an applicable skill before starting work. Skills encode processes that prevent common mistakes.
128
129	2. Skills are workflows, not suggestions. Follow the steps in order. Don't skip verification steps.
130
131	3. 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-launch` in sequence.
132
133	4. When in doubt, start with a spec. If the task is non-trivial and there's no spec, begin with `spec-driven-development`.
134
135	## Lifecycle Sequence
136
137	For a complete feature, the typical skill sequence is:
138
139	```
140	1. interview-me → Extract what the user actually wants
141	2. idea-refine → Refine vague ideas
142	3. spec-driven-development → Define what we're building
143	4. planning-and-task-breakdown → Break into verifiable chunks
144	5. context-engineering → Load the right context
145	6. source-driven-development → Verify against official docs
146	7. incremental-implementation → Build slice by slice
147	8. observability-and-instrumentation → Instrument as you build (runs parallel with 7-9, not after)
148	9. doubt-driven-development → Cross-examine non-trivial decisions in-flight
149	10. test-driven-development → Prove each slice works
150	11. code-review-and-quality → Review before merge
151	12. code-simplification → Reduce unnecessary complexity while preserving behavior
152	13. git-workflow-and-versioning → Clean commit history
153	14. documentation-and-adrs → Document decisions
154	15. deprecation-and-migration → Retire old systems and move users safely when needed
155	16. shipping-and-launch → Deploy safely
156	```
157
158	Not every task needs every skill. A bug fix might only need: `debugging-and-error-recovery` → `test-driven-development` → `code-review-and-quality`.
159
160	## Quick Reference
161
162	\| Phase \| Skill \| One-Line Summary \|
163	\|-------\|-------\|-----------------\|
164	\| Define \| interview-me \| Surface what the user actually wants before any plan, spec, or code exists \|
165	\| Define \| idea-refine \| Refine ideas through structured divergent and convergent thinking \|
166	\| Define \| spec-driven-development \| Requirements and acceptance criteria before code \|
167	\| Plan \| planning-and-task-breakdown \| Decompose into small, verifiable tasks \|
168	\| Build \| incremental-implementation \| Thin vertical slices, test each before expanding \|
169	\| Build \| source-driven-development \| Verify against official docs before implementing \|
170	\| Build \| doubt-driven-development \| Adversarial fresh-context review of every non-trivial decision \|
171	\| Build \| context-engineering \| Right context at the right time \|
172	\| Build \| frontend-ui-engineering \| Production-quality UI with accessibility \|
173	\| Build \| api-and-interface-design \| Stable interfaces with clear contracts \|
174	\| Verify \| test-driven-development \| Failing test first, then make it pass \|
175	\| Verify \| browser-testing-with-devtools \| Chrome DevTools MCP for runtime verification \|
176	\| Verify \| debugging-and-error-recovery \| Reproduce → localize → fix → guard \|
177	\| Review \| code-review-and-quality \| Five-axis review with quality gates \|
178	\| Review \| code-simplification \| Preserve behavior while reducing unnecessary complexity \|
179	\| Review \| security-and-hardening \| OWASP prevention, input validation, least privilege \|
180	\| Review \| performance-optimization \| Measure first, optimize only what matters \|
181	\| Ship \| git-workflow-and-versioning \| Atomic commits, clean history \|
182	\| Ship \| ci-cd-and-automation \| Automated quality gates on every change \|
183	\| Ship \| deprecation-and-migration \| Remove old systems and migrate users safely \|
184	\| Ship \| documentation-and-adrs \| Document the why, not just the what \|
185	\| Ship \| observability-and-instrumentation \| Structured logs, RED metrics, traces, symptom-based alerts \|
186	\| Ship \| shipping-and-launch \| Pre-launch checklist, monitoring, rollback plan \|

6 picks

Type

Run `npx skills use "https://github.com/addyosmani/agent-skills" --skill "addyosmani/agent-skills/using-agent-skills"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the skills in "https://github.com/addyosmani/agent-skills" that are relevant to the current task. Run `npx skills add "https://github.com/addyosmani/agent-skills"` and select the relevant skills, then follow their instructions.

using-agent-skills

How to install using-agent-skills?

Related

using-agent-skills

How to install using-agent-skills?

Related