revise-3dad3c — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited revise-3dad3c (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Use this skill to revise an existing p11 document from reviewer comments and share a new version.
Resolve the p11 document target in this order:
.tsx file provided by the user.p11 history and use the most recent relevant entry.Do not use p11 history when the current chat already contains a usable p11 target.
To publish a new version, locate both:
.tsx document fileIf either cannot be determined from the chat, local files, or p11 history, ask the user for the missing target.
Prefer the global p11 CLI. If missing, install @p11-core/cli globally. Use npx -y @p11-core/cli@latest only when global install is not possible. Never install p11 into the project.
Check availability with command -v p11 and p11 --help.
Install or upgrade with npm install -g @p11-core/cli@latest when the command is missing or any p11 command prints an update warning.
Fetch all comments/replies before editing:
p11 comments <target>Use --json when structured fields are useful. Use --version <number> only when the user asks to revise from a historical version.
Only consider comments/replies that are visible to reviewers. Ignore resolved or hidden comments; reviewers will not see replies to them in the UI.
Classify every visible thread by its content, not by an unresolved status field alone:
If any visible threads need clarification, ask the user before editing or publishing whether to:
p11:reply first to ask clarifying questions on those threads, orIf the user chooses p11:reply, post clarifying replies and do not publish a revision until reviewers answer or the user asks to proceed anyway. If the user chooses to ignore those threads, apply only clear decisions.
If all threads are clear, apply clear decisions directly to the source .tsx document.
Do not silently ignore visible threads that need clarification.
Keep the document static and reviewable. Do not add controls, forms, navigation, tabs, cards, alerts, badges, or app-shell UI.
Read references/components.md when editing component structure. Prefer CLI-bundled docs for current examples:
p11 docs
p11 docs components
p11 example all-componentsBefore sharing, verify the document still:
@p11-core/components with named imports onlybutton, input, select, textarea, form, and navPublish the revision to the existing p11 document:
p11 share <page.tsx> --edit-url <editUrl>Return the updated Read URL and Edit URL when available. Treat edit URLs as bearer credentials and avoid exposing them unnecessarily.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.