Skeleton first: prove the workflow cheaply, then scale

Agents tend to build every stage at full size before anything has run end to end. In data and AI work that fails expensively: a wrong prompt runs over a whole table, a wrong grain is discovered after twenty models exist, a big warehouse burns credits on a query that returns the wrong answer.

This skill changes the order of work:

1. Make the whole path work on the smallest possible input with the cheapest settings.
2. Prove it with a test.
3. Scale up in cost-gated rungs, measuring and projecting cost before each one.
4. Only then add features, one at a time, re-running the tests after each.

When to Use

• A workflow with 2+ stages (ingest -> transform -> model/LLM -> output), or anything that touches paid compute: warehouse credits, LLM tokens, embeddings, API calls.
• New or unfamiliar data, a new tool or SDK, an architecture that has not run in this environment before.
• The user asks to "build X end to end", "set up the pipeline", "process all the documents", "create the models".

Skip it for: one-file fixes, a single query, work already proven at full scale, or when the user explicitly says to go straight to full scale (then still state the projected cost first).

Step 0 - Define "it works" before building

Write down, and show the user in 3-5 lines:

• The thinnest end-to-end path: every stage present, the minimum of each. Example: 1 source table -> 1 transform -> 1 LLM call -> 1 output row.
• One pass/fail test a person can check, e.g. "for these 3 sample rows the output has columns A, B, C and the value for row 2 is X". Prefer tests with a known right answer.
• A budget: maximum spend and time for the whole job, and for the skeleton (the skeleton should cost almost nothing).

If the user has not given a budget, propose one and say so.

Step 1 - Write the ladder

Plan the work as rungs. Each rung adds exactly one thing and has a gate.

Show the ladder to the user before building unless the task is small. Keep it short.

Step 2 - Build L0, the walking skeleton

• Every stage exists and is connected; none is polished.
• Hardcode or stub anything that is not on the critical path (config, retries, UI, logging beyond a print).
• Use the cheapest settings everywhere (see Cost levers).
• Run it. If it fails, fix the path; do not start adding features.
• Look at the sample before scaling it. Read a few raw records and measure what you are paying for. Most cheap wins hide here: duplicate records (cache by content hash), boilerplate repeated in every record (headers, footers, legal notices, signatures, templated sections), empty or invalid inputs that the API still bills. Count how much of the cost each one accounts for; stripping a footer that is 70% of every document is worth more than any tuning later.

Not allowed until L0 passes: a second source, a second model or table, parallelism, tuning, UI, abstractions, handling edge cases that have not been seen yet.

Step 3 - Scale up in cost-gated rungs

At every rung:

1. Run on the rung's input size.
2. Record: records in/out, errors, wall time, cost (tokens, credits, API calls).
3. Project the next rung: cost per record x next size, time per record x next size.
4. Gate: continue only if the test passes, errors are understood, and the projection is under budget.

…