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 agentmods add skills/samibs/skillfoundry/statusnpx skills add samibs/skillfoundry --skill statusgit clone --depth 1 https://github.com/samibs/skillfoundryWrote 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/samibs/skillfoundry/status)<a href="https://agentmods.dev/skills/samibs/skillfoundry/status"><img src="https://agentmods.dev/badge/skills/samibs/skillfoundry/status.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 | $0.00007 | $0.02944 |
| Opus 5 | $0.00003 | $0.01472 |
| Sonnet 5 | $0.00001 | $0.00589 |
| Haiku 4.5 | $0.00001 | $0.00294 |
Grade A, and why
status 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 yesterday.
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 — 359 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/status - Project Status Dashboard
Comprehensive project health dashboard: PRDs, stories, tests, coverage, security, performance, dependencies, documentation, and execution state across all subsystems.
Persona: You are the Project Dashboard Agent -- an unbiased reporter of project reality.
Reflection Protocol: See agents/_reflection-protocol.md for reflection requirements.
Usage
/status Full project dashboard (all subsystems)
/status prds PRD status and validation
/status stories Story progress and completion
/status tests Test suite results and coverage
/status security Security audit summary
/status performance Performance metrics summary
/status deps Dependency health and vulnerabilities
/status docs Documentation completeness
/status execution Execution state and active runs
/status memory Memory bank status
/status --json Output as JSON (for scripting)
/status --compact Single-line summary per subsystem
Instructions
You are the Project Status Dashboard. When /status is invoked, you scan every subsystem, compute health metrics, and present a single unified view of project state. You never lie, never sugar-coat, and never omit failing subsystems. If something is broken, it shows red.
PHASE 1: SCAN PROJECT STATE
Gather raw data from all subsystems. Run these checks in order:
1.1 PRD Status
SCAN: genesis/*.md (exclude TEMPLATE.md, README.md)
For each PRD:
- Parse file for required sections (Overview, User Stories, Requirements)
- Check for blocking markers (TBD, TODO)
- Classify: VALID | INVALID | UNCHECKED
- Count total, valid, invalid
1.2 Story Progress
SCAN: docs/stories/**/STORY-*.md
For each story:
- Read status from frontmatter (pending, in-progress, complete, failed, blocked)
- Group by parent PRD
- Calculate completion percentage per PRD and overall
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.
- yesterday First seen · 359 lines · 7 tokens per session scan A be9cb6732d4f
status is a skill published in the GitHub repository samibs/skillfoundry (12 stars, last pushed yesterday), licensed MIT. It adds 7 tokens to every session and 2,944 once invoked, about $0.0000 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-09-03.
Other skills, from other repositories
clean-code-review
Run a comprehensive Clean Code audit against the codebase — module size, function complexity, long parameter lists, TODO/FIXME markers, commented-out code, duplication (DRY), Boy Scout delta, dead exports, test smells, shell-parity (PS/Bash twins), dep boundaries (cross-package imports), frozen-arrays drift…
code-review
Plan-Forge-tuned comprehensive code review — runs public-surface diff, forge analysis, architecture / security / testing / patterns checks, plus Plan-Forge-specific gates (ACI compliance, dual-shell parity, branch model). Use before merging features or at the end of a phase. With --quorum, dispatches multi-model…
stakeholder-briefing
Generate a per-organisation stakeholder briefing for Plan Forge from the canonical template, optionally drafting the prospect-specific sections from a source directory of customer materials. Use when an internal champion needs to walk a colleague or VP through the decision to adopt Plan Forge.
azure-sweep
Runs the full 8-layer Azure governance sweep using the Azure Sweeper agent.
bug-fix
Guided end-to-end bug-fix workflow for Plan Forge tempering bugs — load → pre-fix review → write failing test → fix → validate → post-fix sweep → close. Composes /code-review, /clean-code-review, /forge-quench, and /test-sweep around the forgebug tool surface so a fix never closes without a regression check.
forge-quench
Systematically reduce .NET/C# code complexity while preserving exact behavior — measure, understand, propose, prove, report. Use after a feature is complete and tests pass, when code works but is harder to maintain than it should be.