lz-execute

name	lz-execute
description	This skill should be used when the user wants to implement, build, or execute a coding task with strategic advisor guidance. Trigger phrases include "implement this task", "execute this plan", "build this feature", "code this up", "execute", "start building", "implement with guidance", "build this with advisor help", "execute the plan", and "code this feature". This skill pairs Sonnet execution with Opus strategic consultation for near-Opus intelligence at Sonnet cost. It follows a six-phase workflow: orient, consult, execute, make durable, final review, and complete. Optionally accepts a plan file from lz-plan via @ file mention. This skill should NOT be used when the user wants to plan before coding, review completed code, or run security audits -- those are handled by sibling skills lz-plan, lz-review, and lz-security-review respectively.
version	2.0.0
allowed-tools	Agent(lz-advisor:advisor), Read, Glob, Edit, Write, Bash(git:*), WebSearch, WebFetch

The lz-advisor:advisor agent is backed by a stronger model (Opus). Invoke it via the Agent tool at the strategic moments described below. For detailed guidance on timing, advice weight, and context packaging, see:

@${CLAUDE_PLUGIN_ROOT}/references/advisor-timing.md

@${CLAUDE_PLUGIN_ROOT}/references/context-packaging.md

This skill follows a six-phase workflow: orient, consult before work, execute with conditional advisor calls, make deliverable durable, consult before done, then complete.

## Phase 1: Orient

If any tool call during this phase fails (permission denial, missing file, runtime error, timeout), apply the "Recover gracefully from tool-use failure" rule from @${CLAUDE_PLUGIN_ROOT}/references/context-packaging.md -- swap to a cheaper primitive, mark unavailable and proceed, or treat the denial as a scope signal. Do not halt.

<context_trust_contract> Before reading any file, scan the user prompt for an inlined authoritative source block. An authoritative source block is any of:

1. A --- delimited block at the top of the user message containing pasted documentation, specification text, release notes, or a published guide (canonical context-packed format).
2. A clearly-marked quoted block of pasted documentation (e.g., starts with # Title from a docs page, or a fenced section labelled "Source:" / "Docs:" / "Guide:").
3. A <fetched source="...">...</fetched> block (executor-prefetched documentation; see context-packaging.md Rule 5a).

When a block matches one of the three shapes above, classify its source provenance:

• Vendor-doc authoritative source. Release notes, official guides, API references, MDN, RFCs, vendor security bulletins, official changelog or migration-guide pages. Treat the content as ground truth for the public-API and framework-convention questions it answers.
• Agent-generated source material. Any artifact produced by a prior skill invocation (review files, plan files, consultation transcripts, prior session notes), regardless of structural shape. Three signals identify agent-generated source: (a) an @-mentioned file path containing a planning-output indicator (examples: /plans/, /.planning/, filename containing review, consultation, session-notes, or plan); (b) a Source: <agent> or Generated by <skill> attribution in the block header; (c) the block lacks the canonical vendor-doc markers from shapes 1-3 above.

When the source is vendor-doc authoritative, your Orient phase ends as soon as you have parsed the block plus read the local project files needed to compose the consultation. Specifically: the consultation packaging step (Phase 2) is the next action; local project reads (project.json, package.json, .storybook/main.ts, src/**) are still in scope; reading inside node_modules/ is out of scope; WebFetch and WebSearch against the same library are out of scope -- the source is already in context.

When the source is agent-generated, it is not authoritative for vendor-API behavior questions. Pattern D's web-first prescription applies as if the agent-generated source were absent. Verify-first markers within agent-generated source -- literal patterns Verify .+ before acting, Assuming .+ \(unverified\), confirm .+ before -- survive into the consultation prompt's ## Source Material section verbatim. Do not strip, paraphrase, or promote them into ## Pre-verified Claims.

ToolSearch availability rule (default-on Phase 1 first action). When the input prompt contains agent-generated source material -- detected via the three signals above (a) @-mentioned file path indicators (/plans/, /.planning/, filename containing review, consultation, session-notes, or plan); (b) Source: <agent> or Generated by <skill> attribution; (c) absence of canonical vendor-doc markers -- invoke ToolSearch select:WebSearch,WebFetch (or equivalent ensure-loaded mechanism) as the FIRST Phase 1 action, before any local-project read or <orient_exploration_ranking> step. This rule fires unconditionally on the agent-generated-source signal; it does NOT wait for the orient ranking to classify the question as Class 2 / 3 / 4. The cost asymmetry justifies the unconditional firing: one redundant ToolSearch invocation costs approximately 0 tokens and 100ms latency (it is a permission-loading op, not a context op), whereas synthesizing a confabulated <pre_verified> block on an agent-generated input that should have triggered web verification costs an entire advisor consultation plus the downstream confidence-laundering cascade documented in Findings B.2 + H + GAP-G1+G2-empirical. The rule is therefore biased toward false positives (loading web tools when only Class-1 sub-questions exist) over false negatives (missing web tools when Class 2 / 3 / 4 sub-questions emerge during orient). If ToolSearch is not available in the session, proceed with ranking and let command_permissions.allowedTools gate WebSearch / WebFetch invocation directly.

Input: `/lz-plan Address findings in @plans/upstream-review.md` where the @-mentioned file is an agent-generated review file containing hedged claims about Storybook 10 + Compodoc behavior. The agent-generated-source signal fires (path matches `/plans/` and filename contains `plan`).

First Phase 1 action: invoke ToolSearch select:WebSearch,WebFetch. This loads the web tools BEFORE the executor reads plans/upstream-review.md and BEFORE the orient ranking classifies any of the review's sub-questions. When the executor subsequently encounters Class 2 / 3 / 4 surfaces in the review (e.g., "verify @storybook/addon-docs/angular still exports setCompodocJson in 10.3.5"), the web tools are already loaded -- no second-pass tool-loading delay, no risk of the orient ranking deciding "I have enough context already, skip web verification." The redundant ToolSearch invocation on Class-1 sub-questions (e.g., "does package.json declare @compodoc/compodoc?") costs approximately 0 tokens because the tools are still permission-loaded but unused.

Input: `/lz-plan` with a `---`-delimited block at the top of the user message containing pasted Storybook 10.3.5 release notes (vendor-doc authoritative source per shape 1 in the `` classification). No @-mentioned file paths, no `Source: ` attribution, the block matches the canonical vendor-doc shape with a `# Storybook 10.3.5 Release Notes` heading.

First Phase 1 action: do NOT invoke ToolSearch. The vendor-doc authoritative source classification rules out the agent-generated-source signal; the user has supplied the verification context inline. Re-fetching the same vendor doc via WebSearch + WebFetch would waste the executor's tokens and the advisor's turn budget per Common Contract Rule 5 ("when the user has inlined an authoritative source, the source IS the verification -- no further fetch or read is required"). Proceed directly to the local-project reads needed to compose the consultation; the <orient_exploration_ranking> step decides whether project-state reads suffice. ToolSearch fires LATER if and only if the executor encounters a sub-question the inlined vendor doc does not answer.

pv-* synthesis precondition. Before packaging any <pre_verified> block on a Class 2 / 3 / 4 question per @${CLAUDE_PLUGIN_ROOT}/references/orient-exploration.md, verify either (a) the block's <evidence> element cites a Read or WebFetch tool output produced in the current skill execution (path or URL on the parent source= attribute, verbatim tool-output excerpt as evidence content), OR (b) the ToolSearch availability rule above has fired in the current skill execution. If neither precondition holds, the synthesis is non-conforming per @${CLAUDE_PLUGIN_ROOT}/references/context-packaging.md Common Contract Rule 5b -- do not ship the block. The self-anchor pathway (synthesizing pv-* from claimed framework / library / runtime knowledge without a tool-output excerpt) is the dominant Phase 6 + Phase 7 empirical failure mode (Finding H); this precondition closes it at the synthesis layer.

When no authoritative source block is present, follow the standard exploration ranking below. </context_trust_contract>

<orient_exploration_ranking> When you need information about a third-party library, framework, or public API beyond what the authoritative source block provides, take ONE of the following actions:

1. WebSearch then WebFetch for library-behavior questions -- if the question is about the library itself (its current API, recommended configuration, integration pattern, or migration path between versions), the first orient action is WebSearch with the library name plus the installed version plus the specific symbol or topic, then WebFetch the top result. This applies whenever the answer requires knowing what the library currently does or recommends, even when the prompt also mentions your project (e.g., "set up X in this Y library" still requires knowing X's current setup pattern). Vendor docs reorganize between releases and training data drifts, so search discovers the current canonical URL rather than guessing it. Skip the WebSearch only when a <fetched> block in the user message or a prior turn in this session has already provided the canonical URL with high confidence. Do not substitute Bash invocations of curl, node scripts, or browser automation for the WebSearch step itself; those tools take a URL as input and cannot replace the search that discovers the URL.

2. Local-project read for project-state-only questions -- if the question is solely about how your project's existing files configure or use the library (no question about the library's own behavior or recommended pattern), read project files only: project.json, package.json, .storybook/, src/, tsconfig*.json. Stop when the project-side question is answered. If the question requires knowing the library's recommended pattern in addition to your project's current state, treat it as a step 1 question with project files as corroboration.

3. git grep for project usage patterns -- when an existing pattern in the project answers the question (e.g., "how does this project already configure Storybook addons?"), git grep against project source.

If none of steps 1-3 produces the answer you need, name the gap explicitly in the consultation Findings section and proceed. Do not extend Orient indefinitely. The advisor can ask a clarifying question if your gap blocks its decision.

Worked example. Question: "Set up Compodoc with Storybook in this Nx Angular library so the Docs tab renders descriptions." Class: step 1 (library behavior). The "set up" part requires knowing the current Storybook + Compodoc integration mechanism (which API is exported, which config keys exist, how docs auto-generation is triggered) -- that knowledge lives in vendor docs, not in your project's existing config files. Reading node_modules/@storybook/angular/dist/ first would skip the docs that explain the integration -- compiled chunks show what was built, not what the library currently recommends. First action: WebSearch for "Storybook Compodoc Angular setup", then WebFetch the top result; corroborate with reads of project.json and .storybook/ after.

For a question-class-aware ranking that decides which orient source to read FIRST based on the class of question (type-symbol existence, API currency, migration / deprecation, language semantics), see @${CLAUDE_PLUGIN_ROOT}/references/orient-exploration.md. </orient_exploration_ranking>

Understand the task scope and current codebase state before doing any work.

If the user mentioned a plan file (via @ file reference), read it first. Use the plan's Strategic Direction and Steps as the foundation for the task. Orient by verifying the plan's assumptions against the current codebase -- check that referenced files exist, patterns match, and dependencies hold. Skip redundant exploration the plan already covers.

If no plan file was mentioned, orient from scratch:

• Read files relevant to the user's request
• Examine directory structure and dependencies
• Identify constraints, existing patterns, and integration points
• Note what exists and what needs to change
• Stop exploring when you have enough context to formulate a specific question for the advisor.
• When the task names a framework or build tool (Nx, Angular, Next.js, Vite, Webpack, Turborepo, and similar build-orchestration systems -- the list is illustrative, not exhaustive), identify the framework-convention claims the task depends on (cache inputs, dependsOn semantics, target lifecycle, addon configuration, generator behavior) and verify each load-bearing claim before consulting. If a plan file already surfaced <pre_verified> framework-convention claims, re-verify them against the current codebase state (versions may have shifted); gap-fill any missing claims. Framework-convention claims use the same block schema as package-behavior claims (see @${CLAUDE_PLUGIN_ROOT}/references/context-packaging.md).

Do not write code or make changes during orientation. Do not consult the advisor yet -- orientation is preparation, not substantive work.

## Phase 2: Consult the Advisor

Before starting substantive work, invoke the lz-advisor:advisor agent via the Agent tool. Package the pre-execute consultation prompt per the Proposal template in @${CLAUDE_PLUGIN_ROOT}/references/context-packaging.md.

## Phase 3: Execute

Carry out the task following the advisor's strategic direction. Read files, write code, run tests, iterate on errors. This is the substantive work phase.

Give the advisor's guidance serious weight. If a step fails empirically, or primary-source evidence contradicts a specific claim, adapt. A passing self-test is not evidence the advice is wrong -- it is evidence the test may not check what the advice checks.

When to Consult Again

During execution, consult the advisor again when:

• Empirical contradiction: Evidence contradicts the plan or pre-execute guidance -- a type error, failing test, or tool output that invalidates an assumption the approach depends on
• Non-trivial approach change: The planned step does not work and the substitute requires strategic judgment, not just a surface fix
• Silent failure: A tool exits successfully but the expected artifact is missing, empty, or wrong -- the cause is unclear
• Strategic shape change: A deviation from the plan changes its overall structure -- moving configuration between files, swapping integration patterns, or adding a workaround with ongoing maintenance cost

Do not re-consult for:

• Trivial fixes: typos, import paths, obvious refactors -- proceed solo
• Format or style corrections -- proceed solo

Keep re-consultation prompts brief (2-3 sentences): what changed, what options are being considered, what decision is needed. These calls reuse the pre-execute consultation context implicitly; a full orient repackage is unnecessary.

Reconciliation

If findings point one way and the advisor points another, do not silently switch. Surface the conflict in one more advisor call: "I found X, you suggested Y -- which constraint breaks the tie?" The advisor saw the evidence provided but may have underweighted it; a reconciliation call is cheaper than committing to the wrong branch.

Context Packaging for Mid-Execution Consultations

Use the Proposal (short form) variant in @${CLAUDE_PLUGIN_ROOT}/references/context-packaging.md. Two to three sentences covering what changed, what options are being considered, and what decision is needed. The pre-execute consultation context carries implicitly; a full repackage is unnecessary.

<verify_before_commit>

Phase 3.5: Verify Before Commit

Before staging or committing changes (Phase 4), execute pending verification actions surfaced by upstream artifacts or by the advisor. This phase closes the gap between hedge-preservation at the prompt-construction layer (Phase 6 Plan 06-05) and verification-completion at the execute layer.

Hedge marker resolution (E.1)

If the source material in your pre-execute consultation prompt contains an unresolved verify-first marker on a load-bearing implementation choice -- sentinel patterns \b(unverified)\b, \bverify .+ before acting\b, \bAssuming .+ \(unverified\)\b, \bconfirm .+ before\b, \bfall back to .+ if .+\b -- AND the advisor's Strategic Direction did not flag the hedge with the literal Unresolved hedge: frame, perform the verification action yourself before staging the related changes. Add a Verified: <claim> trailer to the commit body naming the claim that was verified.

If the advisor's Strategic Direction or **Critical:** block flagged the hedge with the literal frame Unresolved hedge: <marker>. Verify <action> before committing., treat the verification action as a hard precondition for the commit. Do not stage the related changes until the verification has run AND its outcome is recorded in either (a) a new <pre_verified> block synthesized for the next consultation, OR (b) a Verified: <claim> trailer on the commit body.

Plan-step shape rule (E.2)

When the plan input contains a numbered, executable plan step structured as:

N. **Validate** (or Verify, Test, Confirm)
   - Run: `<command>`
   - Verify: <observable conditions>

The Run: directive is an EXECUTOR-BOUND action, not a USER-FACING instruction. Execute the <command> as a Bash invocation BEFORE the commit that ships the related changes. The post-commit summary may surface the result to the user, but the verification itself runs pre-commit.

Select the verify target by change surface (E.3)

The verification that matters is the one that exercises the files you changed. Before choosing a verify command, identify the dominant change surface and run the target that actually loads it. A unit-test pass is not evidence a config change is correct -- it exercises the source, not the changed config surface. When in doubt, run the target whose executor reads the file you edited.

For the canonical surface-to-target mapping (which target validates which change surface), the worked examples, and the stale-daemon tooling-freshness caveat, see @${CLAUDE_PLUGIN_ROOT}/references/verify-target-selection.md.

Pre-commit validation scope

Cheap synchronous validations execute pre-commit:

• npm ls, npm install, git grep, git check-ignore, git status, lint, tsc --noEmit, tsc --noEmit --pretty, jest --bail, focused test runs
• Commands expected to complete in under 30 seconds on a warm dev machine

For long-running async validations (nx storybook, nx test, nx test-storybook, nx serve*, nx run-many over many projects, full test suites lasting longer than 30 seconds, dev-server startup or watch-mode commands), wait for completion before committing. Do not commit before the validation finishes; the commit must reflect the actual verified state. Record completed verifications via Verified: trailers.

Verified: trailer convention

Format: Verified: <claim text> on its own line in the commit body, after the body paragraphs. Multiple trailers are allowed (one per verified claim). Do not embed in the subject line.

The trailer is a DETECTION SIGNAL, not a verification mechanism. Phase 7's smoke fixture E-verify-before-commit.sh (created in Plan 07-06) grep-checks BOTH (a) the Verified: trailer presence in git log --format="%B" -1, AND (b) the corresponding tool_use event for the verification command in the JSONL trace. Either alone is non-conforming -- a trailer without a tool_use event is a self-report (unreliable per outcome-based verification research); a tool_use event without a trailer is undocumented (loses the audit trail).

Reconciliation extension (apply-then-revert flow, Finding A)

The Phase 3 Reconciliation rule already covers findings-vs-advisor conflicts during execution. It now also covers Phase 6 (Complete) apply-then-revert flows on advisor **Critical:** content:

If you applied an advisor **Critical:** block during Phase 3 / 4 / 5 and conclude during Phase 6 that it does not apply, do not revert silently. Choose ONE of:

• (a) Verify the contradicting evidence empirically (compile, run, or read the relevant source) and document the verification in a new commit body's Verified: trailer naming the claim verified, OR
• (b) Issue a reconciliation call to the advisor: "Applied your Critical X, then found Y contradicts it. Which is correct?"

Silent revert of advisor **Critical:** content based on un-grounded internal reasoning is forbidden. The xhigh advisor cost (approximately one extra advisor consultation) is cheap insurance against Critical-content silent loss. </verify_before_commit>

## Phase 4: Make Durable

Before the final advisor consultation, make the deliverable durable.

0. Apply Phase 3.5 verify-before-commit rules from <verify_before_commit> -- resolve hedge markers, execute plan Run: directives, and record verifications via Verified: trailers.
1. Write all files -- ensure nothing remains only in memory or tool output
2. Run tests if applicable and fix failures
3. Commit the changes: stage specific files by name (never use git add . or git add -A) and create a commit with a clear message

The commit ensures work survives if the session ends during the final advisor call. An unwritten or uncommitted result does not persist.

## Phase 5: Final Advisor Consultation

After committing, invoke the lz-advisor:advisor agent one more time. Package the final review consultation prompt per the Verification template in @${CLAUDE_PLUGIN_ROOT}/references/context-packaging.md. Include a summary of changes made, test results if applicable, and the commit reference.

Adapt the template for the advisor's output shape. The Verification template's Findings-list structure (numbered findings with Severity / OWASP tags / code context) is shaped for the reviewer and security- reviewer agents; the advisor's Output Constraint requires a 100-word enumerated response beginning with 1. and forbids Findings-list output. Skip the Findings-list scaffold for this call: package the summary block (changes made, test results, commit reference) plus a single targeted Request ("verify the approach is sound and flag any concerns"). Do not fabricate a reviewer-style grouped findings report -- the advisor does not produce that shape.

Pack the post-change content the advisor would otherwise need to locate. Include the changed files' current contents (or the commit's git diff / git show) in a ## Relevant File Contents block in the consultation prompt -- not just a prose summary of what changed. The advisor's budget is 3 turns; if it has to find the file you changed, it can exhaust that budget on disk before synthesizing. A summary ("added input()/output() with JSDoc") tells the advisor what you did; the actual file text or diff is what lets it review the work. When a changed file does not follow the naming convention the advisor might expect (for example, a component not named *.component.ts), packing its contents removes the advisor's reason to search for it. The thing you want reviewed must be in the prompt, not only described.

This is a final check, not a request for approval. The advisor verifies the approach is sound and flags concerns the executor may have missed.

Handling a Critical: Block

If the advisor response contains a **Critical:** block, treat its content as a primary signal with the same actionability weight as the numbered answers -- NOT bonus-triage content. The advisor's Response Structure budget-excludes Critical blocks from the 100-word cap precisely because they carry primary-signal weight; the budget exclusion is not an invitation to downweight the content. Address any Critical concerns in Phase 6 before declaring the task done.

## Phase 6: Complete

If the advisor flagged concerns in the final consultation -- including any content inside a **Critical:** block, which is treated as primary signal equivalent to the numbered answers -- address Critical items first:

• Address actionable concerns (fix bugs, handle edge cases, update tests)
• Commit any corrections (stage specific files by name)
• If a concern requires a fundamental rethink, surface it to the user rather than silently rebuilding

If the advisor confirmed the approach is sound, present the completed work to the user: summarize what was built, what files were created or changed, and what tests pass.

Completion Verdict (scope-disambiguated)

When summarizing the completed work to the user, include a **Verdict axis:** line stating the axis of correctness the verification covers:

• For most coding tasks: **Verdict axis:** scope: api-correctness
• For security-focused execute invocations (rare; usually security-review handles those): **Verdict axis:** scope: security-threats
• For performance-focused execute invocations: **Verdict axis:** scope: performance
• For accessibility-focused execute invocations: **Verdict axis:** scope: accessibility

Default to scope: api-correctness unless the task explicitly named a different axis. Per references/context-packaging.md "Scope-Disambiguated Provenance Markers", downstream consumers MUST check scope-match before treating the verdict as authoritative.

After completing the task, present a summary to the user. If the work was informed by a plan file, note any deviations from the original plan.