@linimin/pi-letscook 0.1.62 → 0.1.64

package/skills/cook-handoff-boundary/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cook-handoff-boundary
-description: Ordinary-chat contract for treating `/cook` as an optional workflow mode while still allowing direct repo implementation in main chat when workflow state is unnecessary.
+description: Ordinary-chat contract for treating `/cook` as an optional workflow mode while requiring `/cook` to use primary-agent-authored handoff data instead of guessing from recent discussion.
 ---
 
 # /cook Handoff Boundary
@@ -17,7 +17,7 @@ This skill governs the relationship between:
 - Ordinary chat may be used to clarify requirements, discuss tradeoffs, refine scope, and directly implement requested repo changes.
 - `/cook` is an explicit workflow entrypoint for users who want resumability, review, audit, or canonical `.agent/**` workflow state.
 - `/cook` is optional. It is not required just because the work spans multiple files or looks substantial.
-- Ordinary chat remains ordinary chat until the user explicitly runs `/cook`.
+- Ordinary chat remains ordinary chat until the user explicitly chooses `/cook`.
 
 ## What Ordinary Chat May Do
 
@@ -52,24 +52,20 @@ But even in those cases:
 - do not frame `/cook` as mandatory for direct repo edits
 - continue helping directly in ordinary chat unless the user explicitly chooses workflow mode
 
-## Required Behavior Before Explicit `/cook`
+## Required Behavior When The User Explicitly Chooses `/cook`
 
-Before the user explicitly runs `/cook`, the primary agent must:
+If the user explicitly runs or clearly chooses `/cook` workflow mode, the system behavior should be:
 
-- keep the interaction in ordinary chat
-- directly implement requested repo changes when appropriate instead of blocking on workflow mode
-- continue ordinary discussion naturally if the user keeps refining the task
-- avoid claiming that canonical workflow state already exists unless `/cook` actually started it
+1. check for a fresh explicit primary-agent `cook_handoff`
+2. if none exists, call a primary-agent handoff synthesis step immediately from the current task context
+3. use that handoff to show Start / Cancel confirmation in the same `/cook` entry
+4. write canonical workflow state only after Start
 
-## Deferred Handoff Model
+That means:
 
-When the user explicitly runs `/cook`:
-
-- `/cook` synthesizes a startup brief from recent discussion using primary-agent-style context
-- `/cook` shows Start / Cancel confirmation before canonical workflow state is rewritten
-- that synthesized startup brief is advisory intake only until the user confirms startup
-
-This means the primary agent does not need to proactively attach startup capsules during ordinary chat just because the task looks ready.
+- `/cook` must not infer or guess the startup slice from recent discussion alone
+- `/cook` should use primary-agent-authored handoff data
+- `/cook` should not require a manual rerun just to consume a handoff it can synthesize immediately from the primary-agent view
 
 ## Optional Preview Behavior
 
@@ -107,14 +103,12 @@ Optional preview capsule format:
 Notes:
 
 - `constraints` may be replaced or supplemented by `non_goals` when clearer.
-- `first_slice_goal`, `first_slice_non_goals`, `implementation_surfaces`, `verification_commands`, and `why_this_slice_first` are required only for an implementation-ready preview capsule.
-- Any preview capsule is startup intake for `/cook` only. It is not canonical `.agent/**` state, not active-slice state, and not a second repo contract source.
+- `first_slice_goal`, `first_slice_non_goals`, `implementation_surfaces`, `verification_commands`, and `why_this_slice_first` are required for an implementation-ready handoff.
+- Any capsule is startup intake for `/cook` only. It is not canonical `.agent/**` state, not active-slice state, and not a second repo contract source.
 
 Suggested wording:
 
-> We can continue directly in ordinary chat if you want. If you prefer resumable workflow state, explicit review flow, or a confirm-first startup gate, you can run `/cook` and it will synthesize a startup brief from our recent discussion before workflow begins.
-
-A short recap may include mission, scope, or acceptance, but that recap must not be presented as canonical plan state.
+> We can continue directly in ordinary chat if you want. If you prefer workflow mode, run `/cook` and it should use a primary-agent handoff for Start / Cancel confirmation rather than guessing from recent discussion.
 
 ## Forbidden Behaviors
 
@@ -125,9 +119,15 @@ Before the user explicitly runs `/cook`, the primary agent must not:
 - claim canonical `.agent/**` startup state exists when it does not
 - refuse ordinary-chat implementation solely because `/cook` would also be possible
 
+When the user does explicitly choose `/cook`, the system must not:
+
+- let `/cook` invent the startup mission from recent discussion alone
+- let `/cook` replace missing handoff data with generic transcript guessing
+- require a second `/cook` invocation when same-entry primary-agent handoff synthesis is possible
+
 ## Relationship To `completion-protocol`
 
-This skill is only about pre-`/cook` ordinary-chat behavior.
+This skill is only about pre-`/cook` ordinary-chat behavior and `/cook` handoff expectations.
 
 After the user explicitly enters `/cook`, the separate `completion-protocol` skill governs: