| name | new-workspace |
| description | Scaffold a per-vehicle workspace repo for OBD readings, DTC reports and maintenance history. Use when starting to track a new car. |
| disable-model-invocation | true |
| allowed-tools | Bash(mkdir *), Bash(cp *), Bash(git init *), Bash(git add *), Bash(git commit *), Bash(gh repo create *), Bash(gh auth status), Bash(git push *), Read, Write, Edit |
Provision a vehicle workspace
One workspace per vehicle. It holds the readings, the interpretation of them,
and the service history — the things that accumulate and that you will want a
year from now. The plugin holds the know-how and is replaced on update; the
workspace is yours and diverges forever.
Inputs
- Workspace name —
$ARGUMENTS, kebab-case, used as the directory and repo
name. Ask if absent. Convention: <make>-<model>-<year>, e.g.
seat-ibiza-2012.
--public — default is private. A workspace accumulates registration,
VIN, service invoices and locations; private is the sane default and the user
can opt out.--local-only — skip the GitHub step entirely.
Steps
-
Parse arguments. If no workspace name was given, ask for one and stop
until answered. Do not invent a name.
-
Refuse to clobber. If the target directory exists and is non-empty, stop
and report it. Never scaffold over existing files.
-
Copy the template.
mkdir -p <parent>/<workspace-name>
cp -r ${CLAUDE_PLUGIN_ROOT}/template/vehicle-workspace/. <parent>/<workspace-name>/
Do not copy any .claude/ tree — this plugin's primitives are available
globally once installed.
-
Interview for the vehicle profile. Fill vehicle.json against
${CLAUDE_PLUGIN_ROOT}/schemas/vehicle.schema.json. Ask for, in one batch:
make, model, year, variant, engine code, fuel, transmission, current
odometer, and roughly how far it is driven a year. Registration and VIN are
optional — offer, do not insist.
Set id to the workspace name. Leave a field out rather than guessing it;
an omitted engine code is honest, a wrong one poisons every later lookup.
-
Seed the service intervals. Populate service_intervals from the
manufacturer's schedule for that model if the user has it. If not, say
plainly that the intervals are unknown, add the small set that is near
universal (engine oil, brake fluid, coolant, air filter, cabin filter) with
every_km/every_months omitted and source: "not yet established", and
note in docs/ that they need filling from the handbook. Do not populate
intervals from general knowledge and present them as this car's schedule —
timing-belt intervals in particular vary by engine code within one model, and
a wrong one here is an engine.
-
Record what is already known. If the user can recall recent work — last
oil change, last timing belt, tyres — put it into service_history now, with
date and odometer where known. This is the input the maintenance plan is
computed from and it is much easier to capture at setup than later.
-
Personalise CLAUDE.md. Replace the {{VEHICLE}} and {{WORKSPACE}}
tokens. Read the user's global CLAUDE.md if present and carry across
locale, currency and units so downstream commands do not re-ask.
-
Git init and first commit. Then, unless --local-only:
gh repo create <owner>/<workspace-name> --private --source=. --push
Use --public only if the flag was passed. Confirm with the user before
creating a public repo, since the contents are identifying.
-
Report the path, the repo URL, and specifically what in vehicle.json
is still unfilled — that list is the next action, not an afterthought.
Data storage
Everything this skill writes goes inside the new workspace directory. It does
not write to the plugin, and does not touch ${WORKSPACE:obd-diagnostics},
which holds machine-local adapter settings only.
Notes
Multiple vehicles get multiple workspaces, not one workspace with a vehicles
array. They are compared rarely and diverge in history, ownership and privacy;
a shared repo makes selling one of them awkward.
