intent-packets

intent-packets Skill

Core Mission

• Success Criteria:
  • There are as many packet candidates as the expected change size warrants (do not pad the count; one packet is fine for very small changes; treat 1–7 as a loose guide), and each packet references a parent intent
  • Each packet is drafted as an individual file under .intent/packets/active/ (1 packet = 1 file)
  • Each packet has Scope / Non-scope / Expected Behavior / Decisions / Safety(Invariants) / Validation / Evidence / Rollback / How to Proceed (keep Evidence as an empty section when there is no result)
  • In each packet's ## Decisions section, the common-core slots from decision-slots.md (plus the mode-specific diffs) are each closed with one of the 4 statuses (answered / undetermined / not-applicable / ADR candidate) (do not fill in defaults; do not silently skip)
  • Each packet is at a behavior-preserving / testable / rollbackable granularity
  • No existing packet file has been destroyed (changes are presented as differential update proposals)
  • No application code has been changed at all

When addressing responsibility/dependency boundaries, read “Reflect boundaries in work” in rules/design-boundaries.md before decomposition. Also apply “Migrate existing code incrementally” when migrating existing code.

Execution Steps

• Before decomposition and priority presentation, read and apply rules/requirement-coverage.md.

Step 1: Read the prerequisites

• Read .intent/intent-tree.md and .intent/intent-compass.md. If either is missing, guide the user to "run the corresponding command first" and stop.
• Check at the packets entry: check important decisions carried over from the Tree and Compass under the important-decision contract in CONTRACT.md. When a separate session starts from an existing packet, do not skip this entry check. If a decision has no allowed outcome, stop only the packets in the affected scope supported by evidence; drafting and review of unrelated packets may continue.
• While reading, when you see an unsettled verb slipped into the settled phrasing of the compass / intent-tree (assume / reuse / planned / TBD / tentative, etc.), do not fix it by guessing; present it as a conversion proposal into Open Questions or an undetermined slot (with the reason and the revisit condition (Revisit when)). Promotion to a fixed value is left to the user's confirmation. Do not re-convert spots already recorded in Open Questions / Deferred / an undetermined slot.
• Read the mode state in order: the inherited issue directory's discovery/<slug>-<rand>/mode.md (A34; inherit the issue name that discover output) → else the single .intent/mode.local.md (legacy) → else old .intent/mode.md (the CONTRACT.md read fallback contract). If both are absent, default to standard and announce it in Open Questions (do not stop).
• Read .intent/packets/index.md and the existing packet files under .intent/packets/active/ (the basis for differential updates).
• Legacy-install handling: if .intent/packets/, plan.md, index.md, or README.md is missing, the skill creates them itself before proceeding (do not wait for a scaffold reinstall).
• After-the-fact drafting (when implementation ran ahead): when the invocation context or the user's report makes clear that implementation proceeded / completed without a corresponding Packet, treat it with the same procedure as normal drafting (raise the Packet even after the fact; being already implemented is not a reason to skip drafting). In this case:
  • Record the established facts (the wiring / behavior already implemented) as what + constraints + oracle in the packet file.
  • For the spec that cannot yet be fixed (the trigger, threshold, judgment means, etc. — decisions not yet committed to, or placed provisionally), do not fill them by guessing; put them explicitly into the container as Open Questions and Deferred (undecided (deferred, with a revisit condition), always with the revisit condition). "Not drafting a Packet because the spec cannot be fixed" is wrong — holding the unfixed as-is is exactly the Packet's role.
  • Guide the order: first raise the Packet with this skill (the drafting phase), then return the learnings gained from the implementation reality to canonical via a delta with /intent-writeback (the post-implementation phase). These two run in opposite directions; do not perform only writeback while skipping the Packet drafting (the phase boundary follows writeback-protocol.md §3).