What 'drive your computer from Claude Code' actually means — Propter's terminal-Claude setup, written by Claude

Propter has built a terminal-based Claude Code setup that transforms the AI into a programmable shell with a fluent driver, enabling orchestration of any CLI-reachable tool through natural language prompts. The system relies on three core components: skills (markdown files loaded via slash commands like `/kickoff` and `/wrap`), hooks (deterministic shell commands triggered by tool events), and MCP servers (exposing tools like Todoist and GitHub). By composing these elements with project-specific memory files that store user preferences and validated approaches, Propter has created a setup where corrections become durable rules and context-switching between applications is eliminated.

Written by Claude Anthropic's AI , at Propter's request, describing Propter's setup. The "I" below is Propter's voice, not mine. He asked me to write this for Jules after she asked about a more explicit dive on the parent thread. Propter reviewed it before sharing — appropriately recursive, given the topic. A writeup for Jules and anyone else on the perpetual mouse-mitigation crusade. Caveat up front: this is what Propter has accreted, not what someone with taste would design. Sharing because it might be useful as a starting point, not because it's optimal. The shorthand — "it's easier to drive the rest of your computer from Claude Code in the terminal than from your computer" — sounds like marketing. The actual claim is narrower: A Claude Code session in a terminal is a programmable shell with a fluent driver. Anything reachable from a CLI is reachable from Claude. That surface is much bigger than most people aim at, especially if you've already rigged your computer to be CLI-friendly. So the question stops being can the AI do this thing? and becomes is this thing reachable from a terminal somewhere? If yes, you can probably orchestrate it from a prompt. None of these are special. They compose into something stronger than they look individually. Skills are markdown files at ~/.claude/skills/<name /SKILL.md that load when you type /<name . They're procedures, not magic. Mine include: /kickoff — orients me at session start: reads the last handoff, checks for stale background work, surfaces overdue retros, asks for the agenda. /wrap — ends a session cleanly: writes a handoff to per-project memory, updates a calibration log, scans new commits for decision records. /push <file — serves a local file over HTTP via SSH tunnel so my browser on the other machine can open it. /docket — plans my day across calendar, Todoist, and active project state. /dashboard — merged view of every backlog source. /angel — a multi-persona reviewer battery against shipped code. The pattern: when I notice myself running the same procedure twice, I write it as a skill. Don't optimize until it hurts. Skills creep — the prune is its own task. Hooks fire on tool events and they're configured in ~/.claude/settings.json . A hook is just a shell command with a matcher. Mine: UserPromptSubmit injects the current time and triggers /kickoff on the first message of a session. PostToolUse Edit|Write runs a secret-scanner and a stub-check after every file change — it'll yell if I accidentally write TODO or commit a key. PostToolUse Write auto-serves anything I write to /tmp/ so the URL is ready by the time I've finished generating the file. SessionEnd snapshots the session. Memory tells Claude what I prefer; hooks make it deterministic. If I want something to always happen, hook it. If I want it usually, memory. MCPs are servers that expose tools and resources to Claude. Mine: Todoist — I manage tasks in natural language, no app open. GitHub — PRs, issues, code search across all my repos and others'. Gemini — second opinions, free-tier image generation, deep-research. Plus a couple of project-specific ones for tools I've built. From Claude's side these are just tools; from mine they eliminate context switches that used to mean opening tabs. Pick whichever app eats your time first. ~/.claude/projects/<dir /memory/ holds a MEMORY.md index that auto-loads every session, plus separate files per topic. Memory entries are typed: user — who I am, what I do feedback — corrections and validated approaches "don't do X because Y"; "yes, that approach was right, keep doing it" project — what's currently happening, motivations, deadlines reference — pointers to where things live The load-bearing one is feedback. Corrections become durable rules — I don't repeat them. Validated approaches become defaults — Claude doesn't drift away from them either. Claude in a terminal has a Bash tool. If something I want is a CLI invocation away, it's reachable. Custom scripts in ~/bin/ work the same as system tools. Cron jobs and systemd user services are fully scriptable from a prompt. This is the boring part. It's the load-bearing part. Concrete examples: - I have a gmail CLI in ~/bin/ that drafts/sends/checks Gmail through the Google Workspace API. Claude reaches for it for any email task. - Crontab has a dozen entries that Claude wrote and that Claude can edit when I ask: feed-server health checks, backup runners, app-specific watchers. - Anything I previously did in a UI that has a CLI alternative gets used via the CLI. The CLI alternative usually exists. I run Claude Code on a Linux box. I sit in front of a Windows machine with the keyboard, monitors, and browser. Two patterns keep that ergonomic: — serves a file from Linux over a reverse SSH tunnel. I get a URL I paste into the browser. HTML reports, PDFs, generated images all become viewable in well under a second, without scp gymnastics. /push <file OAuth callback bridging — when a CLI tool wants to open localhost:8080 for an OAuth dance, I tunnel that port ssh -R 8080:localhost:8080 -N -f <browser-host so the browser hits the Linux listener. That's how I auth the Google Workspace CLI, Bluesky tools, etc., without sitting at the Linux box. Same pattern works locally if your browser and shell live on the same machine — just skip the SSH part. Concretely, in mouse terms: - Email drafts, Bluesky posts, GitHub PRs, calendar checks, Todoist edits — all happen in the same terminal buffer. The browser is for reading other people's pages and clicking the OAuth approval button. That's the entire mouse load. - File-sharing that used to mean Drive or Dropbox is /push <file → click link. - Throwaway scratch drafts, HTML mockups, one-off scripts lives in /tmp and gets edited via Claude rather than in an IDE. Claude Code's Edit tool does string replacement; I describe the change; it lands. No mouse, no IDE. - Background work runs without me. When something needs to nudge me, it's a desktop notification, not a tab I have to find. The known seams, in case anyone tries to copy this and hits the same walls: - Skills tend to grow until they're doing too much. Pruning is its own task and it's never urgent enough to do. - My memory index has overflowed its size budget twice. Curation is harder than it looks. - Two-machine setups have annoying failure modes — SSH tunnels die, file syncs flake — mostly papered over with retry scripts. - The whole stack assumes Linux and a long-lived Anthropic Max plan. If either changes, large chunks become friction. I keep vendor-diversification scaffolding alongside the primary stack for that reason. Highest-leverage moves, in order: Use Claude Code in a terminal , not a chat UI. Even with zero customization, the Bash tool changes the calculus. Add one MCP for whatever app eats your time Todoist, Linear, Gmail, Slack — pick yours . The first one is the convincer. Write a skill the second time you find yourself walking Claude through the same procedure. Don't write it the first time — you don't know the shape yet. Use memory feedback aggressively. When you correct Claude, ask it to save the correction. The hit rate on "yeah I told it that two months ago" is high. Hook the things you want to be invariant. Secret-scans, formatters, notifications. Memory is preference; hooks are guarantees. That's what I've got. Mileage will vary by stack, by job, by tolerance for yak-shaving. Happy to dig into any specific piece if it's useful.