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 commands/eai-support/eai-gofer/10_gofer_cloudgit clone --depth 1 https://github.com/eai-support/eai-goferWrote 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/commands/eai-support/eai-gofer/10_gofer_cloud)<a href="https://agentmods.dev/commands/eai-support/eai-gofer/10_gofer_cloud"><img src="https://agentmods.dev/badge/commands/eai-support/eai-gofer/10_gofer_cloud.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.00018 | $0.05238 |
| Opus 5 | $0.00009 | $0.02619 |
| Sonnet 5 | $0.00004 | $0.01048 |
| Haiku 4.5 | $0.00002 | $0.00524 |
Grade A, and why
10_gofer_cloud 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 2d 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.
Copies of this mod
7 near-identical copies found in the catalogue:
- gofer:spec-summary — 86% identical, 602 lines differ
- gofer:diagnose — 83% identical, 604 lines differ
- gofer:zoom-out — 78% identical, 602 lines differ
- gofer:tdd — 77% identical, 602 lines differ
- gofer:vocabulary — 77% identical, 602 lines differ
- gofer_constitution — 73% identical, 717 lines differ
- 8_gofer_branding — 69% identical, 650 lines differ
How it starts
The opening of the file, as written. The whole thing — 708 lines — stays where its author put it; the contents beside it link to each section on GitHub.
description: READ-ONLY cloud infrastructure analysis for Azure, AWS, GCP deployments
Gofer Cloud
MVP Capability-Based Validation
Use .specify/references/mvp-capability-validation.md as the source of
truth. Validate the work that the active feature specification requires now.
Do not apply later delivery requirements to an early MVP.
- Create
.specify/specs/{feature}/before app or operator-tool source work. - Keep
spec.md,plan.md,tasks.md,traceability.md, and the validation scope aligned. - Mark each relevant capability as
not_applicable,planned,implemented,verified, orblocked. - Require evidence only for an implemented capability or a capability required by the current delivery decision.
- Treat
run.sh,run.bat, andrun.ps1as launch evidence only. They do not prove authentication, sessions, EAI access, or deployment readiness. - For a user-facing change, store the local HTTP check, screenshot, and review outcome in the feature validation report.
- If browser validation is blocked, mark that user journey
unverified. Do not call it complete. - If the user changes scope, update the feature artifacts before continuing. Explain what changed, what remains valid, and what now needs evidence.
- Use truthful completion language. For example:
The server runs. Authentication is not in the current MVP scope. - When the feature claims a release or deployed outcome, create
release-capability-ledger.mdfrom.specify/templates/release-capability-ledger-template.md. - Do not report a release complete or score 100% when a required capability is missing from traceability, remains on an open PR, is absent from the release branch, or lacks required deployed evidence.
Application Classification And EAI Preflight
Before any EAI CLI, login, tenant, template, or app-enrollment action:
- Classify the request as EAI app delivery or non-application work using the application signals in
.specify/commands/0_gofer_start.md. - Create
.specify/specs/{feature}/and record the active delivery scope before app or operator-tool source work. - If the request is clearly non-app work, confirm once: "This looks like non-app work, so I will skip EAI tenant/app setup and continue the Gofer research/docs path. Is that right?"
- If the user confirms non-app, record the decision and mark app-only capabilities
not_applicable. Do not runeai whoami,eai tenant select,eai init, or/gofer:eai-first-run. - For local MVP app work, validate the implemented user journey, repo runner, and preview evidence. Do not require EAI setup, authentication, or deployment when the active specification does not require them.
- When the feature uses EAI Platform services, requires a tenant, or prepares deployment, run
eai whoamiand record the EAI readiness evidence ineai-preflight.md. - When the feature creates, changes, or validates an EAI Platform app integration, run
node .specify/scripts/node/eai-app-template-readiness.mjs --root . --json. A missing checker or status other thanreadyblocks that EAI capability. It does not block unrelated local MVP work. - When authentication is implemented or required, validate provider, callback, sign-in, session, first protected API call, and safe denied access.
- When deployment is requested or claimed, require the relevant EAI template, security, configuration, and deployment evidence before completion.
- For durable app delivery, use EAI Platform first, Azure second, and every other stack only by explicit exception.
- If the user changes scope, update
spec.md,plan.md,tasks.md,traceability.md, and validation scope before continuing. Explain the business effect and evidence change. - Do not accept copied marker files, partial scaffolds, or custom templates as readiness evidence for an EAI capability.
- Do not write tokens, secrets, private tenant IDs, or local
.envvalues into Gofer artifacts; record only product-safe readiness status and 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.
- 2d ago First seen · 708 lines · 18 tokens per session scan A e85a5a8b591a
10_gofer_cloud is a command published in the GitHub repository eai-support/eai-gofer (1 stars, last pushed yesterday), licensed Apache-2.0. It adds 18 tokens to every session and 5,238 once invoked, about $0.0001 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 commands, from other repositories
aivo_guide
Command "aivo_guide" from yuanchuan/aivo, covering aivo — complete usage guide, global usage, providers & keys — aivo keys, account — aivo account and models & aliases.
ship
Run the Android pre-launch checklist via parallel fan-out to specialist personas, then synthesize a go/no-go decision with rollback and staged rollout plan.
code-simplify
Simplify code incrementally while preserving behavior exactly.
test
Write tests before implementation using Red-Green-Refactor.
spec
Write a structured specification before writing any code.
adr-review
Run the workflow in docs/playbooks/adr-review.md. You review only — never write or rewrite the ADR for me. Check problem framing, option fairness, trade-offs and consequences, reversibility, the revisit trigger, and weak reasoning. Give pointed questions and concrete suggestions; I write the words. If it supersedes an…