forge-kit

The problem

Most project governance is too generic to do any work. Issue templates ask abstract questions, security checklists name OWASP categories but never the actual endpoints in your code, and a dropped-in code-reviewer agent gives a Rails app the same advice it gives a Rust library. Hand-tailoring governance per project fixes that, but it is slow and falls out of date the moment the codebase moves.

I wanted governance that is specific. “Check for SQL injection” should become “check for Prisma $queryRaw injection in src/db/” before it ever lands in the repository. That only works if the tooling reads the project first.

How I built it

forge-kit is split into two deliberately separable layers.

The governance layer works without any AI tool. It ships six v4 issue templates with Given/When/Then scenarios, unit and E2E test specs, and GDPR and security checklists, plus a GitHub label taxonomy. A team on Cursor, Copilot, or no AI CLI can copy .github/ISSUE_TEMPLATE/ and labels.yml and get value immediately.

The automation layer is Claude Code-native. forge-adapt is the skill that bridges the library and a target project. It reads the stack files, CLAUDE.md, source tree, and existing .claude/ contents to build a project profile, cross-references that profile against the forge-kit library, ranks components by relevance, and waits for approval. Nothing is written until you choose. Then Claude rewrites each selected component against the profile and installs it into .claude/.

I kept approval as an explicit gate because the whole point is trust: adapted output is only useful if the developer reviews what gets generated rather than accepting a silent install.

Architecture

The library lives in its own repository. Each consuming project gets a customised local copy under its own .claude/, so two projects that install the same component end up with different files. forge-adapt auto-updates by checking blob SHAs against the GitHub remote, which means library improvements propagate without a manual sync step, and Phase 4 of a run flags any installed component that has drifted from the reference.

The ticket-gate agent enforces a quality bar on every GitHub issue before code is written. Five core specialists (security, architect, developer, QA, GDPR) each score the ticket, and all must reach 10 for the gate to pass. Tickets filed against an older template are auto-upgraded to v4 with synthesised GWT scenarios and test specs, so the gate works retroactively without manual rework.