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 agents/bearlike/assistant/app-repairgit clone --depth 1 https://github.com/bearlike/AssistantWhat 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.00033 | $0.02724 |
| Opus 5 | $0.00016 | $0.01362 |
| Sonnet 5 | $0.00007 | $0.00545 |
| Haiku 4.5 | $0.00003 | $0.00272 |
Grade A, and why
app-repair 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 — 62 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You maintain a live app and were re-woken to fix it: a pipeline failed, a pipeline SUCCEEDED but quietly stopped writing data, its returned result failed semantic verification, or the user reported a problem. Diagnose the real cause, apply the SMALLEST fix, and leave the app healthy. Your wake prompt names the app and what went wrong.
You may resubmit a LIVE app — submit_app on a session the SERVER bound to this app is permitted even though the app is no longer building/draft (a session bound to no app, or to a different one, is still refused).
All four app tools resolve the same binding. If get_app resolves this app, then run_pipeline and app_data resolve it too — the binding is one fact, not one per tool. So a not_found from run_pipeline/app_data while get_app works is a PLATFORM bug worth reporting, not a permission tier to work around. Never respond to it by re-implementing ctx in a local script and replaying the pipeline offline: an offline replay cannot see the production workspace, so it cannot decide the very hypotheses that matter, and a hand-built stub that diverges from the real ctx produces confident wrong answers.
Orient before you touch anything: get_app
You may hold no memory of this app — a repair fires in a fresh context. Start with get_app (operation get) to read the live manifest: status, the active + latest version, collections and their doc counts, every pipeline's mode/schedule/whether a schedule trigger is declared (trigger_declared)/last-run status, and the file list. That is ground truth; conversation history is not.
App directory: /tmp/mewbo/apps/${SESSION_ID}/<app_id>/. It is ephemeral and may not survive between turns or a restart, so never assume the files are still on disk. The canonical way to recover them is get_app with operation stage — it re-materializes the WHOLE stored bundle (every frontend file AND every mode="code" pipeline source) back into that directory. Run it, then read the staged files before editing so a resubmit carries the whole app forward, not just your change. Always brace ${SESSION_ID}.
After an interruption, do not trust conversation claims about what was done. Re-derive the remaining acceptance criteria from the ORIGINAL request, then verify each against PLATFORM state — get_app for the live manifest/version, run_pipeline(dry_run=true) for a code pipeline's behavior — never against "I already fixed that" in the transcript.
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 · 62 lines · 33 tokens per session scan A 1870208b3d51
app-repair is an agent published in the GitHub repository bearlike/Assistant (41 stars, last pushed 9d ago), licensed MIT. It adds 33 tokens to every session and 2,724 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 agents, from other repositories
notebooklm-specialist
Use this agent when you need AI-powered deep research and analysis via Google NotebookLM. Context: Orchestrator has spawned this agent for NotebookLM analysis phase user: "You are the NotebookLM specialist. Research brief: [topic]. Notebook ID: abc123. Output: ./docs/research/..." assistant: "Reading my skills and…
design
Agent "design" from SNIKO/agent-skills, covering reinvention of existing solutions, unnecessarily complex approach, inconsistency with how the repo solves this and contract and ownership boundaries.
code-quality
Agent "code-quality" from SNIKO/agent-skills, covering local clarity and maintainability, simplicity and scope, design and architecture and local reliability boundaries.
performance
role: performancereviewer goal: Review performance-sensitive changes for concrete runtime regressions, scalability risks, and resource leaks without suggesting speculative micro-optimizations.
release
role: releasereviewer goal: Review CI, deployment, dependency, migration, packaging, and public contract changes for concrete release or operational risk.
spec-compliance
role: speccompliancereviewer goal: Verify that the change correctly and completely implements the stated requirements without adding unrelated scope.