Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add pigri/code-remote --skill session-repogit clone --depth 1 https://github.com/pigri/code-remoteWrote 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/skills/pigri/code-remote/session-repo)<a href="https://agentmods.dev/skills/pigri/code-remote/session-repo"><img src="https://agentmods.dev/badge/skills/pigri/code-remote/session-repo/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/pigri/code-remote/session-repo"><img src="https://agentmods.dev/badge/skills/pigri/code-remote/session-repo.svg" alt="Reviewed on agentmods" width="80" 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.00098 | $0.00787 |
| Opus 5.5 | $0.00039 | $0.00315 |
| Sonnet 5.5 | $0.00020 | $0.00157 |
| Haiku 4.5 | $0.00010 | $0.00079 |
Grade A, and why
session-repo 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 — 56 lines — stays where its author put it; the contents beside it link to each section on GitHub.
session-repo
A session registers its git repository once, at launch, from the directory it
starts in. Started anywhere else (typically $HOME), it has no repository, so
the Claude apps cannot show its branch, diff or pull requests - even though the
work itself is fine. The fix is to restart the session inside the repo. crctl
does that and resumes the same conversation; restart-self.sh (next to this
file) lets the session do it to itself.
Steps
-
Check where you are. Run
restart-self.sh --check. It prints this session's id and current directory, or says this claude is not a crctl-managed screen session - in which case stop and tell the user; there is nothing to restart. -
Pick the repository. Use the one the user named. Otherwise use the repo this conversation has been working in (where the commits and PRs went). If the work spans several repos, or you are not sure, ask - a session has one primary repo and a wrong guess costs a second restart. The restart marks the repo as a trusted folder for Claude (nobody can answer the trust prompt of a detached session), so only move into a repo the user works in or named. If the session already runs inside the right repo, say so and stop.
-
Confirm the target. Run
restart-self.sh --check <dir>. It resolves the repo root and its origin remote and verifiescrctlsupports the move. Relay any error as is; do not work around it. -
Wrap up, then schedule. The restart ends this turn's process, so first finish or park whatever is in flight: no half-written files, no running builds you still need. Background shells and their state do not survive; uncommitted changes in the working tree do. Tell the user in one or two lines that the session is about to restart into
<repo>and will come back with the same history - and that the Claude apps will list it as a new session entry (same name), with the old entry archived. -
Run
restart-self.sh <dir>as the last action of the turn, then end the turn. The script returns immediately; a detached helper waits until the session is idle and then runscrctl restart <id> --dir <repo>. Do not runcrctl restarton your own session directly - it would kill the command mid-flight - and do not keep working after scheduling, since the helper waits for idle and anything started now is cut off.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 56 lines · 98 tokens per session scan A 18fa205918a5
session-repo is a skill published in the GitHub repository pigri/code-remote (2 stars, last pushed 8d ago), licensed Apache-2.0. It adds 98 tokens to every session and 787 once invoked, about $0.0004 per session on Opus 5.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-10-10.
Other skills, from other repositories
vhs-e2e-gif
Record a test run, a TUI session, or any terminal command as a GIF with VHS and attach it to a GitHub PR as a release-hosted asset, never a repo commit. Use when asked to record an e2e run, demo a fix on a PR, attach a GIF or screen recording to a pull request, show a test passing visually, or produce a terminal…
check-linters-before-commit
Before any commit, run linters, vet, tests, and build verification; do not commit until checks pass.
gh-infra
Overview of gh-infra and command workflow (import, validate, plan, apply). Use when managing GitHub repository settings, labels, actions settings, rulesets, secrets, variables, or files declaratively via YAML manifests.
repository-manifest
Complete YAML schema reference for Repository and RepositorySet resources. Use when writing or editing manifests for repo settings, labels, actions, branch protection, rulesets, secrets, variables, or repository defaults.
file-manifest
Complete YAML schema reference for File and FileSet resources. Use when writing manifests to manage files (CODEOWNERS, LICENSE, CI workflows, etc.) in one or more repositories, including templating, patches, reconcile modes, delivery method, and import-into behavior.
import-into
Use when pulling live GitHub state back into existing gh-infra manifests with gh infra import --into, especially for write/patch/skip decisions, shared file sources, template-backed files, and import safety rules.