zhongwei/gh-levnikolaevich-claude-code-skills-full-development-workflow-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:37:27 +08:00
commit 37774aa937
131 changed files with 31137 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

199
skills/ln-221-standards-researcher/SKILL.md Normal file
View File

@@ -0,0 +1,199 @@
---
name: ln-221-standards-researcher
description: Research standards/patterns via MCP Ref. Generates Standards Research for Story Technical Notes subsection. Reusable worker.
---
# Standards Researcher (Worker)
This skill researches industry standards and architectural patterns using MCP Ref to generate Standards Research for Story Technical Notes.
## When to Use This Skill
This skill should be used when:
- Need to research standards and patterns BEFORE Story generation (ensures tasks follow industry best practices)
- Epic Technical Notes mention specific standards requiring documentation (OAuth, OpenAPI, WebSocket)
- Prevent situations where tasks use outdated patterns or violate RFC compliance
- Reusable for ANY skill requiring standards research (ln-220-story-coordinator, ln-310-story-decomposer, ln-350-story-test-planner)
**Who calls this skill:**
- **ln-220-story-coordinator** (Phase 3) - research for Story creation
- **ln-310-story-decomposer** (optional) - research for complex Stories
- **ln-350-story-test-planner** (optional) - research for test task planning
- **Manual** - user can invoke directly for Epic/Story research
## How It Works
The skill follows a 5-phase workflow focused on standards and architectural patterns.
Phases: Identify → Ref Research → Existing Guides → Standards Research
### Phase 1: Identify Libraries
**Objective**: Parse Epic/Story for libraries and technology keywords.
**Process**:
1. **Read Epic/Story description** (provided as input)
- Parse Epic Technical Notes for mentioned libraries/frameworks
- Parse Epic Scope In for technology keywords (authentication, rate limiting, payments, etc.)
- Identify Story domain from Epic goal statement (e.g., "Add rate limiting" → domain = "rate limiting")
2. **Extract library list**:
- Primary libraries (explicitly mentioned)
- Inferred libraries (e.g., "REST API" → FastAPI, "caching" → Redis)
- Filter out well-known libraries with stable APIs (e.g., requests, urllib3)
3. **Determine Story domain**:
- Extract from Epic goal or Story title
- Examples: rate limiting, authentication, payment processing, file upload
**Output**: Library list (3-5 libraries max) + Story domain
**Skip conditions**:
- NO libraries mentioned in Epic → Output empty Research Summary
- Trivial CRUD operation with well-known libraries → Output empty Research Summary
- Epic explicitly states "research not needed" → Skip
---
### Phase 2: MCP Ref Research
**Objective**: Get industry standards and architectural patterns.
**Process:**
1. **Focus on standards/RFCs:**
- Call `mcp__Ref__ref_search_documentation(query="[story_domain] RFC standard specification")`
- Extract: RFC/spec references (OAuth 2.0 RFC 6749, OpenAPI 3.0, WebSocket RFC 6455)
2. **Focus on architectural patterns:**
- Call `mcp__Ref__ref_search_documentation(query="[story_domain] architectural patterns best practices")`
- Extract: Middleware, Dependency Injection, Decorator pattern
**Output:** Standards compliance table + Architectural patterns list
---
### Phase 3: MCP Ref Research
**Objective**: Get industry standards and best practices.
**Process**:
1. **FOR EACH library + Story domain** combination:
- Call `mcp__Ref__ref_search_documentation(query="[library] [domain] best practices 2025")`
- Call `mcp__Ref__ref_search_documentation(query="[domain] industry standards RFC")`
2. **Extract from results**:
- **Industry standards** (RFC/spec references: OAuth 2.0, REST API, OpenAPI 3.0, WebSocket)
- **Common patterns** (do/don't examples, anti-patterns to avoid)
- **Integration approaches** (middleware, dependency injection, decorators)
- **Security considerations** (OWASP compliance, vulnerability mitigation)
- **Best practices URLs** (link to authoritative sources)
3. **Store results** for Research Summary compilation
**Output**: Standards compliance table (RFC/Standard name, how to comply) + Best practices list
---
### Phase 4: Scan Existing Guides
**Objective**: Find relevant pattern guides in docs/guides/ directory.
**Process**:
1. **Scan guides directory**:
- Use `Glob` to find `docs/guides/*.md`
- Read guide filenames
2. **Match guides to Story domain**:
- Match keywords (e.g., rate limiting guide for rate limiting Story)
- Fuzzy match (e.g., "authentication" matches "auth.md", "oauth.md")
3. **Collect guide paths** for linking in Technical Notes
**Output**: Existing guides list (relative paths from project root)
---
### Phase 5: Generate Standards Research
**Objective**: Compile research results into Standards Research for Story Technical Notes subsection.
**Process:**
Generate Standards Research in Markdown format:
```markdown
## Standards Research
**Standards compliance:**
- [Standard/RFC name]: [how Story should comply - brief description]
- Example: "OAuth 2.0 (RFC 6749): Use authorization code flow with PKCE for public clients"
**Architectural patterns:**
- [Pattern name]: [when to use, why relevant for Story domain]
- Example: "Middleware pattern: Intercept requests for authentication before reaching endpoints"
**Existing guides:**
- [guide_path.md](guide_path.md) - [brief guide description]
```
**Return Standards Research** to calling skill (ln-220, ln-310, ln-350)
**Output:** Standards Research (Markdown string) for insertion into Story Technical Notes subsection
**Important notes:**
- Focus on STANDARDS and PATTERNS only (no library details - libraries researched at Task level)
- Prefer official docs and RFC standards over blog posts
- If Standards Research is empty (no standards/patterns) → Return "No standards research needed"
- Standards Research will be inserted in EVERY Story's Technical Notes (Standards Research subsection)
---
## Integration with Ecosystem
**Called by:**
- **ln-220-story-coordinator** (Phase 2) - research for ALL Stories in Epic
- **ln-310-story-decomposer** (optional) - research for complex technical Stories
- **ln-350-story-test-planner** (optional) - research for test infrastructure
**Dependencies:**
- MCP Ref (ref_search_documentation) - industry standards and patterns
- Glob (scan docs/guides/)
**Input parameters (from calling skill):**
- `epic_description` (string) - Epic Technical Notes + Scope In + Goal
- `story_domain` (string, optional) - Story domain (e.g., "rate limiting")
**Output format:**
- Markdown string (Standards Research for Technical Notes subsection)
- Format: Standards + Patterns (libraries researched at Task level)
---
## Time-Box and Performance
**Time-box:** 15-20 minutes maximum per Epic
**Performance:**
- Research is done ONCE per Epic
- Results reused for all Stories (5-10 Stories benefit from single research)
- Parallel MCP calls when possible (Context7 + Ref)
**Token efficiency:**
- Context7: max 3000 tokens per library
- Total: ~10,000 tokens for typical Epic (3-4 libraries)
---
## References
**Tools:**
- `mcp__Ref__ref_search_documentation()` - Search best practices and standards
- `Glob` - Scan docs/guides/ directory
**Templates:**
- [research_guidelines.md](references/research_guidelines.md) - Research quality guidelines (official docs > blog posts, prefer LTS versions)
---
**Version:** 2.0.0 (BREAKING: Renamed to ln-221-standards-researcher, removed research_level parameter, simplified to standards/patterns only)
**Last Updated:** 2025-11-20

118
skills/ln-221-standards-researcher/diagram.html Normal file
View File

@@ -0,0 +1,118 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>ln-221-library-researcher Workflow</title>
<link rel="stylesheet" href="../shared/css/diagram.css">
<script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
<script>
mermaid.initialize({
startOnLoad: true,
theme: 'base',
themeVariables: {
primaryColor: '#4A90E2',
primaryTextColor: '#fff',
primaryBorderColor: '#2E5C8A',
lineColor: '#5C6BC0',
secondaryColor: '#7E57C2',
tertiaryColor: '#26A69A'
}
});
</script>
</head>
<body>
<div class="container">
<h1>ln-221-library-researcher: Library Researcher (Worker)</h1>
<div class="diagram-section">
<h2>Workflow Diagram</h2>
<div class="mermaid">
graph TD
Start([Input: Epic Description + Story Domain]) --> Phase1[Phase 1: Identify Libraries]
Phase1 --> Parse[Parse Epic Technical Notes<br/>+ Scope In + Goal]
Parse --> ExtractLibs[Extract Library List<br/>3-5 libraries max]
ExtractLibs --> Domain[Determine Story Domain<br/>e.g., rate limiting]
Domain --> SkipCheck{Libraries<br/>found?}
SkipCheck -->|No| EmptySummary[Output: Empty Research Summary]
SkipCheck -->|Yes| Phase2[Phase 2: MCP Context7 Research]
Phase2 --> LoopLibs[FOR EACH Library]
LoopLibs --> ResolveID[resolve-library-id<br/>libraryName]
ResolveID --> GetDocs[get-library-docs<br/>libraryID, topic, tokens=3000]
GetDocs --> ExtractAPI[Extract:<br/>- Latest version<br/>- Key APIs 2-5<br/>- Constraints<br/>- Deprecations]
ExtractAPI --> Fallback{Found in<br/>Context7?}
Fallback -->|No| WebSearch[Fallback: WebSearch<br/>library latest version API]
Fallback -->|Yes| Phase3[Phase 3: MCP Ref Research]
WebSearch --> Phase3
Phase3 --> RefSearch[ref_search_documentation<br/>library + domain best practices]
RefSearch --> RefStandards[ref_search_documentation<br/>domain standards RFC]
RefStandards --> ExtractStandards[Extract:<br/>- Industry standards<br/>- Common patterns<br/>- Security considerations<br/>- Integration approaches]
ExtractStandards --> Phase4[Phase 4: Scan Existing Guides]
Phase4 --> GlobGuides[Glob docs/guides/*.md]
GlobGuides --> MatchDomain[Match guides to Story domain<br/>fuzzy match]
MatchDomain --> CollectPaths[Collect guide paths]
CollectPaths --> Phase5[Phase 5: Generate Research Summary]
Phase5 --> CompileTable[Compile:<br/>- Library table version, purpose<br/>- Key APIs list<br/>- Constraints list<br/>- Standards compliance<br/>- Existing guides links]
CompileTable --> FormatMD[Format as Markdown]
FormatMD --> End([Output: Research Summary<br/>for Technical Notes])
EmptySummary --> End
style Start fill:#4A90E2,stroke:#2E5C8A,color:#fff
style End fill:#26A69A,stroke:#1B5E20,color:#fff
style Phase1 fill:#7E57C2,stroke:#4A148C,color:#fff
style Phase2 fill:#7E57C2,stroke:#4A148C,color:#fff
style Phase3 fill:#7E57C2,stroke:#4A148C,color:#fff
style Phase4 fill:#7E57C2,stroke:#4A148C,color:#fff
style Phase5 fill:#7E57C2,stroke:#4A148C,color:#fff
style SkipCheck fill:#FF9800,stroke:#E65100,color:#fff
style Fallback fill:#FF9800,stroke:#E65100,color:#fff
style WebSearch fill:#FFC107,stroke:#F57C00,color:#000
style EmptySummary fill:#9E9E9E,stroke:#424242,color:#fff
</div>
</div>
<div class="info-section">
<h2>Key Information</h2>
<ul>
<li><strong>Type:</strong> Worker (reusable)</li>
<li><strong>Phases:</strong> 5 (sequential workflow)</li>
<li><strong>Input:</strong> Epic description + Story domain</li>
<li><strong>Output:</strong> Research Summary (Markdown)</li>
<li><strong>Time-box:</strong> 15-20 minutes per Epic</li>
<li><strong>Token usage:</strong> ~10,000 tokens (3-4 libraries)</li>
<li><strong>Reusability:</strong> Called by ln-220, ln-310, ln-350</li>
</ul>
</div>
<div class="tools-section">
<h2>Tools Used</h2>
<ul>
<li><code>mcp__context7__resolve-library-id()</code> - Get library ID from name</li>
<li><code>mcp__context7__get-library-docs()</code> - Get latest API documentation (max 3000 tokens per library)</li>
<li><code>mcp__Ref__ref_search_documentation()</code> - Search best practices and industry standards</li>
<li><code>Glob</code> - Scan docs/guides/ directory for existing pattern guides</li>
<li><code>WebSearch</code> - Fallback for libraries not in Context7</li>
</ul>
</div>
<div class="notes-section">
<h2>Important Notes</h2>
<ul>
<li>Research done ONCE per Epic, results reused for all Stories (5-10 Stories benefit)</li>
<li>Focus on KEY APIs only (2-5 methods), not exhaustive documentation</li>
<li>Prefer official docs and RFC standards over blog posts</li>
<li>Skip research if NO libraries mentioned or trivial CRUD operation</li>
<li>Parallel MCP calls when possible (Context7 + Ref)</li>
</ul>
</div>
</div>
</body>
</html>

190
skills/ln-221-standards-researcher/references/research_guidelines.md Normal file
View File

@@ -0,0 +1,190 @@
# Research Guidelines
Quality guidelines for library and standards research to ensure accurate, up-to-date, and actionable information.
## Source Credibility Hierarchy
Use this priority order when selecting sources:
| Priority | Source Type | Example | When to Use |
|----------|-------------|---------|-------------|
| **1** | Official documentation | Python.org, FastAPI docs, RFC specifications | ALWAYS prefer official docs |
| **2** | Industry standards | RFC 6749 (OAuth), OpenAPI 3.0 spec, OWASP guidelines | For protocol/standard compliance |
| **3** | Vendor documentation | AWS docs, Redis docs, PostgreSQL docs | For specific vendor implementations |
| **4** | Community standards | PEP (Python), JSR (Java), WCAG (accessibility) | For language/platform best practices |
| **5** | Authoritative blogs | Real Python, DigitalOcean tutorials, vendor blogs | For complex integration examples |
| **6** | Stack Overflow | Accepted answers with high votes (500+) | LAST RESORT - verify info elsewhere |
**RED FLAGS (avoid):**
- Blog posts > 2 years old (outdated patterns)
- Personal blogs without credentials
- Medium posts without verification
- Reddit/forum posts (use for direction only)
---
## Version Selection Guidelines
| Scenario | Preferred Version | Rationale |
|----------|-------------------|-----------|
| **Production projects** | Latest LTS (Long Term Support) | Stability + security updates |
| **New features** | Latest stable release | Modern APIs, avoid beta/RC |
| **Legacy projects** | Match existing version (upgrade path in separate Story) | Avoid breaking changes |
| **Experimental** | Latest (including RC) | ONLY if Epic explicitly requests bleeding edge |
**Version notation:**
- ✅ GOOD: "v3.12.1 (LTS)" or "v2.5.0 (stable)"
- ❌ BAD: "latest" or "v3.x" (not specific)
**Deprecation check:**
- If library has deprecated methods → List in "Key constraints"
- If library is end-of-life → Suggest alternatives
---
## Key APIs Extraction
**Focus on 2-5 MOST RELEVANT methods for Story domain:**
### Good Example (rate limiting Story):
```
**Key APIs:**
- `Limiter(key_func=get_remote_address, default_limits=["200/day"])` - Initialize rate limiter with default limits
- `@limiter.limit("5/minute")` - Decorator for route-specific limits
- `limiter.reset()` - Reset limits programmatically (testing, admin operations)
```
### Bad Example (too generic):
```
**Key APIs:**
- Constructor
- Methods
- Properties
```
**Extraction rules:**
1. Include method signature (parameters, return type if critical)
2. Explain WHEN to use (not just WHAT it does)
3. Prioritize methods for Story domain (not all library methods)
4. If >5 methods → group by category (CRUD, validation, utilities)
---
## Constraints and Limitations
**MUST document:**
- Async/sync support (e.g., "slowapi v0.1.9 has NO async support")
- Storage backends (e.g., "in-memory storage doesn't persist across restarts")
- Multi-process caveats (e.g., "Limiter doesn't share state across workers without Redis")
- Platform limitations (e.g., "Windows async I/O has known issues")
- Performance limitations (e.g., "max 10K requests/sec without Redis backend")
**Format:**
```markdown
**Key constraints:**
- [Limitation]: [Brief explanation] - [Workaround or solution]
```
**Example:**
```markdown
**Key constraints:**
- No async support in v0.1.9 - Use slowapi v0.2.0+ OR sync endpoints only
- In-memory storage loses data on restart - Use Redis backend for production
- Rate limiting doesn't work across multiple workers - Configure Redis shared storage
```
---
## Standards Compliance
**Industry standards to check (by domain):**
| Domain | Relevant Standards |
|--------|-------------------|
| **Authentication** | OAuth 2.0 (RFC 6749), OpenID Connect, JWT (RFC 7519) |
| **REST API** | OpenAPI 3.0, REST principles (RFC 7231), HATEOAS |
| **Security** | OWASP Top 10, NIST guidelines, CSP (Content Security Policy) |
| **Data formats** | JSON Schema, Protocol Buffers, Avro |
| **Protocols** | HTTP/2 (RFC 7540), WebSocket (RFC 6455), gRPC |
| **Accessibility** | WCAG 2.1, ARIA, Section 508 |
**Format:**
```markdown
**Standards compliance:**
- [Standard/RFC name]: [How Story should comply - brief description]
```
**Example:**
```markdown
**Standards compliance:**
- RFC 6749 (OAuth 2.0): Use authorization code flow with PKCE for web apps
- OWASP Top 10 (2021): Implement rate limiting to prevent brute-force attacks (A07:2021)
- OpenAPI 3.0: Document rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset)
```
---
## Research Summary Template
```markdown
## Library Research
**Primary libraries:**
| Library | Version | Purpose | Docs |
|---------|---------|---------|------|
| slowapi | v0.2.1 (stable) | Rate limiting for FastAPI endpoints | [GitHub](https://github.com/laurentS/slowapi) |
| redis-py | v5.0.0 (stable) | Redis backend for distributed rate limiting | [Redis docs](https://redis.io/docs/clients/python/) |
**Key APIs:**
- `Limiter(key_func=get_remote_address, storage_uri="redis://localhost:6379")` - Initialize with Redis backend for multi-worker support
- `@limiter.limit("5/minute")` - Apply per-route rate limits (returns 429 on exceed)
- `@limiter.exempt` - Exempt specific routes (admin endpoints, health checks)
**Key constraints:**
- slowapi v0.1.9 has NO async support - Upgrade to v0.2.0+ for FastAPI async routes
- In-memory storage loses data on restart - Use Redis backend for production environments
- Rate limiting doesn't work across multiple workers without shared storage - Configure Redis URI
**Standards compliance:**
- RFC 6585 (HTTP 429): Return 429 Too Many Requests with Retry-After header
- OWASP A07:2021 (Identification/Auth Failures): Implement rate limiting on login endpoints (5 attempts/15 min)
- OpenAPI 3.0: Document rate limit response headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset)
**Existing guides:**
- [docs/guides/rate_limiting_pattern.md](docs/guides/rate_limiting_pattern.md) - Rate limiting best practices for FastAPI
```
---
## Time Management
**Time-box: 15-20 minutes maximum per Epic**
**Time allocation:**
- Phase 1 (Identify): 2-3 minutes
- Phase 2 (Context7): 5-7 minutes (parallel calls)
- Phase 3 (Ref): 5-7 minutes (parallel calls)
- Phase 4 (Guides): 1-2 minutes
- Phase 5 (Summary): 2-3 minutes
**If time exceeds:**
- Reduce library count (focus on 2-3 primary libraries)
- Skip fallback WebSearch
- Use cached Ref results from previous Epics
---
## Quality Checklist
Before returning Research Summary, verify:
- [ ] All libraries have specific versions (not "latest")
- [ ] Key APIs (2-5 methods) include when to use (not just what)
- [ ] Constraints list workarounds or solutions
- [ ] Standards compliance includes HOW to comply (not just standard name)
- [ ] Official docs URLs are valid (not broken links)
- [ ] Research Summary is ≤ 500 words (concise, actionable)
---
**Version:** 1.0.0
**Last Updated:** 2025-11-17