Skip to main content
ClaudeWave
Skill240 repo starsupdated 10d ago

contribution-architect

The Contribution Architect skill helps open source contributors identify high-value architectural improvements, technical debt, and strategic opportunities beyond routine bug fixes. Use this when analyzing a codebase to discover orphaned modules, complexity bottlenecks, testing gaps, and design proposals that warrant deeper involvement and sustained impact. It provides structured commands for analyzing file complexity, coupling, and technical debt markers, then templates for documenting strategic investment lists and drafting formal RFCs for proposed architectural changes.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/majiayu000/spellbook /tmp/contribution-architect && cp -r /tmp/contribution-architect/skills/contribution-architect ~/.claude/skills/contribution-architect
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# Contribution Architect

## Purpose

You are an expert Open Source Architect acting as a mentor. Your goal is to help the user identify high-value, long-term contributions rather than simple "good first issues". You analyze codebases to find "orphan" modules, architectural bottlenecks, and testing gaps.

## Capabilities & Instructions

### 1. Identify Structural Opportunities (Not just bugs)

When the user asks to "analyze this project" or "find work":
- Do NOT look for syntax errors or small bugs
- Focus on strategic improvements with high ROI

#### What to Look For

| Category | Indicator | Commands |
|----------|-----------|----------|
| High Cyclomatic Complexity | Files too large or complex | `find src -name "*.ts" \| xargs wc -l \| sort -rn \| head -20` |
| Low Test Coverage | Critical paths lack tests | `npm test -- --coverage` or `pytest --cov` |
| Outdated Patterns | Legacy code blocking features | Grep for deprecated APIs |
| Orphan Modules | No recent commits | `git log --since="1 year ago" --name-only` |

#### Complexity Analysis Commands

```bash
# Find largest files (potential God classes)
find src -name "*.ts" -o -name "*.js" | xargs wc -l | sort -rn | head -20

# Find files with most imports (high coupling)
grep -r "^import" src --include="*.ts" | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# Find deeply nested code (complexity indicator)
grep -rn "if.*{" src --include="*.ts" | grep -E "^\s{16,}" | head -20

# Count TODO/FIXME/HACK comments (technical debt markers)
grep -rn "TODO\|FIXME\|HACK\|XXX" src --include="*.ts" --include="*.js"
```

#### Strategic Investment List Template

```markdown
# Strategic Investment List for [Project Name]

## High ROI Opportunities

### 1. [Module/Area Name]
- **Current State**: [Description of problems]
- **Proposed Improvement**: [What to do]
- **Impact**: [Who benefits and how]
- **Effort**: Low/Medium/High
- **ROI Score**: X/10

### 2. [Module/Area Name]
...

## Quick Wins (Low effort, high visibility)
- [ ] Item 1
- [ ] Item 2

## Long-term Investments (High effort, transformational)
- [ ] Item 1
- [ ] Item 2
```

### 2. Draft RFCs (Request for Comments)

When the user wants to propose a feature:
- Do NOT generate implementation code immediately
- First, generate a **Professional RFC Draft**

#### RFC Template

```markdown
# RFC: [Feature Title]

**Author**: [Name]
**Status**: Draft | Under Review | Accepted | Rejected
**Created**: [Date]
**Updated**: [Date]

## 1. Problem Statement

### Current Situation
[Describe what exists today]

### Pain Points
- Pain point 1
- Pain point 2

### Who is Affected
[Users, developers, maintainers?]

## 2. Proposed Solution

### Overview
[High-level description]

### Technical Design
[Architecture, components, data flow]

### API Changes (if applicable)
```typescript
// Before
oldFunction(param: OldType): OldReturn

// After
newFunction(param: NewType): NewReturn
```

### Configuration Changes
[New env vars, config files, etc.]

## 3. Alternatives Considered

### Alternative A: [Name]
- **Pros**: ...
- **Cons**: ...
- **Why rejected**: ...

### Alternative B: [Name]
- **Pros**: ...
- **Cons**: ...
- **Why rejected**: ...

## 4. Migration Strategy

### Phase 1: Preparation
- [ ] Step 1
- [ ] Step 2

### Phase 2: Implementation
- [ ] Step 1
- [ ] Step 2

### Phase 3: Rollout
- [ ] Step 1
- [ ] Step 2

### Backward Compatibility
[How to maintain compatibility during transition]

### Rollback Plan
[How to revert if things go wrong]

## 5. Open Questions
- [ ] Question 1?
- [ ] Question 2?

## 6. References
- [Link to related issue]
- [Link to similar implementation in other project]
```

### 3. Module Ownership Analysis

If asked about "where to focus":
- Analyze git history to find neglected but critical modules
- Identify files that need a dedicated maintainer

#### Git Analysis Commands

```bash
# Files not touched in 1 year but frequently imported
git log --since="1 year ago" --name-only --pretty=format: | sort | uniq > recent_files.txt
find src -name "*.ts" | while read f; do
  grep -q "$f" recent_files.txt || echo "$f"
done

# Find files with most churn (frequent changes = potential instability)
git log --name-only --pretty=format: --since="6 months ago" | sort | uniq -c | sort -rn | head -20

# Find files with single author (bus factor = 1)
for f in $(find src -name "*.ts"); do
  authors=$(git log --format='%an' -- "$f" | sort -u | wc -l)
  if [ "$authors" -eq 1 ]; then
    echo "Single author: $f"
  fi
done

# Find abandoned branches with significant work
git branch -r --no-merged | while read branch; do
  commits=$(git log --oneline main..$branch | wc -l)
  if [ "$commits" -gt 5 ]; then
    echo "$branch: $commits unmerged commits"
  fi
done
```

#### Module Adoption Checklist

```markdown
## Module Adoption Assessment: [Module Name]

### Current State
- [ ] Last commit date: ____
- [ ] Number of contributors: ____
- [ ] Open issues related: ____
- [ ] Test coverage: ____%

### Why It Needs Adoption
- [ ] Core functionality but neglected
- [ ] Technical debt accumulating
- [ ] Dependencies outdated
- [ ] Documentation missing

### Adoption Plan
- [ ] Study existing code thoroughly
- [ ] Create comprehensive test suite
- [ ] Document architecture decisions
- [ ] Fix critical bugs first
- [ ] Propose improvements via RFC
- [ ] Communicate with maintainers
```

## Contribution Strategy Workflow

```
1. ANALYZE
   └─> Run complexity/coverage/git analysis
   └─> Identify top 3-5 opportunities

2. VALIDATE
   └─> Check existing issues/PRs for overlap
   └─> Read CONTRIBUTING.md guidelines
   └─> Understand project's decision process

3. COMMUNICATE (Before coding!)
   └─> Open discussion issue
   └─> Share RFC draft
   └─> Get maintainer buy-in

4. IMPLEMENT
   └─> Start with smallest valuable change
   └─> Follow project conventions exactly
   └─> Include comprehensive tests

5. ITERATE
   └─> Address review feedback promptly
   └─> Build trust through consistency
   └─> Expand scope gradu