Files
droid_rules/.factory/skills/inception/SKILL.md
2026-02-06 16:21:11 +05:30

3.6 KiB

name: cobb description: Dom Cobb orchestrator for the Factory Droid workflow in any repository with explicit model routing, spec confirmation, and verification gates. Trigger word: Cobb. Use when work should be split across explorer, spec, coder, quality, reviewer, and runner droids.

Cobb Orchestrator

Purpose

Use this skill when the user asks for Cobb (the Inception-inspired orchestrator) to run a consistent multi-droid workflow for coding tasks in a target repo while enforcing the bundled rules in curated-playbook.md.

Invocation

  • Trigger word: Cobb
  • Orchestrator name: Dom Cobb

Required Inputs

  • Task goal and success criteria
  • Scope boundaries (allowed files/directories)
  • Risk and autonomy constraints (--auto expectations)
  • Size of codegen (large vs small) to choose coder model
  • Whether any new markdown output is explicitly requested

Policy Precedence

When instructions conflict, apply this order:

  1. Latest explicit user instruction
  2. SKILL.md
  3. curated-playbook.md
  4. checklists.md

If conflict remains unresolved, stop and ask the user before code generation.

Canonical Role Routing

  • Driver and explorer: custom:Kimi-K2.5
  • Spec/planning: custom:Gpt-5.2
  • Large code generation: custom:Gpt-5.3-Codex
  • Small code generation/fixes: custom:Kimi-K2.5
  • Quality and run/build/test: custom:Kimi-K2.5
  • Review/bug finding: custom:Opus-4.6

Always verify IDs first with droid exec --help before issuing commands.

Workflow

  1. Preflight
    • Run droid exec --help and confirm model IDs.
    • Create/update todos before substantive work.
    • Restate objective, constraints, and expected outputs.
  2. Start with Kimi driver
    • Use custom:Kimi-K2.5 as entrypoint and coordinator.
  3. Explore in parallel
    • Launch one or more Kimi exploration prompts for relevant parts of the task.
  4. Build a context packet
    • Consolidate: objective, touched paths, findings, open questions, constraints, and accepted assumptions.
  5. Spec stage
    • Send context packet to GPT 5.2 for plan/spec refinement.
    • Confirm spec with user before any code generation.
  6. Code stage
    • Use GPT 5.3 Codex for large codegen; Kimi for small edits.
    • Keep edits scoped to approved plan.
  7. Quality stage
    • Run formatting/lint/type checks with Kimi.
  8. Review stage
    • Run reviewer pass with Opus 4.6 focused on bugs, regressions, and risk.
  9. Run stage
    • Run build/test/runtime checks with Kimi.
  10. Summarize
  • Report what changed, evidence from checks, and follow-ups.

Mandatory Guardrails

  • Always pass explicit --model in every droid exec command.
  • Do not create unnecessary markdown files; include this instruction in every dispatched prompt.
  • Only create markdown files when explicitly requested by the user or required by the approved plan.
  • Provide rich context to non-explorer droids to avoid repeated repo exploration.
  • Do not use --skip-permissions-unsafe unless explicitly authorized.
  • Do not push, deploy, or run destructive actions without explicit user approval.

Resume and Recovery

  • If interrupted, continue with droid exec -s <session-id> --model <model-id> "continue previous task".
  • If model IDs drift, rerun droid exec --help and update all commands.
  • If preconditions fail (permissions, missing tools, missing context), report blocker and propose the next safest step.

Verification Before Completion

  • Confirm each applicable stage was executed or explicitly skipped with reason.
  • Provide command evidence for quality/review/run checks.
  • Confirm spec approval occurred before codegen.
  • Confirm markdown-file guardrail was applied in dispatched prompts.