The Squad Starter Pack, equipping a team to work with AI

Problem addressed

When a team works with a coding agent, the quality of what comes out depends directly on what the agent knows about the project. Without structured context, it improvises: it knows neither the design system rules, nor the code conventions, nor who owns what. Each person re-briefs at every session, each in their own way, and the AI quickly produces something nobody can maintain.

Steps

The method in 6 steps

1. Step 1

   Lay down the session memory

   An instructions file at the root of the repository: the project map, the git conventions, the patterns, the sensitive areas. Loaded automatically at every session, so every line must earn its place: 200 lines maximum.

2. Step 2

   Write what the AI cannot infer from the code

   A product document: why this product exists, who uses it, which rules govern decisions, what is out of scope. Single source for all the team's AI usage. It belongs to the PM.

3. Step 3

   Govern the design system

   A design document: which system, which hierarchy (the system component first, justified custom second), what maturity level, which deviations are assumed. Not a token dump: what to use, and why. It belongs to the designer.

4. Step 4

   Install the quality gate

   A review that runs in an isolated context, free of the bias of the session that produced the code: it runs the tests, confronts the diff with the written rules, and returns a verdict. Approved or blocked, before every commit.

5. Step 5

   Extend according to context

   Specialized AI collaborators by role (framework review, architecture, security), automation of the ticket-to-PR cycle, a dedicated security audit on diffs, a silent observer that logs debt. Optional: they reflect each team's maturity, not an imposed standard.

6. Step 6

   Measure, then prioritize

   The self-check evaluates each dimension, produces a score and three priority actions. The criteria are loaded at every run from their living source: the framework evolves without reinstallation. We measure to know where to start, not to grade ourselves.

Success conditions

What tells you it works

• Product and tech co-validation from the start: a pack imposed by a single function does not survive the first disagreement
• Short files where every line earns its place, rather than exhaustive documentation nobody will load
• An instantiation adapted to each team's maturity: foundations first, extensions when the need exists
• A living framework: the self-check criteria evolve without teams having to reinstall anything

Contraindications

When not to use it

• × Aiming for the score rather than the usage: an 8/8 on compliance produces nothing if the team does not actually work with the AI
• × Installing everything at once: extensions without foundations give sophisticated plumbing on top of empty context
• × A team without a usable design system: the AI reveals it immediately, and that has to be addressed first

Applied examples

Where the method has lived

• Born on the rebuild of a product portal, where the complete system was built and battle-tested over four months of directed design-to-code

  The reference repository reaches the full score of the framework, and the orchestration report documents what the system made possible

• Instantiated afterwards on several other teams, each one evaluated then equipped according to its maturity, from foundations to extensions

  The spread is underway: the shared framework makes it possible to compare progress without imposing a single pace

Diagnostic

Run your own diagnostic

Before rolling the method out, better to know where your squad stands. Answer the six conditions, the score updates live. The playground is the result when the score allows it, not a deliverable to copy as is.

Going further