Files

Sam e44b0dff51 Confirmed by experiment: how a picker can assign skills per agent, and where the boundary is

2026-11-11 08:58:23 +11:00

4.2 KiB

Raw Blame History

type: session id: session.paperclip-harness.paperclip-pi-adapter-per-agent-skills-and-per-agent-extensio title: Paperclip + Pi adapter: per-agent skills and per-agent extensions status: active source_of_truth: false freshness: current last_reviewed: 2026-11-10 tags: - pack/paperclip-harness - agent-memory/session - paperclip - pi-coding-agent - per-agent-skills - per-agent-extensions - pi_local-adapter - task-sessions - session-history

Paperclip + Pi adapter: per-agent skills and per-agent extensions

Discovery turn correcting an earlier wrong claim that Paperclip supports only one skill set for all agents.

Per-agent skills (already implemented in Paperclip):

GET /api/agents/{id}/skills returns a separate desiredSkills list for each agent.
POST /api/agents/{id}/skills/sync with body { "mode": "add" | "remove" | "replace", "desiredSkills": [string | { key, versionId(uuid|null) }] } syncs an agent's skills. replace means exactly that list.
At run time the pi_local adapter builds a skill directory from that agent's list and passes it to Pi as --skill.
Skill sources: GET /api/skills/available, the company list, and the skill catalog. Key format examples seen: company/<id>/nixos-workflow, paperclipai/paperclip/paperclip.
Caveat: skill links persist in a shared directory, so a skill can linger if not replaced.

Per-agent extensions (no Paperclip source change needed):

pi_local adapter config document (agentConfigurationDoc in adapter index.js) states command defaults to pi and env is KEY=VALUE; both are per agent.
PATCH /api/agents/{id} with adapterConfig.command set to a wrapper script gives each agent its own extension list. Example wrapper: #!/bin/sh\nexec pi --extension npm:pi-memctx --extension git:https://.../extensions/tavily-search/index.ts "$@".
The adapter appends its own args (--mode json, --session, --skill, --tools, --model) to the command, so a wrapper is additive/safe.
adapterConfig.env is the same lever for env per agent.
Suggested role wrappers: builder, documenter, reviewer.

Pi runtime facts (pi-coding-agent):

Paperclip runs Pi with --session <file>; sessions live at ~/.pi/paperclips/<timestamp>-<agentId>.jsonl.
GET /api/agents/{id}/task-sessions maps task -> session file and cwd.
Pi bash-tool env vars: PI_CODING_AGENT, PI_SESSION_ID, PI_SESSION_FILE, PI_PROVIDER, PI_MODEL, PI_REASONING_LEVEL. PI_OFFLINE configures Pi. Inspect $PI_PROVIDER/$PI_MODEL instead of inferring from prompt.
pi -c/--continue continues most recent session; pi -r/--resume browses sessions.

History-viewing options, best first:

Tool pane running pi --session <jsonl> on a finished run (risk: two writers on one session file).
Read-only transcript tab in Agents>agents from the same JSONL.
pi --resume in a tool pane and pick by eye.

Repo/files touched: correction written to docs/PLAN-INTERFACE.md; commit 47aacfd. Nothing in the running layout changed. Sandbox install pin: npm install -g @earendil-works/pi-coding-agent@0.74.0 (adapter) while Nix has pi-coding-agent 0.82.1. Follow-ups the user could pick: an Agents>skills tab (list/add/remove via the two API calls) and a t tool-pane entry to open a chosen Pi session.

Evidence

Confidence: 90%
Reason: Rich discovery snapshot with concrete API endpoints, adapter config levers, session paths, and commit reference that a future agent can reuse.

packs/paperclip-harness/00-system/pi-agent/memory-manifest

4.2 KiB Raw Blame History

Paperclip + Pi adapter: per-agent skills and per-agent extensions

Evidence

Related

Related learned memories

4.2 KiB

Raw Blame History