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 wayne930242/straw-boss --skill peeking-workgit clone --depth 1 https://github.com/wayne930242/straw-bossWrote 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/wayne930242/straw-boss/peeking-work)<a href="https://agentmods.dev/skills/wayne930242/straw-boss/peeking-work"><img src="https://agentmods.dev/badge/skills/wayne930242/straw-boss/peeking-work.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.00048 | $0.00778 |
| Opus 5 | $0.00024 | $0.00389 |
| Sonnet 5 | $0.00010 | $0.00156 |
| Haiku 4.5 | $0.00005 | $0.00078 |
Grade A, and why
peeking-work 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 7d 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 — 48 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Overview
Read-only. Never interrupts a working pane, never sends input, never substitutes for the actual checkpoint-answering flow — it only tells you what a dispatched task is currently doing. Every straw-boss skill that needs this reads it through here; the pane-read, progress-trail, and transcript-tail mechanics are not reimplemented inline anywhere else.
Task 1: Resolve the target dispatch
Identify which dispatch to peek at from a task id/plan slug, session id, or
description. Resolve the canonical instruction at
~/.straw-boss/dispatch/<app>--<slug>.json; for a plan task, use its
plan_id/task_id correlation rather than treating the status record as
routing data. The instruction supplies mode, session_id, and repo_root.
For herdr-pane, its launch receipt supplies the agent name and pane. Ask the
caller when more than one instruction matches.
Verification: the target dispatch is confirmed from its actual instruction/status file, not guessed from a name alone.
Task 2: Read the progress trail first
Before touching the live pane or transcript, read the dispatch's own progress log — a sibling <app>--<slug>.progress.jsonl next to its instruction file (per dispatch-mechanics.md's "Reporting scripts"), written by the dispatched agent's own report-progress.py calls throughout its work. Tail it (most recent few entries) rather than dumping the whole file. For a plan task, also check its status file — a terminal or checkpoint status there answers the question outright.
If the trail (plus, for a plan task, the status file) already answers "what's it doing" — a recent note, a clear status — that's your answer; skip Task 3 entirely. This is the whole point of the trail existing: most peeks shouldn't need to join the dispatched agent's live pane at all.
Verification: the trail was checked before any live read was attempted; a peek that the trail already answered did not also do a live read "just to be thorough."
Task 3: Peek live, only when the trail doesn't answer it
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.
- 7d ago First seen · 48 lines · 48 tokens per session scan A b0c1c2ca20f1
peeking-work is a skill published in the GitHub repository wayne930242/straw-boss (3 stars, last pushed 3d ago), licensed MIT. It adds 48 tokens to every session and 778 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-31.
Other skills, from other repositories
create-request
Create, update, or scan per-task request tickets for progress tracking. These are date-prefixed non-lifecycle docs under requests/, NOT feature-level requirements (use /req-analyze for those). Use when: tracking task progress, updating completion status, scanning incomplete requests, checking request status dashboard.…
req-analyze
A requirements-analysis tool that breaks a problem into needs, stakeholders, and priorities before a technical solution is chosen.
recap-ask
Interactive Q&A over an existing recap document. Use when: user wants to ask follow-up questions about a briefing-recap- .md produced by /recap-doc, with recap-bounded context + out-of-scope redirect + optional promote-to-request. Not for: generating a new recap (use /recap-doc), general project Q&A (use /ask), code…
recap-doc
Post-development recap document generator. Use when: AI/Codex has implemented a feature and the user needs a guided walkthrough of what changed and why, with blind-spot detection and anticipated questions. Not for: Q&A follow-up (use /recap-ask), technical share-out for teammates (use /tech-brief), or generic code…
runbook
Generate and update feature release runbooks from existing docs and codebase. Use when: creating operational runbook, release handbook, deployment checklist, pre-release preparation. Not for: incident response (v2), code review (use codex-code-review), architecture design (use architecture).
jira
Jira integration — view issues, generate branches, create tickets, transition status. Use when: user mentions Jira ticket key (XX-123), says /jira, wants to create branch from ticket, create a new ticket, or update Jira status. Not for: GitHub issues (use issue-analyze).