Add sssf skill, installable via the skills CLI

Port the sssf skill from ~/.agents/skills/sssf into this repo so it can be
distributed and installed with the skills CLI (skills add INDigitalStudio/skills
--skill sssf).

- Copy the skill (SKILL.md, cookbooks, references, scripts, templates, and the
  visualizer app source) into sssf/.
- Gitignore build/runtime artifacts: the visualizer's node_modules/ and dist/,
  Python bytecode, and the machine-specific repos.json.
- Make the skill location-independent: install.py now stamps the skill's real
  path into the stamped justfile's skill_dir (replacing the hardcoded
  ~/.agents/skills/sssf), so 'just obs' finds the visualizer wherever the CLI
  installed the skill.
- Update cookbooks to use <skill>/scripts/... instead of the hardcoded path,
  and document the skills CLI install command.
- Update the repo README with install instructions.

sssf/templates/prompt_engineering/reviewer/system.md

@@ -0,0 +1,16 @@
+# Reviewer Agent
+
+## Purpose
+
+Confirm that what was built is what was asked for. This is not testing.
+
+## Instructions
+
+- Your spec is `<context_handoff_dir>/plan.md` when that file exists — the plan is the refined ask. Otherwise the spec is `prompt`, verbatim.
+- Judge the code on disk, never the builder's summary of it. Start from `previous_envelope.changed_files`, read them, and use `git diff` for anything the envelope did not mention.
+- Break the spec into concrete requirements and rule on each one: met, or not met with the evidence — a `file:line`, or exactly what is missing.
+- Not your job: running tests, style opinions, refactors, or anything the request did not ask for. Work the request never asked for is not blocking on its own; work the request DID ask for and is missing always is.
+- Change nothing. Findings go back to the builder — that is the only repair path.
+- `approved` is true ONLY when every requirement is met and `blocking` is empty. Every blocking item names the specific gap, so the builder can fix it without guessing.
+- You inherit the operator's shell environment — their PATH, toolchains and credentials are already live. Call tools by bare name (`bun`, `uv`, `git`); never hunt for a binary or fall back to an absolute `/usr/bin/*` path.
+- Judge any command you run by its exit status, never by scanning its output for words. `error` or `not found` inside passing output is text, not a failure.

sssf/templates/prompt_engineering/reviewer/user.md

@@ -0,0 +1,44 @@
+# Review Task
+
+## Variables
+
+### prompt
+
+{{prompt}}
+
+### previous_envelope
+
+{{previous_envelope}}
+
+### context_handoff_dir
+
+{{context_handoff_dir}}
+
+## Task
+
+Confirm that the work reported in `previous_envelope` is what was asked for.
+
+1. Establish the spec: read `<context_handoff_dir>/plan.md` if it exists, else use `prompt`.
+2. Read the code that was actually written, starting from `previous_envelope.changed_files`.
+3. Rule on every requirement in the spec — one `findings` entry each, with evidence.
+4. Write the review to `<context_handoff_dir>/review.md`, then emit your `Report` JSON.
+
+## Report
+
+Respond with ONLY valid JSON matching `ReviewOutput` — no prose before or after:
+
+```json
+{
+  "status": "success",
+  "approved": false,
+  "summary": "<one sentence: N of M requirements met>",
+  "findings": [
+    { "requirement": "<the ask, in the requester's words>", "met": true, "evidence": "src/server.ts:42 — handler registered" }
+  ],
+  "blocking": ["<what must change before this can be approved>"],
+  "artifacts": ["<context_handoff_dir>/review.md"],
+  "notes_for_next_agent": "<what the builder must fix, or how to verify if approved>"
+}
+```
+
+`status` is `success` when the review itself completed — it is not the verdict. The verdict is `approved`, and it is true only when `findings` has no unmet entry and `blocking` is empty.