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 issue templates (bug, feature, design, infrastructure, security, contribution) with Given/When/Then scenarios, unit and E2E test specs, personal-data handling and a security checklist, 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 most components are registered by enabling the plugin group they live in, and only the ones that need a project-specific copy (project-scoped components, hooks, or a bare clone with no marketplace) are rewritten against the profile and installed 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, split into seven plugin groups. Registered components update with the plugin and own no file in the consuming repo. Adapted copies carry a per-component version marker, and forge-adapt drift compares those markers against the library to report what has fallen behind, writing nothing. forge-adapt refresh <name> then merges in what one component is missing while preserving the project-specific adaptation.

The ticket-gate agent decides whether an issue is ready to implement before code is written. A set of specialist lenses (security, architecture, testing, personal-data handling) each read the ticket, and the verdict is PASS, NEEDS-WORK or BLOCKED with a concrete list of what must change, never a numeric score.