Execute PRD Task

Execute one PRD task from exploration through tracking updates.

Required Inputs

• Task specification markdown.
• PRD directory path.
• Task file path.
• _tasks.md task graph manifest path.
• Auto-commit mode.
• Optional workflow memory directory path.
• Optional shared workflow memory path.
• Optional current task memory path.

Workflow

1. Ground in repository and PRD context.

- Read the provided task specification. - Read the repository guidance files named by the caller. - Read the PRD documents under the provided directory, especially techspec.md and tasks.md. - Read ADRs from the adrs/ subdirectory of the PRD directory to understand the architectural decision context for this task. - After reading all sources, check for conflicts between the task specification, techspec, and ADRs. If any requirements contradict each other, stop and report the conflict instead of guessing — do not proceed to step 2. - If the caller provides workflow memory paths, use the installed cy-workflow-memory skill before editing code. - Reconcile the current workspace state before new edits.

1. Build the execution checklist.

- Extract deliverables, acceptance criteria, and every explicit Validation, Test Plan, or Testing item into a numbered working checklist. - Print the full checklist before starting implementation so it is visible and trackable. - Capture the concrete pre-change signal that proves the task is not finished yet. - Use this checklist as a gate: mark each item done as evidence is produced during implementation, and do not proceed to validation until every checklist item has been addressed.

1. Implement the task.

- Keep scope tight to the task specification. - Follow repository patterns and real dependency APIs. - Record meaningful out-of-scope work as follow-up notes instead of silently expanding the task.

1. Validate and self-review.

- Run every test and validation command listed in the task specification — not just the repository-wide verification. - Use the installed cy-final-verify skill. This step is mandatory regardless of auto-commit mode — always verify before claiming completion. - Perform a self-review after verification and resolve every blocking issue before proceeding.

1. Update task tracking.

- If workflow memory paths were provided, update the memory files first — record decisions, learnings, and touched surfaces before updating tracking status. - Use the caller-provided task file path and task graph manifest path. - Mark subtasks complete only when the implementation and evidence are actually complete. - Change task status to completed only after clean verification and self-review. - Read references/tracking-checklist.md when applying status, checklist, or commit updates. - Do not edit _tasks.md during normal completion tracking; it owns graph topology, not per-task status. - Sequence: memory update (if applicable) -> task file checkboxes -> task status -> commit (if applicable).

1. Handle commit behavior.

- If auto-commit is enabled, create one local commit after clean verification, self-review, and tracking updates. - If auto-commit is disabled, leave the diff ready for manual review and commit. - Never push automatically.

Error Handling

• If the pre-change signal cannot be reproduced directly, capture the strongest available baseline signal and state the limitation.
• If validation fails, keep the task status unchanged until the failure is resolved.
• If tracking files are missing, stop and report the missing path before marking completion.