The Repository as the Nerve Center

Form Factory’s philosophy on using per-project repositories — with Claude Code, skills, MCP connections, and claude.md — as the shared working interface for all disciplines. The core insight: context that lives in the repo compounds over time, while context trapped in isolated conversations is lost.

The Problem: Partial Views Compound into Misalignment

Work on complex projects requires a shared picture of what you’re building, why, what’s been decided, and where you actually are. Most teams never get one. Everyone carries a partial view — the designer knows the design direction, the engineer knows the code constraints, the product person knows the strategy — and the gaps between these views create friction, rework, and misalignment that compounds over time. (Source)

The costs are invisible until they’re expensive: design gets built that doesn’t match what was intended, code solves problems already solved elsewhere, decisions get made twice because they were never recorded, and new team members spend weeks figuring out what’s already been decided. (Source)

At the tool level, Claude is a force multiplier — it can take more effective action in our tools than we can manually. But most usage is isolated: each conversation starts from scratch, context is fed in piecemeal, and the accumulated understanding stays trapped in that session. It doesn’t compound across the team. (Source)

Claude as Origin Point

More and more work originates in Claude before it reaches Figma, Jira, Qase, or any other tool. Claude drafts, explores, reconciles, and synthesizes — then the results flow into the tools that hold them. What Form Factory is building is the ability for Claude to do this well at the project level: to deeply understand how each external tool is being used on the project, to know where to reach in and fetch what’s needed, and to surface when things drift out of sync. (Source)

Three-Layer Repo Model

The repository contains three things:

Layer	What it holds
Codebase	What gets deployed — application code, internal apps, data models, backend services. Where implementation reality lives and changes first.
Knowledge base	What the team understands — decisions and reasoning, strategy, context, how pieces fit together. The record anyone can read months later to understand why things are the way they are.
Project toolkit	How to use each external tool on this project — not generic docs, but the project-specific conventions, workflows, and API calls that actually work here.

(Source)

Per-Project Mono-Repo

Each project gets its own mono-repo containing both the deployed code (e.g., Hydrogen) and everything Claude Code needs: skills, MCP connections, and claude.md. All disciplines — engineering, design, product, QA — work from the same repo. This is the practical unit of the nerve center concept. (Source)

The Tension: Tools Stay as Sources of Truth

Existing tools (Jira, Confluence, Figma, Qase) were built for human collaboration, not LLM integration. Dumping everything into a central context pool would undermine those tools — they’d lose their clarity, structure, and value as collaborative surfaces. But keeping everything siloed means Claude can’t see across the project landscape. (Source)

The risk of building a central layer that consumes and reorganizes tool data is that people stop maintaining the source tools. If Jira becomes a mess and something else organizes it better, people stop caring about Jira — and then Jira, which is needed for external collaboration, becomes even more useless. The right answer is making the tools themselves work, not layering more systems on top. (Source)

Drift Reconciliation

When Claude is the origin point, it sees across the codebase, the knowledge base, the toolkit, and through the toolkit into Figma, Jira, Qase, and whatever else the project connects to. That visibility catches drift at the moment it happens: when a designer makes a change that affects the data model, Claude flags it; when an engineer discovers a new pattern, Claude updates the knowledge base; when someone finds a better way to query Jira, Claude documents it in the toolkit. (Source)

The main problem in practice is that Jira drifts out of sync with Confluence, Confluence drifts from Figma, Figma drifts from the code. This isn’t about automating synchronization — it’s about making sure that work originating from Claude Code understands the interdependencies between systems. The claude.md and skills encode the project-specific knowledge of what lives where and how systems relate. (Source)

The Resolution: Navigate Messy Reality

Rather than standardizing into one perfect system, the approach is to teach Claude how to navigate reality as it is. Projects are inherently messy — tools evolve, people develop different understandings, systems drift out of sync. The investment goes into Claude’s ability to understand how each tool is actually used on each project: what information lives where, how to find things quickly, what each system is for, and how to reconcile contradictions when systems diverge. The tools stay as true sources of record; Claude learns to work with the mess rather than trying to eliminate it. (Source)

Skills Over Infrastructure

Skills are the preferred mechanism over rigid infrastructure. Skills are more flexible than fixed scripts or CLI tools because they can adapt to the situation. A skill that describes what you want to accomplish is better than a rigid command that does exactly one thing — Claude can adapt the execution to the current context. (Source)

The Repo as Shared Interface

In practice, Claude Code in the project repo becomes the primary interface for all disciplines. Alongside the deployed code, the repo contains:

Skills — reusable capabilities and workflows
MCP connections — integrations with external tools (Jira, Confluence, Figma, Qase, etc.)
claude.md — persistent project context and instructions

When designers, engineers, product managers, and QA all originate work in the same shared instance with the same context, their contributions naturally shape each other. A developer building a feature has visibility into design thinking and business logic. A designer exploring concepts can see what’s feasible and what data is available. Expertise isn’t coordinated after the fact — it’s baked into the origination point. (Source)

Code changes, Confluence creation, Jira manipulation, Figma updates, test case creation — all increasingly originate in Claude Code. If the repo is the shared starting point with the right context, any team member’s contributions naturally benefit from the full project picture. (Source)

Meeting Transcripts

Meeting transcripts should not be automatically processed into shared systems. People are responsible for extracting relevant information from calls and putting it into the appropriate systems (Jira, Confluence, etc.). This is intentional — access control means not everyone should see everything from every meeting. The person who attended decides what information is relevant to share and where it should go. (Source)

Compounding Context

Over time, as each person interacts with Claude and improves its understanding of the project, the shared context compounds. Claude’s thinking converges with how the team actually thinks. The system gets smarter the more it’s used — each interaction makes the next one more effective for everyone. (Source)

The outcome: anyone on the team, at any moment, can ask “what are we building and why” and get the same answer. New people arrive at a project whose history is already organized. Decisions don’t get made twice. Work doesn’t duplicate. Misalignment gets caught when it happens, not six weeks into a sprint. (Source)

Relationship to this KB

This KB is itself an implementation of the “nerve center” philosophy — it accumulates knowledge from multiple sources (Confluence, GitHub, meetings, human notes) into the repo so that Claude has persistent, compounding context. The KB’s raw sources represent the “messy reality” of multiple tools, while the KB pages are Claude’s synthesized understanding. Crucially, the KB complements the source tools rather than replacing them — it processes and indexes without becoming the primary interface that makes people stop caring about Jira or Confluence.

FF KB

Explorer