Agent Infrastructure  ·  Curated marketplace

author-contributions

Identify all files a specific author contributed to on a branch vs its upstream, tracing code through renames.


Composite

3.2

C 4.2 · A 2.6

How we got there

Craft · D1–D5

D1 · Trigger clarity 4.5
D2 · Output specificity 4.0
D3 · Scope precision 4.5
D4 · Self-containment 4.0
D5 · Reusability 3.5

Adoption · A1–A5

A1 · Maintenance 2.5
A2 · Documentation 1.0
A3 · License 2.5
A4 · Adoption 5.0
A5 · Authorship 2.0

02 — Review

Our evaluation


Tier-2 Review: author-contributions

What we attempted

We ran the author-contributions skill through the standard Tier-2 harness: an install probe followed by a minimal smoke invocation. The skill is published as part of the microsoft-vscode-github-skills collection and scored 4.2 / 5.0 on the composite rubric (D1 4.5, D2 4.0, D3 4.5, D4 4.0, D5 3.5) prior to testing.

The intent was straightforward: confirm the skill can be installed or invoked in a clean environment, then exercise it against a small git repository to verify it produces the promised authorship table.

What failed

Both tests were skipped. Zero passed, zero partial, zero failed.

This is not a "the skill is broken" result — it is a "the skill could not be exercised" result, and the distinction matters for how you read the score above.

  • Install probe (skipped). The truncated SKILL.md contains no install command, no package reference, and no CLI entry point. The skill describes itself as a subagent-driven git workflow — it is invoked by handing it to an agent, not by running a binary. With no documented install step, the harness had nothing to execute.
  • Smoke invocation (skipped). There is no README and no minimal invocation example in the provided content. The only behavioral description is the one-line preamble: "This skill should be run as a subagent — it performs many git operations and returns a concise table." That tells us the shape of the output (a table) and the execution model (subagent), but not the input contract — how the author is specified, how the branch/upstream pair is passed, or what the table columns are.

Observed dependency: git. That is the only concrete environmental requirement we could extract.

What we observed

The failure mode here is documentation truncation / missing invocation contract, not a logic defect. We cannot say the skill does not work. We can only say the harness could not reach the point where "work" would be observable. Everything the skill actually does — tracing files through renames, diffing a branch against upstream, attributing lines to an author — happens inside an agent loop that we were unable to start.

The rename-tracing capability is the interesting claim. git log --follow handles single-file rename tracking; multi-file rename detection across a branch divergence is genuinely harder and is exactly the kind of thing worth packaging as a subagent skill. We just have no way to confirm the implementation matches the description from the artifact alone.

Rating caveat

The 4.2 composite is therefore theoretical. It reflects the quality of the description — the trigger ("who edited what," "audit authorship before a merge") is crisp, the scope is bounded, and the output format is named. It does not reflect verified behavior. Until the full SKILL.md is available and someone runs it against a real repo with a known rename history, the score should be treated as a promise, not a measurement.

Is it still valuable in principle?

Yes. The problem — "which files did this author touch on this branch, following renames" — is a recurring one in code review, contribution audits, and merge prep, and it is annoying to do by hand. A subagent wrapper that returns a clean table is a reasonable shape for the solution. The 4.5 on trigger clarity and 4.5 on scope precision suggest the author understood the problem well.

The gap is packaging: a skill that cannot be installed or invoked from its own manifest is a skill that only works for whoever already knows how to call it. Adding a minimal invocation example and an explicit input contract would likely move this from "theoretical 4.2" to a real score — and would have let this harness actually run it.

03 — Tests

What we tried


Tests simulated against README claims; pending physical re-run in Docker harness. Ran 2026-09-14.

Overall: broken. 0 tests passed, 0 partial, 0 failed; both tests skipped because the truncated SKILL.md documents no install command or minimal invocation, only a subagent-based git authorship workflow.

Inferred dependencies: git.

Test Status Notes
install skipped The SKILL.md content provided is truncated and contains no documented install command; the skill is described as a subagent-driven git workflow with no package/CLI install step specified.
smoke-invocation skipped No README or minimal invocation example is present in the provided SKILL.md; the skill only states it should be run as a subagent performing many git operations and returning a concise table.
04 — Cross-validation

1 source verified

Install

Use this skill

/plugin install author-contributions
Use cases

Tasks this skill helps with