github-activity-review
Use when the user asks for a periodic review of their GitHub activity, wants a summary of what they've been working on, asks "what have I done recently", "review my commits", "summarize my GitHub activity", or wants a cross-repository progress report. Also use when asked to review team activity, lab progress, or multi-repo development summaries. Defaults to 2-week window. Creates thematic report in scratch/.
What this skill does
# GitHub Activity Review
Periodic cross-repository review of GitHub activity, organized thematically with
appropriate depth. Produces a structured report in `scratch/`.
## Parameters
- **Period**: Default 2 weeks. User can override (e.g., "last month", "since March 1").
- **GitHub user**: Detect from `gh auth status`. User can override.
- **Orgs**: Detect from `gh api user/orgs`. User can specify which are relevant.
## Process
```dot
digraph activity_review {
rankdir=TB;
node [shape=box];
discover [label="Pass 1: Discover\nFind all active repos"];
triage [label="Pass 2: Triage\nCount commits, rank by activity"];
gather [label="Pass 3: Gather\nParallel subagents per repo cluster"];
synthesize [label="Pass 4: Synthesize\nThematic organization"];
deepen [label="Pass 5: Deepen\nFill gaps, read PROGRESS files"];
finalize [label="Pass 6: Finalize\nTeam report, cross-cutting themes"];
discover -> triage -> gather -> synthesize -> deepen -> finalize;
}
```
### Pass 1: Discover Active Repos
```bash
# Get orgs
gh api user/orgs --jq '.[].login'
# For each relevant org, find repos pushed in period
gh api "orgs/ORG/repos?sort=pushed&per_page=30&type=all" \
--jq '.[] | select(.pushed_at > "SINCE_DATE") | .full_name'
# Also check personal repos
gh api "users/USER/repos?sort=pushed&per_page=20&type=owner" \
--jq '.[] | select(.pushed_at > "SINCE_DATE") | .full_name'
```
### Pass 2: Triage by Commit Count
For each discovered repo, count commits by the user and by others:
```bash
gh api "repos/REPO/commits?since=SINCE&author=USER&per_page=100" --jq 'length'
gh api "repos/REPO/commits?since=SINCE&per_page=100" --jq 'length'
```
Rank repos into tiers:
- **Heavy** (20+ user commits): Full investigation with PROGRESS files
- **Moderate** (5-19): Commit log analysis with theme grouping
- **Light** (1-4): Brief summary
- **Others only** (0 user, >0 total): Team activity section
### Pass 3: Gather Data (Parallel Subagents)
Dispatch subagents in parallel. Group small repos into a single agent. For each:
1. **README** (first 80 lines): `gh api repos/REPO/readme --jq .content | base64 -d | head -80`
2. **User's commits**: `gh api "repos/REPO/commits?since=SINCE&author=USER&per_page=100" --jq '.[] | "\(.commit.committer.date) \(.sha[0:8]) \(.commit.message | split("\n")[0])"'`
3. **Others' commits**: same query filtering `select(.author.login != "USER")`
4. **PRs**: `gh pr list --repo REPO --state all --search "created:>SINCE" --limit 20 --json number,title,author,state,mergedAt`
5. **PROGRESS.md / CHANGELOG.md**: `gh api repos/REPO/contents/PROGRESS.md --jq .content | base64 -d | head -200`
**IMPORTANT: Subagents often lack Bash permissions. Gather all raw data yourself
in the main conversation, then use subagents only for analysis/writing if needed.**
### Pass 4: Synthesize Thematically
**Do NOT organize the report repo-by-repo only.** The first sections should be thematic:
1. Read all gathered data
2. Identify cross-cutting themes (shared techniques, common goals, connected projects)
3. Look for mono-repos, submodules, and shared libraries that tie projects together
4. Group commits by intellectual contribution, not just repository
Common themes to look for:
- Same technique applied across repos (e.g., contrastive learning, JIT compilation)
- Pipeline stages (data prep -> training -> evaluation -> deployment)
- Shared infrastructure or library development
- Factored/disentangled representations across different model types
- Validation against gold-standard comparators
### Pass 5: Deepen (Critical -- Do Not Skip)
After the initial synthesis, actively look for gaps:
- **PROGRESS.md files**: These contain versioned experimental results with quantitative
outcomes, ablation tables, and methodological decisions. They are far more informative
than commit messages alone. Read them for any repo with 10+ commits.
- **Submodule relationships**: Check `.gitmodules` for mono-repos. Trace how subprojects
relate to each other (shared data pipelines, common evaluation frameworks).
- **Cross-repo patterns**: If the same function/technique name appears in multiple repos
(e.g., "phaser", "contrastive", "STP"), trace how it was developed in one and applied
in others.
- **Quantitative results**: Pull specific numbers (error rates, speedups, SRM values,
accuracy) -- these make the report concrete rather than vague.
- **Negative results**: Architecture ablations that failed, approaches that were rejected.
These are often the most interesting findings.
### Pass 6: Finalize
Write the report to `scratch/YYYY-MM-DD-github-activity-review/README.md`.
**Report structure:**
```markdown
# Cross-Repository Activity Report: USERNAME
**Period:** DATE_RANGE
**Organization:** ORG_NAMES
## Executive Summary
3-5 bullet points on major thrusts with commit counts.
## Thematic Analysis
### Theme 1: [Descriptive Name]
Cross-cutting narrative tying together work across repos.
Include quantitative results, key decisions, connections.
### Theme 2: ...
## Per-Repository Details
### Repo Name (N commits by user, M by others)
**What it is:** 1-2 sentences from README.
**Key work:** Grouped by feature/theme, not chronological.
**Results:** Specific numbers from PROGRESS files.
## Team Activity
| Contributor | Repos | Activity Summary |
|---|---|---|
| name | repo list | What they did |
```
## Common Mistakes
| Mistake | Fix |
|---------|-----|
| Organizing only by repo, not by theme | Lead with thematic sections; repos are reference |
| Ignoring PROGRESS.md files | These have the real results; always check heavy repos |
| Missing submodule relationships | Check `.gitmodules`; mono-repos hide connected work |
| Shallow commit-message-only analysis | Read PRs, PROGRESS files, and README for context |
| Skipping team member activity | Always include "others only" repos in team section |
| Not tracing cross-repo techniques | If same keyword appears in 2+ repos, it's a theme |
| Vague summaries without numbers | Pull specific metrics, error rates, speedups |
| Single-pass report | The deepen pass catches 30-50% of the interesting content |
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.