agentleFS
Sign inStart free
salvo8519salvo8519/fairmark/.agents/skills/session-end/SKILL.md

session-end

Skill1 starsChanged 7 days agoApache-2.0View on GitHub

Close a working session on Fairmark cleanly — run the quality gate, write the journal entry, add the release note fragment, commit, push and open or update the pull request with a complete, professional description. Use when the maintainer says the session is over, or before switching to another issue.

  • Commits and pushes

28 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use ship.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • AWSSkill

    ship

    Finalize dev work on an issue branch — update docs, push, and open a PR.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 21 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Gate: Run uv run just check. If it fails, fix what belongs to this session's task.

    line 9
  2. Very specific:

    Release note: If users can see the change and no fragment exists, write one in changes/ (<issue>.<type>.md, plain language for analysts, …

    line 19
  3. Very specific:

    Journal: Write .agents/journal/<YYYY-MM-DD>-<branch-slug>.md from _template.md: what is done (with hashes), what is half done and where, …

    line 22
  4. Very specific:

    Commit: Use /commit (English message, translation for the maintainer).

    line 25
  5. Very specific:

    Pull request: If none exists for the branch, create it.

    line 28
  6. Very specific:

    Use gh api repos/{owner}/{repo}/pulls (POST to create, PATCH to update) with the body in a file.

    line 42
  7. Very specific:

    Labels and board: Add labels that the labeler cannot infer (numerical-change, breaking-change, no-release-note).

    line 44

“Common” is measured: kept by at least 6 in 10 of the 21 edited versions of this file we could read. “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

Talk to the maintainer in their preferred language; everything written to the repository or to GitHub is in English, without icons. Never merge: merging is the maintainer's decision.

  1. Gate. Run uv run just check. If it fails, fix what belongs to this session's task; otherwise record the failure in the journal and open the pull request as a draft.
  2. Scope. git status and git diff origin/main...HEAD --stat. Every changed file must belong to the branch's issue. Unrelated changes go to a separate branch, never into this pull request.
  3. Roadmap. Issues opened in this session were created with uv run python scripts/roadmap.py new (milestone, epic, labels, spec), never by hand. Mark the task of the issue this pull request closes as status: done in roadmap/roadmap.yaml and run uv run python scripts/roadmap.py render: merging closes the issue, and the file must already say so. CI checks it (roadmap.py check --pr-body).
  4. Release note. If users can see the change and no fragment exists, write one in changes/ (<issue>.<type>.md, plain language for analysts, see changes/README.md). Otherwise the pull request gets the label no-release-note.
  5. Journal. Write .agents/journal/<YYYY-MM-DD>-<branch-slug>.md from _template.md: what is done (with hashes), what is half done and where, decisions, open questions and the very next step. Facts only, no client data.
  6. Commit. Use /commit (English message, translation for the maintainer). Signed off.
  7. Push. git push -u origin <branch>. Never force-push a branch that someone else reviewed without telling the maintainer.
  8. Pull request. If none exists for the branch, create it; otherwise update its body. Title: the Conventional Commit summary of the whole change. Body, in this order, filling every section of .github/PULL_REQUEST_TEMPLATE.md:
    • Summary: two to four sentences, what and why, for a reader who has not seen the issue.
    • Linked issue: Closes #<n> (or Refs #<n> when the issue stays open).
    • Specification: spec id and requirement ids covered; acceptance criteria met.
    • Changes: grouped by area (core, adapters, docs, CI), one line each.
    • Numerical impact: "None" or the methods, old and new values, method_version bump, Numerical-change: trailer, and the independent source.
    • Contracts: schema snapshots changed (breaking or not), error codes added.
    • Documentation: pages added or updated, translation status (uv run just i18n).
    • Testing: golden cases, unit and property tests added; commands run and their result.
    • Risks and follow-ups: known limitations, issues opened for later.
    • Checklist: ticked honestly; leave unticked what is not done and say why. Use gh api repos/{owner}/{repo}/pulls (POST to create, PATCH to update) with the body in a file. Open as draft if the gate failed or tasks remain.
  9. Labels and board. Add labels that the labeler cannot infer (numerical-change, breaking-change, no-release-note). Remove in-progress from the issue only when the pull request is ready for review.
  10. Report to the maintainer: pull request link, check status, what remains, next step.

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.

Check your setup, free