development-standards

name	development-standards
description	Org-internal engineering standards. Invoke when scaffolding a repo, auditing one, setting up CI, or configuring `Cargo.toml`, `rust-toolchain.toml`, `justfile`, `.editorconfig`, `.markdownlint-cli2.yaml`, `tsconfig.json`, `package.json`, `pnpm-lock.yaml`, `bunfig.toml`, `pyproject.toml`, `uv.lock`, `.python-version`, `lefthook.yml`, or `*.tf`. Also for `axum`, `utoipa`, `async-graphql`, `markdownlint-cli2`, `uv`, `ruff`, `pyright`, `pytest`, `eslint`, `prettier`, or Node package-manager setup (pnpm is the org default). Fully documented: Rust (workspace inheritance, MSRV, `just`, coverage, test tiers, Axum+utoipa, published-crate conventions, async-graphql), Python (uv workspaces, `src` layout, ruff, pyright strict, pytest tiers), TypeScript/Node (tsconfig, project references, npm scripts), Terraform (workspaces, backend, naming). Only Bun is a stub — invoke anyway so the user defines the convention rather than getting an improvised one.
license	MIT
metadata	{"author":"Ikuma Yamashita","version":"0.5.0"}

Development Standards

Org-internal engineering standards. This file is a router — load the reference that matches the task, not the whole tree.

Routing

Cross-cutting — references/general/

File	When to read
git-repository.md	New repo setup, configuring .editorconfig, markdownlint-cli2, pnpm as the default package manager, lefthook git hooks (file-list template convention, Claude Code PostToolUse integration), baseline layout, editor recommendations.

Commit-message conventions live in the separate conventional-commits skill — defer there, not here.

Rust — references/rust/

File	When to read
general.md	Any Rust project: workspace inheritance, rust-toolchain.toml, just recipes, cargo-llvm-cov, integration test tiers.
web-openapi.md	HTTP API with axum + utoipa: OpenApiRouter, Controller/UseCase/Repository layering, ToSchema DTOs, error mapping, Swagger UI.
web-graphql.md	HTTP API with async-graphql: schema composition, Repository/Service/Resolver layering, ComplexObject lazy fields. Superseded by web-openapi.md for new work — read the status note at the top.
library.md	Publishable crates: multi-crate SDK layout, proc-macro crate splits, versioning/release conventions, readonly/mutable test tiers, gaps to close (docs.rs metadata, sealed traits, semver checks).

Python — references/python/

File	When to read
general.md	Any Python project: uv workspaces, .python-version pinning, packaged src layout, ruff, pyright strict, stdlib logging, pytest hermetic/live tiers, just recipes.

TypeScript — references/typescript/

File	When to read
general.md	Any TypeScript project: tsconfig.json baseline, project references for multi-context packages, inline type-only imports, ESLint/Prettier/Stylelint.

Node.js — references/nodejs/

File	When to read
general.md	Any Node project: dot-namespaced package.json scripts, engines policy, OpenAPI-to-TypeScript client generation, CI shape.

Terraform — references/terraform/

File	When to read
general.md	Any Terraform config: flat file-per-resource layout, S3/Terraform-Cloud backend choice, workspace-based environments, naming, GitHub-as-Terraform.

Planned but unwritten

Section	Status
references/bun/	Stub — not yet documented.

Handling stubbed sections

The user invoked this skill expecting org conventions. If the matching reference is a stub, do not improvise an org standard — that risks laundering a one-off decision into apparent policy. Instead:

1. Tell the user the section is not yet documented.
2. Look for a de facto convention in the current repo or in sibling projects the user has open. If found, propose it and ask whether to adopt it as the standard.
3. If no convention exists, offer a recommendation based on general engineering judgment, label it clearly as a suggestion (not policy), and offer to write it up into the stub once the user decides.

When NOT to invoke

• General programming or library tutorials — use language- or library- specific skills (mcp-knowledge, ag-ui-knowledge, rust-toasty, conventional-commits) or upstream docs.
• Debugging business logic.
• Reviewing changes that do not touch tooling, project layout, or the architectural seams covered in references/.