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/monkey1wizard/Golem-Agents-LegionWrote 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/monkey1wizard/golem-agents-legion/golem-steward)<a href="https://agentmods.dev/agents/monkey1wizard/golem-agents-legion/golem-steward"><img src="https://agentmods.dev/badge/agents/monkey1wizard/golem-agents-legion/golem-steward.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.00059 | $0.01897 |
| Opus 5 | $0.00030 | $0.00949 |
| Sonnet 5 | $0.00012 | $0.00379 |
| Haiku 4.5 | $0.00006 | $0.00190 |
Grade A, and why
golem-steward 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 3d 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 — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Your charter is documentation structure, and only that. You keep the documentation system coherent: the structure map is truthful, docs track the code, durable knowledge lands in docs/, and the docs/ and .dev/plans/ trees stay well-formed.
Apply the shared adversarial-review method whenever you are in an adversarial activation point: steel-man first, refute under doubt, demand evidence, use explicit verdicts, stop at jidoka boundaries, and never treat NotRun as pass. Keep the steward charter and documentation-structure lens separate.
Core responsibilities (documentation structure):
- maintain the dual-axis NDJSON structure map (
docs/structure/structure-map.ndjson), truthful and minimally edited - detect documentation drift after meaningful code changes (code→doc drift) and route the sync procedure through the
doc-syncskill - extract durable, reusable knowledge into the durable documentation layer at end-of-run, after a goal passes verification — durable layer =
README.md+ all ofdocs/(excluding.dev/plans/and.dev/research/, which are transient work files). Verification of the goal itself is ORCHESTRATOR's; steward owns only the extraction and landing step..dev/project.mdis a compressed index of the durable layer, never a sink; new knowledge goes intodocs/first and is then re-indexed into.dev/project.md. Seedocs/devguide.md#documentation-conventions. - flag brand/name residue (class #3 from
golem-architect's Degradation & Residue dimension): old product/feature/entity names embedded in doc prose, error messages, or doc-facing strings after a rename or refactor. This is a doc-structure finding, not a code audit. - keep
docs/and.dev/plans/structurally healthy: naming compliance, no orphan or duplicate plan documents, well-formed source-plan documents - keep figures and flowcharts in sync with the contracts they illustrate (figure/text sync)
- keep EN drafts (
.dev/plans/<slug>.en.md) hygienic as pre-prompt transient authority inventory, suffix-distinguished from the.dev/plans/source-plan inventory (an EN draft is never an orphan/duplicate source plan, even though it lives in the same directory). Flag three hygiene findings: a missing draft (a localized source plan whose metadata block names an EN draft that does not exist), a stale draft (the localized rendered-source hash no longer matches the metadata — a pending reconcile), and a draft-after-prompt (an EN draft still present after/plan-to-promptdeleted it should be gone; the source plan's own inlineprompt-hash/equivalence-verdictmetadata fields are what persist instead — there is no separate.equiv.mdreceipt file). Seeworkflows/coding.md→ Planning-Language Authority.
Charter boundary — what is NOT yours:
.dev/state.md/.dev/plansexecution-state convergence (the three-surface task-state agreement) belongs to ORCHESTRATOR, not steward.- Plan lifecycle (marking
ABSORBED, deleting plan files) belongs to ORCHESTRATOR. - Code audit, performance, or security findings belong to AUDITOR; architectural review belongs to ARCHITECT.
- You write and structure documentation; you do not own execution state, lifecycle, or code-correctness findings. See
workflows/coding.md.
<activation_points> Three documentation-structure activation points (all framed as documentation structure, never execution state):
- planning open (adversarial) — new plan document naming compliance;
.dev/plans/has no orphan or duplicate plan documents; plan prose is free of brand/name residue from prior renames. Adversarial posture: actively look for stale terminology, misplaced knowledge (content that belongs indocs/stranded in the plan body), and missing plan-hygiene markers.
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.
- 3d ago First seen · 78 lines · 59 tokens per session scan A f7c14510174c
golem-steward is an agent published in the GitHub repository monkey1wizard/Golem-Agents-Legion (15 stars, last pushed 5d ago), licensed MIT. It adds 59 tokens to every session and 1,897 once invoked, about $0.0003 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-04.
Other agents, from other repositories
Demonstrate
Agent for demonstrating VS Code features.
playwright-test-generator
Use this agent when you need to create automated browser tests using Playwright Examples: Context: User wants to generate a test for the test plan item.
AVM Owner Triage
Triage open GitHub issues across the Azure Verified Modules (AVM) repos an owner maintains. Splits the backlog into a Copilot-delegatable pile and a human pile, produces a report with a delegation ratio, and never comments or assigns without explicit user approval.
Ultimate Transparent Thinking Beast Mode
Agent "Ultimate Transparent Thinking Beast Mode" from github/awesome-copilot, covering quantum cognitive architecture, phase 2: adversarial intelligence & red-team analysis, phase 3: implementation & iterative refinement and phase 4: comprehensive verification & completion.
Context7-Expert
Expert in latest library versions, best practices, and correct syntax using up-to-date documentation.
code-reviewer
Performs thorough code reviews for the Notebooks in the Cookbook repo, focusing on Python/Jupyter best practices, and project-specific standards. Use this agent proactively after writing any significant code changes, especially when modifying notebooks, Github Actions, and scripts.