know.

CookbookHobbies and playNo. 49

A car restoration build bookparts, specifications and the decisions behind them

Recipe No. 49Hobbies and play

For
A hobbyist restoring a 1972 half-ton pickup truck in a two-car garage
You bring
The factory service manual, a parts catalogue or two, a shoebox of receipts, a phone full of photos, a truck that does not yet stop, and the AI assistant you already use
You get
A build book with a document per system and a finding per job, holding part numbers, specifications quoted from the manual, decisions and problems, plus a restoration plan whose graph shows what the road test is waiting on
Time
An evening for your assistant to sort the shoebox, a weekend for you to check it, then fifteen minutes after each session in the garage
Works in
know.sh on the web · your AI assistant, through MCP · a coding assistant with the plugin
Keep it
Private. This one never goes on a public link.

A restoration runs for years, and its memory is the weakest part of it. Which master cylinder did you order, and from whom? What torque did the manual give for the caliper bolts, and did you use it? Why did you replace the wiring harness instead of repairing it? Three winters on, the answers are in a shoebox of receipts and a camera roll of photos with no captions.

This build book has a research document per system — Engine, Brakes, Electrical, Body — and a finding per job. Whichever assistant you use — Claude, ChatGPT or a local model — sorts the shoebox into it: a finding per job with the part numbers and suppliers read off your receipts. You open the editor and add what only you can: the specifications, copied from the factory service manual with section and page, and the reasons behind each Decision and Problem.

Then the plan. Claude Code, connected to know.sh, reads the build book and lays out what is left as a campaign of operations with dependencies, and the graph shows it plainly: the brakes block the road test, and so does the wiring for the lights.

The photos stay in your photo library, the manual stays on the bench, and every specification comes from the manual, never from an assistant.

What you will use

Your AI assistant
Reads receipts and notes into a finding per job with part numbers and suppliers, leaves every specification blank for you, and, as Claude Code with the know.sh plugin, lays out the plan.
Shelf
One shelf for the truck, whose notes hold the model, engine, transmission and axle, and where the title and receipts are kept.
Research document
Engine, Brakes, Electrical and Body, plus Parts and suppliers.
Finding
One per job; manual specifications filed as Evidence, choices as Decision, setbacks as Problem, hazards as Risk.
The editor
Where you check part numbers against receipts and type each specification from the manual yourself.
Highlights
Highlight each specification once you have checked it against the manual; its number turns bold wherever the finding appears in the index.
Campaigns
What is left of the restoration, as operation sets and operations with blocks and informs, and a graph.
Look up
Find a part, a supplier or a job from the bench with ⌘K.

Method

  1. 1

    Hand your assistant the shoebox

    Connect your assistant to know.sh once, following the support page. Then give it photos of the receipts and invoices, your job notes and a list of what you have done so far, and ask it to make a shelf, 1972 half-ton, with one document per system — Engine, Brakes, Electrical, Body — and a fifth, Parts and suppliers, with a finding per supplier.

    Each job gets a finding titled with the part and the work — “Front calipers — rebuild”, “Brake hoses — replace all three” — with the same headings every time: Parts, Specifications, What I did, What I found, Photos. Tell it three rules: read part numbers exactly as printed, leave Specifications empty, and leave card numbers and your address off every receipt it copies.

  2. 2

    Check it in the editor

    Open each system document, press Edit, and check every part number against its receipt: one wrong digit is a wrong part. Write each document’s overview from what you saw when you started: “Pedal to the floor, front hoses cracked, rear drums scored, left rear wheel cylinder seized.” Keep the part in each title, so Look up (⌘K) finds it next winter.

    Under Photos, name the album and the dates: “Brakes album, 3–5 August, 14 pictures.” know.sh holds no pictures, so the finding says where they are.

  3. 3

    Copy specifications from the manual yourself

    When a job needs a number — a torque, a clearance, a fluid, an adjustment — take it from the factory service manual for your truck’s year and options, and type it under Specifications yourself, followed by the section and page it came from. A finding that is mostly specifications is filed as Evidence. Source links take web addresses, so a paper manual is cited in the text.

    Never ask an assistant for a specification. It will answer, confidently, and the figure may be for another year, another engine or another brake option. Once you have checked a figure against the page, highlight it: the highlight is your mark that it has been checked.

  4. 4

    Give decisions and problems findings of their own

    Some findings are not jobs but choices. “Replace the harness rather than repair it” is a Decision: what you considered, what each option cost, and why you chose. “Left rear bleeder snapped off” is a Problem: what happened, what you tried, what worked. Your assistant can set these up from your notes; the reasons are yours to write. Mark the ones that shaped the build Key.

    Whoever owns the truck in ten years, you included, will want to know why it has a new harness and its original gauges.

  5. 5

    Ask Claude Code to lay out what is left

    Plans need the planning permissions that the Claude Code plugin asks for today. Install it (claude plugin marketplace add knowsh-curtis/know-cli, then claude plugin install know-dev@know-sh), start claude and run /mcp to sign in. Then ask it to read the four system documents and lay out the rest of the restoration as a campaign: an operation set per system, an operation per remaining job, and dependencies between them.

    The dependencies are the point. Rebuilding the calipers, replacing the hoses and bleeding the system each block the road test; so does the harness, because the truck needs working lights and indicators. The engine tune-up informs the road test without blocking it.

  6. 6

    Read the graph and keep it current

    Open the campaign in know.sh and switch to its graph. The road test sits at the end with arrows running into it from Brakes and Electrical. Operations nothing depends on stand apart: work for the weekends when parts have not arrived.

    Each time you finish a job, give Claude Code a few lines of notes and ask it to add the finding and move the operation to done; then fill in the specifications yourself. When an order is delayed, mark its operation blocked, and the graph shows what is waiting on it.

  7. 7

    Look it up at the bench

    With a laptop on the bench, Look up (⌘K, or /) finds a part, a supplier or a job as you type: “master cylinder” brings up the part number, the supplier and the finding where you bled it. The index at the back does the same for browsing, with each system document, such as Brakes, and each supplier’s name, and bold numbers for the specifications you have checked and highlighted.

    Before a long job, such as the harness, ask your assistant for a quiz on Electrical. It writes questions from your own findings, and you take the quiz in know.sh or the iOS app: a wrong answer at the kitchen table is cheaper than one under the dashboard.

Specimen

  1. You

    Read Engine, Brakes, Electrical and Body in my know.sh library and lay out what is left of the restoration as a campaign. One operation set per system, one operation per remaining job. Anything needed to stop, steer or signal safely blocks the road test.

  2. research_listFound Engine, Brakes, Electrical and Body on 1972 half-ton
  3. research_list_findingsRead 11 findings in Brakes and 9 in Electrical
  4. campaign_createCreated “1972 half-ton — to the road test”
  5. operation_set_createCreated four sets: Brakes, Electrical, Engine, Body
  6. operation_createCreated 17 operations, among them “Bleed brake system” and “Road test, 10 miles”
  7. operation_dep_add“Bleed brake system” blocks “Road test, 10 miles”
  8. operation_dep_add“Replace wiring harness” blocks “Road test, 10 miles”
  9. operation_dep_add“Engine tune-up” informs “Road test, 10 miles”

  10. Claude Code

    The campaign has four sets and 17 operations, all in draft.

    The road test is blocked by six operations: four in Brakes (calipers, hoses, rear wheel cylinders, bleeding) and two in Electrical (harness, lights check). Body work does not affect the road test, so I left it unlinked.

    Two brake jobs have no specifications in their findings yet: the rear wheel cylinders and the shoe adjustment. I have not filled them in. Take them from the manual before you start.

  11. You

    Calipers are done. The finding is Brakes, 2.

  12. operation_transition“Rebuild front calipers” marked done
Claude Code turning the build book into a plan, with the road test blocked until the brakes and wiring are done, and leaving the missing specifications to the manual.

1972 half-tonNo. 4

Brakes — from a pedal on the floor to the road test

11 findings, 3,480 words, about 15 minutes, filed 2 August, revised 21 September, 6 highlights.

Bought with the pedal on the floor. Front hoses cracked, rear drums scored, left rear wheel cylinder seized.

Original-type parts throughout, except the hoses. Every figure in this document is quoted from the factory service manual, with its section and page.

Findings

  1. 1Master cylinder — replaceEvidence, keyNew unit, bench-bled before fitting. Part number and supplier under Parts; fluid and pushrod check from the manual, section 5.
  2. 2Front calipers — rebuildEvidence, keySeals, boots and pistons; slides cleaned and greased. Mounting bolt torque quoted from the manual and highlighted once checked.
  3. 3Brake hoses — replace all threeDecisionReplaced rather than inspected: two were cracked, and the third was the same age.
  4. 4Left rear bleeder snapped offProblem, 1 noteSheared at the first quarter turn. Replaced the wheel cylinder instead of drilling it out.
  5. 5Rear drums — measure before machiningQuestionScored. Is there enough metal left? The maximum diameter is cast on the drum; check it against the manual.
  6. 6Old linings — treat as asbestosRisk, keyThe original shoes may contain asbestos. Wet-wiped, bagged, no compressed air.

and 5 more findings

The brakes document: a finding per job, with decisions, problems and a hazard filed under their own types. The manual’s figures stay inside each finding.

Prompts to try

  1. A coding assistant with the know.sh plugin, such as Claude Code

    Using the know.sh tools, read Engine, Brakes, Electrical and Body on my 1972 half-ton shelf and lay out what is left as a campaign: one operation set per system, one operation per remaining job. Anything needed to stop, steer or signal safely blocks an operation called “Road test”. Do not supply any specification yourself; list the jobs whose findings have none.

  2. A coding assistant with the know.sh plugin, such as Claude Code

    I finished the brake hoses today. My notes: [paste]. Add a finding to Brakes called ‘Brake hoses — replace all three’ with the headings Parts, Specifications, What I did, What I found and Photos, and leave Specifications empty for me to fill from the manual. Then mark the matching operation done and tell me what the road test is still waiting on.

  3. Your assistant, connected to know.sh (Claude, ChatGPT or a local model)

    Using know.sh, read every finding in Brakes and Electrical on my 1972 half-ton shelf. List each job whose Specifications section is empty, or has a figure without a manual section and page, in a new finding called ‘Specifications still to check’. Do not supply any figures yourself.

Variations

  • Restoring a motorcycle, a tractor or a boat: the systems change (a boat has hull, engine, electrics and rigging), and the shape of the build book does not.
  • For the reasoning behind the bigger choices, file one Decision finding per choice, with the options you turned down and why.
  • The same shape runs a house: systems, jobs, parts and warranties become a house manual.
  • Once the truck is on the road, keep a Maintenance document with a finding per service, so the build book carries on as the truck’s logbook.

Where it falls short

  • No photos or wiring diagrams. There is no image upload and no diagram block, so photos stay in your library and the diagrams stay in the manual; the findings say where to look.
  • No specification database. know.sh holds the figures you copied from the manual and nothing more; it cannot check them for you.
  • The campaign graph lives in the older part of the web app, and campaigns need the planning permissions only the Claude Code plugin asks for today; a Claude or ChatGPT connector cannot create one.
  • No totals. A finding can hold a table of prices, but nothing adds up what the build has cost; ask your assistant and check its arithmetic, or keep a spreadsheet.
  • Reading receipts from photos is where assistants slip, and smaller local models may not read images at all. Check what any assistant filed; Revisions shows each change it made.

A note on specifications and safety

Indexed under

Build booksCar restorationService manualsPart numbersSpecificationsDependenciesRoad tests

See also