/deepline-plays-review

name: deepline-plays-review
description: 'Use this skill when a human needs to review a Deepline Play result and hand feedback, labels, or approval back to the agent for revision, evaluation, comparison, or bounded iteration. Triggers on “put this run in a Sheet,” “review these results,” “read my feedback,” “make this a standing rule,” “never regress on this case,” “compare these runs,” “keep improving,” or “add the revised run to the same spreadsheet.” Skip ordinary Play authoring or execution with no human review loop, generic spreadsheet work, and one-off CSV export.'

Review and Improve Deepline Plays

Quick Start

npm install -g deepline
# Fallback for secure sandboxes: mkdir -p "$HOME/.local" && npm config set prefix "$HOME/.local" && export PATH="$HOME/.local/bin:$PATH" && npm install -g deepline --registry https://code.deepline.com/api/v2/npm/
deepline auth register --wait auto
deepline auth wait --timeout 120 # completes Cowork/browser approval; no-op if already connected
deepline auth status
deepline -h

CLI resolution

Run `deepline` when it is available. If the shell reports that command is missing, use `<workspace-root>/.deepline/runtime/bin/deepline` (or the npm-created `.cmd` shim on Windows). If neither exists, follow `https://code.deepline.com/INSTALL.md` to set up Deepline.

Improve a Play through one loop:

revision → run → assess → decide → next revision

Google Sheets is the human review surface. The Play revision, completed run, and durable dataset remain the execution record.

Route the request

| User intent | Start here | | ------------------------------------ | ---------------------------------------------- | | Put a run in a Sheet | Export the completed dataset for review | | Address edits, notes, or comments | Read fresh feedback and run one revision | | Make feedback a standing rule | Record a general expectation | | Never regress on a corrected case | Add a case-specific expectation or golden case | | Compare revisions | Evaluate both against one frozen basis | | Try several improvements | Establish a bounded agent-driven loop | | Keep improving together across turns | Resume the loop and yield after each candidate |

**Stop at planning boundaries.** When the user asks for a plan, classification, or proposed evaluation before any calls or edits, write it from the supplied context and stop. Do not inspect live Plays, runs, files, or tool contracts, even through read-only commands. That exploration cannot grant missing authority or define a budget; it turns a short planning turn into irrelevant archaeology and can accidentally start paid work. Resume discovery only after the user asks to proceed.

If the user only wants to build, run, or debug a Play, use `deepline-plays`. If they only want unrelated spreadsheet manipulation, use the relevant spreadsheet workflow. This skill begins when a result will be reviewed, measured, or used to change the Play.

Establish or resume the loop

Use four concepts:

• **Revision:** the Play version under test.
• **Run:** that revision executed on known inputs.
• **Expectation:** what good means, either generally or for a specific case.
• **Assessment:** evidence about how a run met an expectation.

A golden dataset is a versioned collection of representative inputs with case-specific expectations. An evaluation is a reproducible assessment of one revision against a fixed basis. Optimization is permission to repeat the loop, not a separate kind of evaluation.

Before changing the Play, state or recover:

objective
baseline revision and run
applicable expectations
human-stepped or agent-driven control
allowed changes
budget and stopping rule
run, dataset, spreadsheet, and tab breadcrumbs

Default to one candidate and then yield. Repeated autonomous changes can spend credits and move farther than the user intended, so require explicit authority, mutation scope, budget, and a stopping rule before trying multiple candidates.

Set up a durable working directory. Files in `/tmp` disappear, which can erase the evidence needed to resume an improvement session:

WORKDIR="deepline/data/<descriptive-slug>"
mkdir -p "$WORKDIR"

Names in this skill are starting hints. Discover the live Workspace tools and confirm their contracts before first use:

deepline tools search "Google Workspace dataset export" --json
deepline tools search "Google Workspace API request" --json
deepline tools describe google_workspace_export_dataset --json
deepline tools describe google_workspace_request --json

Run and review

Run the Play and keep its completed run ID. When provider calls are involved, pilot on one or two rows before scaling: a wrong payload or output shape can otherwise waste credits across every candidate. Preserve source and status columns because they explain why a row passed or failed.

Inspect the completed run and choose the durable dataset path the user wants to review:

deepline runs get "$RUN_ID" --full --json > "$WORKDIR/run.json"
jq '.package.datasets[] | {path, datasetId, tableNamespace, rowCount}' \
  "$WORKDIR/run.json"

Export the persisted dataset, never CLI preview rows. Use one operation key for one intended export; reuse it only to retry that exact request. Leave `SPREADSHEET_ID` empty for a new workbook, or set it to append a new immutable run tab to an existing workbook:

: "${SKILL_DIR:?Set SKILL_DIR to the installed deepline-plays-review directory}"
: "${RUN_ID:?Set RUN_ID to a completed Play run}"
DATASET_PATH="${DATASET_PATH:-result.rows}"
TAB_LABEL="${TAB_LABEL:-Results}"
SPREADSHEET_TITLE="${SPREADSHEET_TITLE:-Play review}"
OPERATION_KEY="${OPERATION_KEY:-review-$(date -u +%Y%m%dT%H%M%SZ)}"
PRESENTATION="$(node "$SKILL_DIR/scripts/review-sheet-present