Coding Standards | Blog

A Green Pipeline Is Not Proof

Sun, 05 Jul 2026 00:00:00 GMT

Alongside the audit sweep, 1.5 folds a batch of hard-won lessons into the architecture and process standards. They came out of real development on a TypeScript / Rust / Swift local-first monorepo — the kind of project these standards are meant for. Each one is a bug that a reasonable person would not have predicted, and that a green checkmark actively hid.

A green release that never reached production

Twice, a release was cut, promoted, and reported green — while production never changed.

The first time, the deploy platform’s build token had been silently rolled. Every in-repo check passed because the failure lived entirely outside the repo: the git host had no idea the token was dead. The second time, a force-push protection on the release branch blocked the fast-forward promote. Same symptom: pipeline exits zero, nothing ships.

The lesson is uncomfortable because it undercuts the thing we most want to believe: that a passing pipeline means the work is done. It doesn’t. A pipeline proves the steps it ran exited zero. It cannot prove that a system it doesn’t control — the deploy platform, its credentials, its branch rules — did what you asked. So arch-08 and proc-02 now require the release to end by fetching the live deployment and asserting the new version is actually serving. Necessary is not sufficient; the only proof that production updated is production.

A stale tab that bricked every new one

The local-first app used a shared-worker leader/follower model — one tab owns the database, the rest coordinate through it. After a deploy, a browser tab left open from the previous version still held the leader lock. Every freshly loaded tab became a follower, probed the incompatible old leader, timed out, and retried the same doomed probe forever. The app was wedged, and nothing in the running code knew how to recover.

Two fixes, now in arch-05. Version the coordination protocol, so a new follower recognizes an incompatible leader and triggers takeover instead of trusting it. And distinguish transient failure from persistent failure — retry is for hiccups; a persistent leader timeout means re-elect, not retry. A follower that retries a permanent condition forever isn’t resilient, it’s stuck.

Drift a warm build refused to show

This one is subtle. The repo commits generated cross-platform artifacts — wasm blobs, UniFFI bindings. To catch drift, CI regenerates them and diffs against what’s committed. Straightforward, except it kept passing while the artifacts were genuinely stale.

The culprit was the warm build cache. An incremental target/ directory happily produced the already-committed output from stale intermediate state; the drift only reproduced after a cargo clean. So the “regenerate and diff” gate was diffing against a lie. arch-07 now requires the drift gate to rebuild from a cold state — clean first, or run in a fresh checkout — because a warm target masks exactly the drift the gate exists to catch.

The one that fails in seconds vs. the one that waits

A smaller, sharper one for arch-08: two self-hosted runners sharing a machine produced collisions — duplicate listener stacks fighting over _diag paths, package-manager setup dirs racing on big fan-out PRs. The fix is isolation (each runner gets its own HOME, tool-cache, and work directory). But the lesson worth writing down was diagnostic: an offline runner leaves a job queued and waiting; a misconfigured one fails at “Set up job” in seconds. Same red check, opposite cause. Knowing which you’re looking at saves an hour of debugging the wrong thing.

Why these belong in the standards

None of these are exotic. They’re the failure modes you only meet once you ship something real across more than one platform — and once you’ve met them, they’re obvious. The point of a standards repo is to let the next team meet them as a paragraph in a document instead of as a production incident.

That’s the trade every entry in this batch makes: someone already paid for the lesson. The standard is just the receipt, filed where the next person will look.

Standards 1.5: The Audit Sweep

Sun, 05 Jul 2026 00:00:00 GMT

Every few releases we stop shipping features and turn the audit on ourselves. This is one of those releases. We ran a full-repo sweep — scripts, CI, docs, and the standards documents themselves — and it surfaced about thirty distinct issues. 1.5 lands the fixes.

The interesting part isn’t the count. It’s what the count was made of: not one big broken thing, but thirty small ones, each individually easy to wave off, that together added up to a repo quietly drifting from the standards it publishes.

The shape of the drift

A few themes ran through almost everything we found.

Portability assumptions that only held on Linux. The compliance linter (lint-standards.sh) crashed on --format json and --format sarif when there were zero findings — but only under bash 3.2, which is exactly what ships on macOS, and exactly the path the PR-review action runs. gh-task used grep -oP, a GNU-only flag that silently returns empty on a Mac. Both had lived in the tree for months because CI runs on Ubuntu and nobody hit them locally until they did.

Docs describing a repo that no longer existed. The agent configs still told assistants to “strictly follow” arch-03 — a standard we had deleted. Go and Elixir shipped as full language standards but were missing from every agent config’s detection map. The README said the standards-review workflow was “installed automatically by make setup” when in fact it required an explicit --workflow flag. None of these break a build. All of them mislead a reader — or an agent — at exactly the moment they’re trying to trust the document.

Gates that didn’t gate. The Definition-of-Done workflow ran linting, coverage, and security scans and then swallowed every failure with || true. It looked like a quality gate and enforced almost nothing. The lifecycle-sync automation queried the first 100 project items and quietly stopped working past that. A “green” pipeline that proves nothing is worse than no pipeline, because it manufactures false confidence.

A source that would run anything. gh-task read its state file with source .gh-task-state — executing whatever a tampered or mis-merged file put there, with your shell’s privileges. That one we treated as a security fix, not a cleanup.

Batching the fix

Thirty issues is too many for one pull request and too many to merge one-at-a-time without losing the plot. We grouped them by kind — script bugs, doc consistency, CI hardening, chores, dependency triage, standards enrichment — and shipped each as its own reviewable PR that closed a handful of issues at once. Each batch stated what it fixed, how it was verified, and what it deliberately left for later.

That structure paid off when the batches started depending on each other. The new “dogfood” CI job — which runs our own linter against our own repo and asserts the JSON and SARIF output is valid — is a direct regression guard for the zero-findings crash. It literally cannot pass until the crash fix is present. So the batches had a merge order, and the order was part of the plan, not an afterthought.

What actually shipped

The headline items:

The linter now dogfoods. CI runs lint-standards.sh against this repo on every push and fails if the tool crashes or emits malformed output. The bug that would have shipped a broken SARIF file to every consumer is now caught here first.
Secret scanning that teams won’t turn off. We ship a TruffleHog config with a documented allowlist, verification off by default, and merge-blocking on real findings. Noisy scanners get disabled; a scanner with good false-positive hygiene stays on.
Release automation. A release-drafter workflow keeps a categorized draft release current from merged PRs and auto-labels them from their commit type. The changelog stops being a manual chore.
Actions pinned to SHAs, Dependabot grouped. Every workflow now pins actions to an exact commit, and Dependabot batches the updates so they stop piling up as one-PR-per-bump.
Standards enrichment from real cross-platform work — the subject of the companion post.

There’s a satisfying symmetry to fixing your own linter’s crash by making your CI run your own linter. The repo is a little more like the thing it tells everyone else to build. That’s the whole point of doing this on a schedule.

Standards 1.2: Safe Setup

Thu, 16 Apr 2026 00:00:00 GMT

Last release was about governance and drift. This one is about a quieter promise we were breaking: installing the standards into your project should never destroy the work you’ve already done there.

The feedback that kicked off 1.2 came from a real adoption. Someone ran setup.sh against a repo that already had an AGENTS.md, a CLAUDE.md, and a CI workflow. When the dust settled, their AGENTS.md had been overwritten, the new CLAUDE.md was full of literal {{PROJECT_NAME}} tokens, configs for five agents they don’t use had been dropped into the root, and a standards-review.yml workflow had appeared without anyone asking for it. They cherry-picked out what they wanted and sent back a note: here’s what we rejected, and why.

Four problems. One underlying mistake — defaults that assumed more than they should. This release fixes all four and ties them together around a single idea: stage, don’t clobber.

One rule, applied four ways

setup.sh now routes every file it wants to write through the same gate that sync-standards has used for months: should_assemble(). If the target doesn’t exist, write it. If it exists and still matches the last assembled hash, overwrite it. If it exists and has been customized, write the new version to .standards-pending/<file> instead and leave the original alone.

The infrastructure for this wasn’t new — we’d built it for re-syncs. What was new was pointing setup.sh at it. The assembly loop is now a single function in scripts/lib/assembly.sh, shared by both scripts. First-run and re-sync are the same flow. That one change closes the “clobbered AGENTS.md” complaint completely.

Only the agents you actually use

--agents now defaults to detect. When you run setup.sh, it probes for CLAUDE.md, .cursorrules, .github/copilot-instructions.md, .gemini/GEMINI.md, AGENTS.md, .aiderrc — and only installs configs for the agents it finds. A greenfield project gets a short message listing what’s available, not six unused dotfiles.

The old “install everything, let the user delete what they don’t need” default was well-intentioned but wrong. The escape hatch is still there — --agents all if you really do want everything, or --agents claude-code,cursor for an explicit list — but the default respects what’s already in your tree.

Template variables that don’t ship

The base CLAUDE.md template has three placeholders: {{PROJECT_NAME}}, {{PROJECT_OVERVIEW}}, {{KEY_COMMANDS}}. Until this release, the assembler wrote them through as literal {{...}} tokens. If you weren’t paying attention, your repo ended up with a CLAUDE.md that greeted the next agent with # {{PROJECT_NAME}} — Claude Code Guide.

Now: {{PROJECT_NAME}} resolves from package.json, Cargo.toml, pyproject.toml, or the directory name — whichever comes first. The two content placeholders become  markers that the merge skill fills in. The shipped file never contains {{.

The workflow is opt-in

The standards-review.yml workflow is useful, but it’s also opinionated — it can conflict with a project’s existing CI. 1.2 gates its install behind --workflow. When you skip it, setup prints the one-liner to install it later. No more workflow showing up unannounced.

The handoff: MERGE_PLAN.md

Here’s where it gets interesting. When setup.sh stages anything to .standards-pending/, it also writes a MERGE_PLAN.md alongside it — a short briefing that lists the files to reconcile, the agents detected in the project, any unresolved  markers, and three ways to finish the job:

/merge-standards in Claude Code
the merge-standards command in Cursor
make merge-standards at the CLI

All three read the same MERGE_PLAN.md. The design goal is that setup.sh doesn’t finish the install — it hands a complete, agent-agnostic briefing to whichever LLM the user prefers, and that agent finishes the install against the user’s actual preferences. You pick the tool; we give it the context.

What this didn’t require

This release isn’t a rewrite. The pending-mode infrastructure already existed — sync-standards.sh had been using it for months. The 1.2 change lifts that loop into scripts/lib/assembly.sh and points setup.sh at it. Most of the new code is in four small libs (one per concern: assembly, detection, template vars, merge plan), the 17 functional tests that enforce each fix, and the docs that explain it.

Four rejections from one adoption. Four commits. Four test groups that will keep them from regressing. That’s the whole release.

Standards 1.1: Reliability and Agent Coverage

Wed, 15 Apr 2026 00:00:00 GMT

Standards 1.1 is a maintenance-and-maturity release. Most prior posts have been about adding something — a new linter, a new skill, a new framework. This release is about the layer underneath: the governance, infrastructure, and drift-prevention that make the project trustworthy as a long-running dependency. It also closes a gap that was overdue: cross-agent coordination conventions for Google Antigravity, so Missions and design-fidelity reviews work the same way whether the agent in front of you is Antigravity, Claude Code, Cursor, Aider, or Codex.

Project governance you can grep

Three files most projects don’t notice until they’re missing:

.github/CODEOWNERS — default code ownership for review routing. Aligns with proc-03 code review expectations.
.github/dependabot.yml — automated dependency updates for npm and GitHub Actions. This is distinct from the 72-hour age gate: dependabot proposes upgrades, the age gate decides whether they’re old enough to install.
A P0/P1/P2 checklist in the PR template. The security framework defined the severity model; the PR template is where reviewers and authors actually use it. One short checklist beats a 200-line standards doc no one re-reads per PR.

Why decisions are written down

docs/adr/0001-unified-standards-repository.md is the first Architecture Decision Record in the repo. It captures why the standards live in one repo per organization (rather than per-language or per-team) and what the alternatives were. ADRs aren’t documentation in the usual sense; they’re the trail of receipts for choices that later look obvious.

Two new READMEs join it: standards/README.md (a map of the directory layout and naming conventions) and bin/README.md (an overview of the gh-task CLI with links to its full guide). Neither adds anything functionally new; both compress the time-to-orient for someone landing in the repo cold.

Drift detection for the .aiderrc file

When the block-based agent config assembly shipped, every agent config file except one was migrated to it. The exception was .aiderrc — sync-standards.sh treats it as customized (its checksum diverged from the canonical template) and skipped it on every sync. The result: that file carried a 97-line inline P0/P1 security list that the rest of the project had stopped using six weeks earlier (#34).

1.1 resyncs .aiderrc to its canonical template and adds a new make doctor check — check_aiderrc_template_sync — that cmp -s compares the two files and surfaces drift before another six weeks pass. Fix is small; the generalizable lesson is bigger: when you build an assembly system, audit the files that aren’t in it.

The default Aider model also moves from claude-sonnet-4-20250514 (a dated Sonnet 4.0 preview) to the family alias claude-sonnet-4-6, which auto-tracks point releases without requiring further template churn.

Reliability fix: the standards-review action

The standards-review composite action failed to load in consumer repos with:

while scanning a simple key
could not find expected ':' (line 91, col 1)

Root cause: a Python heredoc inside a run: | block was indented at column 0. YAML’s literal block scalar terminates the moment a content line has less indentation than the block, so the parser ended the scalar at the first heredoc line and tried to interpret Python as YAML. It choked on the colon in if len(sys.argv) > 1 else "{}".

The fix moves the formatter to a sibling format-results.py invoked via ${{ github.action_path }}. The YAML stays trivial, and the Python is independently testable. Two-file change (#64).

Website surface area

The website itself caught up in this release:

A “How It Works” page covering the architecture and the standards-sync pipeline end-to-end — useful for anyone evaluating the project before adopting it.
A Security section in the sidebar, surfacing sec-01 rather than burying it under “Standards”.
The build pipeline now syncs security standards into the rendered docs automatically, so the website can’t drift from the canonical files.
The blog backfilled posts covering release history back to 0.1.

Antigravity Mission isolation

Google Antigravity groups work into Missions — long-running, agent-driven tasks scoped to a feature or fix. The problem when multiple agents touch the same project: Claude Code, Cursor, and Aider have no native concept of an active Mission, so they don’t know whether their work is in scope or scope creep.

1.1 ships a cross-agent advisory mechanism — .gemini/active_mission.log — and two helper scripts:

./scripts/mission-set.sh https://antigravity.google.com/missions/<id>   # at start
./scripts/mission-clear.sh                                              # on completion

Other agents check the log before starting work; if a Mission is active, they reference it in commits and avoid expanding scope. The full convention (feature bracketing, lifecycle, what “stale” looks like — i.e. a non-empty log more than ~7 days old) lives in proc-04 § 5, with the read protocol mirrored in GEMINI.md so every agent that consumes the standards picks it up automatically.

Alongside it, .gemini/settings.json ships a Postgres MCP entry — opt-in via POSTGRES_MCP_DATABASE_URL env var. When set, Gemini gets live schema introspection for migration and query work; when unset, the server fails to start gracefully and Gemini continues without it. make doctor warns when the entry is present but the env var is missing.

Browser-agent UI validation

Antigravity, Claude Code (via Playwright MCP), and Cursor all have browser tools that can render and screenshot a UI. Until now there was no convention for what to compare it against — agents would render, agree it looked “fine”, and merge. 1.1 introduces assets/designs/ as a per-project reference directory, plus proc-04 § 7: UI Change Validation defining the protocol:

Render via dev server or the project’s Devloop /rebuild endpoint.
Capture the rendered output with the agent’s browser tool.
Compare against assets/designs/<route-or-component>/<state>.png.

The deliberate non-default: pixel-diff is not the gate. Font rendering, anti-aliasing, and sub-pixel layout drift swamp real changes. The agent surfaces the diff (side-by-side, overlay, or per-region delta) and a written summary; a human approves whether the change matches design intent. Pixel-diff gating is opt-in for projects that want to enforce it, with thresholds documented in assets/designs/NOTES.md.

The assets/designs/ directory is opt-in per project — setup.sh doesn’t auto-create it. Projects taking on UI work add it manually and copy in templates/assets-designs-README.md.example, which documents naming conventions, common state vocabulary (default, loading, error, mobile, dark, etc.), and the cross-agent invocation table.

For agents without native browser tools (Aider, Codex), the protocol relies on the project’s Devloop GET /snapshot HTTP endpoint to normalize capture across all agents.

72-Hour Age Gate: Our Response to the Axios Supply Chain Attack

Tue, 31 Mar 2026 00:00:00 GMT

At 00:21 UTC on March 31, 2026, a compromised npm maintainer account published axios@1.14.1 – a trojaned version of the most popular JavaScript HTTP client, a package downloaded over 100 million times per week. Thirty-nine minutes later, axios@0.30.4 followed. Both versions injected a hidden dependency, plain-crypto-js@4.2.1, whose sole purpose was to drop a cross-platform remote access trojan onto developer machines (Socket, The Hacker News).

Today we are adding a mandatory 72-hour (3-day) dependency age gate to every language standard in this framework.

What Happened

The attacker compromised the npm credentials of the primary Axios maintainer, bypassing the project’s GitHub Actions CI/CD pipeline entirely (StepSecurity). According to Socket’s analysis, the malicious dependency was staged 18 hours in advance, three separate RAT payloads were pre-built for macOS, Windows, and Linux, and both release branches were hit within 39 minutes of each other (Socket).

The dropper used a dual-layer obfuscation scheme – reversed Base64 encoding plus XOR cipher – to evade static analysis (Snyk). On install, npm’s postinstall hook executed automatically, detected the developer’s OS, and downloaded a platform-specific RAT from a command-and-control server. The payloads beaconed to C2 every 60 seconds, accepting commands for arbitrary code execution, credential harvesting, SSH key exfiltration, and filesystem enumeration (Socket).

The malicious versions were live for roughly two to three hours before detection and removal. Socket’s scanner flagged the compromise within about 6 minutes, but the npm registry take-down took longer. Any npm install or CI pipeline that ran during that window – without a lockfile, or with loose version ranges – pulled the trojan automatically.

For the full breakdown, see the Malwarebytes write-up. Additional technical analysis is available from Huntress, Wiz, and SANS.

Why a 72-Hour Age Gate

The axios attack was detected and reverted within hours. Most supply chain attacks follow this pattern: a malicious version is published, the community detects it, and the registry pulls it – usually within 1-3 days. A 72-hour waiting period before adopting any new dependency version means your team never installs a package during that critical window.

This is not a novel idea. Google’s SLSA framework and the OpenSSF Scorecard project both recommend evaluating package freshness as a risk signal. We are making it a hard rule.

What the age gate catches:

Compromised maintainer accounts (like axios) – malicious versions are typically reverted within hours to days
Typosquatting packages – most are flagged and removed quickly once published
Accidental secret leaks – maintainers who publish credentials in a release and yank it

What it does not catch:

Long-lived, subtle backdoors that evade detection for weeks (these require deeper supply chain controls like reproducible builds and code review of dependencies)

What Changed in Our Standards

We updated three layers of documentation:

Core Standards (`core-standards.md`)

A new Dependency Age Gate subsection under Dependency Management:

All 3rd-party dependency versions must be at least 3 days old before adoption. Do not upgrade to or add a dependency version published less than 72 hours ago. CI should enforce age verification against the registry publish date.

Security Standards (`sec-01`, Section 5)

A new P1-severity rule under Dependency & Supply Chain Security. P1 means this is merge-blocking – CI must fail if a dependency version is younger than 3 days. The rule includes:

A registry API reference table covering PyPI, npm, crates.io, RubyGems, Maven Central, pub.dev, Swift packages, and Zig
An exception process for emergency security patches (team lead approval + documented justification + 24-hour follow-up review)

Language Standards (`lang-01` through `lang-10`)

The core language standards (lang-01 through lang-10) now include an Age Gate bullet in their Package Management sections, with the language-specific registry to check and a cross-reference to the full exception process in sec-01. Ruby on Rails (lang-11) inherits the rule from its Ruby base standard (lang-10). Remaining standards, including Go and Elixir, will adopt the same rule in their next revision.

Enforcing It in CI

The registry publish date is available via API for every major ecosystem:

# npm - check publish date of a specific version
curl -s https://registry.npmjs.org/axios | jq '.time["1.14.1"]'

# PyPI
curl -s https://pypi.org/pypi/requests/json | jq '.releases["2.31.0"][0].upload_time'

# crates.io
curl -s https://crates.io/api/v1/crates/serde/versions | jq '.versions[0].created_at'

# RubyGems
curl -s https://rubygems.org/api/v1/versions/rails.json | jq '.[0].created_at'

A CI check that compares lockfile versions against registry timestamps is straightforward to build. We recommend running it as a required status check on every PR that modifies a lockfile.

The Exception Process

Sometimes you genuinely need a fresh dependency version – typically a critical CVE fix. The exception requires:

Explicit approval from a team lead or security owner
Documented justification in the PR description explaining why the bypass is necessary
A follow-up review within 24 hours to confirm the version was not subsequently reverted or flagged

This keeps the gate meaningful without blocking legitimate emergency responses.

What You Should Do Now

If you use Coding Standards in your projects, run make sync-standards to pull the updated rules. If you maintain your own standards, consider adopting the 72-hour age gate – the axios attack demonstrated that even the most trusted packages in the ecosystem can be weaponized overnight.

For the axios incident specifically: if you ran npm install between 00:21 and ~03:29 UTC on March 31, 2026 without a committed lockfile, check whether axios@1.14.1 or axios@0.30.4 was installed. If so, assume compromise and rotate all credentials on the affected machine.

See the full rule in sec-01: Security Standards and the updated core standards.

Seven New Skills: Teaching AI Agents to Enforce Your Standards

Tue, 31 Mar 2026 00:00:00 GMT

We’ve added seven new skills to the Coding Standards framework. Each one teaches AI coding agents (Claude Code, Cursor, Copilot, and others) how to enforce a specific aspect of your standards — from security scanning to coverage thresholds to dependency age gates.

What Are Skills?

Skills are markdown files that describe a workflow an AI agent should follow. They live in standards/agents/claude-code/skills/ and contain structured instructions: when to trigger, what to check, how to report results. Think of them as runbooks that your AI assistant can execute on demand.

Unlike static linter rules, skills can reason about context. They can ask clarifying questions, combine multiple checks, and explain why something is a violation — not just that it is one.

The New Skills

1. Standards Audit

Skill: standards-audit | Issue: #49

Wraps the existing lint-standards.sh compliance linter. Runs all applicable check modules for your detected languages, parses the structured JSON output, and reports violations grouped by severity (FAIL, WARN, PASS). This is the broadest skill — it covers everything from conventional commits to banned functions to test directory structure.

Standards audit: 14 passed, 2 warnings, 1 failure out of 17 checks.

2. Security Gate

Skill: security-gate | Issue: #50

Scans your codebase for P0 and P1 security violations from sec-01. Detects banned functions (eval(), exec(), pickle.loads(), etc.) per language, finds XSS patterns (innerHTML, dangerouslySetInnerHTML), flags hardcoded secrets, and checks for weak randomness. P0 and P1 findings are merge-blocking — the skill clearly states that the PR should not merge until they’re fixed.

3. Dependency Age Gate

Skill: dependency-age-gate | Issue: #51

Born from the axios supply chain attack — this skill verifies that every dependency version in your lockfile was published at least 72 hours ago. It queries registry APIs (npm, PyPI, crates.io, RubyGems, Maven Central, pub.dev) for publish timestamps and flags anything too fresh. Includes the exception process for emergency security patches.

4. Config Assembly

Skill: config-assembly | Issue: #52

Drives the block composition system. Reads your .standards.yml, assembles agent configs from content blocks (architecture, testing, security, naming, language-specific, role-specific), and writes them to the correct output files. Respects the checksum system — customized files aren’t overwritten, they’re written to .standards-pending/ for the merge-standards skill to resolve.

5. Setup Wizard

Skill: setup-wizard | Issue: #53

Guided onboarding for new projects. Detects languages from manifest files, asks about project role and desired agents, generates a .standards.yml, runs setup with dry-run preview, and finishes with a health check. Turns a multi-step manual process into a conversation.

6. Coverage Enforcer

Skill: coverage-enforcer | Issue: #54

Enforces the layer-specific test coverage thresholds from the standards: 100% for domain/core, 95%+ for application and infrastructure, 95% minimum overall. Knows which coverage tool to use per language (coverage.py, c8, simplecov, tarpaulin, JaCoCo) and can break down coverage by architecture layer. Also checks test naming conventions and file mirroring.

7. Naming Convention

Skill: naming-convention | Issue: #55

Lints identifiers against the language-specific naming rules: snake_case for Python, camelCase for JavaScript, PascalCase for Go exports, ? predicates for Ruby, and so on across all 13 supported languages. Uses grep patterns for quick scans and delegates to language-specific linters (ruff, eslint, rubocop, clippy) for deeper analysis.

Existing Skill: Merge Standards

The previously released merge-standards skill (#56) already handles the pending merge workflow — intelligently merging upstream standards updates into customized agent configs while preserving project-specific content.

How They Work Together

The skills form a pipeline that covers the full lifecycle:

setup-wizard onboards the project
config-assembly generates agent configs
standards-audit checks overall compliance
security-gate enforces P0/P1 rules
dependency-age-gate validates supply chain safety
coverage-enforcer verifies test coverage by layer
naming-convention catches identifier inconsistencies
merge-standards keeps configs current as standards evolve

Each skill is self-contained — use any one independently or chain them in CI.

Try It

Update your standards submodule:

make sync-standards

The new skills are available immediately to any agent with access to the .standards/ directory. In Claude Code, reference them by name — for example, “run the standards-audit skill” or “check the dependency age gate.”

See all skills in standards/agents/claude-code/skills/.

Automated Standards Review on Every Pull Request

Wed, 25 Mar 2026 00:00:00 GMT

The standards compliance linter shipped in Phase 2 can now run automatically on every pull request and post its findings as a structured comment — without any manual CI configuration from your team. Phase 3 ships the standards-review composite GitHub Action and installs the workflow into consumer projects during setup.

What gets checked

The PR review bot runs the full lint-standards.sh suite on every pull request. That includes:

Conventional Commits — verifies recent commit messages match type(scope): subject format.
Test directory — confirms a non-empty tests/, spec/, or __tests__/ directory exists.
Secret detection — scans source files for AWS keys, private key blocks, and hardcoded passwords.
Coverage configuration — checks that a coverage threshold is declared in CI or .standards.yml.
Language-specific checks — type annotations, banned functions, linter configs — activated by your .standards.yml language list.

See the linter blog post for the full check catalogue.

What it looks like on a PR

When the action runs it posts a comment with a summary line and a table of results:

## Standards Review

:x: 1 failure(s) found

| Status | Check | Details |
|--------|-------|---------|
| :white_check_mark: PASS | conventional-commits | All recent commits follow Conventional Commits format |
| :white_check_mark: PASS | no-secrets | No hardcoded secrets detected |
| :warning: WARN | test-directory | Test directory found but appears empty |
| :x: FAIL | python/banned-functions | eval() usage detected in src/utils.py |
| :white_check_mark: PASS | python/ruff-config | [tool.ruff] section configured in pyproject.toml |

---
*Generated by Coding Standards linter*

If any check returns FAIL, the action exits with a non-zero code and the workflow step is marked as failed — blocking merge when branch protection is configured.

How to install

Automatic (via setup.sh)

Running make setup (or the one-line curl installer) now copies the workflow template automatically:

curl -fsSL https://raw.githubusercontent.com/c65llc/coding-standards/main/install.sh | bash

This places .github/workflows/standards-review.yml in your project on first setup. The workflow references the composite action from the .standards/ submodule, so it stays in sync with the rest of your standards configuration.

Manual

Copy the template from the standards repository:

cp .standards/templates/standards-review.yml.example .github/workflows/standards-review.yml

Then grant the workflow permission to comment on pull requests by ensuring your repository’s Settings > Actions > General > Workflow permissions allows pull requests write access, or rely on the permissions block already present in the template.

SARIF integration for GitHub Code Scanning

The linter also supports --format sarif output (SARIF 2.1.0). You can extend the workflow to upload results to GitHub Code Scanning, which surfaces violations as inline annotations directly on the diff:

- name: Run standards linter (SARIF)
  run: |
    .standards/scripts/lint-standards.sh --format sarif > standards.sarif || true

- name: Upload SARIF to Code Scanning
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: standards.sarif

SARIF maps WARN checks to warning level and FAIL checks to error level in the Code Scanning UI. PASS results are omitted to keep the annotation list focused.

What’s next

Phase 4 adds --dry-run support and a make diff-standards target so you can preview what a standards sync would change before applying it.

Declarative Config and make doctor: Phase 1 of Standards Tooling

Wed, 25 Mar 2026 00:00:00 GMT

Two new additions land in Phase 1 of our standards tooling roadmap: .standards.yml — a declarative configuration file that replaces the old shell-variable-based approach — and make doctor, a health check command that audits your project’s standards setup and tells you exactly what to fix.

.standards.yml: Declarative Standards Configuration

Previously, consumer projects configured standards through a .standards-config file using KEY=value shell variables. It worked, but it was limited: no schema, no version field, no way to express nested settings like coverage thresholds.

.standards.yml replaces that with a proper YAML config:

# .standards.yml — Project standards configuration
version: 1

languages:
  - python
  - typescript

agents:
  - claude-code
  - cursor
  - copilot

role: service

coverage:
  minimum: 95
  domain: 100

architecture: clean
security: strict

What each field controls

Field	Purpose
`version`	Config schema version — enables forward-compatible migrations
`languages`	Which language standards to load during assembly
`agents`	Which AI agents get config files during setup and sync
`role`	Project type — `service`, `library`, `app`, or `data-pipeline`
`coverage.minimum`	Overall test coverage floor (%)
`coverage.domain`	Domain-layer coverage requirement (%)
`architecture`	`clean` enforces Clean Architecture; `none` removes constraints
`security`	`strict` makes P0/P1 merge-blocking; `moderate` warns on P1

The setup.sh script generates .standards.yml automatically during installation using language detection. You can edit it afterward to adjust agents, coverage thresholds, or architecture mode. sync-standards.sh reads it on every run to assemble only the configs you need.

The legacy .standards-config format remains supported for backward compatibility — make doctor will warn you if you’re on the old format.

make doctor: Standards Health Check

make doctor runs a seven-point audit of your project’s standards setup and produces a scored report:

Standards Health Check
=======================================

  ✅ PASS  Configuration          .standards.yml found (version 1)
  ✅ PASS  Claude Code            CLAUDE.md present
  ✅ PASS  Cursor                 .cursorrules present
  ⚠️  WARN  Copilot               .github/copilot-instructions.md missing
  ✅ PASS  Checksums              All config checksums match
  ⚠️  WARN  Languages             Detected 'go' not in .standards.yml
  ✅ PASS  Submodule              .standards/ is a valid git repo
  ❌ FAIL  Git Hooks              post-merge hook not installed
  ✅ PASS  Gitignore              All required entries present

=======================================
  Score: 6/9 (67%)

  Fixes needed:
    -> Run: make setup-agents  (to install missing Copilot config)
    -> Add: 'go' to .standards.yml languages list
    -> Run: make setup  (to install git hooks for automatic standards sync)

What it checks

Configuration — .standards.yml exists (or legacy .standards-config)
Agent files — each agent declared in config has its expected file on disk
Checksums — .standards-checksums exists and config hashes match stored values, detecting unauthorized edits
Languages — runs detect-languages.sh and compares against declared languages, flagging gaps
Submodule — .standards/ is a valid initialized git repo (skipped when running in the standards repo itself)
Git hooks — .git/hooks/post-merge exists and references standards sync
Gitignore — .gitignore contains .standards-pending/ and *.pre-standards-setup

Every warning and failure includes a concrete fix command so you know exactly what to run.

Try It

Update your standards submodule and run the health check:

cd .standards && git pull origin main && cd ..
make doctor

If you haven’t installed standards yet:

curl -fsSL https://raw.githubusercontent.com/c65llc/coding-standards/main/install.sh | bash
make doctor

A perfect score means your project is fully configured, checksums are clean, and automatic sync is in place via git hooks.

Preview Before You Commit: --dry-run and make diff-standards

Wed, 25 Mar 2026 00:00:00 GMT

Phase 4 of the standards tooling roadmap adds two preview capabilities that let you see exactly what setup and sync-standards would change before a single file is modified.

The problem: trust during team rollouts

When you run make setup or make sync-standards in an existing project, files get written. For a solo developer that is usually fine, but for a team rollout — or any project with carefully tuned AI agent configs — you want to review changes before committing to them. The new --dry-run flag and make diff-standards target solve this.

–dry-run for setup and sync

Both scripts/setup.sh and scripts/sync-standards.sh now accept a --dry-run flag. When active, no files are created, modified, or deleted. Instead, each write operation prints a [dry-run] line describing what would have happened.

$ ./scripts/setup.sh --dry-run

🔍 DRY RUN — showing what would change (no files modified)

📝 Assembling claude-code config...
  [dry-run] Would write: /project/CLAUDE.md
✅ claude-code config (dry-run)
📝 Assembling cursor config...
  [dry-run] Would write: /project/.cursorrules
✅ cursor config (dry-run)
  [dry-run] Would write: /project/.standards.yml
  [dry-run] Would write: /project/.git/hooks/post-merge
  [dry-run] Would append to: /project/.gitignore

Nothing was written. You can now review the list and decide whether to proceed.

The same flag works for sync:

$ ./scripts/sync-standards.sh --dry-run

🔍 DRY RUN — showing what would change (no files modified)

  [dry-run] Would pull latest standards (submodule has updates)
  [dry-run] Would re-assemble: /project/CLAUDE.md
  [dry-run] Would re-assemble: /project/.cursorrules
  [dry-run] Would create: /project/.gemini/GEMINI.md

make diff-standards: line-level preview

--dry-run tells you which files would change. make diff-standards tells you exactly what would change inside each file. It assembles every declared agent config to a temp file, diffs it against the installed version, and prints color-coded output.

$ make diff-standards

Standards Diff
=======================================

→ claude-code  (CLAUDE.md)
  ~ Changes: +12/-3 lines
--- CLAUDE.md
+++ (assembled)
@@ -45,7 +45,7 @@
...

→ cursor  (.cursorrules)
  ✅ Up to date

→ copilot  (copilot-instructions.md)
  + Would create: .github/copilot-instructions.md

=======================================
  Summary: 1 up to date  1 would change  1 new

Run make sync-standards to apply changes.

No temp files are left behind. If everything is up to date you see only checkmarks.

Recommended workflow for team rollouts

make diff-standards — review what would change across all agents
./scripts/sync-standards.sh --dry-run — confirm the list of write operations
make sync-standards — apply once you are satisfied
Commit the updated agent configs in a single PR for team review

This workflow is especially useful when pulling a new version of the standards submodule: diff first, sync second, never surprise your teammates.

Standards Compliance Linter: Enforce Your Standards in CI

Wed, 25 Mar 2026 00:00:00 GMT

Phase 2 of the standards tooling roadmap ships make lint-standards — a multi-language compliance linter that checks your project against coding standards and reports results in text, JSON, or SARIF format for GitHub Code Scanning integration.

What it checks

The linter is organized into two tiers: common checks that run on every project, and language-specific checks that activate based on your .standards.yml configuration.

Common checks (all projects)

Check	What it verifies
`conventional-commits`	Last 10 git commits match `type(scope): subject` pattern
`test-directory`	A `tests/`, `test/`, `spec/`, or `__tests__/` directory exists and is non-empty
`no-secrets`	No AWS keys, private key blocks, or hardcoded passwords/API keys in source files
`coverage-config`	CI workflows, jest config, pytest config, or `.standards.yml` declare a coverage threshold

Python checks

Check	What it verifies
`python/type-annotations`	mypy is configured; WARN if not in strict mode, FAIL if not configured at all
`python/banned-functions`	No `eval()`, `exec()`, `pickle.loads()`, `os.system()`, or `subprocess` with `shell=True`
`python/ruff-config`	`ruff.toml`, `.ruff.toml`, or `[tool.ruff]` in `pyproject.toml`

TypeScript / JavaScript checks

Check	What it verifies
`typescript/strict-tsconfig`	`"strict": true` in `tsconfig.json`
`typescript/banned-functions`	No `eval()`, `new Function()`, `.innerHTML =`, `document.write()`, or `setTimeout` with string literal
`typescript/eslint-config`	An `.eslintrc`, `eslint.config.`, or `eslintConfig` in `package.json`

Go checks

Check	What it verifies
`go/golangci-config`	`.golangci.yml`, `.golangci.yaml`, or `.golangci.toml` present
`go/error-handling`	No bare `_ =` or `, _ :=` patterns that discard return values (likely errors)

Elixir checks

Check	What it verifies
`elixir/credo-config`	`:credo` in `mix.exs` dependencies
`elixir/dialyzer-config`	`:dialyxir` in `mix.exs` dependencies

Plugin architecture

Each check is a standalone bash script in scripts/lint-checks/<language>/. The interface is minimal: receive the project root as $1, print one line (PASS|WARN|FAIL <check-name> <message>), exit with 0, 1, or 2. Adding a new check is as simple as dropping a new script in the right directory — the orchestrator discovers it automatically.

The orchestrator (scripts/lint-standards.sh) reads .standards.yml to determine which language-specific check directories to activate. Common checks always run.

Output formats

Text (default)

🔎 Standards Compliance Check
═══════════════════════════════════════

  ✅ PASS  conventional-commits    All recent commits follow Conventional Commits format
  ⚠️  WARN  test-directory         Test directory found but appears empty
  ✅ PASS  no-secrets              No hardcoded secrets detected
  ✅ PASS  coverage-config         Coverage gate found in .standards.yml (minimum: 95%)
  ✅ PASS  python/type-annotations mypy strict mode enabled in pyproject.toml
  ❌ FAIL  python/banned-functions eval() at src/utils.py:42
  ✅ PASS  python/ruff-config      [tool.ruff] section configured in pyproject.toml

═══════════════════════════════════════
  Results: 5 pass, 1 warn, 1 fail

JSON

./scripts/lint-standards.sh --format json

Produces a structured JSON object with summary counts and a results array — suitable for parsing in scripts, dashboards, or custom reporters.

SARIF (GitHub Code Scanning)

./scripts/lint-standards.sh --format sarif > results.sarif

SARIF 2.1.0 output maps WARN to warning and FAIL to error. Upload to GitHub Code Scanning to get inline annotations on pull requests:

- name: Run standards linter
  run: ./scripts/lint-standards.sh --format sarif > standards.sarif || true

- name: Upload SARIF
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: standards.sarif

How to run

make lint-standards

Or directly with a format flag:

./scripts/lint-standards.sh --format json
./scripts/lint-standards.sh --format sarif

The linter exits with code 1 if any checks fail, making it CI-friendly as a blocking gate.

Adding your own checks

Drop a new executable *.sh script in scripts/lint-checks/common/ or scripts/lint-checks/<language>/. Follow the one-line output contract and the orchestrator picks it up automatically on the next run. Run make test-scripts to validate syntax before committing.

Token-Efficient Agent Configs: 60% Smaller, Zero Traversal

Wed, 25 Mar 2026 00:00:00 GMT

AI coding agents are only as good as the context they’re given. Until now, our agent configs pointed agents into the standards submodule — references like “See standards/languages/lang-01_python_standards.md” meant a diligent agent might read 800-1,200+ lines of documentation per session, much of it irrelevant to the project at hand. A Python web service doesn’t need Rust, Swift, or Dart standards taking up context window space.

We’ve rebuilt the entire agent configuration system around a simple idea: assemble one self-contained config per agent at setup time, with only the content that project actually needs.

How It Works

The setup script now assembles agent configs from three ingredients:

Base template (~25-40 lines) — agent-specific behavioral rules. Cursor gets interaction modes and custom commands. Gemini gets the A-P-E workflow. Aider gets diff mode guidance. Each agent gets only what’s unique to how it works.
Content blocks (~5-20 lines each) — atomic summaries of standards, stored in standards/shared/blocks/. Six common blocks (architecture, testing, security, naming, git, documentation) are always included. Language and role blocks are selected based on detection.
Language + role filtering — detect-languages.sh identifies your project’s languages (13 supported, including Go and Elixir, with TypeScript, Rails, Java, and Kotlin sub-detection). You pick a project role (--role service|library|app|data-pipeline). Only relevant blocks are included.

The result: a Python/TypeScript web service gets a ~130-line CLAUDE.md with everything the agent needs — no submodule traversal required.

What Changed

Before	After
Agent reads 329-line config + traverses into 800+ lines of standards docs	Agent reads one ~130-line self-contained file
All 13 language standards included regardless of project	Only detected languages included
Security rules duplicated across 6 agent configs	Single `security-summary.md` block assembled into each
No `.cursorrules` template for consumer projects	Full Cursor template with assembly support
Codex used obsolete `.codexrc` format	Migrated to `AGENTS.md` (current OpenAI Codex CLI)

Standards Cleanup

We also deduplicated the standards docs themselves:

arch-01 reduced from 253 to ~30 lines (Sections 2-10 were verbatim copies of core-standards.md)
arch-03 deleted entirely — content distributed to the Cursor base template and proc-04
Banned-functions lists removed from 8 language docs (now single source in sec-01)
Git aliases catalog extracted from proc-02 to a standalone reference doc

All Six Agents Supported

Every agent gets a purpose-built base template with platform-specific best practices:

Claude Code — worktree conventions, key commands structure
Cursor — @new-feature/@refactor/@debug/@review modes, condensed custom commands
GitHub Copilot — /explain, /fix, /tests guidance, code review behavior
Gemini CLI — Analyze-Plan-Execute workflow, checkpointing
Aider — two-file model (.aiderrc + .aider-instructions.md), diff mode guidance
Codex — new AGENTS.md format with sandbox awareness

Smart Sync: Customizations Survive Updates

A common worry with generated configs: what happens when you improve your CLAUDE.md with /claude-md-improver or add project-specific conventions, then sync pulls new standards? Before, your changes would be overwritten.

Now, sync-standards uses checksum-based detection. After assembling a config, the setup script records a SHA256 hash of the standards content. On the next sync, if the hash doesn’t match — meaning you’ve customized the file — the sync skips that file and stages the update to .standards-pending/ instead.

To merge the pending update:

Claude Code: Run /merge-standards — an included skill that reads both versions, merges section-by-section (updating standards rules while preserving your additions), and shows a diff for approval.
Any other agent: Point it to .standards/docs/reference/merge-standards-prompt.md — the same merge instructions in a format any agent can follow.

This works for all six agent configs, not just CLAUDE.md. Customize your .cursorrules or GEMINI.md and they’ll be protected too.

Try It

Existing projects can pick up the new system by syncing their standards submodule:

cd .standards && git pull
./scripts/setup.sh --role service

The setup script detects your languages, assembles configs for all detected agents, and saves your selections to .standards-config for reproducible syncs.

New projects get this automatically via the standard install process.

Eating Our Own Dogfood: A Compliance Audit

Wed, 04 Mar 2026 00:00:00 GMT

A coding standards repo that doesn’t follow its own standards is a bad look. We ran a compliance audit and fixed every gap we found.

What We Found

Our standards require several things that the repo itself was missing:

proc-03 (Code Review) requires a CODEOWNERS file — we didn’t have one
sec-01 (Security) requires dependency scanning — no dependabot.yml
proc-01 (Documentation) requires an ADR directory and README per package — missing for standards/, bin/, and the ADR directory entirely
sec-01 defines a P0/P1/P2 severity model — but our PR template had no security checklist
Security standards existed but weren’t synced to the website or shown in the sidebar

What We Fixed

New files:

.github/CODEOWNERS — all paths default to @c65llc
.github/dependabot.yml — weekly scans for npm (website) and GitHub Actions
docs/adr/0001-unified-standards-repository.md — documents the foundational decision
standards/README.md and bin/README.md — package-level documentation

Modified files:

PR template now includes P0/P1/P2 security checkboxes
Website sync script copies security standards with frontmatter injection
Astro sidebar includes a Security section under Standards
CHANGELOG.md restructured from one giant “Unreleased” block into proper versioned sections (0.1.0 through 0.5.0)

The Blog, Too

While we were at it, we noticed the blog had exactly one post. A project that ships security frameworks, adds two languages, builds a CI-tested bootstrap system, and then audits itself for compliance has more than one thing to say. So we added four posts covering the release history.

Takeaway

If you maintain standards, audit yourself first. It’s the fastest way to find gaps in your own documentation — and it builds credibility with the teams you’re asking to follow those standards.

Language-Aware Bootstrap for Claude Code

Tue, 03 Mar 2026 00:00:00 GMT

The setup script now detects your project’s languages and generates a tailored Claude Code settings.json — no manual configuration needed.

How It Works

When you run setup.sh, the bootstrap system:

Scans your project for language markers — *.py, Gemfile, package.json, Cargo.toml, *.swift, etc.
Maps languages to tools — Python projects get ruff, pytest, mypy; Ruby projects get rubocop, rspec, brakeman; TypeScript gets eslint, vitest, tsc.
Generates settings.json with the appropriate allowedTools configuration for Claude Code.

The result: Claude Code can run your project’s linters, test runners, and formatters without you having to manually allowlist each tool.

Template-Driven

The generation uses a base template with language-specific tool blocks injected dynamically. This means the core settings (permissions, MCP servers, etc.) stay consistent while tool access adapts to the project.

CI Test Infrastructure

We added functional tests that validate the bootstrap pipeline:

Language detection tests — verify that each file type maps to the correct language
Settings generation tests — confirm the output JSON is valid and contains expected tool entries
Round-trip tests — run setup on mock projects and validate the generated config

These run in CI on every PR that touches the setup scripts.

Try It

Update your standards submodule and re-run setup:

cd .standards && git pull origin main && cd ..
make setup

Your settings.json will be regenerated with language-appropriate tooling.

P0-P2 Security Standards: Severity-Driven Code Review

Tue, 03 Mar 2026 00:00:00 GMT

We’ve added a comprehensive security standards framework to Coding Standards, built around a severity model that makes security findings actionable in code review.

The P0-P2 Model

Not all security issues are equal. Our framework assigns every rule a severity level:

P0 (Critical) — SQL injection, command injection, hardcoded secrets. These block merge immediately.
P1 (High) — Missing auth checks, insecure deserialization, XSS. Also merge-blocking.
P2 (Medium) — Missing rate limiting, verbose error messages, weak TLS config. Flagged as warnings.

This gives reviewers a clear decision framework: P0/P1 means “stop and fix,” P2 means “track and address.”

Eight Security Categories

The standard covers eight areas:

Injection Prevention — SQL, command, XSS, SSRF, template injection
Authentication & Authorization — session management, access control
Secrets Management — hardcoded credential detection, vault usage
Dangerous Functions — eval(), exec(), insecure deserialization
Dependency Security — CVE scanning, lock files, supply chain
Configuration Security — TLS, security headers, debug mode
Data Protection — PII in logs, encryption at rest/in transit
SAST Tooling — per-language static analysis and dependency scanning

Language-Specific Tooling

Every language standard now includes a security section with recommended SAST tools. For example:

Language	SAST	Dependency Scanner
Python	Bandit, Semgrep	pip-audit, Safety
Ruby	Brakeman	bundler-audit
TypeScript	ESLint security plugins	npm audit
Rust	cargo-audit	cargo-deny

Integrated Everywhere

Security rules are baked into every AI agent config — Cursor, Copilot, Claude Code, Codex, and Gemini all reference the same P0-P2 model. The code review standard (proc-03) includes a security checklist, and the PR template now has P0/P1/P2 checkboxes.

See the full standard at sec-01: Security Standards.

Ruby and Rails Standards: Language 10

Tue, 03 Mar 2026 00:00:00 GMT

Coding Standards now covers 10 languages with the addition of Ruby (including Rails-specific standards).

What’s New

Ruby standards (lang-10) cover idiomatic Ruby patterns: method naming, block usage, exception handling, Sorbet/RBS typing, and RuboCop configuration. The standard follows community conventions — snake_case methods, ? and ! suffixes, frozen string literals.

Ruby on Rails standards (lang-11) complement the base Ruby standard and address Rails-specific patterns: Active Record best practices, controller/service object boundaries, view helpers vs. presenters, Action Cable conventions, and Rails security (strong parameters, CSRF, SQL injection via Active Record).

Both standards include security sections with Brakeman for SAST and bundler-audit for dependency scanning.

File Numbering Restructure

Adding Ruby required renumbering some existing standards to maintain alphabetical ordering within the lang-XX prefix scheme. The restructure keeps the numbering consistent and leaves room for future additions.

Coverage

With Ruby and Rails, the framework now covers:

Python, Java, Kotlin, Swift, Dart, TypeScript, JavaScript, Rust, Zig, Ruby/Rails

All 10 language standards share the same structure: naming conventions, architecture patterns, testing requirements, error handling, and a security section referencing the P0-P2 severity model.

See the standards: Ruby | Ruby on Rails

Introducing Coding Standards: One Framework, Every AI Agent

Mon, 02 Mar 2026 00:00:00 GMT

We’re excited to announce the public release of Coding Standards — a unified framework that keeps every AI coding assistant on the same page.

The Problem

Development teams today use multiple AI coding tools: Cursor, GitHub Copilot, Claude Code, OpenAI Codex, Gemini CLI. Each tool needs its own configuration, and without a shared source of truth, they generate inconsistent code.

The Solution

Coding Standards provides a single repository of standards — covering 9 programming languages, Clean Architecture patterns, and development processes — that automatically syncs to every AI agent in your workflow.

Install it in seconds:

curl -fsSL https://raw.githubusercontent.com/c65llc/coding-standards/main/install.sh | bash

What’s Included

9 language standards: Python, Java, Kotlin, Swift, Dart, TypeScript, JavaScript, Rust, Zig
5 AI agent configs: Cursor, Copilot, Claude Code/Aider, Codex, Gemini CLI
Architecture standards: Clean Architecture, SOLID principles, and more
Process standards: Git workflow, documentation, code review
Automation: One-command setup, auto-syncing git hooks, Make targets

Get Started

Check out the Quick Start guide to get up and running in 5 minutes, learn how it works under the hood, or browse the full documentation for all installation options.

We welcome feedback via GitHub Issues. If these standards don’t fit your team perfectly, fork the repo and customize them.

Coding Standards | Blog

A Green Pipeline Is Not Proof

A green release that never reached production

A stale tab that bricked every new one

Drift a warm build refused to show

The one that fails in seconds vs. the one that waits

Why these belong in the standards

Standards 1.5: The Audit Sweep

The shape of the drift

Batching the fix

What actually shipped

Standards 1.2: Safe Setup

One rule, applied four ways

Only the agents you actually use

Template variables that don’t ship

The workflow is opt-in

The handoff: MERGE_PLAN.md

What this didn’t require

Standards 1.1: Reliability and Agent Coverage

Project governance you can grep

Why decisions are written down

Drift detection for the .aiderrc file

Reliability fix: the standards-review action

Website surface area

Antigravity Mission isolation

Browser-agent UI validation

72-Hour Age Gate: Our Response to the Axios Supply Chain Attack

What Happened

Why a 72-Hour Age Gate

What Changed in Our Standards

Core Standards (core-standards.md)

Security Standards (sec-01, Section 5)

Language Standards (lang-01 through lang-10)

Enforcing It in CI

The Exception Process

What You Should Do Now

Seven New Skills: Teaching AI Agents to Enforce Your Standards

What Are Skills?

The New Skills

1. Standards Audit

2. Security Gate

3. Dependency Age Gate

4. Config Assembly

5. Setup Wizard

6. Coverage Enforcer

7. Naming Convention

Existing Skill: Merge Standards

How They Work Together

Try It

Automated Standards Review on Every Pull Request

What gets checked

What it looks like on a PR

How to install

Automatic (via setup.sh)

Manual

SARIF integration for GitHub Code Scanning

What’s next

Declarative Config and make doctor: Phase 1 of Standards Tooling

.standards.yml: Declarative Standards Configuration

What each field controls

make doctor: Standards Health Check

What it checks

Try It

Preview Before You Commit: --dry-run and make diff-standards

The problem: trust during team rollouts

–dry-run for setup and sync

make diff-standards: line-level preview

Recommended workflow for team rollouts

Standards Compliance Linter: Enforce Your Standards in CI

What it checks

Common checks (all projects)

Python checks

TypeScript / JavaScript checks

Go checks

Elixir checks

Plugin architecture

Output formats

Text (default)

JSON

SARIF (GitHub Code Scanning)

Core Standards (`core-standards.md`)

Security Standards (`sec-01`, Section 5)

Language Standards (`lang-01` through `lang-10`)