Teaching Claude to Do Woodworking

One of the best parts about Claude Code is that the "code" in the name is misnomer. The fact is that it can be used for a wide variety of things. I wanted to use it to help with some woodworking projects. But part of the problem was that I didn't know where to start. I am very inexperienced at this which leads me to lean in to using Claude Code to help with research and planning. So that's where I got started

can we work on creating some plugins/skills/agents and anything else that would be useful for woodworking projects? are there any programs we could write that would help us determine cut lists? material lists? let's be creative here. i'd like to build a complete woodworking project system that we can consult any time we want to build something.

Claude responded with an interactive questionnaire — what kind of projects, what tools do you have, what level of detail — and then built out a full plugin with Python tools and a set of commands. Two corrections landed in the first session, before any wood was cut.

Pushing Back on Claude

Claude will often get an idea and latch on to it. This can dramatically impact downstream results. The initial shelving design defaulted to a plywood box with dados — the standard bookshelf pattern — without asking what I was storing, how much it weighed, or whether the spans could handle the load.

we initially made a lot of assumptions and ended up with a fairly mediocre product IMO... why did we jump straight to a box without support? is there any code we can include to help us determine weights and supports and what loads can be realistically supported? if possible, we should make this more deterministic and off load some of the math work to programs.

This produced the structural analyzer — a Python script that calculates beam deflection using the formula δ = (5 × w × L⁴) / (384 × E × I), with material profiles for 30+ species and standards from L/360 (fine furniture) to L/120 (utility shelving). The rule that came out of this: structural analysis is deterministic code, not Claude's judgment.

At this point the system had a structural analyzer, a cut list optimizer, and a material calculator. All built speculatively, before any real project. The useful tools hadn't been written yet.

The First Build Broke Everything

The first real project was a pair of shelving units — 48" tall, 30" wide, 16" deep, 2x4 frame with plywood sides and dados for shelves. The speculative tools didn't address the actual failure modes.

The frame dimensions were wrong. Claude subtracted lumber width from the overall target instead of adding it to the internal requirement, and got the 2x4 orientation wrong — using 1.5" (the narrow face) when the uprights presented their 3.5" face in the depth direction. I cut 27" front/back pieces when I needed 31.5".

no, i'm measuring with what we want to actually store and the 27" is definitely wrong. that needs to be at least 30.

we also need to account for the width of the 16"x96" plywood. we need 30" usable space internal. so we need 30" + 2x the width of them.

It's fairly well know that models are not great at math and adding in multiple dimensions seems to exacerbate this problems.

"Are There Any Programs We Could Write?"

After correcting the dimensions by hand, with photos of the layout on the shop floor going back and forth, I asked:

are there any programs we could write to help us with this as we work? something to help with these measurements and kerf?

Three tools proposed, each one born from that day's specific errors:

• Frame calculator — give it internal dimensions and material sizes, get every piece length with verification. Exists because of the 27" vs 31.5" mistake.
• Board nester — maps cut pieces to stock boards with kerf accounted for. Exists because of tight-fit surprises.
• Pocket hole calculator — Kreg jig settings per joint and material thickness.

Then:

we should also expose these as tools in our skills so that we know how and when to use them

This established the pattern that the rest of the system follows: Python scripts in tools/ for standalone CLI use, bundled into .claude/skills/ with a SKILL.md file that tells Claude when and how to invoke them.

.claude/skills/frame-calculator/
├── SKILL.md
└── scripts/
    └── frame_calculator.py

These skills and tools were captured as we were working with the full context of what we were doing. This gave Claude more information about what we wanted to do and why we were doing. Instead of starting from scratch, we were building skills and tools with fresh and relevant context.

The Bottom-Up Design Realization

After the first unit was mostly assembled, problems had accumulated — a rabbet that was impractical to cut, a dado flush with the panel edge, wasted margins top and bottom. I stopped and reconsidered the whole approach:

i want to stop here and think about how we came up with this design for a minute. i think a better design would have been a shelf on the base... if we don't have a specific requirement for a dimension we should work up to it from the requirements we do have. in this case, we knew the size of shelf space we wanted and the number of shelves we wanted.

The height was never a hard requirement. It should have been calculated from shelf count × spacing: panel_height = (num_dados × shelf_thickness) + (num_spaces × spacing). No margins, no rabbets, no weird gaps. Every space is exactly what you asked for. The height is a result, not an input.

This became a persistent feedback memory — a file that Claude reads at the start of every future session:

---
name: Bottom-up design for shelving and repetitive structures
description: Derive unconstrained dimensions from requirements instead
  of setting them arbitrarily
type: feedback
---

When designing shelving units or any structure with repeating elements,
derive unconstrained dimensions from the hard requirements.

**Why:** On the first shelving project, we set the height at 48" and
tried to fit shelves in. This led to: arbitrary margins top and bottom,
a rabbet that was impractical to cut, a dado flush with the panel edge,
and hours of rework. The height was never a hard requirement.

**How to apply:**
1. Identify HARD constraints first: internal width, depth, shelf spacing
2. Identify SOFT constraints: height, overall width — these are CALCULATED
3. Build the design bottom-up: shelf on base → panel → dados at regular
   intervals from one edge → top piece at calculated position

The Memory System

Each mistake from the shelving build generated a feedback memory with a "why" and "how to apply." Five accumulated over the first two projects:

• Engineering rigor — run numbers, don't guess. Offload math to code. Structural analysis is deterministic.
• Bottom-up design — derive dimensions from requirements. Don't set height first and cram shelves in.
• Fence calibration — dado stacks shift the blade position. Always verify with test cuts, not the fence scale reading.
• Skills not commands — use SKILL.md with frontmatter, not the deprecated commands/ pattern.
• Shopping list locations — include the aisle and department for each item. Stores are big.

These aren't conversation history. They're structured corrections that persist across sessions. Claude reads them at the start of every conversation in the project, so the same mistake doesn't happen twice.

The Second Project Used the Tools by Name

A month later, I started building nightstands. The workflow had changed. When the cut list was ready:

yes, we should always assume I can go back out for more material if needed. no shortcuts. no hacks. let's check it with the nester first though

The board nester confirmed I needed 8 boards (had 6), and updated the Apple Notes shopping list with Menards SKUs and aisle locations. The frame calculator ran without me having to correct orientations.

What the System Looks Like Now

Eleven skills and six Python calculators, organized around a project planner that enforces a 6-phase workflow:

1. Define — scope, dimensions (hard vs soft constraints), loads, tools, existing materials
2. Design — draft with structural approach, component breakdown, joinery plan
3. Structural validation — mandatory, cannot skip. Runs the deflection calculator on all spans.
4. Cut list and materials — optimized layouts, shopping lists, cost estimates
5. Build sequence — step-by-step with tool selection and technique notes
6. Review — check math, feasibility, adjustments

The project planner encodes the lessons from the shelving build directly. Phase 1 asks whether each dimension is a hard constraint or should be calculated. Phase 2 enforces bottom-up design for repetitive structures. Phase 3 is mandatory — you can't skip structural validation. Each project gets a folder with a design spec, build log, photos directory, and exported plans.

The tools:

• structural_analyzer.py — beam deflection, 30+ material profiles, load path analysis
• frame_calculator.py — piece lengths from internal dimensions, with verification
• board_nester.py — maps pieces to stock boards, flags tight fits
• cut_list_optimizer.py — 2D sheet nesting and 1D lumber optimization with kerf
• material_calculator.py — board feet, cost estimates, waste factors
• pocket_hole_calculator.py — Kreg jig settings, screw lengths, drilling workflow

This Isn't About Woodworking

The pattern — ask for a system, get something generic, use it on real work, hit failures, extract tools from the failures, formalize them as skills with persistent memory — works for any domain. The frame calculator prevents orientation math errors in woodworking; an electronics skill might prevent resistor divider mistakes. The structural analyzer runs deflection formulas; a cooking skill might calculate thermal mass for timing. The feedback memories store domain lessons the same way regardless of what the domain is.

None of the useful tools were designed in advance. They came from specific failures on specific projects, and that's probably how it should work.