Gate Setup

Example Invocations

/gate-setup Gate 1 of 3 for task 4.3. Covers tickets 4.3.01 through 4.3.03. Draft tickets at worktickets/draft/draft_4.3/

/gate-setup Gate 3 of 4 for task 3.10. Covers tickets 3.10.07 through 3.10.09. Previous orchestration at worktickets/active/wt_p3_t3.10_gate2_orchestration.md. Divergences at docs/divergences/t3.10_gate2_divergences.md

/gate-setup Gate 1 of 2 for task 5.1. This is the first gate, no prior orchestration. Tickets 5.1.01 and 5.1.02 at worktickets/draft/draft_5.1/

Instructions

When invoked, follow these steps in order:

Step 1: Create Feature Branch

1. Stay on the current branch. Do NOT switch to main.
2. Create a new feature branch from the current branch using the naming pattern: feature/p{phase}-t{task}-gate{N}-{short-description}
   • Example: feature/p4-t4.3-gate2-embedding-engine
3. Confirm the branch was created and you are on it.

CRITICAL: Never switch to main to create a branch. Always branch from where you are. Switching to main risks losing uncommitted work and breaks the gate continuity.

Step 2: Review Previous Orchestration

If this is NOT the first gate:

1. Read the previous gate's orchestration guide at the provided path.
2. Note: What was planned? What sessions were defined? What finalization commands were used?
3. Identify any patterns or issues from the previous gate that should inform this one.

If this IS the first gate:

1. Skip this step.
2. Note that this is a fresh start — no prior orchestration to reference.

Step 3: Review Draft Worktickets

1. Read all draft worktickets that this gate covers.
2. For each ticket, note:
   • What it delivers
   • Its dependencies (within this gate and on prior gates)
   • Its complexity rating
   • Any files or areas it touches that might conflict with other tickets in this gate
3. Flag any tickets that should NOT run in parallel due to overlapping file modifications or logical dependencies.
4. API verification check: For any ticket that integrates a new external crate or calls APIs discovered during research, flag that the session prompt should include a compile-verification step: write a minimal snippet that compiles against the actual crate version before full implementation. Research-phase API assumptions often diverge from reality (wrong method signatures, different return types, missing traits).

Step 4: Review Divergence Documents

If divergence documents exist from prior gates:

1. Read each divergence document.
2. Identify any divergences that affect this gate's tickets:
   • Scope changes that add or remove work
   • Implementation decisions that change assumptions in draft tickets
   • New risks or dependencies discovered during prior gates
3. List specific adjustments needed to this gate's tickets based on divergences.

If no divergence documents exist (first gate or no divergences captured):

1. Skip this step.

Step 5: Propose Parallel Work Allocation

Present to the PM:

1. Proposed sessions: How many parallel sessions, and which tickets go in each session.
2. Rationale: Why this grouping — what can safely run in parallel vs. what has dependencies.
3. Conflict zones: Any areas where parallel sessions might produce conflicting changes (same files, same modules, overlapping functionality).
4. Recommended adjustments: Any changes to draft tickets based on your review (Steps 2-4).

Wait for PM approval before proceeding. The PM may adjust session allocation, reorder tickets, or modify scope.

Step 6: Apply Approved Adjustments

After PM approval:

1. Apply any agreed-upon changes to draft worktickets.
2. Move the gate's worktickets from worktickets/draft/ to worktickets/active/ (or as directed by PM).
3. Confirm all adjustments are made.

Step 7: Create Orchestration Ticket

Create an orchestration ticket at the path specified by PM (or default to worktickets/active/wt_p{phase}_t{task}_gate{N}_orchestration.md).

The orchestration ticket must contain:

1. Pre-Gate Review Status

   • Summary of previous orchestration review (if applicable)
   • Summary of divergence impacts (if applicable)
   • Any risks or watch items for this gate

2. Session Definitions For each parallel session:

   • Session name/number
   • Assigned worktickets
   • Key deliverables
   • Files/areas this session will touch
   • The full session prompt the PM will paste into each agent terminal

3. Finalization Commands

   • List the commands each session should run before committing.
   • Do NOT hardcode technology-specific commands. Instead, write: "Run the project's finalization commands as defined in OVERRIDES.md or the project's CLAUDE.md."
   • If OVERRIDES.md exists for this skill, it will specify the actual commands (e.g., cargo fmt && cargo clippy, pnpm lint).

4. Commit Template

   • Provide a commit message template for each session, following the project's commit conventions.
   • Include the gate number and session identifier in the commit message.

5. Merge Notes

   • Expected merge order (which session merges first)
   • Known potential conflict areas
   • Any manual steps needed after merge

Step 8: Hand Off to PM

1. Confirm the orchestration ticket is complete.
2. Summarize: how many sessions, which tickets in each, any special instructions.
3. Wait for PM to spin out agent sessions. Do not proceed further — the PM manually opens terminals and pastes session prompts.

Project-Specific Overrides

If an OVERRIDES.md file exists in this skill's folder, read it after these instructions for project-specific customizations (e.g., finalization commands, branch naming conventions, commit templates).

What This Skill Does NOT Do

• It does not execute the parallel sessions — the PM opens terminals and pastes prompts manually.
• It does not merge session results — that's /gate-merge.
• It does not capture divergences after completion — that's /gate-post.
• It does not create or manage the project's branches beyond the initial gate branch.
• It does not define technology-specific build/test/lint commands — those belong in OVERRIDES.md or the project's CLAUDE.md.