@pome-sh/cli 0.4.0 → 0.5.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +27 -2
- package/dist/build-info.json +3 -3
- package/dist/src/cli/docs-topics.js +45 -14
- package/dist/src/cli/install.d.ts +4 -41
- package/dist/src/cli/install.js +31 -412
- package/dist/src/cli/main.js +12 -29
- package/dist/src/cli/register.d.ts +0 -22
- package/dist/src/cli/register.js +1 -31
- package/dist/src/doctor/checks.js +1 -1
- package/package.json +1 -2
- package/dist/src/cli/agent-sdk.d.ts +0 -32
- package/dist/src/cli/agent-sdk.js +0 -105
- package/dist/src/cli/embedded-wiring.d.ts +0 -47
- package/dist/src/cli/embedded-wiring.js +0 -443
- package/dist/src/cli/skills.d.ts +0 -8
- package/dist/src/cli/skills.js +0 -141
- package/skills/pome-setup/SKILL.md +0 -150
- package/skills/pome-test/SKILL.md +0 -137
|
@@ -1,150 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: pome-setup
|
|
3
|
-
description: Use when wiring a repository's coding agent to pome so pome can run it against deterministic SaaS twins (GitHub, Stripe, Slack) — first-time setup, after the agent's third-party services change, when `pome doctor` reports the repo unwired, or when a `pome install` session hands off to you. Triggers on "wire my agent to pome", "set up pome", "make this repo pome-ready", or "/pome-setup".
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# pome-setup
|
|
7
|
-
|
|
8
|
-
Wire an existing coding agent's repository to pome (`https://pome.sh`), adapter-first, and prove the wiring with `pome doctor`. The job is not done until doctor exits green.
|
|
9
|
-
|
|
10
|
-
Pome runs agents against deterministic SaaS twins — local, resettable copies of the GitHub/Stripe/Slack APIs — and records every tool call as a trace. The OSS CLI is capture-only: a local run (`pome run --local`) records a raw trace and never scores; verdicts come from Pome cloud (`pome eval <run-dir>` on a captured trace, or a hosted `pome run`).
|
|
11
|
-
|
|
12
|
-
Wiring changes nothing about production behavior: the adapter only emits trace signals during a pome run, and twin base URLs come from env vars the pome runner injects at run time.
|
|
13
|
-
|
|
14
|
-
## Hard rules
|
|
15
|
-
|
|
16
|
-
Follow these on every step. They are not optional.
|
|
17
|
-
|
|
18
|
-
1. **Never write secrets into source, config, or chat.** No API keys, tokens, or credential values in any file you edit or any message you print. The pome runner injects `POME_*` env vars at run time; read them, never inline their values.
|
|
19
|
-
2. **Read every file immediately before you write it**, even if you already read it earlier in the session. Stale edits break repos.
|
|
20
|
-
3. **Minimal, targeted edits.** Change what the wiring requires and nothing else — no refactors, no reformatting, no drive-by fixes.
|
|
21
|
-
4. **Show the diff and get explicit user approval before applying any edit.** If your harness has an edit-approval UI, that gate counts. If it doesn't, print the proposed change in chat and wait for a yes.
|
|
22
|
-
5. **Never weaken the capture layer.** Don't remove `withPome()`, don't add `*` to `POME_EGRESS_ALLOW`, don't route around the twin.
|
|
23
|
-
6. **No production-host literals in agent source.** `pome doctor` treats a hardcoded `https://api.github.com` — even as a `??` fallback — as a twin bypass and fails. Production fallbacks belong in deployment env, not in source literals. (Loopback fallbacks like `http://127.0.0.1:3333` are fine.)
|
|
24
|
-
7. **Don't guess service coverage.** If the agent talks to a service pome has no twin for, say so explicitly and skip that service — never fake wiring.
|
|
25
|
-
8. **Finish with `pome doctor` and iterate until green.** Never report success while any check is red.
|
|
26
|
-
|
|
27
|
-
## Steps
|
|
28
|
-
|
|
29
|
-
### 0. Preflight
|
|
30
|
-
|
|
31
|
-
```bash
|
|
32
|
-
pome version
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
If the command is missing, install it (`npm install -g @pome-sh/cli`), then continue.
|
|
36
|
-
|
|
37
|
-
Auth — any one of these passing is enough (the macOS Keychain item is service `sh.pome.cli`, account `hosted`):
|
|
38
|
-
|
|
39
|
-
```bash
|
|
40
|
-
security find-generic-password -s "sh.pome.cli" -a hosted -w >/dev/null 2>&1 \
|
|
41
|
-
|| test -f ~/.pome/credentials.json \
|
|
42
|
-
|| [ -n "$POME_API_KEY" ] \
|
|
43
|
-
&& echo ok
|
|
44
|
-
```
|
|
45
|
-
|
|
46
|
-
If this does not print `ok`, run `pome login` (opens a browser; stores credentials in the macOS Keychain, or `~/.pome/credentials.json` on other platforms). When a `pome install` session handed off to you, auth was already checked — the probe just confirms instantly.
|
|
47
|
-
|
|
48
|
-
### 1. Identify the agent and its services
|
|
49
|
-
|
|
50
|
-
Read the repo (`package.json` / `pyproject.toml` / agent source / README) and establish three things:
|
|
51
|
-
|
|
52
|
-
- **Entrypoint + start command** — the exact command that starts the agent (e.g. `npm run src/index.ts`).
|
|
53
|
-
- **Framework** — Claude Agent SDK (`@anthropic-ai/claude-agent-sdk`), another SDK, or a custom script driving an LLM.
|
|
54
|
-
- **Services** — which third-party APIs the agent calls (GitHub? Stripe? Slack?). Run `pome scenarios` to see which twins exist.
|
|
55
|
-
|
|
56
|
-
**Pause: confirm the agent and its services with the user in one short message** before touching anything. Misidentified services produce irrelevant wiring.
|
|
57
|
-
|
|
58
|
-
### 2. Ensure pome.config.json
|
|
59
|
-
|
|
60
|
-
```bash
|
|
61
|
-
test -f pome.config.json && echo ready || echo "needs pome init"
|
|
62
|
-
```
|
|
63
|
-
|
|
64
|
-
If absent, tell the user `pome init` will scaffold `pome.config.json`, `scenarios/`, and example agents — after they confirm, run it.
|
|
65
|
-
|
|
66
|
-
Then set `agent.command` in `pome.config.json` to the real start command from step 1. The scaffold default runs a bundled example, not the user's agent. Show the line you set; confirm before moving on.
|
|
67
|
-
|
|
68
|
-
### 3. Wire the adapter (Claude Agent SDK repos)
|
|
69
|
-
|
|
70
|
-
For repos built on `@anthropic-ai/claude-agent-sdk`:
|
|
71
|
-
|
|
72
|
-
1. Add the dependency, matching the repo's package manager (lockfile tells you): `npm install @pome-sh/adapter-claude-sdk`.
|
|
73
|
-
2. Swap imports — `query` and `tool` come from the adapter as drop-in replacements; `createSdkMcpServer` and everything else stay on the SDK:
|
|
74
|
-
|
|
75
|
-
```ts
|
|
76
|
-
import { query, tool, withPome } from "@pome-sh/adapter-claude-sdk";
|
|
77
|
-
import { createSdkMcpServer } from "@anthropic-ai/claude-agent-sdk";
|
|
78
|
-
```
|
|
79
|
-
|
|
80
|
-
3. Call `withPome()` once at agent startup, before any requests are made. It hooks `fetch` to emit trace signals and correlation headers — only during a pome run.
|
|
81
|
-
|
|
82
|
-
For other stacks there is no adapter yet: wiring is step 4 alone, and the trace comes from the twin side. Say so explicitly in the confirmation message.
|
|
83
|
-
|
|
84
|
-
### 4. Route requests through the env pome injects
|
|
85
|
-
|
|
86
|
-
Find every place the agent reaches a twinned service and read the base URL from env instead of a literal:
|
|
87
|
-
|
|
88
|
-
```ts
|
|
89
|
-
// twin URL + token injected by the pome runner — never production
|
|
90
|
-
const { POME_GITHUB_REST_URL: baseUrl, POME_AUTH_TOKEN: token } = process.env;
|
|
91
|
-
```
|
|
92
|
-
|
|
93
|
-
| Env var | What the runner injects |
|
|
94
|
-
| --- | --- |
|
|
95
|
-
| `POME_<SERVICE>_REST_URL` | REST base URL of that service's twin (e.g. `POME_GITHUB_REST_URL`) |
|
|
96
|
-
| `POME_<SERVICE>_MCP_URL` | MCP endpoint of that twin |
|
|
97
|
-
| `POME_AUTH_TOKEN` | Bearer token for the twin session |
|
|
98
|
-
| `POME_TASK` | The task's prompt |
|
|
99
|
-
|
|
100
|
-
Remove hardcoded production hosts entirely (hard rule 6).
|
|
101
|
-
|
|
102
|
-
### 5. Verify: pome doctor to green
|
|
103
|
-
|
|
104
|
-
```bash
|
|
105
|
-
pome doctor
|
|
106
|
-
```
|
|
107
|
-
|
|
108
|
-
Doctor runs four checks in order — config → twin reachable → routing → egress floor — and stops at the first failure with ONE named cause (file:line where knowable) and ONE concrete fix. Apply the minimal fix (hard rules 2–4 still apply) and re-run. Loop until it ends green:
|
|
109
|
-
|
|
110
|
-
```
|
|
111
|
-
✓ pome.config.json found
|
|
112
|
-
✓ twin reachable github · local
|
|
113
|
-
✓ requests route to the twin reads POME_GITHUB_REST_URL
|
|
114
|
-
✓ egress floor active deny-by-default · N pattern(s) + loopback
|
|
115
|
-
```
|
|
116
|
-
|
|
117
|
-
### 6. Print next steps — don't run them
|
|
118
|
-
|
|
119
|
-
End the session by printing exactly this shape (substitute the twin and task):
|
|
120
|
-
|
|
121
|
-
```
|
|
122
|
-
wiring verified — pome doctor is green.
|
|
123
|
-
|
|
124
|
-
next steps:
|
|
125
|
-
pome scenarios github --copy # pull runnable tasks into ./scenarios/
|
|
126
|
-
pome run scenarios/01-bug-happy-path.md # 5 isolated trials against the twin
|
|
127
|
-
pome register agent <name> # optional: group dashboard runs under one agent
|
|
128
|
-
```
|
|
129
|
-
|
|
130
|
-
## Common pitfalls
|
|
131
|
-
|
|
132
|
-
| Symptom | Fix |
|
|
133
|
-
| --- | --- |
|
|
134
|
-
| `npm install @pome-sh/adapter-claude-sdk` fails | Confirm registry access (`npm view @pome-sh/adapter-claude-sdk version`). Inside a pome-twins checkout you can also pin `"@pome-sh/adapter-claude-sdk": "file:<checkout>/packages/adapter-claude-sdk"` while iterating on unpublished workspace changes. |
|
|
135
|
-
| doctor: "reads from a hardcoded https://api.github.com" | A production-host literal survives in agent source — even a `?? "https://api.github.com"` fallback triggers it. Move the fallback out of source; read `POME_GITHUB_REST_URL`. |
|
|
136
|
-
| doctor: "twin not reachable" | Twin dependencies missing — run the repo's install (`npm install` / `npm install`) and re-run `pome doctor`. |
|
|
137
|
-
| doctor: "egress floor disabled" | Remove `*` from `POME_EGRESS_ALLOW`. Never widen egress to pass a check. |
|
|
138
|
-
| Hosted commands fail 401/403 | Re-run `pome login` (or set `POME_API_KEY` in CI). |
|
|
139
|
-
| `agent.command` is still the scaffold default | Point it at the user's real agent (step 1's start command); the default runs a bundled example. |
|
|
140
|
-
| The agent talks to a service with no twin | Name it in the confirmation message and skip it (hard rule 7). The user can request the twin from pome. |
|
|
141
|
-
|
|
142
|
-
## Output contract
|
|
143
|
-
|
|
144
|
-
When this skill finishes successfully:
|
|
145
|
-
|
|
146
|
-
- `pome.config.json` exists with a real `agent.command`.
|
|
147
|
-
- Claude Agent SDK repos: `@pome-sh/adapter-claude-sdk` resolves and `withPome()` runs at startup.
|
|
148
|
-
- No hardcoded production hosts remain in agent source; twinned-service base URLs are read from `POME_*` env.
|
|
149
|
-
- `pome doctor` exits green — all four checks.
|
|
150
|
-
- The session ends with the next-steps block printed, not executed.
|
|
@@ -1,137 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: pome-test
|
|
3
|
-
description: Use when the user wants to test an already-registered coding agent against pome's deterministic SaaS twins, run their TESTS.md, or re-run scenarios after changing the agent. Triggers on phrases like "test my agent with pome", "run pome", "use /pome-test", or "run the pome tests". Reads TESTS.md, runs each scenario against the hosted twin, and reports pass/fail plus a dashboard URL.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# pome-test
|
|
7
|
-
|
|
8
|
-
Runs the scenarios listed in the repo's `TESTS.md` against pome's hosted twins, reports pass/fail per scenario, and points the user at the dashboard for the trace and the LLM-judge handoff on any failures.
|
|
9
|
-
|
|
10
|
-
This skill assumes the agent is already wired up. If `pome.config.json` or `TESTS.md` is missing, invoke `pome-setup` first.
|
|
11
|
-
|
|
12
|
-
## Prerequisites — check first
|
|
13
|
-
|
|
14
|
-
```bash
|
|
15
|
-
test -f pome.config.json && test -f TESTS.md && echo ok
|
|
16
|
-
```
|
|
17
|
-
|
|
18
|
-
If this does not print `ok`, stop and invoke `pome-setup` — the project isn't pome-ready yet.
|
|
19
|
-
|
|
20
|
-
Also verify auth (any of these passes is sufficient — Keychain on macOS is preferred):
|
|
21
|
-
|
|
22
|
-
```bash
|
|
23
|
-
security find-generic-password -s "pome-sh" -w >/dev/null 2>&1 \
|
|
24
|
-
|| test -f ~/.pome/credentials.json \
|
|
25
|
-
|| [ -n "$POME_API_KEY" ] \
|
|
26
|
-
&& echo ok
|
|
27
|
-
```
|
|
28
|
-
|
|
29
|
-
If not, run `pome login` (or ask the user to).
|
|
30
|
-
|
|
31
|
-
## Steps
|
|
32
|
-
|
|
33
|
-
### 1. Read TESTS.md
|
|
34
|
-
|
|
35
|
-
Parse the file as Markdown. Collect every line that looks like a relative path to a scenario file — typically bullets under a `## Scenarios` heading. Example:
|
|
36
|
-
|
|
37
|
-
```markdown
|
|
38
|
-
## Scenarios
|
|
39
|
-
|
|
40
|
-
- scenarios/01-bug-happy-path.md
|
|
41
|
-
- scenarios/02-missing-label.md
|
|
42
|
-
```
|
|
43
|
-
|
|
44
|
-
Yields the list `["scenarios/01-bug-happy-path.md", "scenarios/02-missing-label.md"]`. Ignore commented-out lines (`<!-- … -->`) and anything that doesn't end with `.md`.
|
|
45
|
-
|
|
46
|
-
If the list is empty, stop and report: "TESTS.md has no scenarios. Run `pome scenarios <twin> --copy` to add some, then list them under `## Scenarios`."
|
|
47
|
-
|
|
48
|
-
### 2. Confirm scope with the user
|
|
49
|
-
|
|
50
|
-
Print the planned runs in one short message:
|
|
51
|
-
|
|
52
|
-
```
|
|
53
|
-
About to run 2 scenarios (hosted):
|
|
54
|
-
- scenarios/01-bug-happy-path.md
|
|
55
|
-
- scenarios/02-missing-label.md
|
|
56
|
-
```
|
|
57
|
-
|
|
58
|
-
Wait for the user to confirm before spending hosted credits. If they want to skip a scenario or add one, edit TESTS.md and re-read.
|
|
59
|
-
|
|
60
|
-
### 3. Run each scenario
|
|
61
|
-
|
|
62
|
-
For every scenario path, run:
|
|
63
|
-
|
|
64
|
-
```bash
|
|
65
|
-
pome run <path>
|
|
66
|
-
```
|
|
67
|
-
|
|
68
|
-
Pome handles agent spawning, twin routing, recording, and scoring. A `--local`
|
|
69
|
-
run is not scored, so its exit code only reflects whether the agent ran
|
|
70
|
-
cleanly (`0`) or errored/timed out (`3`); exit `0` from `--local` means "trace
|
|
71
|
-
captured," not "scenario passed." Do not gate CI on a `--local` exit code.
|
|
72
|
-
|
|
73
|
-
The exit code tells you the result:
|
|
74
|
-
|
|
75
|
-
| Exit code | Meaning |
|
|
76
|
-
| --- | --- |
|
|
77
|
-
| 0 | All scenarios passed (hosted/scored run), or trace captured (`--local`, not scored) |
|
|
78
|
-
| 1 | At least one scenario scored below threshold |
|
|
79
|
-
| 2 | Twin or runner error (network, 5xx, twin spawn failed) |
|
|
80
|
-
| 3 | Auth error — `pome login` again; also a `--local` agent that failed to start or timed out |
|
|
81
|
-
| 4 | Quota exceeded |
|
|
82
|
-
| 5 | Usage error (bad flags, missing files) |
|
|
83
|
-
|
|
84
|
-
Capture stderr from each run — `pome` prints `PASS`/`FAIL`, the score, the local run dir, and the cloud dashboard URL on a successful invocation.
|
|
85
|
-
|
|
86
|
-
### 4. Report inline
|
|
87
|
-
|
|
88
|
-
After all runs finish, print a single summary block:
|
|
89
|
-
|
|
90
|
-
```
|
|
91
|
-
Pome results — 2 scenarios
|
|
92
|
-
|
|
93
|
-
✓ scenarios/01-bug-happy-path.md score 100/100 <cloud-url>
|
|
94
|
-
✗ scenarios/02-missing-label.md score 60/100 <cloud-url>
|
|
95
|
-
|
|
96
|
-
1 failed. Open the dashboard for the trace and the LLM-judge handoff:
|
|
97
|
-
https://app.pome.sh
|
|
98
|
-
```
|
|
99
|
-
|
|
100
|
-
Use the cloud URL pome printed on stderr for each run. For scenarios with a non-zero exit code from the runner (codes 2-5), surface the error verbatim — don't try to recover.
|
|
101
|
-
|
|
102
|
-
### 5. On failures, surface the judge handoff
|
|
103
|
-
|
|
104
|
-
The dashboard's run page shows an LLM-judge handoff: a one-paragraph diagnosis and a concrete next step to fix the agent. **Do not invent your own fix suggestion** — the judge has the full trace and the agent's tool calls; you don't.
|
|
105
|
-
|
|
106
|
-
Tell the user, once, at the end:
|
|
107
|
-
|
|
108
|
-
```
|
|
109
|
-
For each failed run, open the dashboard URL above and copy the "judge handoff" section
|
|
110
|
-
into a new prompt. That's the most reliable next step.
|
|
111
|
-
```
|
|
112
|
-
|
|
113
|
-
## Output contract
|
|
114
|
-
|
|
115
|
-
When this skill finishes:
|
|
116
|
-
|
|
117
|
-
- Each scenario has been attempted (or skipped explicitly with a reason).
|
|
118
|
-
- A pass/fail summary is in the chat.
|
|
119
|
-
- Each run has a `cloud` URL in the summary (hosted runs always land on the dashboard).
|
|
120
|
-
- For failed runs, the user knows how to retrieve the judge handoff.
|
|
121
|
-
|
|
122
|
-
## Common pitfalls
|
|
123
|
-
|
|
124
|
-
| Symptom | Fix |
|
|
125
|
-
| --- | --- |
|
|
126
|
-
| Every scenario exits 3 (auth) | `pome login` and re-run. |
|
|
127
|
-
| Scenarios exit 2 with "agent command failed" | The `agent.command` in `pome.config.json` is wrong. Open it, fix, retry one scenario. |
|
|
128
|
-
| `pome run` blocks waiting for input | The agent is reading stdin. Make sure the agent reads its task from `POME_TASK`, not stdin. |
|
|
129
|
-
| User asks "what changed since last run?" | Pome stores per-run artifacts under `runs/<scenario>/<run-id>/` locally, and the dashboard page diffs clone state between runs. |
|
|
130
|
-
| User asks for an automatic fix | Decline — surface the dashboard handoff instead. The handoff is grounded in the full trace; an unguided fix attempt usually regresses. |
|
|
131
|
-
|
|
132
|
-
## Reference
|
|
133
|
-
|
|
134
|
-
- Dashboard layout: `pome docs dashboard`
|
|
135
|
-
- Scenarios catalog: `pome scenarios`
|
|
136
|
-
- CLI flags and exit codes: `pome docs cli-reference`
|
|
137
|
-
- Re-wire from scratch: invoke `pome-setup`
|