← ArezCONTENT HISTORY

Update to Arez

Snapshot Sep 30, 2026 · 22:58 UTC · version 1.0.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "name": "executing-noodle-plans",
  "description": "Use when the user asks to execute an approved, decision-complete implementation plan for a Noodle Seed project task by task with test-first changes, review, recovery, and final verification.",
  "included_files": [],
  "skill_md_contents": "---\nname: executing-noodle-plans\ndescription: \"Use when the user asks to execute an approved, decision-complete implementation plan for a Noodle Seed project task by task with test-first changes, review, recovery, and final verification.\"\n---\n\n<!-- noodle-skill version:0.62.1 hash:6a9f132ddb79352e -->\n\n# Execute a Noodle Seed implementation plan\n\nExecute an approved plan without reopening settled design decisions. Keep implementation, review, and evidence scoped to the current repository and the authority the user granted.\n\n## Preconditions\n\n- Read the plan, repository instructions, current branch status, and the files named by the first incomplete task.\n- Confirm the plan is decision-complete, test-first, compatible with the current code, and explicit about public contracts and required verification.\n- Work in the repository-required isolated branch or worktree and preserve unrelated changes.\n- If current code invalidates the plan or two requirements conflict, stop before editing and ask which requirement governs.\n\n## Task loop\n\nExecute one task at a time in plan order:\n\n1. Restate the task boundary, expected behavior, focused failing test, and files in scope.\n2. Add or update the focused test first and run it to confirm the expected failure when practical.\n3. Implement only the behavior required to make that test pass. Do not add compatibility paths, abstractions, or adjacent cleanup the plan did not require.\n4. Run the focused test, then the package-level checks named by the plan.\n5. Review the task diff for plan compliance, correctness, security, type safety, and unnecessary surface area.\n6. Record completion in the plan checkbox when it is writable and in a focused conventional commit.\n\nWhen the active host provides isolated task workers and user authorization permits delegation, use a fresh implementer for an independent task and a separate reviewer after it. Give each worker only the task requirements, binding global constraints, file paths, and required evidence. Never run workers in parallel when their files or contracts overlap. Execute inline when workers are unavailable, tasks are tightly coupled, or delegation is not authorized.\n\n## Review and recovery\n\n- Independent review must compare the task requirements with the exact task diff and test evidence; implementer self-review does not replace it when a reviewer is available.\n- Return concrete findings to the implementer, rerun the tests that cover each correction, and review the correction diff again.\n- Allow at most three correction rounds for the same finding. Then stop with the unresolved requirement, attempted fixes, and current evidence instead of silently accepting drift.\n- On context loss or interruption, resume from the plan checkboxes, git status, and git log; verify the last completed task before starting the first incomplete one.\n\n## Completion\n\n- Review the complete branch diff against the plan and all accepted design constraints.\n- Run the focused tests, affected package checks, generated-surface checks, and the repository readiness gate.\n- For Noodle application behavior, also run the validation, test, check, preview, or hosted evidence level selected by the owning Noodle Seed build or verification skill.\n- Report commits, evidence, residual risk, and the first unproven layer. Do not claim deployment, publication, merge, or production behavior that was not performed.\n- Hand delivery to the repository workflow; executing a plan does not itself authorize merge, deploy, publication, or other external mutation.\n\n## Stop conditions\n\n- Stop before implementation when the plan is incomplete or stale in a way that changes behavior, architecture, security, or public contracts.\n- Stop after three unsuccessful correction rounds on the same load-bearing finding.\n- Stop before any external mutation or destructive action outside the user-authorized task boundary.\n"
}

SHA-256: dedfcafc0be37267f9a8c8c29f7c12bf15b63c202be8cf4f3a45b4fda1c0053e