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 jongwony/epistemic-protocols --skill triagegit clone --depth 1 https://github.com/jongwony/epistemic-protocolsWrote 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/jongwony/epistemic-protocols/triage)<a href="https://agentmods.dev/skills/jongwony/epistemic-protocols/triage"><img src="https://agentmods.dev/badge/skills/jongwony/epistemic-protocols/triage.svg" alt="Measured on agentmods" height="20"></a>- NVIDIA SkillSpector pass
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.00045 | $0.04636 |
| Opus 5 | $0.00023 | $0.02318 |
| Sonnet 5 | $0.00009 | $0.00927 |
| Haiku 4.5 | $0.00005 | $0.00464 |
Grade A, and why
triage 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 8d 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 — 242 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Triage: Work-Unit Formation
Form executable work units from GitHub issue substrate, handing execution — branches, PRs, applied fixes — to a normal session. It reads raw issues, groups related issues, fuses each group with the project's inscribed northstar and the user's current-session judgment, forms one or more focused work units, and — once the user routes a unit for handoff — externalizes it to a substrate-owned record a continuing collaborator session is pointed at.
Core Contract
/triage owns work-unit formation:
BacklogIntake
-> RawIssueSet
-> IssueGroup
-> NormalizedProblemFrame
-> NorthstarFusion
-> FocusedWorkUnit
-> RouteChoice
-> independent session: externalize -> WorkUnitRecord
-> re-triage: back to the relevant earlier phase, no record externalized
Execution is not /triage's. The receiving session starts from the record's canonical locator, dereferences the work-unit record with its own tools, grounds the premises it needs, and does the branching, editing, and PR work itself as a continuing collaborator, not a mere executor. Arranging how several routed units run is likewise outside this skill: /triage externalizes one record per routed unit and stops.
Types
| Type | Meaning |
|---|---|
BacklogIntake |
The scale-aware intake step that binds an explicit issue scope or, when no scope is supplied, inspects the current repository's open GitHub issue backlog through lightweight metadata before deciding how much substrate to read. Scale is judged by triage load, not by a fixed issue-count threshold. |
RawIssueSet |
The issue substrate read from GitHub: issue body, comments, labels, linked PRs, and explicitly cited blockers. Scope this narrowly to issues; do not call it external signals. |
IntakeIntent |
The user-recognized purpose for the triage pass, explicitly stated in the current session. |
TriageLoad |
A metadata-grounded composite judgment spanning IssueLoad, RepoLoad, MappingLoad, and IntentAmbiguity. |
IssueGroup |
One or more raw issues that share a problem pressure: similar symptom, target behavior, conceptual request, affected surface, or blocked execution axis. |
NormalizedProblemFrame |
A single problem statement reconstructed from the issue group, with duplicates collapsed and contradictions surfaced. |
Northstar |
The inscribed direction line read from AGENTS.md or the active project guide, usually under ## Northstar. This may have been produced by /realign. |
NorthstarFusion |
A session-text trace showing how the normalized problem frame preserves, transforms, or drops issue claims in light of the northstar and the user's current judgment. |
FocusedWorkUnit |
The executable unit formed from one issue group after northstar fusion. Default cardinality is IssueGroup -> FocusedWorkUnit one-to-one. Split only when northstar fusion exposes distinct execution axes. |
RouteChoice |
The user's current-session choice for a formed work unit: hand it off to an independent session, or re-triage it. |
WorkUnitRecord |
The substrate-owned record a routed FocusedWorkUnit is externalized to — an anchor-issue comment or issue-body triage section carrying the problem frame, fusion trace, issue provenance, exclusions, and verification expectations. It is the canonical record; the receiving session dereferences it rather than a session-local restatement of it. |
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.
- 8d ago First seen · 242 lines · 45 tokens per session scan A c997f37b83ac
triage is a skill published in the GitHub repository jongwony/epistemic-protocols (160 stars, last pushed today), licensed MIT. It adds 45 tokens to every session and 4,636 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 skills, from other repositories
flow-next-plan
Plan a feature into a flow-next spec with tasks in .flow/. Use when asked to plan, spec out, or break down work (fn-N ids).
flow-next-tracker-sync
Project a flow-next spec to a tracker issue (Linear, GitHub, GitLab, Jira) and reconcile two-way. Use when asked to sync to a tracker. NOT plan-sync.
flow-next
Manage .flow/ tasks and specs. Use for show or list tasks, task status, what is ready, show fn-N. NOT for planning or executing (use the plan and work skills).
backlog
Read, work, and maintain a Git repo's deferred-work items in docs/backlog/, one file per item. Use when the user says "backlog", "check backlog", "what's on my backlog", "work the backlog", "address the backlog", "add to backlog", "clean up backlog", or when a review or task produced items that are real but not being…
specs
Use when a rough user story, bug report, feature idea, piece of feedback, or an implementation plan should be recorded as a GitHub issue — "file a ticket for this", "open an issue", "write this up for the backlog", "we should track this", "log this bug", "spec this out as a ticket so we can pick it up later" — i.e.…
plan-tree
Maintain a structured planning document tree made of roadmap/status files, implementation status or handoff TODO files, topic notes, decision records, open questions, ideas/inspiration pools, and repository/file-structure hygiene plans. Use when Codex needs to create, reorganize, audit, or update a multi-file plan…