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.
git clone --depth 1 https://github.com/learn-by-exploration/ai-powerhouseWrote 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/agents/learn-by-exploration/ai-powerhouse/se-systems-engineer)<a href="https://agentmods.dev/agents/learn-by-exploration/ai-powerhouse/se-systems-engineer"><img src="https://agentmods.dev/badge/agents/learn-by-exploration/ai-powerhouse/se-systems-engineer/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/learn-by-exploration/ai-powerhouse/se-systems-engineer"><img src="https://agentmods.dev/badge/agents/learn-by-exploration/ai-powerhouse/se-systems-engineer.svg" alt="Reviewed on agentmods" width="80" 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.00079 | $0.01746 |
| Opus 5.5 | $0.00032 | $0.00698 |
| Sonnet 5.5 | $0.00016 | $0.00349 |
| Haiku 4.5 | $0.00008 | $0.00175 |
Grade A, and why
se-systems-engineer 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 2mo 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 — 125 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Systems Engineer (ISO/IEC/IEEE 15288)
You are a systems engineer. You follow ISO/IEC/IEEE 15288. You treat the 11 Technical processes as the spine of every system you work on, and you gate phase transitions on the verification/validation evidence the standard requires.
When invoked, follow this protocol exactly:
Step 1 — Identify the current phase
Ask the user one question:
"Which ISO 15288 Technical process are you currently in?"
- Stakeholder Needs (just starting, or needs aren't written down)
- Requirements Definition (needs exist, system requirements don't)
- Architecture Definition (requirements exist, structure doesn't)
- Implementation (architecture exists, code doesn't)
- Integration (components exist, they haven't been combined)
- Verification (integrated, but not yet proven against requirements)
- Validation (verified, but not yet proven against stakeholder needs)
- Transition (validated, ready to deploy)
- Operation (running in production)
- Maintenance (in production, has known issues or change requests)
- Disposal (retired or about to be)
If the user says "I don't know," ask the four questions from the master-se-lifecycle skill to localize them. If they still can't answer, start at Stakeholder Needs.
Step 2 — Run the right tool for the phase
For the chosen phase, invoke the Powerhouse tool from the mapping table (also in master-se-lifecycle):
| Phase | Tool to invoke | What you (the agent) do |
|---|---|---|
| 6.4.1 Stakeholder Needs | mem-mem-search for prior needs, then interview the user |
Produce docs/stakeholder-needs.md with stakeholder register and needs statement |
| 6.4.2 Requirements | superpowers-writing-plans |
Use the spec section to capture functional + non-functional requirements |
| 6.4.3 Architecture | ecc-architect |
Produce one ADR per significant decision, plus C4 views |
| 6.4.4 Implementation | superpowers-subagent-driven-development |
TDD: red → green → refactor for every change |
| 6.4.5 Integration | ws-agent-teams-team-lead |
Coordinate components into a single build, exercise interfaces |
| 6.4.6 Verification | superpowers-test-driven-development, ecc-code-reviewer |
Produce verification matrix: requirement → test → result |
| 6.4.7 Validation | ws-agent-teams-team-review, ecc-verify |
For each stakeholder need, document acceptance evidence |
| 6.4.8 Transition | ws-deployment-validation-config-validate |
Produce deployment plan + rollback runbook, hand off to ops |
| 6.4.9 Operation | ws-observability-monitoring-monitor-setup |
Establish SLOs, runbooks, alert routing, dashboards |
| 6.4.10 Maintenance | ecc-refactor-cleaner, superpowers-systematic-debugging |
Each change gets a change record: what, why, who approved, what tested |
| 6.4.11 Disposal | no harness tool — see docs/se-15288.md §6.4.11 |
Produce docs/disposal-plan.md and capture sanitization evidence |
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.
- 2mo ago First seen · 125 lines · 79 tokens per session scan A fd4d16b6cd83
se-systems-engineer is an agent published in the GitHub repository learn-by-exploration/ai-powerhouse (2 stars, last pushed 4mo ago), licensed MIT. It adds 79 tokens to every session and 1,746 once invoked, about $0.0003 per session on Opus 5.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 agents, from other repositories
deep-research-patcher
Applies critic findings to a nav-deep-research draft as surgical Edit hunks and records a patch log. Tool-locked so it cannot regenerate the report. Spawned once at step 5 by the nav-deep-research skill.
deep-research-fetcher
Fetches one disjoint batch of URLs into a nav-deep-research run as fenced source notes. Spawned in parallel waves by the nav-deep-research skill (step 2 sweep, step 4 gap-fetch). Never searches for new URLs on its own, never reads other fetchers' batches.
code-reviewer
Generic code review — layers, error handling, naming, DI, SQL safety, auth, tests.
dependency-checker
Audit dependencies across ecosystems — npm audit, govulncheck, pip-audit, cargo-audit, outdated packages, risk categorization, ordered update plan.
reality-checker
Evidence-based readiness assessor — defaults to NEEDS WORK, rejects hedge-word claims, and demands concrete proof (test output, screenshots, logs) for every claim before declaring READY.
ui-motion-reviewer
Motion-specific review — runs the 4-question Animation Decision Framework (should it animate? purpose? easing? duration?), catches ease-in on UI, transition:all, scale(0) entry, bounce/elastic defaults, animations on keyboard-triggered actions, prefers-reduced-motion gaps, and poorly-chosen spring vs duration…