# A car restoration build book — parts, specifications and the decisions behind them Recipe No. 49, Hobbies and play. From The know.sh Cookbook: https://know.sh/cookbook/build-book - 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 - Keep it: private; never 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. 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. 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. 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. 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. 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. 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. 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. ## Prompts to try 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. 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. 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](/cookbook/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 Take every torque, clearance, fluid and adjustment from the factory service manual for your truck's year, model and options, and quote it with its page. AI assistants make mistakes, and a figure from an assistant may belong to a different engine, year or truck. It has no place in a brake or steering job. Brakes and steering are safety systems. If you are not certain of your work, have a qualified mechanic inspect it before the truck goes on a public road, and make the first road test somewhere quiet. Support the truck on rated jack stands, never on a jack alone. Brake shoes, pads and clutch linings of this age may contain asbestos. Do not blow out brake dust with compressed air; clean it wet, wear a suitable respirator, and dispose of it as your local rules require. Old paint may contain lead, so take the same care when you strip it. Indexed under: Build books, Car restoration, Service manuals, Part numbers, Specifications, Dependencies, Road tests.