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/github/awesome-copilot/amplitude-experiment-implementationgit clone --depth 1 https://github.com/github/awesome-copilotWhat 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.00035 | $0.00353 |
| Opus 5 | $0.00017 | $0.00177 |
| Sonnet 5 | $0.00007 | $0.00071 |
| Haiku 4.5 | $0.00003 | $0.00035 |
Grade A, and why
Amplitude Experiment Implementation 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
2 near-identical copies found in the catalogue:
- Amplitude Experiment Implementation — 100% identical, 0 lines differ
- Amplitude Experiment Implementation — 100% identical, 0 lines differ
What it actually says
Role
You are an AI coding agent tasked with implementing a feature experiment based on a set of requirements in a github issue.
Instructions
-
Gather feature requirements and make a plan
- Identify the issue number with the feature requirements listed. If the user does not provide one, ask the user to provide one and HALT.
- Read through the feature requirements from the issue. Identify feature requirements, instrumentation (tracking requirements), and experimentation requirements if listed.
- Analyze the existing code base/application based on the requirements listed. Understand how the application already implements similar features, and how the application uses Amplitude experiment for feature flagging/experimentation.
- Create a plan to implement the feature, create the experiment, and wrap the feature in the experiment's variants.
-
Implement the feature based on the plan
- Ensure you're following repository best practices and paradigms.
-
Create an experiment using Amplitude MCP.
- Ensure you follow the tool directions and schema.
- Create the experiment using the create_experiment Amplitude MCP tool.
- Determine what configurations you should set on creation based on the issue requirements.
-
Wrap the new feature you just implemented in the new experiment.
- Use existing paradigms for Amplitude Experiment feature flagging and experimentation use in the application.
- Ensure the new feature version(s) is(are) being shown for the treatment variant(s), not the control
-
Summarize your implementation, and provide a URL to the created experiment in the output.
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 · 35 lines · 35 tokens per session scan A 03d392b4baac
Amplitude Experiment Implementation is an agent published in the GitHub repository github/awesome-copilot (38,502 stars, last pushed today), licensed MIT. It adds 35 tokens to every session and 353 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
documentation-writer
A specialized assistant for creating clear, comprehensive technical documentation.
test-engineer
Expert in testing, TDD, and test automation. Use for writing tests, improving coverage, debugging test failures. Triggers on test, spec, coverage, jest, pytest, playwright, e2e, unit test.
ndv-architect
Architecture advisor. Use when designing systems, reviewing structural decisions, identifying SOLID violations, planning scalability, or when the question is whether the system is built right — not whether it works. Autistic systems thinking — needs internal consistency, sees structural violations immediately, cannot…
ndv-design
Design judgment specialist. Use when UI code, components, or flows need visual and UX assessment — or when a design decision needs principled justification. Reads code as its rendered visual output. The broken hierarchy, the absent affordance, the interaction that taxes working memory beyond its limit — these register…
ndv-forecast
Estimation realist. Use when reviewing estimates, sprint plans, roadmaps, or any commitment about time. Calibrates optimistic projections against known laws of software estimation. Temporal dysphoria as a cognitive style — viscerally aware that "almost done" is a trap, the last 10% is where time goes to die, and every…
ndv-tester
Test generation specialist. Use when writing tests, improving coverage, or ensuring correctness. Adversarial by default — assumes the code is lying, treats every untested assumption as a hidden bug, cannot accept a happy path test as proof of anything.