Document IBM Bob install requirements as the basis for a Bob installer #478

Problem

adept installs only through the Claude Code and Codex plugin marketplaces. Bob has
no plugin system for skills (its marketplace covers MCP servers and modes), so a Bob user
must hand-place files. The skills depend on layout beyond their own folders, and nothing
in the repository records what a Bob install must provide. An installer cannot be
specified, or reviewed, until those requirements are written down and verified.

Evidence

Distribution policy and history:

• docs/adr/0001-distribution-via-plugin-marketplace.md:32-37, :52 — plugin-only
  distribution; "no install script and there will not be one".
• .claude/CLAUDE.md:7 and README.md:52 — same statement.
• .codex-plugin/plugin.json:4 — plugin install is driven by "skills": "./skills/";
  Bob has no equivalent manifest.
• docs/workflow/plans/2026-08-11-adept-dotfiles-separation.md:18, :967-969 — "Bob is
  retired", Bob install task skipped; :979 records "Bob has no plugin system" and a
  planned clone-plus-symlink approach that was never executed.
• scripts/reserved-skill-names.txt:10-13 — Bob slash-command/mode names are the only
  Bob support in the tree today.

Layout the skills require at runtime (the <plugin root> convention, defined as "two
levels above this skill's own directory", e.g. skills/attunement/SKILL.md:33-36):

• Cross-skill relative links: ../quest-log/SKILL.md#..., e.g. skills/quest/SKILL.md:46,
  :320; skills/campaign/SKILL.md:97, :414.
• Shared standards under <root>/references/: 11 files, linked as
  ../../references/*.md, e.g. skills/quest/SKILL.md:57, :129, :902;
  skills/forge/SKILL.md:239, :354; skills/trial-loop/SKILL.md:69, :85.
• Scripts that derive ROOT three levels up and then address siblings:
  skills/deliver/scripts/deliver-write:3-4, :60;
  skills/quest/scripts/publish-forge-review:13, :151, :499;
  skills/return-to-town/scripts/publish-handoff:47-48, :124-127, :538;
  skills/return-to-town/scripts/refresh-merge:5-6, :192-194.
• A root-level script outside skills/: publish-handoff:126 requires
  <root>/scripts/check-public-safety.sh, which itself execs
  <root>/skills/quest/scripts/check-public-safety (scripts/check-public-safety.sh:4-8).
• Sibling-skill script lookup: skills/bounty/scripts/create-verified-issue.sh:10-11 uses
  ../../quest-log/assets/tracker.sh.
• Symlink sensitivity: deliver-write:3 resolves its directory with a logical cd,
  publish-handoff:47-48 and refresh-merge:5-6 with cd -P. Probe (macOS arm64, bash,
  temp directory, path resolution only, not a live Bob session): with skills symlinked
  into a bob/skills/ tree, deliver-write resolved ROOT to the Bob directory and
  publish-handoff resolved it to the checkout. So a link install and a copy install
  need different directory contents.

Bob side, from the Bob documentation (skills page):

• Skills live in ~/.bob/skills/<name>/SKILL.md (global) or <project>/.bob/skills/
  (project); project wins on name collision.
• SKILL.md needs name and description; skills without a description are ignored.
• Supporting files and subfolders beside SKILL.md are readable once activated.
• Bob Shell sandboxing docs warn that symlinks pointing outside the project directory
  "may not work correctly" (sandboxing page, File system limitations).

Related, not a duplicate: #460 (detect-host-architecture under Bob's tool executor).

Expected

A document under docs/ (e.g. docs/bob-install-requirements.md) that records, with each
claim marked verified or unverified and the environment it was checked in:

1. The minimum file tree a Bob install must produce, for both global (~/.bob) and
   project (.bob) scope, including references/ and the root-level
   scripts/check-public-safety.sh.
2. Whether <plugin root> resolves correctly for a copy install and for a symlink
   install, per script, and which of the two is supported.
3. Whether Bob (IDE and Bob Shell separately) follows symlinked skill folders, and
   whether it needs a reload to see new skills.
4. How a skill's directory is named to the model under Bob, since the skills rely on the
   harness naming it (skills/attunement/SKILL.md:35-36).
5. Collision and idempotency rules: pre-existing ~/.bob/skills, ~/.bob/references
   content that adept did not create, and re-running after an update.
6. Which adept features have no Bob equivalent (slash-command syntax, agents/openai.yaml).
7. Open decisions the installer is blocked on: it contradicts ADR 0001's "no install
   script" and the "Bob is retired" plan note. Either an ADR supersedes/amends them, or
   the outcome is documentation only.

Proposed approach

Run the verification on a Bob install (IDE and Shell), write the document, and file the
installer as a separate follow-up only after the ADR 0001 question is decided. This issue
does not add an installer, script, or manifest.