Menu
Plan and start isolated parallel module implementation tracks from specs/MODULES.md and per-module parallel.yaml declarations.
Implement a fully-specced module via dual-harness execution — Claude orchestrates, Codex CLI executes inside a live tmux pane in your attached session. Use when ready to write code for a module that has approved SPEC.md and CLAUDE.md files. Triggers on phrases like 'execute the X module via codex', 'dual-harness build', or '/project-execute X'.
Initialise a new software project with full spec-first workflow — research, architecture, module specs, and roadmap. Use this whenever someone says 'build me a...', 'I want to create...', 'new project', 'start a project', or describes a product idea. Also use for major new feature areas within an existing project.
Generate or regenerate the master architecture document (specs/MASTER_BLUEPRINT.md) — the single source of truth for tech stack, data model, API patterns, auth, UI conventions, and module relationships. Use when starting architecture, changing stack decisions, or after significant research that affects the technical approach.
End-of-session review — captures what was done, learnings, mistakes, and patterns, then updates LEARNINGS.md and CLAUDE.md. Run this after completing any task, at the end of a working session, or when switching to a different area of the project. This is what makes the system compound and get smarter over time.
Independent security review of pending changes via an isolated Agent context — fresh subagent reads the diff and a security checklist with no implementation bias. Use after a module is implemented and before merge, especially for changes that touch auth, data persistence, PII, audit logging, or anything UK GDPR-sensitive. Triggers on '/project-security-review', 'security review', 'audit this branch'.
Create or update a detailed module specification — data model, API endpoints, UI screens, business logic, and acceptance criteria. Use when planning a new module, refining requirements before implementation, or updating specs after implementation revealed changes. Trigger on any mention of 'spec', 'specification', 'plan this module', or 'define the requirements for'.
| name | project-tracks |
| description | Plan and start isolated parallel module implementation tracks from specs/MODULES.md and per-module parallel.yaml declarations. |
| effort | high |
Parallel module implementation command. Stage 1 supports:
/project-tracks plan [modules...] [--harness=codex|claude]/project-tracks start [modules...] [--harness=codex|claude]Use the helper script for deterministic parsing and side effects:
bash .claude/lib/project-tracks.sh plan "$ARGUMENTS"
bash .claude/lib/project-tracks.sh start "$ARGUMENTS"
Run:
bash .claude/lib/project-tracks.sh plan [modules...] [--harness=codex|claude]
Requirements enforced by the helper:
specs/MODULES.md must exist, otherwise print clear guidance.specs/modules/<module>/parallel.yaml.parallel.yaml must declare version: 1.specs/MODULES.md.shared: path.<= KIT_PARALLEL_MAX (default 4).parallel.yaml prints add parallel.yaml or run sequentially.plan is read-only. It prints a proposal and does not create worktrees,
registry entries, locks, panes, logs, or branches.
Run:
bash .claude/lib/project-tracks.sh start [modules...] [--harness=codex|claude]
start reuses the same validation as plan, then for each selected module:
.claude/worktrees/track-<module> on branch track/<module>..worktreeinclude when they exist.KIT_PARALLEL_PORT_BASE + index (default 3000 + index)..claude/parallel/tracks.json under a mkdir lock.All tracks in one invocation use the same harness. Default harness is codex.
Stage 1 supports only --harness=codex. --harness=claude is reserved for a future stage; the current launcher fails fast rather than silently bypass the per-track lock, JSON-mode capture, and schema validation that the codex path gets through dispatch.sh.
For Codex tracks, the helper launches .claude/lib/dispatch.sh with:
KIT_DISPATCH_TS=<per-track-ts>
KIT_PARALLEL_TRACK=<module>
KIT_PARALLEL_PORT=<reserved-port>
PORT=<reserved-port>
KIT_PARALLEL_TRACK already namespaces the dispatcher's lock by module, so KIT_ALLOW_CONCURRENT=1 is not set — it would disable that lock and let a second launch of the same module race in the same worktree. KIT_DISPATCH_TS is the per-track timestamp; the dispatcher reuses it for .log/.jsonl/-report.json filenames so they share the <TS>-<module> identifier with the per-track prompt directory.