Integrate

Use the work-artifact contract throughout; keep the owning issue current as understanding changes. Reuse current guidance already in context, but read the latest artifact at the start.

Start from the work artifact, local Markdown, code, PR, or deployed result; earlier skills need not have run. Review the entire functioning slice through the Development Principles: does it solve the actual gap, use the smallest coherent change, read clearly, leave touched areas healthy, and have sufficient integrated verification? Use judgment proportionate to the change. Check useful comments and meaningful tests without producing a separate audit or requiring artificial coverage.

When work came from multiple agents, use the agent-continuation guidance: inspect the assembled change and its evidence, reconcile conflicting assumptions, and verify the combined behavior rather than inferring readiness from individual reports.

Make an active refinement pass: can existing behavior replace added machinery, can a responsibility be clearer, or can the experience solve the same problem with fewer moving parts? Within the authorized scope, remove unnecessary branches, abstractions, and prototype shortcuts, and improve unclear interactions or code. Preserve required behavior and contracts, avoid unrelated cleanup, and recheck behavior affected by refinements. Use the scope and completion guidance to judge further passes by concrete remaining gaps; stop when the requested outcome and evidence are sufficient. If no useful simplification exists, keep the implementation; less but better is a judgment, not a deletion quota. For review-only requests, recommend concrete refinements without editing.

Run appropriate checks and verify integrated product behavior when feasible. Check the useful outcome against the existing product, affected relationship contracts, and governing principles; passing local tests alone does not establish system coherence. If basic usefulness still needs future work, reconcile the boundary before claiming readiness. Read the delivery-slicing guidance when broader delivery boundaries need reconsideration. For a foundational issue, verify its enabled capability and identify the delivery it supports. Establish what a maintainer must now understand about responsibilities, relationships, and invariants, and preserve that meaning in Impact; use Explain when it needs fuller teaching. Reconcile material changes to an existing System Model under the optional shared-context guidance; recommend updates for review-only work. If review exposes a material problem in framing, system understanding, direction, or behavior, reconcile it and return to the appropriate earlier concern before claiming readiness.

Reconcile all five coordinates against actual code and verified behavior, replacing disproven claims and compressing for handoff under the shared contract.

Ensure consequential decisions and their reasons are explicit in the owning issue for humans and any existing Product Memory automation. Identify changes worth communicating and their audience under the shared-context guidance, preserving actual delivery state rather than treating review readiness as a release.

Before preparing a PR, ensure the artifact reflects implemented and verified work. Read and follow the PR guidance and its template, limits, and issue-link rule.

Merge, release, or deploy only when explicitly authorized. When they occur, update Reality with actual state, audience, live verification, and meaningful observations. Prefer independent release and feedback where useful; distinguish planned observation, observed feedback, and inference. Deployment alone does not prove live behavior, and a live test does not prove customer outcomes.