Implementing Work

Implement the work described by the user in the spec or tickets.

Completion ownership

At invocation, establish and record exactly one mode:

• Caller-owned — only when the caller explicitly says it owns integration and final landing. /vibe-goal invokes ticket work in this mode.
• Standalone — a direct /vibe-implement workflow that owns tracker-directed branch retention or publication and the in-commit ticket update for a version-controlled local Markdown tracker; for a hosted tracker it owns tracker-change handling only in a later or resumed action after independent landing proof. It never owns final landing.

If the completion mode is unclear, stop and ask before creating or changing a workspace.

Before touching anything, record the current commit (git rev-parse HEAD) — that is the fixed point the review will run against.

Workspace isolation

First classify the requested change. A single-file change or other trivial change is below the isolation threshold and stays in place; do not create a dedicated worktree for it. In caller-owned mode, use only the ticket branch and worktree supplied by the caller; never create or use an integration workspace. For a larger change, if no caller-supplied ticket worktree is in use and the project uses git with at least one commit (git rev-parse HEAD succeeds), isolate the work in a dedicated worktree instead of editing the main checkout: