Turn a confirmed Build Contract into a verified result. Require both an implementation-ready contract and authority to change the scoped system. Do not infer deployment, publication, destructive migration, or external communication authority from implementation authority alone.
Establish The Execution Path
Read the target project's instructions, current state, and Build Contract. Check that tasks trace to desired behavior and must-pass scenarios. If the contract is represented by OpenSpec artifacts, use the official installed OpenSpec apply workflow and keep task state there. When an active relevant OpenSpec change exists, it remains the sole task state. Superpowers TDD, debugging, review, and verification skills may be used as focused implementation methods when available, but they must not create a duplicate plan or replace OpenSpec task state. Otherwise, use the active client's native plan or goal mechanism when useful; do not create duplicate workflow state.
Return to deep-design before editing when a material behavior, interface, data, migration, verification, release, or authority decision is missing or contradicted. Return to deep-grill when evidence invalidates root product intent. Small implementation details that do not alter the contract remain implementation decisions.
Build In Verified Slices
Implement the smallest dependency-ready vertical slice that produces observable behavior. Follow the established project stack and local ownership boundaries. Use engineering, testing, security, frontend, deployment, or other specialists only within the active slice and only when their focused method is needed.
After each slice, run the narrowest credible verification and inspect the result. Fix failures before expanding scope. Reassess the remaining contract when evidence changes; do not preserve a task list that the system has disproved. Keep user changes intact and do not broaden the requested behavior through opportunistic refactors.
Verify the must-pass scenarios at real entry points when practical, then run proportionate regression checks. Record meaningful gaps and the risk they leave. For an OpenSpec-backed contract, validate and archive the change only when the official workflow calls for it and the delivered behavior is complete.
Execute UI Contracts
For UI work, implement the contract's approved direction, preserved behavior, preview decision, target routes/states/viewports and review milestones. If a requested preview is still unapproved, return that decision to deep-design before production edits. Do not restart settled reference research or change design direction through a component choice.
Build layout/reflow and hierarchy before visual finish and motion, using realistic content and required states. Inspect shared component/token consumers and isolate scoped changes. Use react-bits when the contract selects its free components; verify current source, variants and dependencies in the target stack. When the contract selects GSAP, use the official gsap-* skills when available, otherwise the official GSAP documentation, and keep plugin registration and cleanup explicit. Preserve existing files and add only needed packages. Missing optional specialists do not block an equivalent verified implementation.
For broad redesigns, implement the representative end-to-end workflow first. Show the running result and obtain the contract's milestone approval before migrating remaining pages. Honor an explicit prose preference; otherwise use the active client's callable native question tool, falling back immediately to concise prose when none is callable. Revisions keep that milestone open. Small visual corrections stay in the current slice, while new scope, navigation or layout principles return to deep-design.
When the product can run, use browser interactions and actual implementation screenshots at agreed viewports. Check preserved routes, permissions, validation, requests/data effects and important states; inspect density, alignment, wrapping, overflow/clipping, focus, touch targets, reduced motion, broken assets and related console errors. Use meaningful runtime measurements for performance claims, not DOM-query timings or build success alone.
Do not require a Before/After board unless requested. Missing baseline screenshots are not a blocker; missing runtime access is a verification gap. State unavailable startup, auth, data or browser evidence and the checks not performed. A prototype or generated image cannot prove that production behavior passed.
Deliver Within Authority
Prepare commits, releases, deployment, publication, or external updates only when the user's authority covers them. Verify the actual remote or runtime result after any authorized delivery action. Stop and request new authority when completion would require a materially different external action.
Finish with exactly four concise fields, translated when appropriate to the user's language:
Changes:
Verification:
Not verified:
Remaining risks:
Include release, deployment, or artifact links inside those fields when applicable. Mark a field None when it is empty. The result is complete only when the Build Contract's authorized endpoint and must-pass scenarios are satisfied, or when a clearly reported blocker prevents further progress.