agentleFS
tsukumogamitsukumogami/shirabe/skills/inflight/SKILL.md

inflight

Skill0 starsChanged 30 days agoApache-2.0View on GitHub

Show the pull requests this session has in flight as a standardized "work in flight" block -- repo, PR number, state, CI/review status, title, and a clickable URL per item, ordered attention-first. Use when the user asks "what PRs are in flight", "show this session's PRs", "work in flight", "which PRs did I open", or invokes /inflight explicitly. Does NOT apply to authoring a new PR, checking a single named PR's details, or listing every open PR in a repo regardless of session -- it reports the current session's tracked PRs, or a session-scoped empty-state when none are tracked, not an arbitrary query.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run the command and relay whatever it prints, unchanged:

    line 40
  2. Very specific:

    When the session ledger is empty or unreachable -- a fresh session that has not opened a PR yet, a session whose id the hooks never …

    line 92
  3. Very specific:

    No pull-request reference (URL, owner/repo#N, "I opened PR ...") may appear in the relay text around the block unless it is a real PR the …

    line 124

≈ “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

!${CLAUDE_PLUGIN_ROOT}/scripts/skill-preflight.sh inflight 2>&1 || true

In Flight

Report the pull requests the current session is tracking as the standardized work-in-flight block. This skill is a thin relay: the compiled shirabe work-summary subcommand owns capture, the gate, and rendering, and the same binary backs the ambient dot-niwa hooks -- so /inflight and the automatic emissions always produce the identical block shape.

What it does

/inflight invokes shirabe work-summary render through dynamic command injection and relays its output verbatim. The command reads this session's private PR ledger, refreshes each item's live state via gh pr view, orders attention-first, drops terminal PRs after their one post-transition showing, and stamps a freshness line. When live state is unreachable it prints a best-effort, ledger-only block clearly marked as such. When the ledger is empty it prints a single-line, session-scoped empty-state instead of a block -- it never fails the turn and never issues a non-session gh listing.

Invocation

Run the command and relay whatever it prints, unchanged:

!shirabe work-summary render || echo 'shirabe work-summary render did not run: the shirabe binary is not on PATH. Report to the user that the work-in-flight block is unavailable on this host and that installing shirabe restores it. Do not substitute an empty-state line and do not list pull requests from memory.'

Present the output to the user exactly as produced -- do not reformat, summarize, or add PRs from memory. render always prints something: either the work-in-flight block, or the session-scoped empty-state line (for example no pull requests tracked for this session). Relay that empty-state line as-is; it is the truthful answer for a session with nothing tracked.

Why the line carries a fallback

render itself is not the risk. Every shirabe work-summary subcommand exits 0 by construction -- an internal error degrades to no output, never a non-zero abort -- so once the binary runs, the injection cannot fail. The || echo branch catches the one case the binary cannot handle from inside itself: the binary is absent or unresolvable, the shell returns 127, and a non-zero exit from an injected command aborts the entire skill invocation. Without the branch, a host without shirabe gets no skill body at all rather than a degraded one.

The fallback text is written for the model, not the user: it names what failed, what to tell the user, and what not to do. It deliberately does not print an empty block or the empty-state line, because both are assertions about this session's ledger that nothing read. Relaying either would make /inflight claim no PRs are tracked when the truth is that nothing was checked, and an empty block is precisely the shape that invites narrating PRs from memory to fill it.

The frontmatter declares Bash(shirabe:*), Bash(echo:*) for this line because permission patterns do not compose across shell operators: || splits the line into two subcommands, and each is matched against allowed-tools on its own. A single Bash(shirabe:*) entry would leave the echo half undeclared, and an undeclared subcommand deletes the skill silently rather than degrading it.

/inflight is the only skill carrying two injected lines, so its allowed-tools carries four patterns rather than two: the pair above, plus Bash(${CLAUDE_PLUGIN_ROOT}/scripts/skill-preflight.sh *), Bash(true) for the preflight line every skill now has at the top of its body. The list is additive for the same reason it is a list: one entry per subcommand across both lines, four subcommands, four patterns. Extending it rather than replacing it is the whole point -- dropping either pair to make room for the other deletes the skill on exactly the host the surviving pair was meant to protect.

Session id and the empty-state

shirabe work-summary render resolves the session id itself from the harness environment variable CLAUDE_CODE_SESSION_ID (confirmed exposed to a skill's ! injection on Claude Code 2.1.201); no --session argument is needed. That id must match the id the dot-niwa capture hook keys the ledger by (the PostToolUse hook stdin's session_id); when they match, the primary path returns this session's captured PRs.

When the session ledger is empty or unreachable -- a fresh session that has not opened a PR yet, a session whose id the hooks never captured, or gh offline -- render prints the session-scoped empty-state. It does not fall back to a repo-and-author gh pr list: no gh-only query is session-scoped, so a repo dump would both over-report (other sessions' PRs in this repo) and under-report (this session's PRs in other repos) under the work-in-flight banner. The empty-state is the honest answer; completeness for the common case comes from the ambient capture hook populating the ledger, not from an on-demand listing.

Recovering a PR the hook missed (submit, don't narrate)

The capture hook records a PR only when this session ran gh ... pr create and its stdout carried the PR URL. A PR opened another way -- via the web UI, a gh api call, or a subagent whose tool calls never hit this session's hook -- is structurally invisible to capture, so the ledger (and the block) will not list it.

The sanctioned recovery is to submit it through the validated verb, never to narrate it as prose. Run:

shirabe work-summary track <pr-url> [<pr-url> ...]

track validates each URL against the anchored PR-URL pattern and a live gh pr view before appending it to this session's ledger (marked agent-asserted, deduped by URL); a fabricated or malformed URL is rejected, not appended. After a successful track, re-run render to show the recovered PR inside the normal block. Only submit a PR you actually opened this session.

Guardrail: no PR reference outside the block

No pull-request reference (URL, owner/repo#N, "I opened PR ...") may appear in the relay text around the block unless it is a real PR the block itself lists. This is a checkable rule, and it applies to two places:

  • The /inflight relay. Present exactly what render prints -- the block, or the empty-state line -- and add no PR reference of your own. If a PR is missing, the only sanctioned move is track-then-render, which routes your session knowledge through the validated block, not around it.
  • The dispatch final-message rule. A dispatched session's final message must not append PR references beside the summary block. A PR the session opened belongs in the block (via capture or track); if it is not in the block, it is not narrated next to it.

A reviewer or an automated check can verify conformance objectively: every PR reference in the surrounding text must correspond to a row the block renders. The empty-state carries no PR references, so relaying it can never violate the rule.

Notes

  • This skill is user-invoked only (disable-model-invocation: true); the model does not trigger it on its own.
  • The block format is defined once, by the binary. The shirabe work-summary subcommands (capture, absence, compact, render, track) share the same block renderer, so the ambient hooks and /inflight never drift.

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.