菜单
Grounds every implementation decision in official documentation. Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/seaworld008/Commonly-used-high-value-skills --skill source-driven-development命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Multi-agent collaboration plugin that spawns N parallel subagents competing on the same task via git worktree isolation. Agents work independently, results are evaluated by metric or LLM judge, and the best branch is merged. Use when: user wants multiple approaches tried in parallel — code optimization, content variation, research exploration, or any task that benefits from parallel competition. Requires: a git repo.
Design production-grade multi-agent orchestration systems. Covers five core patterns (sequential pipeline, parallel fan-out/fan-in, hierarchical delegation, event-driven, consensus), platform-specific implementations, handoff protocols, state management, error recovery, context window budgeting, and cost optimization.
App Store Optimization toolkit for researching keywords, optimizing metadata, and tracking mobile app performance on Apple App Store and Google Play Store.
正在显示 SKILL.md
基于 SOC 职业分类
| name | source-driven-development |
| description | Grounds every implementation decision in official documentation. Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters. |
| zh_description | 用于来源、驱动、development，支持任务规划、执行、评审和验证。 |
| version | 1.0.0 |
| author | addyosmani |
| source | github:addyosmani/agent-skills |
| source_url | https://github.com/addyosmani/agent-skills/blob/main/skills/source-driven-development/SKILL.md |
| license | MIT |
| tags | ["agent", "ai", "engineering", "source-driven-development", "workflow"] |
| created_at | 2026-07-27 |
| updated_at | 2026-07-27 |
| quality | 4 |
| complexity | advanced |
| upstream_slug | source-driven-development |
Every framework-specific code decision must be backed by official documentation. Don't implement from memory — verify, cite, and let the user see your sources. Training data goes stale, APIs get deprecated, best practices evolve. This skill ensures the user gets code they can trust because every pattern traces back to an authoritative source they can check.
When NOT to use:
DETECT ──→ FETCH ──→ IMPLEMENT ──→ CITE
│ │ │ │
▼ ▼ ▼ ▼
What Get the Follow the Show your
stack? relevant documented sources
docs patterns
Read the project's dependency file to identify exact versions:
package.json → Node/React/Vue/Angular/Svelte
composer.json → PHP/Symfony/Laravel
requirements.txt / pyproject.toml → Python/Django/Flask
go.mod → Go
Cargo.toml → Rust
Gemfile → Ruby/Rails
State what you found explicitly:
STACK DETECTED:
- React 19.1.0 (from package.json)
- Vite 6.2.0
- Tailwind CSS 4.0.3
→ Fetching official docs for the relevant patterns.
If versions are missing or ambiguous, ask the user. Don't guess — the version determines which patterns are correct.
Fetch the specific documentation page for the feature you're implementing. Not the homepage, not the full docs — the relevant page.
Source hierarchy (in order of authority):
| Priority | Source | Example |
|---|
| 1 | Official documentation | react.dev, docs.djangoproject.com, symfony.com/doc |
| 2 | Official blog / changelog | react.dev/blog, nextjs.org/blog |
| 3 | Web standards references | MDN, web.dev, html.spec.whatwg.org |
| 4 | Browser/runtime compatibility | caniuse.com, node.green |
Not authoritative — never cite as primary sources:
Be precise with what you fetch:
BAD: Fetch the React homepage
GOOD: Fetch react.dev/reference/react/useActionState
BAD: Search "django authentication best practices"
GOOD: Fetch docs.djangoproject.com/en/6.0/topics/auth/
After fetching, extract the key patterns and note any deprecation warnings or migration guidance.
When official sources conflict with each other (e.g. a migration guide contradicts the API reference), surface the discrepancy to the user and verify which pattern actually works against the detected version.
Write code that matches what the documentation shows:
When docs conflict with existing project code:
CONFLICT DETECTED:
The existing codebase uses useState for form loading state,
but React 19 docs recommend useActionState for this pattern.
(Source: react.dev/reference/react/useActionState)
Options:
A) Use the modern pattern (useActionState) — consistent with current docs
B) Match existing code (useState) — consistent with codebase
→ Which approach do you prefer?
Surface the conflict. Don't silently pick one.
Every framework-specific pattern gets a citation. The user must be able to verify every decision.
In code comments:
// React 19 form handling with useActionState
// Source: https://react.dev/reference/react/useActionState#usage
const [state, formAction, isPending] = useActionState(submitOrder, initialState);
In conversation:
I'm using useActionState instead of manual useState for the
form submission state. React 19 replaced the manual
isPending/setIsPending pattern with this hook.
Source: https://react.dev/blog/2024/12/05/react-19#actions
"useTransition now supports async functions [...] to handle
pending states automatically"
Citation rules:
/useActionState#usage over /useActionState) — anchors survive doc restructuring better than top-level pagesUNVERIFIED: I could not find official documentation for this
pattern. This is based on training data and may be outdated.
Verify before using in production.
Honesty about what you couldn't verify is more valuable than false confidence.
| Rationalization | Reality |
|---|---|
| "I'm confident about this API" | Confidence is not evidence. Training data contains outdated patterns that look correct but break against current versions. Verify. |
| "Fetching docs wastes tokens" | Hallucinating an API wastes more. The user debugs for an hour, then discovers the function signature changed. One fetch prevents hours of rework. |
| "The docs won't have what I need" | If the docs don't cover it, that's valuable information — the pattern may not be officially recommended. |
| "I'll just mention it might be outdated" | A disclaimer doesn't help. Either verify and cite, or clearly flag it as unverified. Hedging is the worst option. |
| "This is a simple task, no need to check" | Simple tasks with wrong patterns become templates. The user copies your deprecated form handler into ten components before discovering the modern approach exists. |
package.json / dependency files before implementingAfter implementing with source-driven development: