[codex] Move maintainer task skills under .agents (#7658)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The skills layout separates runtime Paperclip skills in `skills/` from maintainer/agent workflow skills in `.agents/skills/`. > - Three maintainer workflow skills still lived under root `skills/`, making them look like runtime skills shipped through the Paperclip skill path. > - Root `skills/` is documented as reserved for Paperclip runtime skills, so these task-oriented maintainer skills belong with the other `.agents/skills` entries. > - This pull request moves the three requested skill packages, updates the direct smoke path, and adds regression coverage for the maintainer-only skill boundary. > - The benefit is a cleaner skills boundary without changing skill contents or runtime behavior. ## Linked Issues or Issue Description Internal Paperclip issue: PAP-10471. No public GitHub issue exists for this repository-maintenance change. Inline feature/enhancement issue description follows the feature request template fields: ### Problem or motivation Root `skills/` is documented as reserved for Paperclip runtime skills, but `terminal-bench-loop`, `paperclip-create-plugin`, and `diagnose-why-work-stopped` lived there even though they are maintainer/agent workflow skills. ### Proposed solution Move those three skill packages to `.agents/skills/`, update the terminal-bench loop smoke script to read the new local path, and cover the moved skill names in the existing runtime-skill discovery test fixture. ### Alternatives considered Leaving the skills in root `skills/` would preserve direct old paths, but it keeps blurring the runtime-skill boundary. Moving them into the app-shipped skills catalog would be the wrong fit because these are maintainer workflow skills, not bundled company skills. ### Roadmap alignment This is a small maintenance cleanup around the existing Skills Manager/workflow-skill organization and does not introduce a roadmap-level core feature. ## What Changed - Moved `terminal-bench-loop`, `paperclip-create-plugin`, and `diagnose-why-work-stopped` into `.agents/skills/`. - Updated the terminal-bench loop smoke script and skill self-check text to use `.agents/skills/terminal-bench-loop/SKILL.md`. - Added regression coverage in `server/src/__tests__/paperclip-skill-utils.test.ts` that places these three skills under `.agents/skills` while asserting runtime discovery still lists only root runtime skills. ## Verification - `pnpm smoke:terminal-bench-loop-skill --source-issue-id "$PAPERCLIP_TASK_ID" --run-key PAP-10471-move-skill-path` - `pnpm exec vitest run server/src/__tests__/paperclip-skill-utils.test.ts` - `rg -n "skills/(terminal-bench-loop|paperclip-create-plugin|diagnose-why-work-stopped)" . --glob '!node_modules' --glob '!dist' --glob '!ui/dist'` returned no matches. ## Risks - Low risk: this is a file-location change plus direct path/test updates. - Maintainer agents that referenced the old root paths directly will need to use `.agents/skills/...` instead. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, GPT-5 coding agent with shell/tool use. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] If this change affects the UI, I have included before/after screenshots - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge
This commit is contained in:
Dotta
@@ -0,0 +1,154 @@
|
||||
---
|
||||
name: paperclip-create-plugin
|
||||
description: >
|
||||
Create and develop external Paperclip plugins with the CLI-first workflow.
|
||||
Use when scaffolding a new plugin, working on a local plugin against a running
|
||||
Paperclip instance, or updating plugin authoring docs. Covers `paperclipai
|
||||
plugin init`, the local install loop via `paperclipai plugin install <path>`,
|
||||
worker/UI rebuild and reload semantics, and the required success checklist.
|
||||
---
|
||||
|
||||
# Create and develop a Paperclip plugin
|
||||
|
||||
Use this skill when the task is to create, scaffold, or iterate on a Paperclip plugin against a local Paperclip instance.
|
||||
|
||||
## 1. Default: build the plugin OUTSIDE Paperclip core
|
||||
|
||||
Plugins are their own packages. Unless the task **explicitly** asks for a bundled in-repo example, do not add plugin source under `packages/plugins/` in this repo.
|
||||
|
||||
- Scaffold the plugin into a directory outside the Paperclip checkout (e.g. `~/dev/paperclip-plugins/<name>`).
|
||||
- Install it into the running Paperclip instance by local absolute path.
|
||||
- Edit code in the external package; let Paperclip pick up rebuilt output.
|
||||
|
||||
Only edit Paperclip core itself when the user asks to surface a plugin as a bundled example (`server/src/routes/plugins.ts`, in-repo example lists, docs).
|
||||
|
||||
## 2. Ground rules
|
||||
|
||||
Reference docs when you need detail:
|
||||
|
||||
1. `doc/plugins/PLUGIN_AUTHORING_GUIDE.md`
|
||||
2. `packages/plugins/sdk/README.md`
|
||||
3. `doc/plugins/PLUGIN_SPEC.md` — future-looking context only
|
||||
|
||||
Current runtime assumptions:
|
||||
|
||||
- plugin workers are trusted code
|
||||
- plugin UI is trusted same-origin host code
|
||||
- worker APIs are capability-gated
|
||||
- plugin UI is not sandboxed by manifest capabilities
|
||||
- no host-provided shared plugin UI component kit yet
|
||||
- `ctx.assets` is not supported in the current runtime
|
||||
|
||||
## 3. CLI-first scaffold workflow
|
||||
|
||||
Use `paperclipai plugin init`. Do not invoke the scaffold package node entrypoint by hand unless the CLI command is unavailable in the environment.
|
||||
|
||||
```bash
|
||||
paperclipai plugin init @acme/my-plugin --output ~/dev/paperclip-plugins
|
||||
```
|
||||
|
||||
Useful flags (all optional):
|
||||
|
||||
- `--output <dir>` — parent directory; the command creates `<dir>/<unscoped-name>/`. Defaults to the current directory.
|
||||
- `--template <default|connector|workspace|environment>` — starter template.
|
||||
- `--category <connector|workspace|automation|ui|environment>` — manifest category.
|
||||
- `--display-name <name>`, `--description <text>`, `--author <name>` — manifest metadata.
|
||||
- `--sdk-path <path>` — snapshot the local SDK from a Paperclip checkout into `.paperclip-sdk/` (useful when developing against an unreleased SDK).
|
||||
|
||||
On success the command prints the exact next commands (`cd`, `pnpm install`, `pnpm dev`, `paperclipai plugin install <abs-path>`). Run them in order.
|
||||
|
||||
If `paperclipai` is not on PATH in your environment, fall back to:
|
||||
|
||||
```bash
|
||||
pnpm --filter @paperclipai/create-paperclip-plugin build
|
||||
node packages/plugins/create-paperclip-plugin/dist/index.js @acme/my-plugin \
|
||||
--output /absolute/path \
|
||||
--sdk-path /absolute/path/to/paperclip/packages/plugins/sdk
|
||||
```
|
||||
|
||||
## 4. Local install + rebuild loop
|
||||
|
||||
In the scaffolded plugin folder:
|
||||
|
||||
```bash
|
||||
pnpm install
|
||||
pnpm dev # esbuild --watch: rebuilds dist/manifest.js, dist/worker.js, dist/ui/
|
||||
paperclipai plugin install /absolute/path/to/my-plugin
|
||||
```
|
||||
|
||||
Notes:
|
||||
|
||||
- `paperclipai plugin install` auto-detects local paths (absolute, `./`, `../`, `~`, or an existing relative folder) and forwards `isLocalPath: true` to the server. Pass `--local` to force local mode if the heuristic is ambiguous.
|
||||
- Paths are resolved to absolute paths before being sent to the server.
|
||||
- The server watches built outputs (`dist/`) for local-path plugins and restarts the plugin worker on rebuild — you do not need to reinstall after every edit.
|
||||
- UI hot reload via the SDK dev server (`pnpm dev:ui`, port `4177`) is optional and template-dependent; only mention it if the template wires `devUiUrl` and you verified it works end to end.
|
||||
- `--version` only applies to npm package installs. Combining it with a local path is an error.
|
||||
|
||||
After install, inspect with:
|
||||
|
||||
```bash
|
||||
paperclipai plugin list
|
||||
paperclipai plugin inspect <plugin-key>
|
||||
```
|
||||
|
||||
## 5. After scaffolding, sanity-check the package
|
||||
|
||||
Open and confirm:
|
||||
|
||||
- `src/manifest.ts` — declared capabilities and slots
|
||||
- `src/worker.ts` — worker entry
|
||||
- `src/ui/index.tsx` — UI entry (if applicable)
|
||||
- `tests/plugin.spec.ts` — placeholder test
|
||||
- `package.json` — `paperclipPlugin` block points at `dist/manifest.js`, `dist/worker.js`, `dist/ui/`
|
||||
|
||||
Make sure the plugin:
|
||||
|
||||
- declares only supported capabilities
|
||||
- does not use `ctx.assets`
|
||||
- does not import host UI component stubs
|
||||
- keeps UI self-contained
|
||||
- uses `routePath` only on `page` slots
|
||||
|
||||
## 6. Verification (run before declaring success)
|
||||
|
||||
From the plugin folder:
|
||||
|
||||
```bash
|
||||
pnpm typecheck
|
||||
pnpm test
|
||||
pnpm build
|
||||
```
|
||||
|
||||
If the plugin is already running under `pnpm dev`, you can keep the watcher up and run `pnpm typecheck` and `pnpm test` in a separate shell.
|
||||
|
||||
If you changed Paperclip SDK/host/plugin runtime code in addition to the plugin, also run the relevant Paperclip workspace checks.
|
||||
|
||||
## 7. Success checklist (report this back)
|
||||
|
||||
When you finish a local plugin task, report:
|
||||
|
||||
- **Scaffold path** — absolute path of the created plugin folder.
|
||||
- **Commands run** — the exact `paperclipai plugin init`, `pnpm install`, `pnpm dev`, `paperclipai plugin install <path>` invocations (and any verification commands).
|
||||
- **Install status** — output of `paperclipai plugin list` / `plugin inspect` (plugin key, version, status). Note if `status` is anything other than `ready` and include `lastError`.
|
||||
- **Tests / build result** — `pnpm typecheck`, `pnpm test`, `pnpm build` pass/fail with the failing output if any.
|
||||
- **Reload limitations** — call out anything that did not hot-reload (e.g. manifest changes required a reinstall, UI dev server was not wired, etc.).
|
||||
|
||||
If any item is missing, mark it as such — do not silently skip.
|
||||
|
||||
## 8. When NOT to edit Paperclip core
|
||||
|
||||
Do not add the plugin under `packages/plugins/` or update bundled-example wiring unless the user explicitly asks for a bundled example. Local-path installs are the supported development model; npm packages are the production deployment path.
|
||||
|
||||
If the user does ask for a bundled example, also update:
|
||||
|
||||
- `server/src/routes/plugins.ts` example list
|
||||
- any docs that enumerate in-repo example plugins
|
||||
|
||||
## 9. Documentation expectations
|
||||
|
||||
When authoring or updating plugin docs:
|
||||
|
||||
- distinguish current implementation from future spec ideas
|
||||
- be explicit about the trusted-code model
|
||||
- do not promise host UI components or asset APIs
|
||||
- prefer local-path development + npm-package deployment guidance over repo-local workflows
|
||||
Reference in New Issue
Block a user