CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

30.8 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 · 1 flagged

Securityscore 88 · 1 finding

MEDIUMInstruction telling the agent not to ask for approvalSS-SKILL-INJECT-DONT-ASK-01 · Prompt injection · CHANGELOG.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

excerptCHANGELOG.md· markdown

1214denied. Detects the stack (including `scripts/` and Makefile runners that a

1215bare `Bash(pytest *)` rule misses) and the app's run command, allows shell

1216builtins so compound `cd x && <cmd>` lines don't prompt, and documents an

1217honest boundary: curated mode trusts the agent to run repo code, and per-tool

1218denies don't stop Bash reads of secret files. Broad mode is opt-in.

Occurrences

1 occurrence · at L1216

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-01sha256627f92ff2a5134a6…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.

skills/klaussy-update/SKILL.md · 1 file

skills/klaussy-update/SKILL.md3.7 KB · Markdown

name: klaussy-update

description: Use when the user wants to refresh klaussy-generated boilerplate (per-agent conventions, skills, settings, hooks) across every scaffolded agent after upgrading klaussy itself. Re-runs the scaffold against the latest templates so this repo picks up new skills, prompt revisions, and convention rules.

argument-hint: "[--skip-enrich]"

allowed-tools: Read Bash(pipx *) Bash(klaussy *) Bash(pip *) Bash(git *)

license: FSL-1.1-MIT

Klaussy update

Refresh this repository's klaussy-generated boilerplate to match the latest klaussy version, for every agent klaussy previously scaffolded.

Steps

Upgrade klaussy first. Run pipx upgrade klaussy-agents (or pip install --user --upgrade klaussy-agents if klaussy wasn't installed via pipx) — the PyPI distribution is klaussy-agents, not klaussy. Verify the new version with klaussy --version. Note the version for the report at the end.

Read the existing version marker. cat .claude/skills/.klaussy-version captures the version that last generated the skills. If the new klaussy version is the same as the marker, klaussy will skip — surface that to the user and confirm they want to proceed anyway (rare; usually only useful if you've also bumped klaussy-repo-conventions and want to re-run the path-scoped CLAUDE.md emission).

Detect the base branch the same way klaussy-init does (git branch --list dev develop main master | head -1).

Run `klaussy init --force`. The --force flag overrides the version-skip check and rewrites all generated files with the new templates:

   klaussy init --force --base-branch <detected> $ARGUMENTS

Diff the result. Run git diff over the generated files for every scaffolded agent — Claude (CLAUDE.md, .claude/) plus any of GEMINI.md/.gemini/, AGENTS.md (Codex/Antigravity), .cursor/, .github/copilot-instructions.md/.github/skills/, .clinerules/, .opencode/, .kimi-code/, CONVENTIONS.md (Aider) that exist — and summarize the substantive changes for the user:

New skills added or removed
Prompt body changes in <repo>-plan / <repo>-review / etc.
New / changed rule files (e.g. under .claude/rules/)
Settings or hook changes

This is the user's chance to review before committing the refresh.

If klaussy init printed "This clone uses --local", the generated files are in .git/info/exclude and git diff won't show them. Summarize from klaussy's own output instead, and skip the reminder to commit: in a local clone there's nothing to commit.

Report. Tell the user the old marker version → new version and what materially changed in the generated content. Remind them to commit, unless klaussy init printed "This clone uses --local".

When NOT to use

The user wants klaussy's files gone rather than refreshed — that's the

klaussy-uninstall skill. Re-running init --force rewrites them, it never removes them.

The repo isn't klaussified yet — use the klaussy-init skill instead (running klaussy init --force on a clean repo works but the skill auto-detect is cleaner).
The user only wants to update one specific surface (just skills, just hooks, just settings) — they can run klaussy skills, klaussy hooks, or klaussy settings directly without init --force.
The user pinned an older klaussy version intentionally and doesn't want to upgrade — skip step 1 and re-run klaussy init --force against the existing version, but flag that this is unusual.

klaussy-update— agent skill

Is klaussy-update safe to install?

Klaussy update

Steps

When NOT to use

Audit the pieces. Scan the whole. Decide.