using-agent-skills
GitHub元技能，用于在会话开始时发现并调用适用的工程工作流技能。通过识别开发阶段（如编码、测试、调试等），将任务路由至对应的具体技能，确保遵循高级工程师的最佳实践流程。
Trigger Scenarios
Install
npx skills add AjayIrkal23/agentic-mercy-10x --skill using-agent-skills -g -y
SKILL.md
Frontmatter
{
"name": "using-agent-skills",
"schema": 1,
"category": "general",
"surfaces": [
"general"
],
"triggers": {
"paths": [],
"intents": [
"general"
],
"keywords": [
"agent",
"applies",
"current",
"discover",
"discovered",
"discovers",
"governs",
"invoked",
"invokes",
"meta-skill",
"need",
"other",
"session",
"skill",
"skills",
"starting",
"task"
]
},
"platforms": [
"linux",
"darwin",
"windows"
],
"token-cost": 2332,
"description": "ALWAYS invoke when starting a session or when you need to discover which skill applies to the current task — discovers and invokes agent skills. This is the meta-skill that governs how all other skills are discovered and invoked."
}
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.
Hooks, rules, and linkage story
Cursor injects context via ~/.claude/settings.json (hooks key) (sessionStart, beforeSubmitPrompt, postToolUse on Write, stop). Always-on routing is reinforced by ~/.claude/rules/plan-exec-unified-stack.md and agent-lifecycle-routing.md.
Read skill-linkage-story when you need the full spine (Superpowers + agent skills + hooks): ~/.claude/skills/skill-linkage-story/SKILL.md → references/graph-and-stories.md, references/hooks-rules-e2e.md.
Personal routing spine: open ~/.claude/rules/agent-lifecycle-routing.md for phase → skill → Superpowers → hooks in one skim (supplements this tree).
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 (+ Superpowers `executing-plans`, `subagent-driven-development`; hook: **`plan-exec-stack-hint` execution mode**)
│ ├── UI work? ─────────────────→ frontend-standards-always-follow (+ `vite-react-best-practices`, `frontend-ui-engineering`, `impeccable` / `taste-skill` when polish matters; UI hook overlay when paths match)
│ ├── 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? ───────→ tdd (+ local `test-driven-development` slug if installed; + Superpowers `test-driven-development` when keywords hit)
│ └── Browser-based? ───────────→ browser-testing-with-devtools
├── Something broke? ─────────────→ debugging-and-error-recovery (procedural recovery) → diagnose → debug-investigation (+ Superpowers `systematic-debugging` when prompts match)
├── Reviewing code? ───────────────→ code-review-and-quality
│ ├── Security concerns? ───────→ security-and-hardening
│ └── Performance concerns? ────→ performance-optimization
├── Committing/branching? ─────────→ git-workflow-and-versioning
├── CI/CD pipeline work? ──────────→ ci-cd-and-automation
├── Writing docs/ADRs? ───────────→ documentation-and-adrs
└── 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).
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→tdd→code-review-and-quality→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. 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. source-driven-development → Verify against official docs
6. incremental-implementation → Build slice by slice
7. doubt-driven-development → Cross-examine non-trivial decisions in-flight
8. tdd → Prove each slice works
9. code-review-and-quality → Review before merge
10. git-workflow-and-versioning → Clean commit history
11. documentation-and-adrs → Document decisions
12. shipping-and-launch → Deploy safely
Not every task needs every skill. A bug fix might only need: diagnose → debug-investigation → tdd → code-review-and-quality.
Quick Reference
| Phase | Skill | One-Line Summary |
|---|---|---|
| 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-standards-always-follow | Frontend baseline (hooks may also list deeper FE stack skills) |
| Build | api-and-interface-design | Stable interfaces with clear contracts |
| Verify | tdd | Failing test first, then make it pass |
| Verify | browser-testing-with-devtools | Chrome DevTools MCP for runtime verification |
| Verify | diagnose / debug-investigation | Reproduce → localize → fix → guard |
| Review | code-review-and-quality | Five-axis review with quality gates |
| 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 | documentation-and-adrs | Document the why, not just the what |
| Ship | shipping-and-launch | Pre-launch checklist, monitoring, rollback plan |
Version History
- 581d130 Current 2026-07-19 09:15
