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 skills add Metalnib/dotnet-episteme-skills --skill dotnet-techne-review-pipelinegit clone --depth 1 https://github.com/Metalnib/dotnet-episteme-skillsWrote 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/skills/metalnib/dotnet-episteme-skills/dotnet-techne-review-pipeline)<a href="https://agentmods.dev/skills/metalnib/dotnet-episteme-skills/dotnet-techne-review-pipeline"><img src="https://agentmods.dev/badge/skills/metalnib/dotnet-episteme-skills/dotnet-techne-review-pipeline/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/metalnib/dotnet-episteme-skills/dotnet-techne-review-pipeline"><img src="https://agentmods.dev/badge/skills/metalnib/dotnet-episteme-skills/dotnet-techne-review-pipeline.svg" alt="Reviewed on agentmods" width="80" 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.00097 | $0.01315 |
| Opus 5 | $0.00048 | $0.00658 |
| Sonnet 5 | $0.00019 | $0.00263 |
| Haiku 4.5 | $0.00010 | $0.00131 |
Grade A, and why
dotnet-techne-review-pipeline 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 12d 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.
.NET review pipeline (multi-agent)
You are the orchestrator. Do not review the code yourself - dispatch, then format the result.
Paths below are relative to this skill's base directory. The checklists, scripts, and contracts live in the sibling review skill: ../../../skills/dotnet-techne-code-review/.
Step 0 - Check the budget, then the roles
A full run spends six agent turns - five reviewers plus the maintainer - on top of your own context. That is the point (independent lanes, fresh-context falsification), but it is not free.
Before fanning out, say in one line what the run will cost and offer the cheaper path when it fits: a diff under ~5 files with no security, public-API, data or messaging surface, or a user on a constrained plan, is better served by the single-context dotnet-techne-code-review skill. If the user wants the pipeline but not the full cost, drop lanes explicitly and name which and why - never silently review less than you claim.
The roles: review-correctness, review-performance, review-security-observability, review-data-messaging, review-generalist, review-maintainer.
Step 0b - Check the roles exist
List your available agent roles. If the review-* roles are missing, stop and tell the user to run scripts/install-codex.sh from the plugin, and use the dotnet-techne-code-review skill for a single-context review in the meantime.
Step 1 - Resolve target and mode
- Target: a branch name, commit range, staged changes, or (default) the current uncommitted changes. For a document or spec review, use
dotnet-techne-code-reviewinstead. - Mode: Cynical if the user's language is explicitly skeptical ("tear this apart", "assume this is broken", "devil's advocate"); otherwise Standard.
- Intent pack (maintainer only, never shown to reviewers): 2-5 lines on what was built and any deliberate trade-offs decided in this session, if you have that context.
Step 2 - Gather context once
Run the helper scripts in ../../../skills/dotnet-techne-code-review/scripts/ (list-changes.sh, branch-diff.sh, review-context.sh; .ps1 variants on Windows) and build one compact context pack: changed files, the diff (per-file summaries above ~2000 lines), component types, repo root.
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.
- 12d ago First seen · 62 lines · 97 tokens per session scan A bc628a32d17f
dotnet-techne-review-pipeline is a skill published in the GitHub repository Metalnib/dotnet-episteme-skills (12 stars, last pushed 4d ago), licensed MIT. It adds 97 tokens to every session and 1,315 once invoked, about $0.0005 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 skills, from other repositories
resharper-clt
Use the free official JetBrains ReSharper Command Line Tools for .NET repositories. USE FOR: jb inspectcode; jb cleanupcode; stronger C# inspections, cleanup profiles, and CI-friendly JetBrains analysis. DO NOT USE FOR: replacing tests with inspection output; ad-hoc formatting-only work when the repo intentionally…
roslynator
Use the open-source free Roslynator analyzer packages and optional CLI for .NET. USE FOR: Roslynator.Analyzers setup; Roslynator CLI checks or cleanup; C# linting, static analysis, and code-fix automation. DO NOT USE FOR: overlapping analyzer packs with no consolidation plan; formatting-only work owned by another…
stylecop-analyzers
Use the open-source free StyleCop.Analyzers package for naming, layout, documentation, and style rules in .NET projects. Use when a repo wants stricter style conventions than the SDK analyzers alone provide. USE FOR: the repo wants StyleCop.Analyzers; naming, layout, or documentation style needs stronger enforcement…
dotnet-best-practices
Ensure .NET/C# code follows maintainable, modern best practices. Use when reviewing or improving C# code, solution structure, async patterns, dependency injection, or testability.
cratis-engineering-csharp-conventions
Apply the Cratis C# house conventions when writing or reviewing C# in a Cratis repository - formatting, naming, records and primary constructors, nullable handling, XML documentation, custom exceptions, structured logging, dependency injection, and service lifetimes. Use for any "how should this be written" C# style…
quickdup
Use the open-source free QuickDup clone detector for .NET repositories. Use when a repo needs duplicate C# code discovery, structural clone detection, DRY refactoring candidates, or repeatable duplication. USE FOR: the repo wants QuickDup; the team needs repeatable duplicate-code scans for C#; the user asks about DRY…