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
- inflightsoftware/skillstheir own version, first seen Mar 30, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- inflightsoftware/skills★ 0same 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.
In this repository23 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- briefSkill
- charterSkill
- compSkill
- coordinateSkill
- decisionSkill
- deliverSkill
- designSkill
- executeSkill
- exploreSkill
- planSkill
- prdSkill
- private-contentSkill
- public-contentSkill
- releaseSkill
- review-planSkill
- roadmapSkill
- scopeSkill
- strategySkill
- visionSkill
- work-onSkill
- writing-styleSkill
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
- Distinctive: line 40
Run the command and relay whatever it prints, unchanged:
- Very specific: line 92
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 …
- Very specific: line 124
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 …
≈ “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.
Files
!${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
/inflightrelay. Present exactly whatrenderprints -- the block, or the empty-state line -- and add no PR reference of your own. If a PR is missing, the only sanctioned move istrack-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-summarysubcommands (capture,absence,compact,render,track) share the same block renderer, so the ambient hooks and/inflightnever drift.
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
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.

