Project Standard: the house standard, in one command

In most teams the standard exists. It lives in people's heads, in an old repo somebody copies, in the review of whoever has the eye for it. It never quite survives into the next project.

Project Standard is our attempt to make it something other than oral culture: a Claude Code plugin that installs, configures and audits the standard on any repository, new or already running.

The standard is cut into modules that can be installed separately. Quality gates in continuous integration — secret scan, lint, typecheck, format, tests, build — on every pull request. Local hooks, so the same bar applies before the commit is even made. Project skills, covering release, audit, specification and ticket intake.

Then the Atlassian wiring, with a Jira board and a Confluence tree for requirements, decisions and architecture. Ferry, for agent automation. The branch and release model. And infrastructure: deploy target, transactional mail, secrets doctrine.

None of it is original taken one at a time. What is original is refusing to make those choices again at every kickoff.

A tool that installs itself onto an existing repository can do a lot of damage. So this one starts by writing nothing: it interviews you, then produces a read-only gap analysis, module by module — missing, present, or drifted from the standard.

The install plan that follows waits for one explicit confirmation before writing anything at all. On an already compliant repository, running the command again does nothing but audit.

That is what makes the tool usable on a live project rather than only on an empty repo.

The repository is public, which imposes a strict discipline on what it can hold. It documents where secrets live and what they are called — never their values, which stay in GitHub secrets, server environment files and provider portals.

It carries no infrastructure coordinates either: no hostname, no address, no client identity. Every deploy target is a placeholder the setup interview fills in from your own environment.

That constraint cost real work, and it is what makes the standard shareable. A standard you cannot publish is just one more private configuration.

The standard was not designed in the abstract: it is distilled from two production projects, a Next.js client website and an AI support agent. The first supplied the quality gates and the skills, the second the agent automation and the infrastructure.

That is also its limit, and it is worth saying: this standard is ours. It encodes our trade-offs, not universal truths. It is published under the MIT licence to be read, reused and argued with — not to be applied as-is by someone who has not made the same choices.