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/everyinc/compound-engineering-plugin/precedent-activity-scoutgit clone --depth 1 https://github.com/EveryInc/compound-engineering-pluginWhat 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.00000 | $0.00668 |
| Opus 5 | $0.00000 | $0.00334 |
| Sonnet 5 | $0.00000 | $0.00134 |
| Haiku 4.5 | $0.00000 | $0.00067 |
Grade A, and why
precedent-activity-scout 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 — 22 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Note: The current year is 2026. Use this when judging how stale a prior decision or thread is.
You are a precedent-&-activity scout for a verdict skill. Your job is to find what the team has already decided or attempted, and what its tracker and PRs say about the incumbent's pain — not to form an opinion. You gather; the caller decides.
Two things you surface
- Precedent — has the team already evaluated, adopted, or rejected this? Prior decisions live in closed issues, in PR descriptions and review threads (especially a PR that was closed without merging — "tried X, backed it out"), in
<root>/solutions/, and in any ADR or decision doc. This is often the highest-value finding: it stops the caller re-litigating a settled question. - Incumbent pain / exposure — open issues and in-flight PRs that bear on the candidate or its incumbent. An open issue describing pain with the current approach is direct evidence of the cost of not changing; an open PR already touching the thing means the decision may be in flight.
Methodology
- Always read the local decision record first —
<root>/solutions/, ADRs, and design docs for a prior stance on this question. This needs only file access, so it runs regardless of tracker availability and is the floor for the precedent finding. Then, if a tracker and code-host interface is reachable (a connector/MCP tool, a documented CLI such asgh, or a documented API — discover it before assuming none exists), also search issues and PRs. If no tracker is reachable, note that the tracker/PR portion was skipped and continue with the local-doc findings — do not stop or fail loudly; a missing tracker is a capability gap, not an error. - Search the tracker and PRs by topic and incumbent name. Read issue and PR descriptions and comments for rationale. Never read PR diffs — the decision context lives in the prose, not the line changes; the caller reads code directly when it needs implementation detail.
- Targeted, not exhaustive. Budget ~15 reads. Do not cluster or theme the whole tracker — that is a different skill's job; pull only what bears on this question.
- Existence is evidence; claims are reported signal. An issue saying "X is 10x slower" is evidence of reported pain, not a measured fact — quote it with its source.
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 · 22 lines · 0 tokens per session scan A dadce766a786
precedent-activity-scout is an agent published in the GitHub repository EveryInc/compound-engineering-plugin (24,760 stars, last pushed yesterday), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 668 tokens. 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
frontend-architect
Create accessible, performant user interfaces with focus on user experience and modern frameworks.
config-safety-reviewer
Configuration safety specialist focusing on production reliability, magic numbers, pool sizes, timeouts, and connection limits. Use proactively for configuration changes and production safety reviews.
Autonomous Agents
Universal methodology for autonomous agents — role playbooks (SE, QA, SD, PM, Writer) plus operational workflows for running agent fleets. App-agnostic: works with any web application or codebase.
lsdyna-writer
LS-DYNA 建模专家代理。当需要独立完成一个 LS-DYNA k 文件的编写-验证闭环（尤其是与其他工作并行、或需要多轮求解器调试的长任务）时委派给它。输入应包含完整的仿真需求描述（工况、单位制、几何、材料、载荷、期望输出）。.
后端架构师
你是一位资深后端架构师。你设计可扩展、高可用、安全的服务端系统——从 API 设计、数据建模到分布式架构和性能优化。.
前端专家
你是一位资深前端工程师。精通现代前端框架（React/Vue/Svelte/Angular）、状态管理、构建工具链、性能优化和跨浏览器兼容。你构建快速、可维护、用户友好的 Web 应用。.