केस स्टडी: टीम के लिए Release-Notes Skill

दोहराए काम से साझा skill तक

टीम हर दो हफ़्ते release notes लिखती है और हर बार format फिर समझाती है। दायरा: अंतिम tag के बाद merged PRs से notes का मसौदा; एक Markdown file लिखने के सिवा केवल-पढ़ना। Folder: .claude/skills/release-notes/ जिसमें SKILL.md, scripts/prs_since_tag.py (git log से merged PRs JSON में छापती है), references/style-guide.md (लहजा, समूहन, क्या छोड़ें) और templates/notes.md। Description: काम का नाम, कब उपयोग करें, trigger वाक्यांश ("release notes, changelog, what shipped, what changed")। Body: चरण (script चलाएँ, entries समूहित करें, style guide लगाएँ, template भरें), सत्यापन चरण (notes का हर PR नंबर script आउटपुट में हो), और बारीकियाँ (dependency bumps छोड़ें; PR नंबर कभी न गढ़ें)। सुरक्षा: allowed-tools उसी एक script तक सीमित; कोई network नहीं; कोई secrets नहीं। परीक्षण: 6 should-trigger और 6 should-not prompts; fixture repository के साथ script tests; दो असली releases आज़माए और छूटी बारीकी ठीक करने को transcripts पढ़े। साझा करना: repo में commit, कोड की तरह PR में समीक्षित, स्वामी नामित, और release प्रक्रिया बदलने पर skill अद्यतन।

छोटी, तीखी, परखी, समीक्षित skill

तीखा description, केंद्रित body, निश्चित scripts, tests और समीक्षा skill को ऐसा बनाते हैं जिस पर पूरी टीम भरोसा कर सके।

एक पन्ने पर checklist

हर पंक्ति इस कोर्स के एक खंड से जुड़ती है।

Scope        one job; says what it does NOT do                                   (Sec 2)
Description  what + when + trigger phrases; validated; tested both ways                   (Sec 2, 5)
Body         steps, expected output, verification step, gotchas; < 500 lines              (Sec 2)
Files        script (JSON out, exit codes), style guide reference, template                (Sec 3)
Safety       allowed-tools = that one script; no secrets; fetched text is data             (Sec 3, 6)
Testing      should / should-not prompts; script tests on fixtures; read transcripts        (Sec 5)
Sharing      .claude/skills in git, PR review, owner, update with the process              (Sec 4)

लाभ मापें

Skill से पहले और बाद release notes बनाने का समय तुलना करें।

त्वरित जाँच: Skill को repository में commit क्यों किया गया?

• सहकर्मियों से छिपाने के लिए
• क्योंकि skills सिर्फ़ git में चलती हैं
• ताकि टीम उसे साझा करे, बदलावों की कोड की तरह समीक्षा करे और उसे versioned रखे
• क्योंकि Markdown के लिए यह ज़रूरी है