implement-client-feedback · git:20260714.4835a66 · 2026-07-14 · sha256 defb8b6dbcf0dd5e
implement-client-feedback git:20260714.4835a66A
Immutable. This exact content never changes and is served at /api/v1/blob/defb8b6dbcf0dd5e.
--- name: implement-client-feedback description: Convert client revision notes into scoped implementation work with traceable decisions and verification. Use when a user provides comments, marked-up files, approval notes, or a feedback handoff and asks to implement changes, preserve approved elements, enforce exclusions, prepare a new version, or prove that every requested item was handled. --- # Implement Client Feedback Turn client language into a controlled implementation contract, apply the authorized changes, and verify the result against the feedback source. ## 1. Establish the authoritative feedback set - Confirm the project root, current artifact or version, feedback source, and requested outcome. - Read the latest approved brief, feedback, current implementation, and relevant handoff material before changing files. - Treat the latest explicit decision as authoritative when it overrides earlier direction. - Preserve literal replacement text, names, exclusions, filenames, and approved claims. ## 2. Build the feedback matrix - Use [assets/feedback-implementation-brief.md](assets/feedback-implementation-brief.md). - Classify every item as `change`, `keep`, `remove`, `exclude`, `question`, or `future`. - Record the literal instruction, minimal interpretation, target, acceptance evidence, and status. - Keep rejected concepts in a prominent exclusion list so older files or templates cannot reintroduce them. - Separate client requests from optional internal improvements. ## 3. Resolve only material ambiguity - Inspect the current artifact to resolve locations, nearby patterns, and implementation details. - Record small reversible assumptions that cannot change the intended outcome. - Ask before choosing a visual direction, changing approved scope, removing a public route, altering rights or deliverables, or contradicting literal feedback. - Do not turn a focused revision into a redesign. ## 4. Implement with controlled scope - Follow the project's existing architecture, versioning, and file conventions. - Start from the latest approved foundation. - Preserve approved elements and unrelated user-owned changes. - Apply only confirmed changes and keep excluded items absent. - Use the appropriate project tools for code, copy, images, documents, or website work. - Do not deploy, publish, upload, send, or change external permissions unless the user explicitly authorizes that separate action. ## 5. Verify every feedback item - Check each matrix row against the final files or rendered result. - Confirm additions, exact replacements, removals, preserved elements, and exclusions. - Run checks appropriate to the artifact, such as syntax, build, route, browser, dimensions, contrast, packaging, or document inspection. - Mark every item `verified`, `partial`, `blocked`, or `awaiting client`. - Do not call the revision complete while a required item is partial or unverified. ## 6. Report the review state Return the implementation-brief location, version or artifact location, changed items, verification results, preserved exclusions, unresolved questions, and next client-review action.