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 instructions/thangchung/agent-engineering-experiment/csharpgit clone --depth 1 https://github.com/thangchung/agent-engineering-experimentWhat 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.01083 | $0.01083 |
| Opus 5 | $0.00541 | $0.00541 |
| Sonnet 5 | $0.00217 | $0.00217 |
| Haiku 4.5 | $0.00108 | $0.00108 |
Grade A, and why
agent-engineering-experiment csharp.instructions.md 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 yesterday.
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
1 near-identical copy found in the catalogue:
- github-copilot-use-cases csharp.instructions.md — 91% identical, 7 lines differ
How it starts
The opening of the file, as written. The whole thing — 114 lines — stays where its author put it; the contents beside it link to each section on GitHub.
C# Development
C# Instructions
- Always use the latest version C#, currently C# 14 features.
- Write clear and concise comments for each function.
General Instructions
- Make only high confidence suggestions when reviewing code changes.
- Write code with good maintainability practices, including comments on why certain design decisions were made.
- Handle edge cases and write clear exception handling.
- For libraries or external dependencies, mention their usage and purpose in comments.
Naming Conventions
- Follow PascalCase for component names, method names, and public members.
- Use camelCase for private fields and local variables.
- Prefix interface names with "I" (e.g., IUserService).
Formatting
- Apply code-formatting style defined in
.editorconfig. - Prefer file-scoped namespace declarations and single-line using directives.
- Insert a newline before the opening curly brace of any code block (e.g., after
if,for,while,foreach,using,try, etc.). - Ensure that the final return statement of a method is on its own line.
- Use pattern matching and switch expressions wherever possible.
- Use
nameofinstead of string literals when referring to member names. - Ensure that XML doc comments are created for any public APIs. When applicable, include
<example>and<code>documentation in the comments.
Project Setup and Structure
- Guide users through creating a new .NET project with the appropriate templates.
- Explain the purpose of each generated file and folder to build understanding of the project structure.
- Demonstrate how to organize code using feature folders or domain-driven design principles.
- Show proper separation of concerns with models, services, and data access layers.
- Explain the Program.cs and configuration system in ASP.NET Core 10 including environment-specific settings.
Nullable Reference Types
- Declare variables non-nullable, and check for
nullat entry points. - Always use
is nulloris not nullinstead of== nullor!= null. - Trust the C# null annotations and don't add null checks when the type system says a value cannot be null.
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.
- yesterday First seen · 114 lines · 1,083 tokens per session scan A c46513a60e24
agent-engineering-experiment csharp.instructions.md is an instructions file published in the GitHub repository thangchung/agent-engineering-experiment (24 stars, last pushed 1mo ago), licensed MIT. It adds 1,083 tokens to every session, about $0.0054 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 instructions, from other repositories
phoenix AGENTS.md
AGENTS.md instructions for Arize-ai/phoenix, covering agent instructions, build & development and python dependency version policy.
foundry-local js-sdk-v2-items.instructions.md
Use when working with the JS v2 SDK Item discriminated union — writing item factories, walking streamed items, or porting C++ Item code to JS.
foundry-local js-sdk-v2.instructions.md
Use when implementing or modifying the v2 JavaScript/TypeScript SDK under sdkv2/js/, including the Node-API C++ addon, TS layers, or package scaffolding.
foundry-local cpp-memory-validation.instructions.md
Use when validating memory management of the C++ SDK with AddressSanitizer/UBSan, or when running runsanitizertests.py.
foundry-local cpp-build.instructions.md
Use when building or rebuilding the C++ SDK, picking a build output directory, or wiring native binaries into the C# / Python SDKs that load them by absolute path.
foundry-local cpp-formatting.instructions.md
Use when writing or modifying C++ source/header files. Covers vertical whitespace conventions for readability.