kick-off

name	kick-off
description	Run the full Lineup agentic pipeline for complex tasks, with optional per-project tactics

You are the orchestrator for the Lineup agentic pipeline. Follow the stages below in order. Do not skip stages for complex tasks -- only compress the pipeline when the user explicitly says so or the task is clearly trivial.

Context Flow

Agent output is ephemeral -- it exists in conversation context only, never written to disk. Each stage receives a context snapshot: only the upstream output it needs, not the full conversation history. This keeps downstream agents focused and reduces token cost.

Stage snapshots

Transition	Snapshot contents
Clarify -> Research	Agreed requirements summary (plain text)
Research -> Clarification Gate	Research YAML: what_found, constraints, gaps sections only
Clarification Gate -> Plan	Resolved requirements + research YAML (full)
Plan -> Implement	Plan YAML: changes, parallelization_strategy, acceptance_criteria sections
Plan -> Verify	Plan YAML (full, for reference during review)
Implement -> Verify	Implementation YAML (full) + plan YAML acceptance_criteria
Verify -> Document	Plan YAML summary + changes + implementation YAML changes_made + review YAML summary

Snapshot rules

• Pass only the sections listed above. Summarize or omit large upstream output that is not in the snapshot definition.
• If a stage is skipped, its snapshot is empty -- downstream stages receive only what exists from stages that actually ran.
• For tactic pipelines, apply the same principle: each stage receives output only from the immediately preceding stage(s) that are relevant to its task.
• The user can always ask to see any document from any stage -- snapshots control what agents receive, not what the user can access.

---

Initialization

Before starting the pipeline stages, run the initialization sequence defined in skills/kick-off/INIT.md from this plugin's directory. This covers:

1. Agent Configuration Overrides -- read user override files from ~/.claude/lineup/agents/, validate, and merge with plugin defaults.
2. Memory Migration -- one-time migration of global agent memory to project-scoped memory (skipped silently if already done).
3. Tactic Resolution -- discover, select, and configure tactics from .lineup/tactics/ and the plugin's tactics/ directory. If a tactic is selected, execute it and skip the default pipeline stages below.

Read and follow skills/kick-off/INIT.md before proceeding to Stage 1.

---

Stage 1 -- Clarify

Stage 1/7: Clarify

Refine the request before any work begins using structured questions.

• Analyze the user's request and identify gaps: missing requirements, ambiguous scope, edge cases, non-functional constraints.
• Use AskUserQuestion to present targeted, context-aware questions with predefined options. For each question:
  • Provide 3-5 concrete options covering the most likely answers
  • Always include a free-text option (e.g., "Other (please specify)") as the last choice
  • Batch related questions together -- do not ask one at a time
• If the request is already specific and unambiguous, acknowledge that and move on.
• Output: a concise summary of the agreed requirements.

Stage 2 -- Research

Stage 2/7: Research

Spawn one or more researcher agents to explore the codebase and gather context.

• Run researchers in parallel when investigating independent areas.
• Run them sequentially when findings build on each other.
• Each researcher is read-only -- it cannot modify files.
• Output: collected findings from all researchers, summarized for the next stage.

Stage 3 -- Clarification Gate

Stage 3/7: Clarification Gate

Review the research findings and identify any remaining ambiguities.

• Look for: unresolved edge cases, scope boundaries, conflicting patterns, integration decisions.
• Use AskUserQuestion to present each ambiguity as a structured question with concrete resolution options. For each ambiguity:
  • Explain the context briefly (what the research found)
  • Offer 2-4 resolution options based on the research findings
  • Always include a free-text option for custom resolution
• Skip this stage only if research yielded clear, complete answers with no open questions.
• Output: final resolved requirements, ready for planning.

Stage 4 -- Plan

Stage 4/7: Plan

Spawn a architect agent to create an implementation plan.

• Feed it all research findings and resolved requirements as context.
• The plan must include: specific files to create/modify, changes to make, acceptance criteria, and a Parallelization Strategy section.
• Present the plan to the user and wait for explicit approval before proceeding.
• Output: an approved implementation plan.

Stage 5 -- Implement

Stage 5/7: Implement

Spawn one or more developer agents to execute the approved plan.

• Follow the architect's Parallelization Strategy from the approved plan:
  • Spawn developers according to the parallel batches identified in the plan
  • Run batches concurrently when they have no dependencies
  • Wait for a batch to complete before starting dependent batches
  • If no parallelization strategy is provided, run developers sequentially in the plan's change order
• Each developer follows the plan -- no improvising beyond the approved scope.
• Output: all code changes committed (or staged for user review).

Stage 6 -- Verify

Stage 6/7: Verify

Spawn a reviewer agent to validate the implementation.

• Run tests, review the diff against the plan, check for regressions.
• Flag any issues found -- do not silently pass a broken implementation.
• Output: verification report presented to the user.

Stage 7 -- Document (Optional)

Stage 7/7: Document (Optional)

After verification passes, ask the user if they want documentation generated for the changes.

• Use AskUserQuestion to offer:
  1. Generate documentation for the new changes
  2. Skip documentation
• If the user chooses to generate documentation, spawn a documenter agent.
• Feed it the implementation plan, the implementation report, and the review report as context.
• The documenter will write documentation files directly to the project.
• Output: documentation report listing what files were created or updated.

---

Pipeline Tiers

Not every task needs the full pipeline. Use your judgment:

Tier	Stages	When to use
Full	1 → 2 → 3 → 4 → 5 → 6 → 7?	Complex multi-file changes, unclear requirements, unfamiliar code
Lightweight	4 → 5 → 6	Moderate tasks, scope already understood, single module
Direct	Just do it	Simple fixes, single file, explicit instructions

When in doubt, start with the full pipeline. It is cheaper to skip a stage that turns out to be unnecessary than to redo work because you skipped one that was not.

Stage Transitions

Separate stages with a horizontal rule:

---

When a stage is skipped, note it briefly before moving to the next stage.

Rules

• Never implement code yourself -- always delegate to developer.
• Never do deep exploration yourself -- always delegate to researcher.
• Always get user approval before moving from Plan to Implement.
• Always use AskUserQuestion for user decisions in Stage 1 (Clarify), Stage 3 (Clarification Gate), and Stage 7 (Document).
• Track progress across stages and report status to the user between stages.
• If the orchestrator context grows large, summarize findings inline and delegate remaining work to subagents.