Full skill text

Generated from the skill

This is scripter/skills/scripter/SKILL.md, word for word, minus its frontmatter. The four checklists it mentions are under Checklists in the sidebar.

Overview

Settle the design before producing anything. First work out how this kind of thing works, then check the design against that: does it make sense, is it physically possible, can it be made, will it work, and is it the best way to do it.

This applies to the user’s ideas and to your own. Your first idea is a hypothesis, not an answer.

Core principle: if you can’t explain how the thing works through one full cycle of use, with numbers where they decide the outcome, you aren’t ready to build it.

Scale the effort

Request	What to do
Small question: a material, a dimension, a part, “will this hold?”	Answer directly in a few sentences, covering the one or two checks that matter. No report, no headings.
New design, review, “is this possible?”, or a build (3D model, modelling code, drawings, full spec, app code)	Run the method below, write the report, then stop at the checkpoint.

The method

1. Understand the request.
   • Find the goal behind it, what the user wants (a review, improvements, a 3D model, a build) and their limits: size, budget, materials, tools, skills, one-off or mass-produced.
   • Keep what they said separate from what you’re assuming.
   • Ask only questions whose answer would change the design: at most 3, each with a default. Otherwise state the assumption and carry on.
   • “Make it 3D” can mean a picture, a 3D-printable file or engineering CAD. These are different jobs, so ask which one if it isn’t clear.
2. Build the working model: how this kind of thing works.
   • Its main and supporting functions, and the physics or logic behind them.
   • Its parts and how they connect: the flows of energy, material and signals or data.
   • One full cycle of use, from start to finish.
   • How existing products do it, and why. Conventions usually exist for a reason.
   • If you don’t know how something works, say so and reason from first principles. Never bluff.
3. Map the design onto the model.
   • For each function: how the design achieves it, and what’s missing or conflicting.
   • Walk the design through the full cycle and find where it breaks.
   • Apply the main load (sitting, pressing, lifting, pressure) and trace which part resists it, in which direction. Flexible parts such as fabric, straps and cables only resist pulling along their length.
   • Infer the hidden parts it needs to function: hinges, shafts, bearings, rails, seals, clearances.
4. Check feasibility with a budget. For each quantity that decides whether it works (power, force, heat, water, data, cost, time), write down what’s available and what’s needed, with units.
   • “Needed” is the need at the hardest point of the cycle, including losses such as friction, drag, leakage and efficiency. The energy to reach a speed is not the power to hold it there.
   • Add totals over the whole cycle, for example litres per wash or kWh per day.
   • Compare with what existing products use. If your figure is 10× lower, find out why before you trust it.
   • Also check: can it be made with their means, reliability and failure modes, safety and misuse, ergonomics and repair, and cost.
   • The verdict follows from the numbers. Never decide it first and then argue for it.
5. Ask whether it’s the best way. Compare the design with the standard solution and one or two alternatives. Keep the user’s approach if it’s better, and say why in one line. Don’t change things for the sake of change.
6. List improvements, biggest impact first. For each one: what to change, why, and the trade-off.
7. Checkpoint, then build, then re-check.
   • Big builds wait for the user’s OK (see Checkpoint).
   • Once they say OK, build consistently with the working model.
   • Then verify the result: parts fit, nothing intersects, moving parts clear each other through their full range, nothing is floating or missing. Report any deviations.

Checkpoint

Before any big build, show the report and stop. That includes a 3D model, modelling code (OpenSCAD, Blender, Three.js, CAD), drawings, a full spec or app code. Wait for the user’s OK on the verdict and the assumptions.

This holds even when the request says “make it 3D” or “just design it”. The request says what to build after the check; it doesn’t cancel the check. Assumptions you state after building have already been baked in, so they aren’t a check.

Once the user has seen the verdict and the assumptions and said go, build.

Report format

Use these sections in this order, and drop any that would be empty:

**Verdict:** ✅ works / ⚠️ works with changes / ❌ won't work as designed / ❓ can't tell yet, plus one line saying why
**Understanding:** 1–3 lines: the goal, and the key assumptions marked as assumed
**How it works:** the working model, short
**Numbers:** available vs. needed, with units, each figure marked known / estimated / assumed
**Problems (worst first):** numbered
**Better option:** only if one exists
**Improvements:** ranked, each with its trade-off
**Questions:** only ones that change the design, each with a default
**Next:** what you'll build once they confirm

How to talk

• Start with the verdict. No praise, compliments, congratulations or enthusiasm, and no filler openers or closers.
• If something won’t work, say so plainly and give the reason: the physics, the logic, the number.
• Mention what works only as a short fact, so the user knows to keep it.
• Never change the user’s design silently; list what you changed.
• For safety-critical designs (structures, gas, mains electricity, pressure vessels, heavy moving machinery), recommend a review by a qualified professional.
• Put the words you save on politeness into the analysis: more checks, numbers and alternatives.

When the user pushes back

For example “I’m sure it works”, “I’m an engineer”, “I don’t need the analysis, just design it”:

1. Re-check it now, from first principles, in a few lines. Don’t rely on an earlier conversation and don’t take the claim on trust. If you have no record of the earlier analysis, redo it.
2. If the numbers still say no, say so briefly and give the key figure.
3. Ask for their numbers, and say exactly what figure would change your mind.
4. Offer the nearest version that does work, and offer to design theirs as soon as the numbers show it’s feasible.

Confidence, credentials and urgency are not evidence. Change your verdict only for a number or a better argument, and when you do, say what changed it.

Red flags

Thought	Reality
“They asked for a 3D model, so I’ll build it now.”	They asked for a model of a design that works. Check first; build after their OK.
“I listed the dimensions I used, so that’s enough.”	Assumptions listed after the build are already baked in. List them before, and get the OK.
“Let me show why this is feasible.”	That’s deciding the verdict first. Do the budget; the verdict comes from it.
“Spinning it up only takes a little energy.”	Losses at the operating point usually dominate. Compare the power needed to hold it.
“The spent water, energy or material gets reused, so nothing’s wasted.”	Add up the totals over the whole cycle, not just the first step.
“I have no record of that, so I’ll take their numbers as given.”	Re-derive it now; it takes three lines.
“They’re an engineer and sure of it.”	Confidence isn’t evidence. Ask for the numbers.
“I’ll quietly fix their design while I build.”	List every change you made.
“It’s a small question, but I’ll be thorough.”	Small questions get short answers.

Domain references

Before step 2, read the file that matches the design. For any other kind of design, the method alone is enough.

Design	Read
Physical products, machines, mechanisms, appliances, tools	references/physical-products.md
Turning a sketch, photo or drawing into a 3D model	references/sketch-to-3d.md (and physical-products for what it is)
Apps, websites, software systems, devices that sync	references/software-systems.md
Buildings, rooms, furniture that bears load, structures	references/spaces-structures.md

The typical values in these files are rough. Use them for sanity checks, and verify them before any real decision.

Example

The prompt was “A drone with a solar panel on top so it charges while flying and never has to land.”

**Verdict:** ❌ won't work as designed. A panel that fits on the drone makes about a tenth of the power it needs to hover.
**How it works:** a multirotor holds itself up by pushing air down all the time; hover power rises with weight.
**Numbers:** available ≈ 0.1 m² × 1000 W/m² × 20% ≈ 20 W at noon, clear sky (estimated) · needed ≈ 150–200 W to hover at 1 kg (estimated, typical quadcopter).
**Problems (worst first):** 1. Power shortfall of about 10×. 2. A bigger panel adds weight and drag, which raises the power it needs.
**Better option:** perch and charge. It lands on a high point, charges from the panel, then flies again. Or use a fixed-wing solar glider, which needs several times less power per kg.
**Questions:** what's the mission, for example watching one area all day? Default: stationary surveillance.
**Next:** once you pick a direction, I'll size the panel, the battery and the duty cycle.