agent-machine-bootstrap

Files (2)

• SKILL.md
• baseline-inventory.md · references/

SKILL.md (first lines)

# Agent Machine Bootstrap

Bring a bare machine to a verified coding-agent environment. Detect before
installing, install in dependency order, and prove the result with real usage
rather than version strings.

## When to use

Use for a new, rebuilt or freshly wiped machine, a new VM or VPS, or adding a
host to an existing fleet. Use `virtualbox-guest-access` for hypervisor guest
access mechanics and `opencode-bedrock-config` for one provider's auth detail.
This skill installs software. It must never invent credentials: every secret is
supplied by the operator or minted fresh on the target.

## Privacy contract

This file is generic on purpose. It names publicly documented products, and
never hosts, addresses, usernames, account identifiers, hardware inventory,
private project names or credentials.

Machine-specific values belong in a local inventory held outside this
repository, or at minimum ignored by version control. Keep the operator's
baseline application list, per-machine records and credential-rotation log
there, not here. Never commit a filled-in inventory, and never paste secrets
into a chat, issue or commit message.

Commit messages are as public and as permanent as the files themselves. Apply
the same rule to them.

### Inventory the agent needs

Supply these per target. Anything omitted becomes a detection step or a
question, not an assumption.

| Field | Example shape | Notes |
|---|---|---|
| Target identity | `<alias>` | Alias only; keep real hostnames local |
| Access method | ssh alias, host+user+key, hypervisor guest channel, console | Determines whether remote-driven is possible |
| Elevation | passwordless sudo, password-per-call, admin account | Changes every install script |
| Agents wanted | subset of the agent CLIs you use | Install only what is asked |
| Model provider + region + model id | provider, region, model identifier | Region matters for cross-region routing |
| Credential source | mint fresh on target, operator-supplied, existing SSO | Prefer mint-fresh |
| Skill library remote | git remote | Clone, never sync-mount |
| MCP servers wanted | server names | Each may need its own auth |
| Container runtime needed | yes/no | Large disk and RAM impact |
| Fleet integration | mesh VPN, SSH inbound, shares | Often blocked by a VPN killswitch |
| Desktop apps wanted | messaging, communication and GUI utilities | Requires a desktop session; skip on headless targets |
| Sync client wanted | which service, and the client to use per platform | Some services have no first-party client on every platform |
| Headless or desktop | headless, desktop | Decides whether layer 9 applies at all, and whether browser auth flows work |

## Kickoff prompt

Paste this and fill the bracketed fields from your private inventory. Keep the
final clause: it is what prevents a premature completion claim.

```text
Bootstrap <target alias> into a working coding-agent environment.

Access:            <ssh alias | host+user+key | guest channel | console>
Elevation:         <passwordless sudo | password per call | admin>
Agents wanted:     <list>
Model provider:    <provider>, region <region>, model <model-id>
Credentials:       <mint fresh on target | I will supply | existing SSO>
Skill library:     <git remote>
MCP servers:       <list or none>
Container runtime: <yes | no>
Fleet access:      <mesh VPN | SSH inbound | none>
Desktop apps:      <list or none>
Sync client:       <service + client, or none>
Session type:      <headless | desktop>

Follow the agent-machine-bootstrap skill.

Detect the target's OS, distro, architecture, login shell, existing runtimes,
version managers, privilege model and outbound network path BEFORE installing
anything, and report what you found before proceeding.

Work in the skill's layer order. Batch each layer into one operation where the
transport is slow. Never copy secrets between machines.

Do not report completion until every verification gate in the skill passes,
including one real end-to-end model request whose actual output you show me.
Report per layer: what succeeded, what failed, what needs me, and any
credential I must rotate.
```

## Sizing

Agent processes, not the OS, dominate resource use on these machines. A single
long-running agent session can hold well over a gigabyte of resident memory,
and several agents plus a build will outweigh everything else present.

Plan capacity from concurrency rather than from installed tool count:

| Component | Reserve | Notes |
|---|---|---|
| OS, shell, base tooling | 1–2 GiB RAM | Higher on a desktop environment |
| Each concurrent agent session | ~2 GiB RAM | Observed resident sets range widely; long sessions grow |
| Each concurrent build or test run | ~4 GiB RAM | Compilers and bundlers spike |
| Container runtime, if used | 1–2 GiB RAM | Excludes the containers themselves |
| Headroom | +25% | On top of the sum |
| vCPU | 2 baseline, +1 per concurrent agent, +2 per concurrent build | Not benchmarked; a planning heuristic |

Disk, additive: OS 15–25 GiB; runtimes and global packages ~5 GiB; each agent
binary up to ~0.5 GiB; skill library well under 1 GiB; repository clones and
agent worktrees per your own footprint; container images 20–40 GiB if a runtime
is installed; then +25%. Build caches grow unbounded — budget for pruning.

Treat all of the above as planning estimates, not measurements. Measure the
real machine before committing to a paid tier.

## Layer order

Later layers depend on earlier ones. Installing out of order is the most common
cause of confusing failure.

```text
0 preflight → 1 base tooling → 2 runtimes → 3 agent CLIs → 4 credentials
→ 5 agent config → 6 plugins + MCP → 7 skill library → 8 remote access

From hongyime/theprawnskills, MIT.

More from hongyime/theprawnskills