TON-XXXX: Add Skill Catalog pup commands for the agentic onboarding API#640
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0e4ac4bb84
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6784b62eab
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Mirrors the query params added in DataDog#640's onboarding skills_get, so `pup skills catalog get` can scope a fetch to an onboarding session/org and record fetch intent. - src/commands/skills.rs: catalog_get takes optional intent (validated against explore/install/reference), session_id, org_id and forwards them as query params. - src/main.rs: SkillsCatalogActions::Get gains --intent, --session-id, --org-id flags. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
6784b62 to
e45df6a
Compare
This comment has been minimized.
This comment has been minimized.
9566d40 to
cce253a
Compare
|
@codex review |
|
Codex Review: Didn't find any major issues. More of your lovely PRs please. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
2b2ff83 to
f1c332b
Compare
… API
Adds a `remote` subgroup under `pup skills` that wraps the public
agentic onboarding API, so an AI assistant can discover hosted skills,
fetch their instructions, and record sessions by running `pup` instead
of raw HTTP calls. Distinct from the other `skills` subcommands, which
install the statically bundled skills onto a local assistant.
Commands (all hit /api/v2/onboarding/*):
- `pup skills remote list [--tag …] [--org-id N]`
GET /api/v2/onboarding/skills. `--tag` filters in memory against each
skill's frontmatter tags (repeatable; AND semantics).
- `pup skills remote get <skill_id> [--intent …] [--session-id …] [--org-id N]`
GET /api/v2/onboarding/skills/{id}?format=md, printed as raw markdown.
`--session-id` maps to the API's `onboarding_run_id` query param.
- `pup skills remote sessions create --session-id … --skill-id … --summary …
--status …` → POST /api/v2/onboarding/sessions (JSON:API).
Details:
- list/get are public (OpenAuth); sessions create requires authentication
and derives the org from the caller (no org_id in the request).
- skill_id is percent-encoded before path interpolation.
- Terminal session statuses (completed/failed/abandoned) require at least
one --skill-id; in_progress may be empty, mirroring the backend.
- Read-only guard: `skills` stays exempt for local installs, but
`skills remote` is not, so `pup --read-only skills remote sessions create`
is correctly blocked (via a new is_read_only_exempt helper).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
f1c332b to
acdb192
Compare
Summary
Adds a
pup skills remotecommand group to thepupCLI that wraps the public routes of Datadog's agentic skills API (agentic-onboarding-api, indd-source).Background — what is this for?
Datadog serves a catalog of agent skills: markdown documents that give an AI coding assistant step-by-step instructions for setting something up (e.g. wiring up the AWS integration). The backend also records sessions — a log of which skills an assistant used during a run and how it turned out.
Today an assistant has to make raw HTTP calls (with the JSON:API envelope, auth headers, etc.) to reach those routes. This PR gives it ergonomic
pupsubcommands instead, so the assistant can just shell out topup skills remote ….Commands
All hit the existing
/api/v2/onboarding/*routes:pup skills remote list [--tag <tag>…] [--org-id N]GET /api/v2/onboarding/skillspup skills remote get <skill_id> [--intent explore|install|reference] [--session-id …] [--org-id N]GET /api/v2/onboarding/skills/{skill_id}?format=mdpup skills remote sessions create --session-id … --skill-id … --summary … --status …POST /api/v2/onboarding/sessionslistreturns the available skills (id, name, description, cloud provider, required tools, example prompts…).--tagfilters the results client-side; repeat it to require multiple tags.getreturns a single skill's instructions. It always requests the markdown representation (format=md) — the raw skill file (YAML frontmatter + body), which is exactly what an assistant consumes to follow the skill — and prints it to stdout. The representation isn't exposed as a flag because there's no reason for the caller to want the JSON:API envelope instead.--session-idcorrelates the fetch with a recorded session; it is sent as the API'sonboarding_run_idquery param (only the CLI flag is renamed).sessions createrecords the outcome of a run.--statusis one ofin_progress | completed | failed | abandoned;--skill-idmay be repeated. A terminal status (completed/failed/abandoned) requires at least one--skill-id;in_progressmay have none. Both rules mirror the server-side validation. There is no--org-idhere — the org is derived from the caller's credentials.Design notes
listandgetroutes areOpenAuth(they work without credentials, e.g. before a customer has authenticated). The client attaches an OAuth bearer or API+App key when present so the request is attributed to the caller's org, but never requires them — unlike the sharedclient::apply_auth, which fails without credentials.sessions createrequires authentication.skill_idis percent-encoded (util_ext::percent_encode) before being interpolated into the/skills/{id}path, so an id containing reserved characters (/,?) can't rewrite the route or start a query string.intent,status, terminal-status-requires-skill) so obvious mistakes fail fast with a clear message instead of a 400 round-trip.Testing
cargo build,cargo clippy --all-targets -- -D warnings,cargo fmt --check— all clean.cargo test(skills_remote suite) — passes, covering: happy paths,org_idquery forwarding,--tagfiltering,format=mdalways sent,--session-id→onboarding_run_idmapping, percent-encoding of reserved-character skill ids, and negative cases (invalidintent, invalidstatus, 404 surfacing, terminal-status skill-id requirement,in_progressempty-skill-ids allowance).--helpon each subcommand.🤖 Generated with Claude Code