amend-project

# Project Amender Workflow <rules> - Project-bootstrap scope only. Do not run feature-delivery phases. - Never update `specs/prd.md`, `specs/sad.md`, `specs/dod.md`, `specs/project-plan.md`, `project-instructions.md`, or epic detail files under `specs/plan/` directly when an owning bootstrap workflow exists for that artifact. Execute the owning workflow inline instead. - Read local context first: `README.md`, `project-instructions.md`, `.github/sddp-config.md` when present, and all resolved canonical bootstrap artifacts. - Resolve canonical document paths using the same config-first, fallback-second pattern used by `project-planning/SKILL.md`. - `project-instructions.md` is always rooted at the workspace root and is never registered through `.github/sddp-config.md`. - Product Document, Technical Context Document, and Project Plan are mandatory. Halt if any are unresolvable. - Deployment & Operations Document is optional. When absent, skip DOD impact analysis and execution. - `specs/project-plan.md` is always considered for update because any accepted bootstrap change must be reflected in future epic planning. - Completed epics (`[X]`) in `specs/project-plan.md` are immutable. Only unchecked epics may be adjusted. - Each inline workflow invocation must receive the full change description plus artifact-specific amendment guidance derived from the impact analysis. Never pass vague instructions like "update as needed". - Interactive mode: ask the user to confirm or override the ...