---
name: ll2
description: Clarify a larger delegated task with a lightweight deliverable sketch, expand it into LLL's reviewable HTML goal contract, then run it after an explicit Launch.
---

# LL2

Keep LLL's board and Prepare → review → Launch flow. Add a lightweight sketch before the full contract. Never queue an executor during preparation. If Matt requests a full contract for already-settled deliverables, give the short chat summary and go straight to step 2. Do not ask him to approve the same outputs again.

## 1. Sketch the deliverables

- Start in chat with one sentence about the current situation and a short bullet list of proposed observable deliverables. Use the request and facts already available. Do not begin with a broad audit, transcript extraction or access inventory.
- If an unknown would change the outcome or priorities, ask a short operational multiple-choice question with genuinely plausible options. Do not invent equal probabilities or ask the user to choose implementation details. Questions are optional.
- Put that same list into the bundled HTML immediately, with a small diagram: current state, available inputs, desired state and observable deliverables. Mark guesses as proposed or unknown.
- Give each deliverable a stable ID and a plain explanation: current problem, exact proposed change and where the result will be visible. Add a small preview only when it helps: an existing screenshot, a labeled first-block wireframe, or a 2–4 node process diagram. A preview is not completion proof.
- Publish one stable commentable URL. Open the board only when the user requests it. Matt’s LL2 request explicitly says: “When I invoke this skill I will see the HTML template appear in the sidebar ASAP.” That authorizes this board in this flow when a panel is available. Otherwise give its URL. Do not open unrelated artifacts or child goal panels.
- Keep sketches free of requirement/verification pairs. After steering, remove answered questions, carry settled answers into the relevant inputs or sourced constraints, and retain deliverable IDs. Matt can annotate and ask either to regenerate the sketch or expand it into the full contract. Neither action launches execution.

## 2. Expand the same board

- On approval to expand, reconcile chat, annotations and inline edits. Read the comments once, record the read time and apply them to the same deliverable IDs and document URL. Preserve the sketch bullets and previews.
- Add each required observable, measurable or user-experienced result and its appropriate verification, following [launch-agent](../launch-agent/SKILL.md). One deliverable and one criterion are enough when appropriate.
- Add only relevant constraints with their source, shared resources/tools and any per-deliverable overrides. Preserve settled copy, offers, quantities and scope. Keep unresolved choices visible.
- Use targeted source/access checks only when needed to make the contract executable or resolve a consequential unknown. Do not prepare a separate resource dossier for the child.
- Use nested toggles by default: checks and constraints under each main card, then evidence/screenshots under each check. Start every planned check unchecked with evidence pending. No invented success, fixed criterion quota or mandatory refinement council.
- Republish the same board for review. A contract ready for review is not its deliverables completed. Wait for a later explicit Launch.

## 3. Launch and finish

- Reconcile the latest approved contract and any changed annotations. Use [launch-agent](../launch-agent/SKILL.md) for one fresh executor, preserving the requested model; otherwise use LLL's Sol Medium default.
- Give a self-contained /goal with deliverables, requirement/verification pairs, shared resources/rules, scope and authority, the stable board URL, owned output paths, an assigned report path/template and the exact parent return channel.
- Let the child discover relevant inputs, execute, recover, verify and maintain the board. The parent continues independent work, then waits passively. Never load the child transcript or poll progress.
- After DONE or STALLED, read the concise report once and check the actual main artifacts and decisive evidence. Correct the same child if needed, then wait again. Ordinary recovery stays within the authorized goal; pause or changed review authority takes precedence.
- Accept only the original requested result and its proof. Preserve normal workflow versus QA-only evidence and technical versus design/content quality. Update the board and give one parent handoff. No automatic child wrap-up.

Read [board.md](references/board.md) when filling the board and [execution.md](references/execution.md) at launch. Historical analysis is opt-in, not part of every invocation.

# Two short examples

## Website improvement: sketch first

User: “Use $ll2 to improve our booking page. People seem to get lost.”

Start in chat:

> The page needs a clearer route from deciding to book to receiving confirmation.
>
> Suggested deliverables:
> - An updated booking page with a clear next action and visible confirmation.
> - A short verification report showing whether the normal booking flow works.
>
> Which outcome matters most for this version?
> - Make the existing booking route easier to understand.
> - Shorten the booking route, even if its steps change.

The HTML sketch repeats those deliverables. If a current screenshot is already available, use it as a small reference. Do not investigate analytics or redesign the page before the user chooses the intended result.

When the user asks to expand, add concrete requirement/verification pairs to the same cards. For example: **Successful booking shows confirmation → complete one permitted test booking and inspect the visible confirmation.** Keep any actual booking or client-message authority clear. Wait for Launch.

## Process change: retain settled decisions

User: “Use $ll2 to route replied leads into our existing CRM. Keep the current table.”

Start in chat:

> Replied leads should reach the existing CRM table without losing its current data.
>
> Suggested deliverables:
> - A working replied-lead-to-CRM process using the existing table.
> - A concise report showing one normal record arriving once with the required fields.

Use a small proposed-process preview: **Human reply → Find/create CRM record → Update existing table**. Ask a question only if an unresolved outcome changes the process, such as which reply types qualify. Do not ask the user to choose an API or automation library.

After approval to expand, pair the requirements with checks: **No duplicate record for the same lead → run one applicable duplicate check against the resulting table.** State shared sources and rules once. Preserve “keep the current table” as an explicit user constraint. Wait for Launch.

# Fill the same board in two stages

## Sketch: make the intended result easy to review

- Start with the same short deliverable list you gave in chat.
- Show four things in the overview: current state, inputs, desired state, observable deliverables.
- Use facts already available. Label guesses as proposed and missing facts as unknown.
- Give each deliverable a stable ID, a clear name and its output location.
- Explain the current problem and proposed change in plain language.
- Show optional outcome questions with no preselected answer.
- Show the next choice: regenerate this sketch, or expand it into a full contract.
- Hide execution counters, recovery logs and empty proof sections. Nothing has launched.

## Previews: optional and small

Use one small preview per deliverable only when it helps the user understand the result:

- Existing asset: a small screenshot labelled **Current reference**.
- New HTML asset: its first block as a simple wireframe labelled **Proposed layout**.
- Process: a 2–4 node diagram, such as **Trigger → Action → Outcome**, labelled **Proposed process**.

Reuse an available image instead of investigating the entire asset. Do not build the deliverable just to preview it. Do not add a preview quota. A sketch preview does not prove completion.

## Contract: add the checks below the same cards

Keep the deliverable names, overview, previews, IDs and public URL. Add:

- The observable, measurable or user-experienced result for each deliverable.
- Each requirement paired with an appropriate verification.
- Relevant constraints and their source.
- Shared resources and tools, with per-deliverable exceptions only when useful.
- Output and report locations.
- Any remaining decision that affects execution.

Use a code or browser check when it is applicable and straightforward. Otherwise name the concrete observation that will establish the requirement. One deliverable and one requirement are enough when appropriate.

Use the Analit board’s default nested toggles: keep **Checks and constraints** collapsed beneath each main card, then keep each criterion’s **Evidence and screenshots** collapsed inside it. The requirement, verification method and check state remain together when the outer toggle is opened. Do not mark a planned check as passed. Label **Ready for review** separately from **Launched**, **Verified**, **Published**, **Sent** or **Serving**.

## Preserve identity and annotations

- Start from `assets/verification-board.html`, the unchanged LLL template. Use the renderer for stage-specific content.
- Render with `python3 scripts/render_board.py --data <board.json> --out <board.html> --stage sketch` (or `--stage contract` after approval).
- Copy the input shape from `examples/board-data.json` instead of inventing field names. Process previews use `type: flow` with 2–4 nodes, not `type: process`. Contract-only resources, tools, paths and comment-read time can be omitted from a sketch. Use semantic IDs, not array positions. Give each deliverable’s text fields stable `id` or `data-cid` attributes so comments survive expansion.
- Publish through `$comment-html-review-host` with one stable document ID and URL.
- Before a revision or launch, reconcile current chat, comments and inline edits. Record when comments were read.
- Retain unchanged card and text IDs across sketch revisions, contract expansion and execution. Remove a card only when the user removes that deliverable.
- Preserve useful preview and settled wording. Change the proposed result only when the user's steering or new evidence justifies it.
- Never replace this review surface with a separate execution dashboard. Update the existing board and its execution state so a running or completed task is not labelled “not launched”.

The HTML is a review surface. Its displayed next choices do not trigger execution by themselves.

# Execute the approved contract

## Before launch

- Require explicit **Launch**. Approving the sketch or asking for a full contract does not launch execution.
- Reconcile the current contract with newer chat instructions and annotations.
- Use `$launch-agent` and one fresh executor. Use the user's requested model, otherwise LLL's Sol Medium default.
- Give the child the approved goal in its prompt. Do not make a separate Markdown assignment or resource dossier.
- Include deliverables and requirement/verification pairs, shared resources/tools/rules, owned outputs, the board URL, report path, report template and exact parent return channel.
- Point to existing folders, databases and assets. Let the child find relevant inputs. Add per-deliverable resources only when they differ.
- Preserve explicit user constraints and their source. Label parent implementation choices separately.

## During execution

- The child owns implementation, verification, board updates and recovery.
- Test one representative normal case before a large batch or consequential rollout.
- Before changing live configuration, read its current values. Record any difference from the reviewed baseline and retain a rollback snapshot.
- Preserve settled copy, quantities, offers and scope. Do not restart discovery merely because a new executor is used.
- Keep normal workflow evidence separate from synthetic QA evidence. Check design/content quality as well as technical behavior when they matter to the deliverable.
- For GUI checks, use actual post-change screenshots and an independent blind Luna High description, then compare with the criterion. Follow the required section QA for client website deployments, including postdeployment images. Internal documents and simple HTML do not need that website loop.
- Apply `$am-i-blocked` before declaring a stall. Try viable permitted alternatives and change strategy after unchanged failures.
- A user pause or changed authority overrides the earlier launch. Block only the affected action.
- The parent does independent work, then waits passively. Do not inspect child progress or load its transcript.
- The child writes a concise report using `$launch-agent`'s report template, then returns DONE or STALLED with that path once. No routine child `$wrap-up` or `$to-my-parent`.

## Acceptance and handoff

- Read the finished report once. Check the main artifacts and decisive evidence against the original request and later steering.
- A green board, passing technical test or published page alone is not proof of the requested business outcome.
- For STALLED, resolve the precise missing decision or give the same child a bounded recovery instruction. Do not restart the whole task by default.
- For a failed acceptance check, send one bounded correction to the same child and wait again.
- Keep one reconciled final check tally. Where relevant, distinguish configured, eligible, serving and observed outcomes.
- Update the existing board with honest final states, links and remaining limits.
- Deliver one combined parent recap using the applicable handoff skills. Keep bulky delegated evidence in its report.