first-principles-review — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited first-principles-review (Agent Skill) and scored it 45/100 (orange). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 2 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 2 flagged
A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.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 as a lightweight decision review before another Aegis workflow makes a directional choice. It is a compositional skill, not a standalone workflow.
Do not replace brainstorming, systematic-debugging, writing-plans, requesting-code-review, or verification-before-completion. Use it to clean the decision surface those skills will act on.
razor.
criteria.
direction risk.
consumer-side patches, or "just add another branch" reasoning.
wrong.
single-owner changes.
appears.
Answer only what is needed, usually in five short lines:
First Principle: What irreducible outcome must this satisfy?
Non-negotiables: What constraints cannot be broken?
Assumptions to Drop: What is habit, inherited shape, or unproven preference?
Smallest Sufficient Path: What is the least complex path that satisfies the first principle?
Escalation Signal: What finding would require spec/design/architecture review?For repair choices, "smallest" means smallest sufficient stable repair, not the smallest textual diff:
Minimality Check:
- Smallest textual diff:
- Correct owner:
- Bug class fixed:
- New branch/fallback added:
- Old path retired or scheduled:
- Verdict: sufficient repair | local patch | needs first-principles reviewUse this escalation only when a design, fix, or plan needs endorsement before it is written into a spec or implementation plan.
Escalate from the five-line review when any of these risk signals appear:
principles", or "Occam"
retirement schedule
Use this compact shape:
First-principles invariants:
- Non-negotiable goal:
- Non-negotiable constraints:
- Historical assumptions to delete:
Owner / retirement matrix:
- New canonical owner:
- Old owner:
- Compat-only carrier:
- Delete-first / retirement trigger:
Falsification matrix:
- Dependency-removal test:
- Counterexample scenario:
- Must fail / degrade / remain correct cases:
Verdict:
- Adopt / revise / reject / needs evidence:
- Blocking gaps:
- Next evidence:Use this narrower lens when a proposal is executable but may still encode the wrong owner, abstraction, contract boundary, or retirement path. It is advisory method-pack output and may be embedded inside Decision Hygiene Review when that is enough.
Trigger it when any of these appear before approach selection, task decomposition, review, or completion-risk reporting:
carrier
higher level
higher-level simplification claim
Use this compact shape:
Architecture Integrity Lens:
- Invariant: What must remain true for the system to be coherent?
- Canonical owner / contract: Which owner, contract, or source-of-truth should carry the behavior?
- Responsibility overlap: What duplicate owner, caller-side patch, fallback, or stale path might still carry real logic?
- Higher-level simplification: Can the problem be solved at the owner / contract / source-of-truth layer instead of by another local branch?
- Retirement / falsifier: What old path retires, or what evidence would disprove this architecture judgment?
- Verdict: proceed | revise design | split owner | return to baseline | needs ADR/baseline syncDo not run this lens for every low-risk task. If it does not change the decision surface, return to the active workflow immediately.
brainstorming: run before approach selection when the request is broad,ambiguous, likely to inherit a poor product shape, or involves owner / retirement / fallback / adapter risk. Use Decision Hygiene Review or the narrower Architecture Integrity Lens before recommending or selecting an approach when those signals appear.
systematic-debugging: run after evidence shows repeated fixes, fallbackgrowth, duplicate owners, or consumer-side patching.
writing-plans: run before task decomposition when the plan could encodethe wrong owner, abstraction, compatibility boundary, fallback, adapter, or retirement schedule. If the approved spec did not already cover this, use Decision Hygiene Review or the Architecture Integrity Lens before writing tasks.
requesting-code-review: run when review should check direction andowner integrity, not just code quality.
verification-before-completion: use only to name residual directionalrisk. It does not grant completion authority.
user requirements. If evidence is missing, mark the line as unknown rather than inventing a principle.
not create authoritative GateDecision, PolicySnapshot, or completion authority.
active workflow immediately.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.