yishan-io/yishan-mono/executing-plans

Executing Plans

Use this skill to execute an approved plan in the current session.

The SQLite-backed Local Task daemon owns task metadata and status. Pi uses the managed daemon through its configured endpoint. New tasks use daemon-generated UUIDs. Imported IDs stay opaque.

Load the Task

Use task_read for Local Task metadata and its synthetic, read-only brief. That brief is not a controller-frozen plan-subtask brief, and executors cannot write it. A tracked Local Task may contain multiple independently deliverable plan subtasks in plan.md; their independent deliverability does not by itself require separate Local Tasks. Every plan subtask must have an actionable frozen brief before execution. Each brief must define its scope, non-goals, acceptance criteria or check, and a finite execution budget. Read plan.md and notes when they are relevant. Use task_list or task_search to find work by status, priority, workspace, or tags.

If YISHAN_PROJECT_ID is set, work only with that project. Without it, work only with global tasks.

Execute the Plan

The controller owns plan-subtask scope and is the sole authority to create or replace scope-changing plan content. Local Task metadata identifies and tracks the Local Task; plan.md contains the frozen, independently verifiable briefs for its plan subtasks. Execute only when the applicable plan-subtask brief defines its scope, non-goals, acceptance criteria or check, and finite execution budget.

1. Read plan.md, including the applicable frozen plan-subtask brief, before you edit.
2. Confirm the plan subtask is independently deliverable; do not create a new Local Task solely for that reason.
3. Perform one frozen plan subtask at a time, staying within its scope boundary and execution budget.
4. Run its acceptance check and focused verification.
5. Record material discoveries in notes as dated, factual entries under ## Evidence and Progress. Keep the document readable with ## Summary, ## Decisions, and ## Open Questions; use task_write to reorganize it when needed.

Do not incorporate scope-changing related work into an active plan subtask. If a discovery requires work outside the frozen brief, stop and report the boundary change to the controller. The controller decides whether to continue and, if so, must replace the affected scope-changing plan content with a newly frozen brief before additional or revised work proceeds. Do not expand or retry a stopped plan subtask indefinitely; replan only through a new frozen brief with a new finite execution budget.

Use task_write to update plan.md only for execution details that remain within the frozen brief; do not modify the frozen brief or other scope-changing plan content. Scope-changing work requires the controller to replace the applicable plan content. Use task_append_note to add task-specific research or progress. Use task_update for a title, description, new, progressing, or cancelled status, priority, or tags. It cannot set done.

task_update cannot complete a task. Use task_finish only when the user explicitly asks to complete the task. When the user explicitly says all work is complete, run the self-checks and finish without asking again. It writes outcome and marks the task done.

Boundaries

Do not bypass the daemon. Do not create or parse task IDs. Do not write the synthetic Local Task brief. Do not change a frozen brief while executing it. Stop when the applicable plan-subtask brief no longer fits the work, its acceptance check cannot be met within budget, or completing it would cross a non-goal. The controller decides whether to continue; if it does, replan only through a newly controller-frozen plan.md brief. Local Task closure remains under the user's explicit control.