agent-skills - AI coding agents के लिए production-grade engineering skills का संग्रह
(github.com/addyosmani)- AI coding agents द्वारा spec, test, और security review को skip करने की समस्या को हल करने के लिए, Google Cloud AI Director Addy Osmani ने senior engineer-स्तर के workflow को structured skills के रूप में पैकेज किया हुआ open source प्रोजेक्ट बनाया है
- पूरे development lifecycle (परिभाषा→योजना→बिल्ड→सत्यापन→रिव्यू→डिप्लॉय) को कवर करने वाले 7 slash commands और 19 skills से बना है
/specक्या बनाना है, यह परिभाषित करें: "code से पहले spec"/planimplementation का तरीका प्लान करें: "छोटे atomic tasks में"/buildincremental implementation: "एक बार में सिर्फ एक slice"/testव्यवहार साबित करें: "test ही प्रमाण है"/reviewmerge से पहले quality gate: "code health में सुधार"/code-simplifycode को सरल बनाना: "cleverness से ज़्यादा clarity"/shipproduction deployment: "जितना तेज़, उतना सुरक्षित"
- स्थिति के अनुसार उपयुक्त skill अपने-आप activate हो जाती है। उदाहरण: API design के समय
api-and-interface-design, UI implementation के समयfrontend-ui-engineeringआदि - Google engineering culture के मुख्य सिद्धांत (Hyrum's Law, Beyonce Rule, Chesterton's Fence, Shift Left आदि) चरण-दर-चरण workflow में सीधे embedded हैं
सभी 19 skills की सूची
-
Define (क्या बनाना है, इसे स्पष्ट करना)
- idea-refine: divergent/convergent thinking को structured करके अस्पष्ट idea को ठोस proposal में बदलना
- spec-driven-development: code लिखने से पहले goal, commands, structure, code style, test, और boundaries को कवर करने वाला PRD लिखना
-
Plan (विभाजन)
- planning-and-task-breakdown: spec को acceptance criteria और dependency order वाले छोटे, verifiable tasks में तोड़ना
-
Build (code लिखना)
- incremental-implementation: thin vertical slice तरीके से implement, test, verify, commit करना; feature flag और rollback-friendly changes का समर्थन
- test-driven-development: Red-Green-Refactor, test pyramid (80/15/5), DRY से ऊपर DAMP, Beyonce Rule का उपयोग
- context-engineering: सही जानकारी सही समय पर agent को देना (rules files, context packing, MCP integration)
- frontend-ui-engineering: component architecture, design system, state management, responsive design, WCAG 2.1 AA accessibility
- api-and-interface-design: contract-first design, Hyrum's Law, One-Version Rule, error semantics, boundary validation
-
Verify (व्यवहार साबित करना)
- browser-testing-with-devtools: Chrome DevTools MCP के जरिए real-time runtime data (DOM inspection, console logs, network traces, performance profiling)
- debugging-and-error-recovery: 5-step triage (reproduce→localize→reduce→fix→defend), stop-the-line rule
-
Review (merge से पहले quality gate)
- code-review-and-quality: 5-axis review, change size (~100 lines), severity labels (Nit/Optional/FYI), review speed standards
- code-simplification: Chesterton's Fence, Rule of 500, सही behavior बनाए रखते हुए complexity कम करना
- security-and-hardening: OWASP Top 10 prevention, authentication patterns, secret management, dependency audit, 3-layer boundary system
- performance-optimization: measure-first approach, Core Web Vitals targets, profiling workflow, bundle analysis
-
Ship (डिप्लॉय)
- git-workflow-and-versioning: trunk-based development, atomic commits, change size (~100 lines), commit-as-savepoint pattern
- ci-cd-and-automation: Shift Left, Faster is Safer, feature flags, quality gate pipeline
- deprecation-and-migration: code-as-debt mindset, mandatory/recommended deprecation methods, zombie code हटाना
- documentation-and-adrs: Architecture Decision Records, API docs, inline documentation standards ('क्यों' को document करना)
- shipping-and-launch: pre-release checklist, feature flag lifecycle, phased rollout, rollback procedures, monitoring setup
Agent personas
- targeted review के लिए 3 expert personas पहले से configured हैं
- code-reviewer: senior staff engineer का दृष्टिकोण, "क्या यह staff engineer की approval पाने लायक है?" मानक पर 5-axis code review
- test-engineer: QA expert का दृष्टिकोण, test strategy, coverage analysis, Prove-It pattern
- security-auditor: security engineer का दृष्टिकोण, vulnerability detection, threat modeling, OWASP evaluation
Reference checklists
- skills ज़रूरत पड़ने पर जिन 4 quick-reference materials को refer करती हैं
- testing-patterns.md: test structure, naming, mocking, React/API/E2E examples, anti-patterns
- security-checklist.md: pre-commit checks, authentication, input validation, headers, CORS, OWASP Top 10
- performance-checklist.md: Core Web Vitals targets, frontend/backend checklist, measurement commands
- accessibility-checklist.md: keyboard navigation, screen reader, visual design, ARIA, testing tools
Skill design principles
- process, prose नहीं: skills agent द्वारा follow किए जाने वाले workflows हैं; इनमें steps, checkpoints, और exit criteria शामिल हैं, सिर्फ reference docs नहीं
- rationalization को रोकना: हर skill में वे आम बहाने ("test बाद में जोड़ दूँगा") और उनके counter-arguments embedded हैं, जिनका उपयोग agent steps skip करने के लिए करता है
- verification non-negotiable है: हर skill evidence requirements (tests pass, build output, runtime data) के साथ खत्म होती है; "लगता है काम कर रहा है" पर्याप्त नहीं है
- progressive disclosure:
SKILL.mdentry point है, और supporting references केवल ज़रूरत पर load होते हैं ताकि token usage न्यूनतम रहे
Installation methods (supported tools)
- Claude Code (recommended):
/plugin marketplace add addyosmani/agent-skillsके बाद/plugin install agent-skills@addy-agent-skills- local development:
git cloneके बादclaude --plugin-dir /path/to/agent-skills
- local development:
- Cursor: किसी भी
SKILL.mdको.cursor/rules/में copy करें या पूरेskills/directory को refer करें - Gemini CLI:
gemini skills install https://github.com/addyosmani/agent-skills.git - Windsurf: skill contents को Windsurf rules settings में जोड़ें
- GitHub Copilot:
agents/की agent definitions को Copilot personas के रूप में, और skill contents को.github/copilot-instructions.mdमें उपयोग करें - Codex और अन्य agents: skills सामान्य Markdown हैं, इसलिए system prompt या instruction files को support करने वाले सभी agents के साथ compatible हैं
7 टिप्पणियां
आजकल ऐसा लग रहा है कि अपने-अपने skill set सार्वजनिक करना जैसे एक ट्रेंड बन गया है
खैर, ये आखिरकार Markdown files ही हैं, इसलिए इन्हें ज्यों का त्यों पूरा अपनाने की ज़रूरत नहीं है
जितनी ज़्यादा होंगी, उतना ही token consumption बढ़ेगा
अपने agent से "इसे analyze करके सिर्फ़ ज़रूरी चीज़ें ही ले आओ" कहना ज़्यादा बेहतर है
ऐसे ही आप अपना खुद का harness बनाते जाते हैं
बिलकुल। मेरा मानना है कि लगातार आते जा रहे open source से निपटने का यह सबसे अच्छा तरीका है।
लगता है यह speckit जैसी चीज़ है।
कंपनी के भीतर सिर्फ vibe coding के सहारे डेवलपमेंट करके देखने का निर्देश मिला, इसलिए मैंने यह-वह कई चीज़ें आज़माईं। लेकिन असल में करके देखा तो समझ आया कि बेहतरीन डेवलपमेंट स्किल्स भी हमेशा उच्च गुणवत्ता की गारंटी नहीं देतीं..
बल्कि ऐसा लगता है कि AI द्वारा बनाए गए कोड की समीक्षा करने और उसे समझने की क्षमता ही असली कुंजी है। टूल जितने बेहतर होते जा रहे हैं, "पढ़कर सही निर्णय लेने की क्षमता" उतनी ही ज़्यादा महत्वपूर्ण होती जा रही है—शायद यही विडंबना है।
Google Chrome टीम के लीड Addy Osmani ने Director, Google Cloud AI के रूप में जॉइन करने के लिए नौकरी बदली।
अरे, यह कब बदला गया? मैं तो लगातार ऐसा ही समझ रहा था। मैंने इसे ठीक कर दिया है।
अब क्रोम टीम में मेरी जान-पहचान का सिर्फ़ Paul Kinlan (Chrome DevRel lead) ही बचा है। वक़्त सच में कैसे बीत जाता है।