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 | $0.00042 | $0.01269 |
| Sonnet 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 9d 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.
- 9d 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 2mo ago), licensed MIT. It adds 84 tokens to every session and 2,539 once invoked, about $0.0004 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-31.
Other skills, from other repositories
agent-carnet
Use this skill when the user asks to save, recall, find, or organize notes. Triggers on: 'remember this', 'save this', 'note this', 'what did we discuss about...', 'check the notebook', 'find in carnet'. Also use proactively when discovering findings worth preserving across sessions.
deploy-docker-compose
Run the Omnigent server as a Docker compose stack (server + Postgres) on any Docker host — your laptop, a VPS, EC2 by hand, or as the base layer of any container-platform deploy. Invoke when the user wants to build the image, bring up the compose stack, debug the stack on a host they already have, or extend the stack…
security-audit
Audit a codebase or directory for security issues (hardcoded secrets, injection, unsafe deserialization, weak crypto, authz gaps) and produce a structured findings report. Use when the user asks for a security review, an audit, or to check code for vulnerabilities. Report only — never fix.
taiyi-ui-design
A design-planning guide for describing how an application's user interface should look and behave. It produces a UI-DESIGN.md document covering layouts, components, interactions, accessibility, and error states.
taiyi-evolve
A workflow skill that compares the implemented code with the frozen design after development and testing. It records architecture changes and proposes updates to DESIGN.md, the document describing the intended system structure.
taiyi-diagram-c4
A code-scanning tool that builds C4 architecture documents from a repository. It separates facts observed in the code from conclusions inferred about the design and uses Mermaid diagrams as the source format.