Plan a cross-repo feature¶
From the workspace folder, run:
Commands in Codex
In Codex, swap the prefix for $ — e.g. /n45-feat → $n45-feat.
Planning a workspace feature is always structured (a cross-repo feature has a CONTRACT) and happens in steps, each with a confirmation point of yours.
flowchart TD
Start([/n45-feat]) --> Intent[Intent + interview
+ screen mapping per member]
Intent --> Disc[Cross-repo discovery]
Disc --> Spec[SPEC + CONTRACT]
Spec --> Review{Review the CONTRACT}
Review -->|Approve| Fanout[Fan-out
one sub-roadmap per member]
Review -->|Adjust| Spec
Fanout --> Exec([Execution])
1. Intent and interview¶
N45 first gets to know each member (each service's stack and patterns) and then talks with you to nail down what the feature does across the services. The depth is the same as in Project mode:
- Progressive interview — the intent, and (when a member is new/without a base) that service's foundation: stack, architecture, constraints.
- Screen and contract mapping, attributed per member — for each member with a UI, N45 proposes the screens (with states, components and actions); for each API member, the contracts (
input → output). You validate everything before moving on.
That mapping is what makes the result rich and concrete instead of generic.
2. Discovery + SPEC + CONTRACT¶
With the intent settled, N45 generates the coordination artifacts and presents each one with a link + the content:
- DISCOVERY — the integration surface between the services and the screens/contracts per member.
- SPEC — the feature's intent across the services, with the screens per member.
- CONTRACT — the most important one: the integration points between members.
The CONTRACT¶
The CONTRACT is the seam between the services — the "source of truth" each member follows to converge. Each integration point declares:
- the transport (REST, queue, event, gRPC, shared DB, webhook…);
- producer and consumer(s);
- the typed schema + a concrete example;
- the errors and each side's obligations ("Producer MUST…", "Consumer MUST…").
You review and approve the CONTRACT before the fan-out:
Why review the CONTRACT carefully
It's what the members converge on. If an integration point comes out wrong, every member that depends on it diverges. It's worth reviewing calmly before approving.
3. Fan-out¶
Once you approve, N45 does the fan-out: for each affected member it generates a self-contained roadmap (the member's own discovery, spec and roadmap), honoring that member's slice of the CONTRACT and transcribing the screens/contracts you validated. The feature creates its own branch in each repository (and in the workspace).
From here, each member has its own sub-roadmap, with its own phases — ready for execution.