Install a coding agent

Both Siltpoke Review and Project Life Cycle sit on top of a coding agent — the agent does the writing, and they handle everything around it. So the agent goes in first.

Any of the five works — Siltpoke Review and Project Life Cycle both run in all of them. Install the agents you actually use, skip the rest — with one exception: if you want Siltpoke Review to have a different company's model check your code (cross-family review), install that company's agent too and sign in, because Siltpoke calls it to do the review. (Their install commands are collected here so you don't have to chase five different vendor docs.)

Each entry notes what the agent needs — account, runtime, and whether there's a free way in. The cost notes are a snapshot as of July 2026; vendors change these often, so trust the linked pricing pages over this paragraph.

Before you start: git

What it is. git keeps a record of every change you make to your code — each save point is called a commit.

Why you need it. Siltpoke Review and Project Life Cycle live on GitHub, and when your coding agent installs them it downloads them with git. Without git, the install fails on Claude Code, Codex and Qoder (CodeBuddy can fall back to a plain download), and Antigravity and installing from source start with git clone. Git is also how Siltpoke Review sees what you changed — no git, nothing to review.

Check whether you have it — if this prints a version number, you're set:

git --version

If it doesn't:

xcode-select --install     # macOS: installs git with Apple's command line tools
# Linux: install git with your package manager (apt, dnf, …)

winget install --id Git.Git -e

Before you start: npm

What it is. npm is the installer for tools written in JavaScript. It isn't downloaded on its own — it comes with Node.js.

Why you need it. Claude Code and CodeBuddy are installed with npm install -g, and so is Codex on Windows. If you'll only use Antigravity, Qoder, or Codex on macOS or Linux, you can skip this one.

Check whether you have it:

npm --version

If it doesn't print a version number, install Node.js (take the LTS version) and npm comes with it:

# macOS: download the LTS installer from https://nodejs.org/
# Linux: install Node.js with your package manager (apt, dnf, …)

winget install --id OpenJS.NodeJS.LTS -e

After installing either one, open a new terminal window so it can find them.

Claude Code

needs Node ≥ 18 and an Anthropic account on a paid plan — there's no free tier for Claude Code: Pro ($20/mo) or Max, or pay-as-you-go API credits (pricing):

npm install -g @anthropic-ai/claude-code
claude        # opens the TUI; log in with your Anthropic account

Codex

works on every ChatGPT plan, including Free, or an API key. Free gets the smallest allowance, local tasks only, drawing on the same 5-hour window as paid tiers — enough for a few small edits to feel it out, not enough to finish a real feature (run /status inside Codex to see your live quota). Plus ($20/mo) is the real-use tier — roughly 15–80 messages per 5-hour window on the top model. The installer is a standalone binary; the npm route needs Node ≥ 22 (pricing):

curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex         # opens the TUI; sign in with your ChatGPT account or an API key

npm install -g @openai/codex
codex         # opens the TUI; sign in with your ChatGPT account or an API key

Antigravity

standalone installer; any Google account. Free in public preview, but metered by how much work the agent does (not by request count) and the free tier refreshes weekly — a few light tasks a day is realistic; one complex build can hit the ceiling in a single session, and the limits have been tightened repeatedly, so don't plan around them. Paid Google AI plans lift them (pricing):

curl -fsSL https://antigravity.google/cli/install.sh | bash
agy           # opens the TUI; authenticates via your Google account in the browser

irm https://antigravity.google/cli/install.ps1 | iex
agy           # opens the TUI; authenticates via your Google account in the browser

CodeBuddy

needs Node ≥ 18 and a CodeBuddy (Tencent) account. Free limited-time trial tier for individuals plus a small daily free-credit allowance — on the order of ~50 credits a day (IDE side): enough to poke around and run a few small tasks, not to build with, and the free tier was cut back in the May 2026 repricing. Pro is the paid step up (pricing):

npm install -g @tencent-ai/codebuddy-code
codebuddy     # opens the TUI

Qoder

standalone installer, no Node needed; sign in with a Qoder account. Free plan keeps you on the basic model under daily and monthly caps — fine for light everyday use, not for the strongest models. Your first sign-in grants a 14-day Pro trial with 300 credits — that trial, not the free plan, is what you evaluate the real models with; Pro at $20/mo (pricing):

curl -fsSL https://qoder.com/install | bash
qodercli      # opens the TUI; type /login to sign in via browser

irm https://qoder.com/install.ps1 | iex
qodercli      # opens the TUI; type /login to sign in via browser

What to install next

Both are one command away, and neither needs the other:

• Project Life Cycle — the process layer, from a fuzzy idea to a merged PR.
• Siltpoke Review — the companion that reviews what the agent writes, remembers the project, and maps the code.

Or skip the commands: an agent prompt pasted into your agent installs either one, or both, for you.

Install with an agent prompt

Once you have a coding agent, this is the quickest way to add Project Life Cycle and Siltpoke Review. Pick your agent below, copy its prompt, and paste it into the agent as an ordinary message. (No agent yet? Install one first — the commands are above.) The agent then does the install for you:

• it checks what you already have (git, Bun, either plugin);
• it asks which you want — both, only Siltpoke Review, or only Project Life Cycle;
• it asks before it downloads and runs a script, installs an app, or changes your shell profile;
• it creates your Siltpoke pet, then walks you through your first day.

The prompts are in English, but the agent answers in whatever language you write in. Want the other plugin later? Paste the same prompt again — it only adds what is missing.

Rather type each command yourself? That still works, step by step: Project Life Cycle → Install · Siltpoke Review → Install & setup.

On native Windows the prompt stops first and tells you why: Siltpoke installs there, but its review never runs. Use WSL, or install Project Life Cycle only.

Claude Code

Paste into Claude Code. The one step it can't do for you comes at the end: quit Claude Code and start it again, so the new commands load.

You are installing Claude Code plugins for me, setting them up, and then teaching me to use them. Talk to me in the language I am writing in. Keep each message short. **Ask me before anything that downloads and runs a script, installs an app, or changes my shell profile.**

There are two plugins. They are independent — I can have one, the other, or both:
- **Siltpoke** — a second reviewer that watches my coding sessions. After each turn, a *separate* AI process reads what changed and writes down what it thinks was missed. It remembers bugs across sessions, and it has a dashboard and a small pet. Repo: https://github.com/Siltpoke/siltpoke
- **Project Life Cycle (PLC)** — a working method for AI coding: spec → plan → build → verify → ship → release, with commands to set up a project, ship a feature, save/resume a session, and cut a release. Repo: https://github.com/Siltpoke/project-life-cycle

## Before anything — am I on Windows?

Run `uname -s`. If it fails, or prints anything that is not `Darwin` or `Linux`
(on Windows it will not exist, or a Git-Bash shell prints `MINGW64_NT-...`),
**stop here and tell me this, in my language, before installing anything:**

> Siltpoke does not support native Windows yet. It will install, the pet will
> appear, the commands will work and the config will say the setup is fine —
> but the review hook is registered as `sh ./hooks/stop.sh`, Windows has no
> `sh`, so no review will ever run and nothing will say so. If you have WSL,
> run this again inside WSL and everything works, because that is Linux.
> Otherwise, wait for native Windows support.

Then ask whether I want to continue anyway. **Do not install unless I say yes**,
and if I do, say once more that reviews will not fire. Project Life Cycle has no
such problem — it is prompts and commands, no hook — so offer to install only
PLC instead.

## Step 0 — What do I already have, and what do I want?

Run `claude plugin list` first. Then:
- If one of them is already installed, say so in one line ("you already have PLC — this time I'll only add Siltpoke") and skip its install. Offer `claude plugin update <name>` instead.
- For anything not installed yet, ask me once: **both / only Siltpoke / only PLC**. Recommend "both" in one sentence, but do what I pick. Every later step applies only to what I picked.

## Step 1 — Check the tools

Run these and tell me in one line each what you found:
- `claude --version` (must work — you are running inside it)
- `git --version`
- `uname -s` (tells you if I'm on a Mac — only matters for the menu-bar pet in Step 4)
- Siltpoke only: `bun --version`. Siltpoke's reviewer runs on Bun. If it is missing, **ask me first**, then run `curl -fsSL https://bun.sh/install | bash` and check again with `~/.bun/bin/bun --version` (my shell will not see the new PATH until it restarts — that is fine, setup records the full path).

## Step 2 — Install

Run with the Bash tool, one line at a time. If any line fails, stop and show me the exact error.

```bash
# PLC
claude plugin marketplace add Siltpoke/project-life-cycle
claude plugin install project-lifecycle@project-life-cycle

# Siltpoke
claude plugin marketplace add Siltpoke/siltpoke
claude plugin install siltpoke@siltpoke
```

Then run `claude plugin list` and confirm each one I picked shows as installed and enabled. Do not claim success from the install output alone.

## Step 3 — Set up Siltpoke (skip if I did not pick it)

The `/siltpoke-setup` command is not available until Claude Code restarts, but its instructions are already on disk:

1. Find the plugin folder: `ls -d ~/.claude/plugins/cache/siltpoke/siltpoke/*/ | sort -V | tail -1`. Call it `PLUGIN_ROOT`.
2. Read `PLUGIN_ROOT/.claude-plugin/commands/siltpoke-setup.md` (if it is not there: `find PLUGIN_ROOT -name siltpoke-setup.md`).
3. Follow that file exactly, as if I had typed `/siltpoke-setup`. Wherever it says `${CLAUDE_PLUGIN_ROOT}`, use the real `PLUGIN_ROOT`. If `bun` is not on PATH yet, use `~/.bun/bin/bun`.
4. It first asks me **Express** (one step, a default pet) or **Custom** (choose species, name, language, personality). Let me choose.
5. When it finishes, tell me the result in plain words. If it fails, translate the one-line error and stop.
6. If `~/.siltpoke/config.json` already existed before you started, setup was done before: say so, ask if I want to redo it, and skip to Step 4 if not.

## Step 4 — The menu-bar pet (Siltpoke + Mac only)

If setup already offered the menu-bar pet and I answered, skip this step. Otherwise, explain it in two sentences and ask if I want it:

- **The terminal pet (statusline)** sits in the bottom line of Claude Code. It shows **this session only**: it changes after every turn, and its speech bubble carries the latest review. You see it only while you are in that Claude Code window.
- **The menu-bar pet** sits in the Mac's top menu bar and shows **all your sessions at once** — every project, and every coding tool Siltpoke watches. You see it all the time, even with every terminal closed. The number next to it is how many sessions have a recent review (not a count of problems). Click it for a list: one line per session (project · branch · time · which coding tool wrote the code) with its latest review, plus "Open dashboard" and "Restart daemon". It refreshes once a minute, not after every turn.

If I say yes:
1. It needs the free app SwiftBar. Check with `ls /Applications/SwiftBar.app`. If it is missing, ask me: install with `brew install --cask swiftbar` (only if `brew --version` works), or let me download it myself from https://github.com/swiftbar/SwiftBar. Then open it once: `open -a SwiftBar` (the first time, it asks me to pick a plugin folder — accept the default).
2. Run `bun "PLUGIN_ROOT/dist/siltpoke-cli.js" menubar install`, then `… menubar status`, and tell me in one sentence what it said.

## Step 5 — PLC needs no global setup (skip if I did not pick it)

Tell me: PLC is set up **per project**, not once for the whole machine. Inside a project folder, `/init-harness` looks at the code, writes a `CLAUDE.md` and a few config files, and asks before overwriting anything. Do **not** run it now. If my current folder is a git repo, say: "after the restart, you can run `/init-harness` here."

## Step 6 — The one thing I must do myself

Tell me clearly: **quit Claude Code and start it again now.** Slash commands, the Siltpoke review hook, and the terminal pet only load on restart. Then tell me what to type first after the restart (Step 7, item 1).

## Step 7 — Getting started: my first day

Before the restart, print this walkthrough in my language, only the parts for what I installed, filled with my real results. Make it a numbered list I can follow step by step. Do not invent commands that are not listed here.

**Siltpoke — first 10 minutes**
1. Type `/siltpoke-doctor`. It prints a ✓/✗ checklist. All ✓ means the install works. If something is ✗, it says what to do.
2. Ask Claude for any small real change (for example: "add a comment explaining this function"). When Claude finishes, Siltpoke reviews the change in the background. You do not need to do anything.
3. Watch the terminal pet: its face and speech bubble change when the review is done. (On a Mac with the menu-bar pet, the menu bar shows it too, within a minute.)
4. Type `/siltpoke-last` to read the full review in the chat.
5. Type `/siltpoke-dashboard`. It opens http://127.0.0.1:9876 — review history, chat with your pet about your code, what it remembers, and the Code Map. On a review, press **ACK** (seen, useful) or **DISMISS** (wrong). This is how it learns what to stop saying.
6. Need quiet (a demo, pairing)? `/siltpoke-mute 1h`, and `/siltpoke-unmute` to undo. Reviews stopped showing up? `/siltpoke-wake`.

**PLC — your first project**
1. `cd` into a project and type `/init-harness`. Answer its questions. It writes `CLAUDE.md` and asks before overwriting anything.
2. Talk about the code first, no edits: "explain how this project is structured."
3. Build one small feature with `/ship <what you want>`. It stops 3 times to check with you: the user story, the spec, and the pull request.
4. Stopping for the day? `/handoff` saves where you are to `RESUME.md`.
5. Next time, start with `/catchup` — a "welcome back" card of where you left off.
6. The `project-lifecycle` skill also turns on by itself when you start a project or plan multi-step work. You do not have to type the commands — they are shortcuts.

**Both together — a normal day**
1. Open a project → `/catchup`
2. Build with `/ship`, or just work normally
3. Siltpoke reviews each turn in the background → `/siltpoke-last` when the pet looks worried
4. Leaving → `/handoff`

## Step 8 — Keep using it

Print this right after the first-day walkthrough, in my language, only the parts for what I installed. It is how I use the plugins every day after the first one.

**Siltpoke, every day**
1. Just work. Siltpoke reviews each turn by itself — you never have to start it.
2. When the pet looks worried (or the menu-bar number goes up), read the review: `/siltpoke-last`.
3. Teach it. In the dashboard (`/siltpoke-dashboard`), press **DISMISS** on a review that is wrong and **ACK** on one that helped. It remembers, and over time stops repeating what you dismissed.
4. Once a week, look at the dashboard's Memory page — that is what it has learned about your code.
5. Reviews went quiet? `/siltpoke-doctor` first; if everything is ✓, `/siltpoke-wake`.
6. Busy (a demo, pairing)? `/siltpoke-mute 1h` — it turns itself back on when the time is up.

**PLC, every session**
1. Start: `/catchup` — where you left off, what shipped, what is next.
2. New feature: `/ship <what you want>`.
3. A design question you are not sure about: `/research <question>` — it comes back with cited sources.
4. Before merging a branch: `/review`.
5. End: `/handoff`. The next session starts again at item 1.
6. Ready to publish a version: `/release`.

**Keep it current:** `claude plugin update siltpoke` · `claude plugin update project-lifecycle`, then restart Claude Code.

## Step 9 — The manual

End with this, in my language, only the rows for what I installed:

| | Status |
|---|---|
| Project Life Cycle | installed — version from `claude plugin list` |
| Siltpoke | installed — version, pet name + species |
| Bun | version (and its path) |
| Menu-bar pet | installed / not installed / not a Mac |
| **Still to do** | restart Claude Code → `/siltpoke-doctor` (Siltpoke) · `/init-harness` in a project (PLC) |

Siltpoke commands: `/siltpoke-last` · `/siltpoke-dashboard` · `/siltpoke-doctor` · `/siltpoke-mute <duration>` / `/siltpoke-unmute` · `/siltpoke-wake` · `/siltpoke-brain` (which model reviews — can be another company's CLI or a local model) · `/siltpoke-menubar` · `/siltpoke-help` (the full manual).

Cost: the review uses your existing Claude Code login — no extra account. Roughly $0.04–$0.10 a day with prompt caching. Reviews are saved on your machine; nothing is sent anywhere except the normal model call and a once-a-day check with GitHub for the latest version number — that check sends nothing about you or your code, and Siltpoke receives nothing. Turn it off with `"updateCheck": {"enabled": false}` in `~/.siltpoke/config.json`.

PLC commands: `/init-harness` · `/ship` · `/review` · `/research` · `/handoff` · `/catchup` · `/release`. If another plugin uses the same name, use the long form, e.g. `/project-lifecycle:ship`.

Uninstall: `claude plugin uninstall siltpoke` · `claude plugin uninstall project-lifecycle@project-life-cycle`
Want the other plugin later? Paste this same prompt again — it only adds what is missing.

Codex

Paste into Codex. Codex has no custom slash commands, so the prompt teaches you the plain-words version of each one.

You are installing Codex plugins for me, setting them up, and then teaching me to use them. Talk to me in the language I am writing in. Keep each message short. **Ask me before anything that downloads and runs a script, installs an app, clones a repo, or changes my shell profile or config files.**

There are two plugins. They are independent — I can have one, the other, or both:
- **Siltpoke** — a second reviewer that watches my coding sessions. After each turn, a *separate* AI process reads what changed and writes down what it thinks was missed. It remembers bugs across sessions, and it has a dashboard and a small pet. Repo: https://github.com/Siltpoke/siltpoke
- **Project Life Cycle (PLC)** — a working method for AI coding: spec → plan → build → verify → ship → release. Repo: https://github.com/Siltpoke/project-life-cycle

**Important for Codex:** neither plugin has slash commands here. Everything is done by asking you in plain words, and you use their skills. Tell me this once, early.

## Before anything — am I on Windows?

Run `uname -s`. If it fails, or prints anything that is not `Darwin` or `Linux`
(on Windows it will not exist, or a Git-Bash shell prints `MINGW64_NT-...`),
**stop here and tell me this, in my language, before installing anything:**

> Siltpoke does not support native Windows yet. It will install, the pet will
> appear, the commands will work and the config will say the setup is fine —
> but the review hook is registered as `sh ./hooks/stop.sh`, Windows has no
> `sh`, so no review will ever run and nothing will say so. If you have WSL,
> run this again inside WSL and everything works, because that is Linux.
> Otherwise, wait for native Windows support.

Then ask whether I want to continue anyway. **Do not install unless I say yes**,
and if I do, say once more that reviews will not fire. Project Life Cycle has no
such problem — it is prompts and commands, no hook — so offer to install only
PLC instead.

## Step 0 — What do I already have, and what do I want?

Run `codex plugin list` first. Then:
- If one of them is already installed, say so in one line ("you already have PLC — this time I'll only add Siltpoke") and skip its install.
- For anything not installed yet, ask me once: **both / only Siltpoke / only PLC**. Recommend "both" in one sentence, but do what I pick. Every later step applies only to what I picked.

## Step 1 — Check the tools

Run these and tell me in one line each what you found:
- `codex --version`, `git --version`, `uname -s` (a Mac? only matters for the menu-bar pet in Step 4)
- Siltpoke only: `bun --version`. Siltpoke's reviewer runs on Bun. If it is missing, **ask me first**, then run `curl -fsSL https://bun.sh/install | bash` and check again with `~/.bun/bin/bun --version` (my shell will not see the new PATH until it restarts — that is fine, setup records the full path).

## Step 2 — Install

Run one line at a time. If any line fails, stop and show me the exact error.

**Siltpoke:**
```bash
codex plugin marketplace add https://github.com/Siltpoke/siltpoke
codex plugin add siltpoke@siltpoke
```
The `@siltpoke` part is required — a bare `codex plugin add siltpoke` fails.

**PLC** installs from a local copy in Codex, so it needs more steps:
1. Ask me, then clone it: `git clone https://github.com/Siltpoke/project-life-cycle ~/plugins/project-lifecycle`
2. Read the section "Codex setup" in `~/plugins/project-lifecycle/README.md` and follow it exactly: it adds one entry to `~/.agents/plugins/marketplace.json`, then runs `codex plugin add project-lifecycle@<marketplace-name>`. If that file already exists, show me the change before you write it. If you cannot tell the marketplace name, show me the file and ask.

Then run `codex plugin list` and confirm each one I picked shows as installed and enabled. Do not claim success from the install output alone. **If Siltpoke is not in that list, stop here and show me the error** — do not go on to Step 3; setup on a plugin that is not installed looks like it worked, but reviews will never run.

## Step 3 — Set up Siltpoke (skip if I did not pick it)

Reviews do not start until a pet exists at `~/.siltpoke/config.json`. If that file already exists, setup was done before: say so, ask if I want to redo it, and skip to Step 4 if not.

The Siltpoke skill does the setup. A new Codex skill may not be loaded until a new thread, so read it from disk instead:
1. Find the installed plugin folder: `ls -d ~/.codex/plugins/cache/siltpoke/siltpoke/*/ | sort -V | tail -1`. Call it `PLUGIN_ROOT`. Only use this folder — Codex also keeps a download copy under `~/.codex/.tmp/`, which is not the installed plugin.
2. Read `PLUGIN_ROOT/skills/siltpoke/SKILL.md` (if not there: `find PLUGIN_ROOT -name SKILL.md -path '*siltpoke*'`).
3. Follow its sections **"Resolve the plugin root first"** and **"Create your pet (first-time setup)"** exactly. It asks me Express or Custom — let me choose.
4. When it finishes, tell me the result in plain words. If it fails, translate the error and stop.

## Step 4 — The menu-bar pet (Siltpoke + Mac only)

On a Mac, the menu bar is the easiest place to see Siltpoke without opening anything. Explain it in two sentences and ask if I want it:

- **The menu-bar pet** sits in the Mac's top menu bar and shows **all your sessions at once** — every project, and every coding tool Siltpoke watches (Codex, and Claude Code if you use it too). You see it all the time, even with every terminal closed. The number next to it is how many sessions have a recent review (not a count of problems). Click it for a list: one line per session (project · branch · time · which coding tool wrote the code) with its latest review, plus "Open dashboard" and "Restart daemon". It refreshes once a minute.
- (If I also use Claude Code: there, Siltpoke also has a **terminal pet** in the bottom line, which shows only that one session and changes after every turn.)

If I say yes:
1. It needs the free app SwiftBar. Check with `ls /Applications/SwiftBar.app`. If it is missing, ask me: install with `brew install --cask swiftbar` (only if `brew --version` works), or let me download it from https://github.com/swiftbar/SwiftBar. Then open it once: `open -a SwiftBar` (the first time, it asks me to pick a plugin folder — accept the default).
2. Run `"$BUN" "$PLUGIN_ROOT/dist/siltpoke-cli.js" menubar install`, then `… menubar status`, and tell me in one sentence what it said.

## Step 5 — PLC needs no global setup (skip if I did not pick it)

Tell me: PLC is set up **per project**, not once for the whole machine. There is no `/init-harness` command in Codex — instead, inside a project I say "set up this project with project-lifecycle", and the skill looks at the code, writes a few project files, and asks before overwriting anything. Do **not** do it now.

## Step 6 — The one thing I must do myself

Tell me clearly: **quit Codex and start it again (or at least start a new thread) now.** New skills and the review hook only load then.

## Step 7 — Getting started: my first day

Before I restart, print this walkthrough in my language, only the parts for what I installed, filled with my real results. Make it a numbered list I can follow step by step. In Codex everything is said in plain words — give me the exact sentence to say. Do not invent features that are not listed here.

**Siltpoke — first 10 minutes**
1. Say: "check my Siltpoke install". You get a ✓/✗ checklist. All ✓ means it works. If something is ✗, it says what to do.
2. Ask Codex for any small real change (for example: "add a comment explaining this function"). When Codex finishes, Siltpoke reviews the change in the background. You do not need to do anything.
3. On a Mac with the menu-bar pet, the menu bar shows the new review within a minute.
4. Say: "show me the latest Siltpoke review".
5. Say: "open the Siltpoke dashboard". It opens http://127.0.0.1:9876 — review history, chat with your pet about your code, what it remembers, and the Code Map. On a review, press **ACK** (seen, useful) or **DISMISS** (wrong). This is how it learns what to stop saying.
6. Need quiet? Say "mute Siltpoke for 1 hour", and "unmute Siltpoke" to undo.

**PLC — your first project**
1. Inside a project, say: "set up this project with project-lifecycle". Answer its questions.
2. Talk about the code first, no edits: "explain how this project is structured."
3. Build one small feature: "use project-lifecycle to ship <what you want>". It stops to check with you at the user story, the spec, and the pull request.
4. Stopping for the day? Say "hand off — save where we are to RESUME.md".
5. Next time, say "catch me up from RESUME.md".

**Both together — a normal day**
1. Open a project → "catch me up"
2. Build with project-lifecycle, or just work normally
3. Siltpoke reviews each turn in the background → "show me the latest Siltpoke review"
4. Leaving → "hand off"

## Step 8 — Keep using it

Print this right after the first-day walkthrough, in my language, only the parts for what I installed. It is how I use the plugins every day after the first one.

**Siltpoke, every day**
1. Just work. Siltpoke reviews each turn by itself — you never have to start it.
2. When the pet looks worried (or the menu-bar number goes up), read the review: say "show me the latest Siltpoke review".
3. Teach it. In the dashboard (say "open the Siltpoke dashboard"), press **DISMISS** on a review that is wrong and **ACK** on one that helped. It remembers, and over time stops repeating what you dismissed.
4. Once a week, look at the dashboard's Memory page — that is what it has learned about your code.
5. Reviews went quiet? say "check my Siltpoke install" first; if everything is ✓, say "wake Siltpoke".
6. Busy (a demo, pairing)? say "mute Siltpoke for 1 hour" — it turns itself back on when the time is up.

**PLC, every session**
1. Start: say "catch me up from RESUME.md" — where you left off, what shipped, what is next.
2. New feature: say "use project-lifecycle to ship <what you want>".
3. A design question you are not sure about: say "research <question> with project-lifecycle" — it comes back with cited sources.
4. Before merging a branch: say "review this branch with project-lifecycle".
5. End: say "hand off — save where we are to RESUME.md". The next session starts again at item 1.
6. Ready to publish a version: say "cut a release with project-lifecycle".

**Keep it current:** PLC: `git -C ~/plugins/project-lifecycle pull`, then the update steps in its README §"Codex setup". Siltpoke: the Codex section of https://github.com/Siltpoke/siltpoke#codex. Then restart Codex.

## Step 9 — The manual

End with this, in my language, only the rows for what I installed:

| | Status |
|---|---|
| Project Life Cycle | installed — version from `codex plugin list` |
| Siltpoke | installed — version, pet name + species |
| Bun | version (and its path) |
| Menu-bar pet | installed / not installed / not a Mac |
| **Still to do** | restart Codex → "check my Siltpoke install" (Siltpoke) · "set up this project with project-lifecycle" (PLC) |

Siltpoke, things to say: check my install · show the latest review · open the dashboard · mute for <time> / unmute · menu-bar pet install / status / remove · show the Siltpoke manual. Not available in a plugin install (they need a source clone): listing or dismissing reviews from the chat, `remember`, and indexing a repo for the Code Map from the chat — use the dashboard for reviews.

Cost: the review runs a separate model call through a CLI you are already logged into — no extra account. Reviews are saved on your machine; nothing is sent anywhere except the normal model call and a once-a-day check with GitHub for the latest version number — that check sends nothing about you or your code, and Siltpoke receives nothing. Turn it off with `"updateCheck": {"enabled": false}` in `~/.siltpoke/config.json`.

Want the other plugin later? Paste this same prompt again — it only adds what is missing.

Antigravity

Paste into Antigravity (agy). It clones the repos for you — Antigravity only installs from a local folder.

You are installing Antigravity (agy) plugins for me, setting them up, and then teaching me to use them. Talk to me in the language I am writing in. Keep each message short. **Ask me before anything that downloads and runs a script, installs an app, clones a repo, or changes my shell profile or config files.**

There are two plugins. They are independent — I can have one, the other, or both:
- **Siltpoke** — a second reviewer that watches my coding sessions. After each turn, a *separate* AI process reads what changed and writes down what it thinks was missed. It remembers bugs across sessions, and it has a dashboard and a small pet. Repo: https://github.com/Siltpoke/siltpoke
- **Project Life Cycle (PLC)** — a working method for AI coding: spec → plan → build → verify → ship → release. Repo: https://github.com/Siltpoke/project-life-cycle

**Important for agy:** neither plugin has slash commands here. Everything is done by asking you in plain words, and you use their skills. Tell me this once, early.

## Before anything — am I on Windows?

Run `uname -s`. If it fails, or prints anything that is not `Darwin` or `Linux`
(on Windows it will not exist, or a Git-Bash shell prints `MINGW64_NT-...`),
**stop here and tell me this, in my language, before installing anything:**

> Siltpoke does not support native Windows yet. It will install, the pet will
> appear, the commands will work and the config will say the setup is fine —
> but the review hook is registered as `sh ./hooks/stop.sh`, Windows has no
> `sh`, so no review will ever run and nothing will say so. If you have WSL,
> run this again inside WSL and everything works, because that is Linux.
> Otherwise, wait for native Windows support.

Then ask whether I want to continue anyway. **Do not install unless I say yes**,
and if I do, say once more that reviews will not fire. Project Life Cycle has no
such problem — it is prompts and commands, no hook — so offer to install only
PLC instead.

## Step 0 — What do I already have, and what do I want?

Run `agy plugin list` first. Then:
- If one of them is already installed, say so in one line ("you already have PLC — this time I'll only add Siltpoke") and skip its install.
- For anything not installed yet, ask me once: **both / only Siltpoke / only PLC**. Recommend "both" in one sentence, but do what I pick. Every later step applies only to what I picked.

## Step 1 — Check the tools

Run these and tell me in one line each what you found:
- `agy --version`, `git --version`, `uname -s` (a Mac? only matters for the menu-bar pet in Step 4)
- Siltpoke only: `bun --version`. Siltpoke needs Bun both to build and to review. If it is missing, **ask me first**, then run `curl -fsSL https://bun.sh/install | bash` and use `~/.bun/bin/bun` for the rest of this session (my shell will not see the new PATH until it restarts — that is fine, setup records the full path).

## Step 2 — Install

Run one line at a time. If any line fails, stop and show me the exact error.

**Siltpoke** — agy must install the `.antigravity-plugin` folder from a local copy. **Never** run `agy plugin install https://github.com/Siltpoke/siltpoke` and never install the repo's top folder: agy then registers it as a Claude Code plugin and reviews silently never run.
```bash
git clone https://github.com/Siltpoke/siltpoke.git ~/siltpoke
cd ~/siltpoke && bun install
cd ~/siltpoke && bun run build:dist
agy plugin install ~/siltpoke/.antigravity-plugin
agy plugin validate ~/siltpoke/.antigravity-plugin
```
If `~/siltpoke` already exists, ask me before touching it (it may be my own copy); if it is a clean clone of this repo, `git -C ~/siltpoke pull` instead of cloning.

**PLC:**
```bash
git clone https://github.com/Siltpoke/project-life-cycle.git ~/plugins/project-life-cycle
agy plugin install ~/plugins/project-life-cycle
```

Then run `agy plugin list` and confirm each one I picked shows as installed. Do not claim success from the install output alone.

## Step 3 — Set up Siltpoke (skip if I did not pick it)

Reviews do not start until a pet exists at `~/.siltpoke/config.json` — until then, the plugin is installed but does nothing. If that file already exists, setup was done before: say so, ask if I want to redo it, and skip to Step 4 if not.

The Siltpoke skill does the setup. Read it from disk so you do not depend on it being loaded yet:
1. `PLUGIN_ROOT` is `~/.gemini/config/plugins/siltpoke` (agy copies the plugin there). Check that `PLUGIN_ROOT/dist/siltpoke-cli.js` exists; if not, use `~/siltpoke/.antigravity-plugin`.
2. Read `PLUGIN_ROOT/skills/siltpoke/SKILL.md`.
3. Follow its sections **"Resolve the plugin root first"** and **"Create your pet (first-time setup)"** exactly. It asks me Express or Custom — let me choose.
4. When it finishes, tell me the result in plain words. If it fails, translate the error and stop.

## Step 4 — The menu-bar pet (Siltpoke + Mac only)

With this install, agy has no terminal pet (statusline) — so on a Mac, the menu bar is the one place you see Siltpoke without opening anything. Explain it in two sentences and ask if I want it:

- **The menu-bar pet** sits in the Mac's top menu bar and shows **all your sessions at once** — every project, and every coding tool Siltpoke watches (agy, and Claude Code or Codex if you use them too). You see it all the time, even with every terminal closed. The number next to it is how many sessions have a recent review (not a count of problems). Click it for a list: one line per session (project · branch · time · which coding tool wrote the code) with its latest review, plus "Open dashboard" and "Restart daemon". It refreshes once a minute.
- (A **terminal pet** — the bottom line of Claude Code — shows only the current session and changes after every turn. agy can show one too, but only with Siltpoke's from-source install, which this prompt does not use.)

If I say yes:
1. It needs the free app SwiftBar. Check with `ls /Applications/SwiftBar.app`. If it is missing, ask me: install with `brew install --cask swiftbar` (only if `brew --version` works), or let me download it from https://github.com/swiftbar/SwiftBar. Then open it once: `open -a SwiftBar` (the first time, it asks me to pick a plugin folder — accept the default).
2. Run `"$BUN" "$PLUGIN_ROOT/dist/siltpoke-cli.js" menubar install`, then `… menubar status`, and tell me in one sentence what it said.

## Step 5 — PLC needs no global setup (skip if I did not pick it)

Tell me: PLC is set up **per project**, not once for the whole machine. There is no `/init-harness` command in agy — instead, inside a project I say "set up this project with project-lifecycle", and the skill looks at the code, writes a few project files, and asks before overwriting anything. Do **not** do it now.

## Step 6 — The one thing I must do myself

Tell me clearly: **quit agy and start it again now.** New skills and the review hook only load then.

One limit to mention: reviews do not run in headless `agy -p` mode with this install — only in normal interactive sessions.

## Step 7 — Getting started: my first day

Before I restart, print this walkthrough in my language, only the parts for what I installed, filled with my real results. Make it a numbered list I can follow step by step. In agy everything is said in plain words — give me the exact sentence to say. Do not invent features that are not listed here.

**Siltpoke — first 10 minutes**
1. Say: "check my Siltpoke install". You get a ✓/✗ checklist. All ✓ means it works. If something is ✗, it says what to do.
2. Ask agy for any small real change (for example: "add a comment explaining this function"). When agy finishes, Siltpoke reviews the change in the background — agy does not wait for it.
3. On a Mac with the menu-bar pet, the menu bar shows the new review within a minute.
4. Say: "show me the latest Siltpoke review".
5. Say: "open the Siltpoke dashboard". It opens http://127.0.0.1:9876 — review history, chat with your pet about your code, what it remembers, and the Code Map. On a review, press **ACK** (seen, useful) or **DISMISS** (wrong). This is how it learns what to stop saying.
6. Need quiet? Say "mute Siltpoke for 1 hour", and "unmute Siltpoke" to undo.

Good to know: if you pick a Claude model inside agy, the reviewer is also Claude — Claude reviewing Claude, so it can share the same blind spots.

**PLC — your first project**
1. Inside a project, say: "set up this project with project-lifecycle". Answer its questions.
2. Talk about the code first, no edits: "explain how this project is structured."
3. Build one small feature: "use project-lifecycle to ship <what you want>". It stops to check with you at the user story, the spec, and the pull request.
4. Stopping for the day? Say "hand off — save where we are to RESUME.md".
5. Next time, say "catch me up from RESUME.md".

**Both together — a normal day:** catch me up → build → Siltpoke reviews each turn in the background → "show me the latest Siltpoke review" → hand off.

## Step 8 — Keep using it

Print this right after the first-day walkthrough, in my language, only the parts for what I installed. It is how I use the plugins every day after the first one.

**Siltpoke, every day**
1. Just work. Siltpoke reviews each turn by itself — you never have to start it.
2. When the pet looks worried (or the menu-bar number goes up), read the review: say "show me the latest Siltpoke review".
3. Teach it. In the dashboard (say "open the Siltpoke dashboard"), press **DISMISS** on a review that is wrong and **ACK** on one that helped. It remembers, and over time stops repeating what you dismissed.
4. Once a week, look at the dashboard's Memory page — that is what it has learned about your code.
5. Reviews went quiet? say "check my Siltpoke install" first; if everything is ✓, say "wake Siltpoke".
6. Busy (a demo, pairing)? say "mute Siltpoke for 1 hour" — it turns itself back on when the time is up.

**PLC, every session**
1. Start: say "catch me up from RESUME.md" — where you left off, what shipped, what is next.
2. New feature: say "use project-lifecycle to ship <what you want>".
3. A design question you are not sure about: say "research <question> with project-lifecycle" — it comes back with cited sources.
4. Before merging a branch: say "review this branch with project-lifecycle".
5. End: say "hand off — save where we are to RESUME.md". The next session starts again at item 1.
6. Ready to publish a version: say "cut a release with project-lifecycle".

**Keep it current:** `git -C ~/siltpoke pull && cd ~/siltpoke && bun install && bun run build:dist && agy plugin install ~/siltpoke/.antigravity-plugin` · PLC: `git -C ~/plugins/project-life-cycle pull && agy plugin install ~/plugins/project-life-cycle`. Then restart agy.

## Step 9 — The manual

End with this, in my language, only the rows for what I installed:

| | Status |
|---|---|
| Project Life Cycle | installed — version from `agy plugin list` |
| Siltpoke | installed — version, pet name + species |
| Bun | version (and its path) |
| Menu-bar pet | installed / not installed / not a Mac |
| **Still to do** | restart agy → "check my Siltpoke install" (Siltpoke) · "set up this project with project-lifecycle" (PLC) |

Siltpoke, things to say: check my install · show the latest review · open the dashboard · mute for <time> / unmute · menu-bar pet install / status / remove · show the Siltpoke manual. Not available in a plugin install (they need Siltpoke's source scripts): listing or dismissing reviews from the chat, `remember`, and indexing a repo for the Code Map from the chat — use the dashboard for reviews.

Cost: the review runs a separate model call through a CLI you are already logged into — no extra account. Reviews are saved on your machine; nothing is sent anywhere except the normal model call and a once-a-day check with GitHub for the latest version number — that check sends nothing about you or your code, and Siltpoke receives nothing. Turn it off with `"updateCheck": {"enabled": false}` in `~/.siltpoke/config.json`.

Want the other plugin later? Paste this same prompt again — it only adds what is missing.

CodeBuddy

Paste into CodeBuddy.

You are installing CodeBuddy plugins for me, setting them up, and then teaching me to use them. Talk to me in the language I am writing in. Keep each message short. **Ask me before anything that downloads and runs a script, installs an app, or changes my shell profile or config files.**

There are two plugins. They are independent — I can have one, the other, or both:
- **Siltpoke** — a second reviewer that watches my coding sessions. After each turn, a *separate* AI process reads what changed and writes down what it thinks was missed. It remembers bugs across sessions, and it has a dashboard and a small pet. Repo: https://github.com/Siltpoke/siltpoke
- **Project Life Cycle (PLC)** — a working method for AI coding: spec → plan → build → verify → ship → release. Repo: https://github.com/Siltpoke/project-life-cycle

## Before anything — am I on Windows?

Run `uname -s`. If it fails, or prints anything that is not `Darwin` or `Linux`
(on Windows it will not exist, or a Git-Bash shell prints `MINGW64_NT-...`),
**stop here and tell me this, in my language, before installing anything:**

> Siltpoke does not support native Windows yet. It will install, the pet will
> appear, the commands will work and the config will say the setup is fine —
> but the review hook is registered as `sh ./hooks/stop.sh`, Windows has no
> `sh`, so no review will ever run and nothing will say so. If you have WSL,
> run this again inside WSL and everything works, because that is Linux.
> Otherwise, wait for native Windows support.

Then ask whether I want to continue anyway. **Do not install unless I say yes**,
and if I do, say once more that reviews will not fire. Project Life Cycle has no
such problem — it is prompts and commands, no hook — so offer to install only
PLC instead.

## Step 0 — What do I already have, and what do I want?

Run `codebuddy plugin list` first (if that subcommand is not available, tell me to open the `/plugin` screen and read you the **Installed** tab). Then:
- If one of them is already installed, say so in one line ("you already have PLC — this time I'll only add Siltpoke") and skip its install.
- For anything not installed yet, ask me once: **both / only Siltpoke / only PLC**. Recommend "both" in one sentence, but do what I pick. Every later step applies only to what I picked.

## Step 1 — Check the tools

Run these and tell me in one line each what you found:
- `codebuddy --version`, `git --version`, `uname -s` (a Mac? only matters for the menu-bar pet in Step 4)
- Siltpoke only: `bun --version`. Siltpoke's reviewer runs on Bun. If it is missing, **ask me first**, then run `curl -fsSL https://bun.sh/install | bash` and check again with `~/.bun/bin/bun --version` (my shell will not see the new PATH until it restarts — that is fine, setup records the full path).

## Step 2 — Install

Run one line at a time. If any line fails, stop and show me the exact error.

```bash
# Siltpoke
codebuddy plugin marketplace add https://github.com/Siltpoke/siltpoke
codebuddy plugin install siltpoke@siltpoke

# PLC
codebuddy plugin marketplace add https://github.com/Siltpoke/project-life-cycle
codebuddy plugin install project-lifecycle@project-life-cycle
```

The `@…` part is required — a bare `codebuddy plugin install siltpoke` fails with `Marketplace 'undefined' is not ready`. If the PLC lines fail as a command-line call, tell me to type these two inside CodeBuddy instead: `/plugin marketplace add Siltpoke/project-life-cycle` and `/plugin install project-lifecycle@project-life-cycle`.

Then confirm each one I picked shows as installed. Do not claim success from the install output alone.

## Step 3 — Set up Siltpoke (skip if I did not pick it)

Reviews do not start until a pet exists at `~/.siltpoke/config.json`. If that file already exists, setup was done before: say so, ask if I want to redo it, and skip to Step 4 if not.

CodeBuddy installs the same plugin files as Claude Code, so the setup instructions are on disk:
1. Find them: `find ~/.codebuddy -name siltpoke-setup.md 2>/dev/null | head -1` (if nothing, try `find ~ -maxdepth 6 -name siltpoke-setup.md -path '*siltpoke*' 2>/dev/null | head -1`). The plugin folder, `PLUGIN_ROOT`, is the folder that contains `.claude-plugin/`. Check that `PLUGIN_ROOT/dist/siltpoke-cli.js` exists.
2. Read that `siltpoke-setup.md` and follow it exactly. Wherever it says `${CLAUDE_PLUGIN_ROOT}`, use the real `PLUGIN_ROOT`. If `bun` is not on PATH yet, use `~/.bun/bin/bun`. Where it says "restart Claude Code", say "restart CodeBuddy".
3. It first asks me **Express** or **Custom** — let me choose.
4. When it finishes, tell me the result in plain words. If it fails, translate the error and stop.

## Step 4 — The menu-bar pet (Siltpoke + Mac only)

If setup already offered the menu-bar pet and I answered, skip this step. Otherwise explain it in two sentences and ask if I want it:

- **The menu-bar pet** sits in the Mac's top menu bar and shows **all your sessions at once** — every project, and every coding tool Siltpoke watches. You see it all the time, even with every terminal closed. The number next to it is how many sessions have a recent review (not a count of problems). Click it for a list: one line per session (project · branch · time · which coding tool wrote the code) with its latest review, plus "Open dashboard" and "Restart daemon". It refreshes once a minute.
- The difference from the **terminal pet** (the bottom line of Claude Code): that one shows only the current session and changes after every turn.

If I say yes:
1. It needs the free app SwiftBar. Check with `ls /Applications/SwiftBar.app`. If it is missing, ask me: install with `brew install --cask swiftbar` (only if `brew --version` works), or let me download it from https://github.com/swiftbar/SwiftBar. Then open it once: `open -a SwiftBar` (the first time, it asks me to pick a plugin folder — accept the default).
2. Run `bun "PLUGIN_ROOT/dist/siltpoke-cli.js" menubar install`, then `… menubar status`, and tell me in one sentence what it said.

## Step 5 — PLC needs no global setup (skip if I did not pick it)

Tell me: PLC is set up **per project**, not once for the whole machine. Inside a project I either type `/init-harness` (if CodeBuddy shows it) or say "set up this project with project-lifecycle". It looks at the code, writes a few project files, and asks before overwriting anything. Do **not** do it now.

## Step 6 — The one thing I must do myself

Tell me clearly: **run `/reload-plugins` in CodeBuddy, or quit and start it again, now.** The plugins and the review hook only load then. Then ask me to type `/siltpoke-` and tell you whether commands show up — that decides which column of Step 7 I use.

## Step 7 — Getting started: my first day

Before I reload, print this walkthrough in my language, only the parts for what I installed, filled with my real results. Make it a numbered list. For each step give both forms — **the slash command** (if CodeBuddy shows `/siltpoke-…` commands) **or the sentence to say**. Do not invent features that are not listed here.

**Siltpoke — first 10 minutes**
1. `/siltpoke-doctor` or "check my Siltpoke install". You get a ✓/✗ checklist. All ✓ means it works. If something is ✗, it says what to do.
2. Ask CodeBuddy for any small real change (for example: "add a comment explaining this function"). When it finishes, Siltpoke reviews the change in the background. You do not need to do anything.
3. On a Mac with the menu-bar pet, the menu bar shows the new review within a minute.
4. `/siltpoke-last` or "show me the latest Siltpoke review".
5. `/siltpoke-dashboard` or "open the Siltpoke dashboard". It opens http://127.0.0.1:9876 — review history, chat with your pet about your code, what it remembers, and the Code Map. On a review, press **ACK** (seen, useful) or **DISMISS** (wrong). This is how it learns what to stop saying.
6. Need quiet? `/siltpoke-mute 1h` or "mute Siltpoke for 1 hour"; `/siltpoke-unmute` or "unmute Siltpoke" to undo.

**PLC — your first project**
1. Inside a project: `/init-harness` or "set up this project with project-lifecycle". Answer its questions.
2. Talk about the code first, no edits: "explain how this project is structured."
3. Build one small feature: `/ship <what you want>` or "use project-lifecycle to ship <what you want>". It stops to check with you at the user story, the spec, and the pull request.
4. Stopping for the day? `/handoff` or "hand off — save where we are to RESUME.md".
5. Next time: `/catchup` or "catch me up from RESUME.md".

**Both together — a normal day:** catch up → build → Siltpoke reviews each turn in the background → read the latest review when you want → hand off.

## Step 8 — Keep using it

Print this right after the first-day walkthrough, in my language, only the parts for what I installed. It is how I use the plugins every day after the first one.

**Siltpoke, every day**
1. Just work. Siltpoke reviews each turn by itself — you never have to start it.
2. When the pet looks worried (or the menu-bar number goes up), read the review: `/siltpoke-last` or "show me the latest Siltpoke review".
3. Teach it. In the dashboard (`/siltpoke-dashboard` or "open the Siltpoke dashboard"), press **DISMISS** on a review that is wrong and **ACK** on one that helped. It remembers, and over time stops repeating what you dismissed.
4. Once a week, look at the dashboard's Memory page — that is what it has learned about your code.
5. Reviews went quiet? `/siltpoke-doctor` or "check my Siltpoke install" first; if everything is ✓, `/siltpoke-wake` or "wake Siltpoke".
6. Busy (a demo, pairing)? `/siltpoke-mute 1h` or "mute Siltpoke for 1 hour" — it turns itself back on when the time is up.

**PLC, every session**
1. Start: `/catchup` or "catch me up from RESUME.md" — where you left off, what shipped, what is next.
2. New feature: `/ship <what you want>` or "use project-lifecycle to ship <what you want>".
3. A design question you are not sure about: `/research <question>` or "research <question> with project-lifecycle" — it comes back with cited sources.
4. Before merging a branch: `/review` or "review this branch with project-lifecycle".
5. End: `/handoff` or "hand off — save where we are to RESUME.md". The next session starts again at item 1.
6. Ready to publish a version: `/release` or "cut a release with project-lifecycle".

**Keep it current:** inside CodeBuddy, `/plugin marketplace update siltpoke` and `/plugin marketplace update project-life-cycle`, then `/reload-plugins`.

## Step 9 — The manual

End with this, in my language, only the rows for what I installed:

| | Status |
|---|---|
| Project Life Cycle | installed — version |
| Siltpoke | installed — version, pet name + species |
| Bun | version (and its path) |
| Menu-bar pet | installed / not installed / not a Mac |
| Slash commands in CodeBuddy | yes / no (from Step 6) |
| **Still to do** | reload → check the Siltpoke install · set up a project with PLC |

Cost: the review runs a separate model call through a CLI you are already logged into — no extra account. Reviews are saved on your machine; nothing is sent anywhere except the normal model call and a once-a-day check with GitHub for the latest version number — that check sends nothing about you or your code, and Siltpoke receives nothing. Turn it off with `"updateCheck": {"enabled": false}` in `~/.siltpoke/config.json`.

Want the other plugin later? Paste this same prompt again — it only adds what is missing.

Qoder

Paste into Qoder (qodercli).

You are installing Qoder plugins for me, setting them up, and then teaching me to use them. Talk to me in the language I am writing in. Keep each message short. **Ask me before anything that downloads and runs a script, installs an app, or changes my shell profile or config files.**

There are two plugins. They are independent — I can have one, the other, or both:
- **Siltpoke** — a second reviewer that watches my coding sessions. After each turn, a *separate* AI process reads what changed and writes down what it thinks was missed. It remembers bugs across sessions, and it has a dashboard and a small pet. Repo: https://github.com/Siltpoke/siltpoke
- **Project Life Cycle (PLC)** — a working method for AI coding: spec → plan → build → verify → ship → release. Repo: https://github.com/Siltpoke/project-life-cycle

## Before anything — am I on Windows?

Run `uname -s`. If it fails, or prints anything that is not `Darwin` or `Linux`
(on Windows it will not exist, or a Git-Bash shell prints `MINGW64_NT-...`),
**stop here and tell me this, in my language, before installing anything:**

> Siltpoke does not support native Windows yet. It will install, the pet will
> appear, the commands will work and the config will say the setup is fine —
> but the review hook is registered as `sh ./hooks/stop.sh`, Windows has no
> `sh`, so no review will ever run and nothing will say so. If you have WSL,
> run this again inside WSL and everything works, because that is Linux.
> Otherwise, wait for native Windows support.

Then ask whether I want to continue anyway. **Do not install unless I say yes**,
and if I do, say once more that reviews will not fire. Project Life Cycle has no
such problem — it is prompts and commands, no hook — so offer to install only
PLC instead.

## Step 0 — What do I already have, and what do I want?

Run `qodercli plugin list` first (if it errors, try `qodercli plugins list`). Then:
- If one of them is already installed, say so in one line ("you already have PLC — this time I'll only add Siltpoke") and skip its install.
- For anything not installed yet, ask me once: **both / only Siltpoke / only PLC**. Recommend "both" in one sentence, but do what I pick. Every later step applies only to what I picked.

## Step 1 — Check the tools

Run these and tell me in one line each what you found:
- `qodercli --version`, `git --version`, `uname -s` (a Mac? only matters for the menu-bar pet in Step 4)
- Siltpoke only: `bun --version`. Siltpoke's reviewer runs on Bun. If it is missing, **ask me first**, then run `curl -fsSL https://bun.sh/install | bash` and check again with `~/.bun/bin/bun --version` (my shell will not see the new PATH until it restarts — that is fine, setup records the full path).

## Step 2 — Install

Run one line at a time. If any line fails, stop and show me the exact error.

```bash
# Siltpoke
qodercli plugin marketplace add https://github.com/Siltpoke/siltpoke
qodercli plugin install siltpoke@siltpoke

# PLC
qodercli plugins marketplace add Siltpoke/project-life-cycle
qodercli plugins install project-lifecycle
```

For Siltpoke the `@siltpoke` part is required — a bare install fails. If a line fails with an unknown-command error, try the same line with `plugin` ↔ `plugins` swapped, and tell me which form worked.

Then confirm each one I picked shows as installed. Do not claim success from the install output alone.

## Step 3 — Set up Siltpoke (skip if I did not pick it)

Reviews do not start until a pet exists at `~/.siltpoke/config.json`. If that file already exists, setup was done before: say so, ask if I want to redo it, and skip to Step 4 if not.

Qoder installs the same plugin files as Claude Code, so the setup instructions are on disk:
1. Find them: `find ~/.qoder -name siltpoke-setup.md 2>/dev/null | head -1` (if nothing, try `find ~ -maxdepth 6 -name siltpoke-setup.md -path '*siltpoke*' 2>/dev/null | head -1`). The plugin folder, `PLUGIN_ROOT`, is the folder that contains `.claude-plugin/`. Check that `PLUGIN_ROOT/dist/siltpoke-cli.js` exists.
2. Read that `siltpoke-setup.md` and follow it exactly. Wherever it says `${CLAUDE_PLUGIN_ROOT}`, use the real `PLUGIN_ROOT`. If `bun` is not on PATH yet, use `~/.bun/bin/bun`. Where it says "restart Claude Code", say "restart Qoder".
3. It first asks me **Express** or **Custom** — let me choose.
4. When it finishes, tell me the result in plain words. If it fails, translate the error and stop.

## Step 4 — The menu-bar pet (Siltpoke + Mac only)

If setup already offered the menu-bar pet and I answered, skip this step. Otherwise explain it in two sentences and ask if I want it:

- **The menu-bar pet** sits in the Mac's top menu bar and shows **all your sessions at once** — every project, and every coding tool Siltpoke watches. You see it all the time, even with every terminal closed. The number next to it is how many sessions have a recent review (not a count of problems). Click it for a list: one line per session (project · branch · time · which coding tool wrote the code) with its latest review, plus "Open dashboard" and "Restart daemon". It refreshes once a minute.
- The difference from the **terminal pet** (the bottom line of Claude Code): that one shows only the current session and changes after every turn.

If I say yes:
1. It needs the free app SwiftBar. Check with `ls /Applications/SwiftBar.app`. If it is missing, ask me: install with `brew install --cask swiftbar` (only if `brew --version` works), or let me download it from https://github.com/swiftbar/SwiftBar. Then open it once: `open -a SwiftBar` (the first time, it asks me to pick a plugin folder — accept the default).
2. Run `bun "PLUGIN_ROOT/dist/siltpoke-cli.js" menubar install`, then `… menubar status`, and tell me in one sentence what it said.

## Step 5 — PLC needs no global setup (skip if I did not pick it)

Tell me: PLC is set up **per project**, not once for the whole machine. Inside a project I either type `/init-harness` (if Qoder shows it) or say "set up this project with project-lifecycle". It looks at the code, writes a few project files, and asks before overwriting anything. Do **not** do it now.

## Step 6 — The one thing I must do myself

Tell me clearly: **run `/plugins reload` in Qoder, or quit and start it again, now.** The plugins and the review hook only load then. Then ask me to type `/siltpoke-` and tell you whether commands show up — that decides which column of Step 7 I use.

## Step 7 — Getting started: my first day

Before I reload, print this walkthrough in my language, only the parts for what I installed, filled with my real results. Make it a numbered list. For each step give both forms — **the slash command** (if Qoder shows `/siltpoke-…` commands) **or the sentence to say**. Do not invent features that are not listed here.

**Siltpoke — first 10 minutes**
1. `/siltpoke-doctor` or "check my Siltpoke install". You get a ✓/✗ checklist. All ✓ means it works. If something is ✗, it says what to do.
2. Ask Qoder for any small real change (for example: "add a comment explaining this function"). When it finishes, Siltpoke reviews the change in the background. You do not need to do anything.
3. On a Mac with the menu-bar pet, the menu bar shows the new review within a minute.
4. `/siltpoke-last` or "show me the latest Siltpoke review".
5. `/siltpoke-dashboard` or "open the Siltpoke dashboard". It opens http://127.0.0.1:9876 — review history, chat with your pet about your code, what it remembers, and the Code Map. On a review, press **ACK** (seen, useful) or **DISMISS** (wrong). This is how it learns what to stop saying.
6. Need quiet? `/siltpoke-mute 1h` or "mute Siltpoke for 1 hour"; `/siltpoke-unmute` or "unmute Siltpoke" to undo.

**PLC — your first project**
1. Inside a project: `/init-harness` or "set up this project with project-lifecycle". Answer its questions.
2. Talk about the code first, no edits: "explain how this project is structured."
3. Build one small feature: `/ship <what you want>` or "use project-lifecycle to ship <what you want>". It stops to check with you at the user story, the spec, and the pull request.
4. Stopping for the day? `/handoff` or "hand off — save where we are to RESUME.md".
5. Next time: `/catchup` or "catch me up from RESUME.md".

**Both together — a normal day:** catch up → build → Siltpoke reviews each turn in the background → read the latest review when you want → hand off.

## Step 8 — Keep using it

Print this right after the first-day walkthrough, in my language, only the parts for what I installed. It is how I use the plugins every day after the first one.

**Siltpoke, every day**
1. Just work. Siltpoke reviews each turn by itself — you never have to start it.
2. When the pet looks worried (or the menu-bar number goes up), read the review: `/siltpoke-last` or "show me the latest Siltpoke review".
3. Teach it. In the dashboard (`/siltpoke-dashboard` or "open the Siltpoke dashboard"), press **DISMISS** on a review that is wrong and **ACK** on one that helped. It remembers, and over time stops repeating what you dismissed.
4. Once a week, look at the dashboard's Memory page — that is what it has learned about your code.
5. Reviews went quiet? `/siltpoke-doctor` or "check my Siltpoke install" first; if everything is ✓, `/siltpoke-wake` or "wake Siltpoke".
6. Busy (a demo, pairing)? `/siltpoke-mute 1h` or "mute Siltpoke for 1 hour" — it turns itself back on when the time is up.

**PLC, every session**
1. Start: `/catchup` or "catch me up from RESUME.md" — where you left off, what shipped, what is next.
2. New feature: `/ship <what you want>` or "use project-lifecycle to ship <what you want>".
3. A design question you are not sure about: `/research <question>` or "research <question> with project-lifecycle" — it comes back with cited sources.
4. Before merging a branch: `/review` or "review this branch with project-lifecycle".
5. End: `/handoff` or "hand off — save where we are to RESUME.md". The next session starts again at item 1.
6. Ready to publish a version: `/release` or "cut a release with project-lifecycle".

**Keep it current:** `qodercli plugins marketplace update project-life-cycle` then `qodercli plugins update project-lifecycle` (the same pair with `siltpoke` for Siltpoke), then `/plugins reload`.

## Step 9 — The manual

End with this, in my language, only the rows for what I installed:

| | Status |
|---|---|
| Project Life Cycle | installed — version |
| Siltpoke | installed — version, pet name + species |
| Bun | version (and its path) |
| Menu-bar pet | installed / not installed / not a Mac |
| Slash commands in Qoder | yes / no (from Step 6) |
| **Still to do** | reload → check the Siltpoke install · set up a project with PLC |

Cost: the review runs a separate model call through a CLI you are already logged into — no extra account. Reviews are saved on your machine; nothing is sent anywhere except the normal model call and a once-a-day check with GitHub for the latest version number — that check sends nothing about you or your code, and Siltpoke receives nothing. Turn it off with `"updateCheck": {"enabled": false}` in `~/.siltpoke/config.json`.

Want the other plugin later? Paste this same prompt again — it only adds what is missing.