Plan Expander

Non-overlap Contract (Critical)

This skill must NOT:

• create a new sprint plan or re-plan the work
• rewrite the ticket structure
• propose major resequencing

It must instead:

• take the given tickets as source of truth
• only add clarifications, code touchpoints, and implementable checklists

Operating Rules

1. For each ticket, open/inspect the exact files referenced by the plan first.
2. Always extract:
   • relevant functions/classes
   • existing patterns (telemetry, cache, session memory, tool wrappers)
   • constraints and compatibility requirements
3. Prefer minimal changes:
   • introduce a new module boundary only if it reduces risk and matches the spec
4. When adding new modules:
   • propose exact file paths and exports
5. If file access is not available:
   • request only the minimal snippets required (file header + relevant functions)
   • continue with partial workpack if needed

Output Contract (Strict)

0) Assumptions & Repo Signals (short)

• detected stack (Next/Vite/Node/etc.)
• testing stack (Vitest/Jest/etc.)
• telemetry/log conventions (if found)

1) Ticket Workpacks (one section per ticket)

For each ticket:

A) Ticket Summary

• ID + Title
• Goal (1–2 lines)
• Dependencies (from plan)

B) Code Touchpoints (mandatory)

• Inspect first:
  • file paths + what to search for (grep strings)
• Likely edit points:
  • function/class names
  • lines/regions (if available)
• New files to create (if needed)

C) Implementation Checklist (mandatory)

Concrete bullets, no fluff:

• add type X in file Y
• add function Z signature
• integrate read/write here
• add telemetry fields here

D) Contracts to Implement (mandatory)

• explicit types/interfaces
• API surfaces
• version/TTL rules (if relevant)
• backwards compatibility obligations

E) Verification & Observability (mandatory)

• tests to add/update
• commands to run
• log/metric fields to verify
• expected outcomes

F) Failure Modes + Guardrails (mandatory)

Top 3–5 ways this ticket can break correctness and how to detect/prevent.

G) Minimal Patch Skeletons (optional but preferred)

Provide short code skeletons for:

• new modules
• new types
• wiring points Do not dump huge code; focus on the “spine”.

2) Cross-ticket Consistency Check (short)

• duplicated keys?
• conflicting versioning rules?
• telemetry field naming consistency?
• shared modules that must be reused?

3) Open Questions (max 5)

Only truly blocking gaps.

Formatting

Markdown, with tables when helpful. No generic advice. Every checklist item must map to a code location.