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 avizmarlon/agent-skills --skill engineering-standardsgit clone --depth 1 https://github.com/avizmarlon/agent-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/avizmarlon/agent-skills/engineering-standards)<a href="https://agentmods.dev/skills/avizmarlon/agent-skills/engineering-standards"><img src="https://agentmods.dev/badge/skills/avizmarlon/agent-skills/engineering-standards/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/avizmarlon/agent-skills/engineering-standards"><img src="https://agentmods.dev/badge/skills/avizmarlon/agent-skills/engineering-standards.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.00084 | $0.02539 |
| Opus 5.5 | $0.00034 | $0.01016 |
| Sonnet 5.5 | $0.00017 | $0.00508 |
| Haiku 4.5 | $0.00008 | $0.00254 |
Grade A, and why
engineering-standards 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 2mo 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 — 89 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Engineering Standards and Project Governance
Every non-trivial project should have the artifacts and process gates listed below. This skill defines what to create, when, and why. Gates marked ★ block merge or release if they fail.
Core Artifacts
| Artifact | Purpose | When to Create |
|---|---|---|
| Charter | 1–2 page document answering: why does this project exist? Vision, scope, stakeholders (who is affected), constraints (what are the hard limits), non-goals (what this is NOT), success criteria. Think of it as the north star for all decisions that follow. | Before any implementation work — even before detailed specs. Required for any project with multiple stakeholders. |
| One-pager / Executive Summary | Single page, no jargon. Problem → Solution → Expected impact → Cost → Timeline. Audience: CEO, investors, leadership without technical context. | Every business/product project. Update when direction changes. |
| RFC (Request for Comments) | Structured proposal inviting review before implementing something that affects multiple components, public APIs, or process. Format: Context + Proposal + Alternatives Considered + Impact Assessment + Decision Status. | Breaking changes, major redesigns, integrations with wide impact, significant process changes. |
| Specification / Design Document (SDD) | What to build, why, and the high-level approach. Distinct from architecture: this answers "what does the system do?" before detailing "how is it built?" | Every non-trivial feature. Can be a section in the RFC or a standalone document. |
| Technical Design Document | Low-level implementation plan: components, interfaces, data flows, performance decisions, edge cases, pseudocode where needed. More granular than the specification. | Complex features, critical modules, performance-sensitive systems. |
| Architecture.md | The system as actually built: components, communication patterns, security invariants, extension points. Must reflect real code, not the original plan. Keep it updated as the system evolves. | Every project with code. Part of the repository root. |
| Architecture Decision Records (ADRs) | Immutable log of design decisions that were non-obvious or consequential. Format: Context + Decision + Rationale + Consequences + Status. Stored in docs/adr/ with timestamp in filename. |
Every significant technology choice, architectural shift, or design tradeoff. |
| Threat Model | Structured map of what can break or be attacked: valuable assets (data, tokens, credentials) + potential attackers + attack vectors + mitigations. Minimal format: STRIDE, or simple "What can go wrong + how we prevent it". | Any feature touching auth, user data, payments, external APIs, or permissions. Update when threat landscape changes. |
| Post-mortem | Blameless analysis after an incident. Answers: what happened, timeline, root cause, impact, corrective actions (with owner and deadline). Stored in docs/post-mortems/YYYY-MM-DD-incident-title.md. Focus on systems, not people. |
After any production incident or significant failure. Published internally. |
| Software Bill of Materials (SBOM) | Complete, machine-readable inventory of all dependencies: name, version, license. Generated automatically via cyclonedx, syft, package-manager export, or equivalent. |
Projects with compliance requirements, sensitive data, or third-party redistribution. Attach to releases. |
| CONTRIBUTING.md | How to contribute: environment setup, PR workflow, code standards, review process, who to contact. Written for humans and AI agents alike. | Any open-source project or repo with multiple contributors (human or AI). |
| Runbooks | Step-by-step operational procedures for routine tasks: deploy, rollback, scale infrastructure, restart service, restore backup. Stored in docs/runbooks/. Written to be executable under pressure, without requiring additional context. |
Every operation that might need to happen in production. Include rollback steps. |
| Playbooks | Response scripts for emergencies: "service is down at 3am — what do you do?" / "data breach detected — sequence of actions." Different from runbooks (which are routine); playbooks handle crisis scenarios. Stored in docs/playbooks/. |
Projects in production serving real users. Publish in Slack, incident-response tool, or wiki. |
| Build-in-Public Log / Devlog | Visible documentation of progress, milestones, and learnings for team, stakeholders, and community. Posts may live in blog, changelog, status page, or project wiki. | Projects with external visibility, community, or stakeholder reporting. Can be optional for internal-only projects. |
| CHANGELOG.md | Chronological record of all releases: features, fixes, breaking changes. Follows semantic versioning. Machine-readable format (Conventional Commits) enables automated generation. | Every project with a public version or release cycle. |
| PROGRESS.md or Dashboard | Executive summary of current phase, lane status, blockers, and key metrics. Updated continuously. | Business/product projects; multi-phase work. Keep it current so the next team/session knows where you are. |
| SESSION-HANDOFF.md or Equivalent | Snapshot of project state for the next person/AI: what's done, what's in progress, what's blocked, next steps, any gotchas or context that won't be obvious from reading code. | Multi-session, multi-phase, or multi-person projects. Update at end of session before you leave. |
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.
- 2mo ago First seen · 89 lines · 84 tokens per session scan A 971ea2add545
engineering-standards is a skill published in the GitHub repository avizmarlon/agent-skills (2 stars, last pushed 4mo ago), licensed MIT. It adds 84 tokens to every session and 2,539 once invoked, about $0.0003 per session on Opus 5.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-31.
Other skills, from other repositories
subagent-driven-development
Execute plans via delegatetask subagents (2-stage review).
duckduckgo-search
Free keyless web, news, and image search via ddgs.
mcporter
List, auth, and call MCP servers/tools from the terminal.
article-writing
Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
mem0-oss-to-platform
Plan, then execute, a migration of a project from the mem0 open-source / self-hosted SDK (local Memory class) to the mem0 Platform / hosted SDK (MemoryClient). TRIGGER when: the developer wants to move, switch, or migrate mem0 off OSS/self-hosted to the hosted API, e.g. "migrate my mem0 setup to the platform", "switch…
safe-refactor
Restructure code while preserving behavior. Use for extraction, consolidation, ownership moves, or cleanup where verification must bracket structural edits.