
Author Contributions
Audit which files a named contributor touched on your branch versus upstream, including renames, before review or merge.
Overview
Author-contributions is an agent skill most often used in Ship (also Build, Operate) that lists every file a given author changed on a branch vs upstream, tracing contributions through renames into a markdown table.
Install
npx skills add https://github.com/microsoft/vscode --skill author-contributionsWhat is this skill?
- Delegates to a subagent—many sequential git operations, returns a concise markdown table
- Compares branch to upstream (e.g. main) with DIRECT vs VIA_RENAME status per file
- Resolves exact git author identity from log (no guessing short usernames vs display names)
- Per-commit file extraction with line change (+/-) summary for humans and LLMs
- Optional GitHub MCP get_me when mapping requested person to --author= string
Adoption & trust: 1.3k installs on skills.sh; 186k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need to know exactly what code a contributor changed on a branch before review or merge, but renames and many commits make manual git archaeology slow and error-prone.
Who is it for?
Pre-merge contribution audits on feature branches when you must attribute edits across renames for code review or release notes.
Skip if: Blame on a single file in main, org-wide contributor analytics, or environments without git CLI access on the target branch.
When should I use this skill?
Asked who edited what, what code an author contributed, or to audit authorship before a merge on a branch vs upstream.
What do I get? / Deliverables
You get a markdown table of files with DIRECT or VIA_RENAME status and line deltas plus a summary line suitable for review notes or merge checklists.
- Markdown table: Status (DIRECT/VIA_RENAME), File Path, Lines (+/-)
- End summary line of contribution scope
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill is built for pre-merge authorship audits and review prep on feature branches. Review subphase matches “who edited what” and contribution tracing right before code review or merge decisions.
Where it fits
Generate a contribution table for a contractor’s branch before you approve the PR.
See which modules a teammate actually touched on a sprawling feature branch for task accountability.
After a messy merge, reconstruct who changed which paths including files that were renamed mid-branch.
How it compares
Focused authorship-on-branch procedure for agents—not a generic “run git blame” one-liner or a full code-quality review skill.
Common Questions / FAQ
Who is author-contributions for?
Solo builders and maintainers using VS Code–adjacent agent workflows who need structured git authorship reports before merging or reviewing someone else’s branch.
When should I use author-contributions?
Use it in Ship during code review prep before a merge; in Build when validating who owns changes on a long feature branch; in Operate when auditing contribution scope after a contentious integration.
Is author-contributions safe to install?
The skill instructs read-oriented git operations in your local repo; review the Security Audits panel on this Prism page and treat subagent git access like any other shell-capable skill.
SKILL.md
READMESKILL.md - Author Contributions
When asked to find all files a specific author contributed to on a branch (compared to main or another upstream), follow this procedure. The goal is to produce a simple table that both humans and LLMs can consume. ## Run as a Subagent This skill involves many sequential git commands. Delegate it to a subagent with a prompt like: > Find every file that author "Full Name" contributed to on branch `<branch>` compared to `<upstream>`. Trace contributions through file renames. Return a markdown table with columns: Status (DIRECT or VIA_RENAME), File Path, and Lines (+/-). Include a summary line at the end. ## Procedure ### 1. Identify the author's exact git identity ```bash git log --format="%an <%ae>" <upstream>..<branch> | sort -u ``` Match the requested person to their exact `--author=` string. Do not guess — short usernames won't match full display names (resolve via `git log` or the GitHub MCP `get_me` tool). ### 2. Collect all files the author directly committed to ```bash git log --author="<Exact Name>" --format="%H" <upstream>..<branch> ``` For each commit hash, extract touched files: ```bash git diff-tree --no-commit-id --name-only -r <hash> ``` Union all results into a set (`author_files`). ### 3. Build rename map across the entire branch For **every** commit on the branch (not just the author's), extract renames: ```bash git diff-tree --no-commit-id -r -M <hash> ``` Parse lines with `R` status to build a map: `new_path → {old_paths}`. ### 4. Get the merge diff file list ```bash git diff --name-only <upstream>..<branch> ``` These are the files that will actually land when the branch merges. ### 5. Classify each file in the merge diff For each file in step 4: - If it's in `author_files` → **DIRECT** - Else, walk the rename map transitively (follow chains: current → old → older) and check if any ancestor is in `author_files` → **VIA_RENAME** - Otherwise → not this author's contribution ### 6. Get diff stats ```bash git diff --stat <upstream>..<branch> -- <file1> <file2> ... ``` ### 7. Return the table Format the result as a markdown table: ``` | Status | File | +/- | |--------|------|-----| | DIRECT | src/vs/foo/bar.ts | +120/-5 | | VIA_RENAME | src/vs/baz/qux.ts | +300 | | ... | ... | ... | **Total: N files, +X/-Y lines** ``` ## Important Notes - **Use Python for the heavy lifting.** Shell loops with inline comments break in zsh. Write a temp `.py` script, run it, then delete it. - **Author matching is exact.** Always run step 1 first. `--author` does substring matching but you must verify the right person is matched (e.g., don't match "Joshua Smith" when looking for "Josh S."). Use the GitHub MCP `get_me` tool or `git log` output to resolve the correct full name. - **Renames can be multi-hop.** A file may have moved `contrib/chat/` → `agentSessions/` → `sessions/`. The rename map must be walked transitively. - **Only report files in the merge diff** (step 4). Files the author touched that were later deleted entirely should not appear — they won't land in the upstream. - **The rename map must include all authors' commits**, not just the target author's. Other people often do the rename commits (e.g., bulk refactors/moves). ## Example Python Script ```python import subprocess, os os.chdir('<repo_root>') UPSTREAM = 'main' AUTHOR = '<Author Name>' # Resolve via `git log` or GitHub MCP `get_me` # Step 2: author's files commits = subprocess.check_output( ['git', 'log', f'--author={AUTHOR}', '--format=%H', f'{UPSTREAM}..HEAD'], text=True).strip().split('\n') author_files = set() for h in (c for c in commits if c): files = su