agentleFS
g-denng-denn/finish-line/skills/finish-line/SKILL.md

finish-line

Skill0 starsChanged 50 days agoMITView on GitHub

Reconcile feature work produced across multiple agent tasks, branches, or worktrees into one clean, tested, pushed, deployed, and live-verified release. Use when work is scattered, several coding agents have finished independently, or local progress is not appearing in the product. Do not use for ordinary single-branch edits.

2 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. remix-run/react-router★ 57ksame name
    2. ravidsrk/agent-skills★ 1same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before integrating, inventory the requested feature tasks and candidate branches, worktrees, commits, and owned uncommitted diffs.

    line 12
  2. Distinctive:

    Do not silently omit intended work because it lacks a commit, lives on an unexpected branch, or overlaps another change.

    line 22
  3. Distinctive:

    Prefer a commit. Never treat uncommitted files as a completed handoff.

    line 26
  4. Distinctive:

    If a completed task left uncommitted work, identify its exact owned diff and preserve it as one coherent commit before integration.

    line 37
  5. Distinctive:

    Wait for active writers touching overlapping files to produce a stable handoff.

    line 42
  6. Distinctive:

    Create a clean integration worktree from the current authoritative release branch.

    line 43
  7. Distinctive:

    Run the cross-cutting suite on the combined tree.

    line 46
  8. Distinctive:

    Verify the real destination routes and user flows when release verification is in scope.

    line 48
  9. Distinctive:

    Never say "done" when only one step in the truth-state ladder is proven.

    line 81

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Finish Line

Convert parallel feature work into one releasable commit history and a verified destination state. The core risk is losing the mapping between the user's intended features, the artifacts agents produced, and what actually reached users.

Build the reconciliation ledger

Before integrating, inventory the requested feature tasks and candidate branches, worktrees, commits, and owned uncommitted diffs. Use the schema in references/ledger-template.md.

For every intended item record:

  • source task, branch or worktree, base SHA, and exact commit when available;
  • owned files and any intentional overlap;
  • tests, migrations, configuration, provider permissions, and deployment ordering;
  • truth state: active, uncommitted, committed, integrated, tested, pushed, deployed, or live-verified;
  • disposition: include, defer, superseded, or blocked.

Do not silently omit intended work because it lacks a commit, lives on an unexpected branch, or overlaps another change. Do not blindly include every branch. Reconcile candidates against the requested release.

Require a usable handoff

Prefer a commit. Never treat uncommitted files as a completed handoff.

Require:

  • branch and exact commit SHA;
  • base SHA;
  • owned files and intentional overlap;
  • checks that passed;
  • migrations, environment variables, provider permissions, or deployment order;
  • known incomplete or unavailable behavior.

If a completed task left uncommitted work, identify its exact owned diff and preserve it as one coherent commit before integration. Do not include unrelated dirty files.

Integrate from a clean lane

  1. Refresh the authoritative remote and inspect every claimed SHA. Keep local, committed, pushed, deployed, configured, and live-verified states separate.
  2. Wait for active writers touching overlapping files to produce a stable handoff. Do not integrate a moving checkout.
  3. Create a clean integration worktree from the current authoritative release branch.
  4. Order commits by dependency: shared schema and contracts, backend, UI, then release and configuration.
  5. Integrate one feature commit at a time. After each, run its smallest meaningful check. Resolve conflicts according to current product intent, not by blindly choosing a side.
  6. Run the cross-cutting suite on the combined tree. Verify migrations and environment requirements without exposing secrets.
  7. Push the exact clean integration SHA only when authorized. Deploy dependencies before consumers.
  8. Verify the real destination routes and user flows when release verification is in scope. A successful build or push is not completion.

Keep ownership simple

Default to:

one feature = one worktree = one branch = one coherent commit handoff

Give each active feature a narrow ownership boundary. If two features must edit the same contract or core file, make one depend on the other's commit or give that shared file one owner.

Compatibility is proven centrally, not inferred from clean individual branches. Integrate foundations first, run a focused check after each commit, then run combined checks and the cross-feature flow.

Respect the permission boundary

Integration authorization does not automatically authorize pushing, merging, deploying, production migrations, paid services, secret transfer, destructive actions, or external communication. Stop at the highest authorized state and name the remaining state precisely.

Preserve unrelated user work. Never expose secrets in logs or reports.

Completion gate

Finish only when every ledger item has an explicit disposition and the requested behavior works at the authorized destination.

For a production release, require the production destination and exact deployed SHA. For integration-only work, stop at the exact clean integrated SHA and say that deployment remains unverified.

Report:

  1. release outcome and highest proven state;
  2. compact final ledger;
  3. integrated commits and conflict decisions;
  4. focused and combined checks;
  5. deployed SHA and live-flow evidence, when authorized;
  6. remaining blockers and deferred items.

Never say "done" when only one step in the truth-state ladder is proven.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.