Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add Redtropig/harness-anchor/plugin install harness-anchorWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/redtropig/harness-anchor/session-end)<a href="https://agentmods.dev/commands/redtropig/harness-anchor/session-end"><img src="https://agentmods.dev/badge/commands/redtropig/harness-anchor/session-end.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00037 | $0.01614 |
| Opus 5 | $0.00018 | $0.00807 |
| Sonnet 5 | $0.00007 | $0.00323 |
| Haiku 4.5 | $0.00004 | $0.00161 |
Grade A, and why
session-end scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 118 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/session-end
End the current session cleanly (the "clean restart path" lifecycle pattern). The mechanical gathering is ONE script call; every judgment step below consumes its facts.
Steps
-
Gather the facts:
bash ${CLAUDE_PLUGIN_ROOT}/scripts/session-end-precheck.sh --target "$(pwd)"The block reports: active feature + counts · init.sh result (60s cap;
--skip-initonly if the user explicitly asks) · archival backlog (state-archive dry-run) · ledger validation · working tree in two columns (state files / source) · secrets scan over state files · state hygiene (golden-rules count) · TOC structural changes since anchor. If the script fails, report its error verbatim and stop — do not hand-replay the gathering (writes follow it; only /status may degrade). -
If no active feature (block says so), ask: "No active feature. What were we working on this session?" — use the answer for the progress entry.
-
Write
session-handoff.md(overwrite). Fields: ISO-8601 UTC timestamp · active feature id · what's in flight (2-5 bullets) · build/test/lint state (from the init.sh fact + this session's runs, with timestamps) · next session's first action (ONE concrete thing — the most important field) · risks. Keep ≤ 300 words. -
Prepend the
progress.mdentry. Compose the section (template shape:## YYYY-MM-DD HH:MM — Session N, Accomplished / Files changed / Evidence collected / Remaining / Decisions / Next first action), then prefernode ${CLAUDE_PLUGIN_ROOT}/scripts/progress-prepend.mjs progress.md <entry-file>; fall back to Read+prepend+Write only if node is unavailable. -
Update
feature_list.jsonif applicable — Default-FAIL:- All criteria met with evidence → status='pass', evidence object, completedAt.
- Blocked → status='blocked' + blockedReason. Otherwise leave in-progress.
- Then
node ${CLAUDE_PLUGIN_ROOT}/scripts/feature-list-sort.mjs feature_list.json(best-effort). If step 1's ledger fact reported duplicate ids, resolve by renaming the NEWER entry per its suggestion before committing.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 118 lines · 37 tokens per session scan A 22f6d4ca99ca
session-end is a command published in the GitHub repository Redtropig/harness-anchor (13 stars, last pushed 1mo ago), licensed MIT. It adds 37 tokens to every session and 1,614 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
swarm-migrate
Cross-repo migration swarm — one coordinator + N parallel subagents (one per target repo) that apply the same transformation, open PRs, wait for CI, and report back to a shared JSON ledger. Coordinator handles topology, conflict auto-rebase, and stop-on-novel-failure. Use when bumping a shared dependency, rolling out…
commit
Run when user calls /commit or asks to generate a commit message. Analyzes staged changes and writes a structured commit message.
design-ship
One-shot pipeline turning a claude.ai/design link into a pull request: scaffold via /ork:design-import, stories and specs via /ork:cover, browser verification via /ork:expect, then open the PR. Use when a design link should come back as a PR with no intermediate steps; if all you need is the components written to…
release-sync
Syncs latest release content to NotebookLM and HQ Knowledge Base after version tagging. Reads CHANGELOG, CLAUDE.md, and hook README, updates notebook sources, and ingests release digest. Optionally generates podcast from updated knowledge base. Use after tagging a new version to propagate release knowledge.
red-team
Stress-test a plan, strategy, PRD, or launch with a room of hostile expert personas before you commit.
release
Drive the release lifecycle from one command — verify CI and ship, or cut a versioned tag with patch notes — instead of remembering which release skill fits which step. Trunk-based: releases are tags cut from the trunk (the repo's default branch); staging and production are deployment environments driven by CI/CD and…