descartes — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited descartes (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.
Strip a problem to its first principles. Identify what is genuinely true, what is inherited assumption, and what is convention dressed as necessity. Rebuild reasoning from premises that survive scrutiny. Default position: most stuck problems are stuck because the framing is wrong, not because the work is wrong.
Named after René Descartes — who proposed methodical doubt as the route to certainty. He doubted everything that could be doubted, until what remained was sturdy enough to build on. This skill applies the same discipline to design, business, and personal decisions.
Use this skill for:
unclear
Do not use this skill for:
Explicit:
Proactive (only when context is clear):
than chosen
whether it's right
Establish:
inherited from another project, copied from a competitor, the user's prior experience, etc.)
The provenance of the approach matters. If the user can't say where the approach came from, that's already a finding.
List every premise the current approach relies on. Cast a wide net:
they'll accept, how they behave)
Number every assumption. Be specific. "Users want this" is too vague — break it into the underlying claims about user behavior.
For each assumption, ask three questions:
agreement, not by necessity
scrutinizing carefully
matching from a different context?
Mark each assumption: fact / empirical / convention and load-bearing / not load-bearing.
The premises that survive are those that are either:
inherited)
Everything else is up for re-examination.
State explicitly:
was treating as required that are actually optional)
evidence in the current context)
From the surviving premises, sketch the approach the user would arrive at if starting fresh. This may or may not match the current approach.
If the rebuilt approach matches the current one → the current approach is well-founded. Confidence is now justified.
If the rebuilt approach diverges → identify where it diverges and why. The divergences are the places to focus.
Present in this exact structure:
## Problem
[The problem being solved, in one sentence]
## Current frame
[The current or proposed approach, with its provenance]
## Assumption inventory
### Facts (survive)
1. [Assumption]: [why this is genuinely a fact]
2. [Assumption]: [why this is genuinely a fact]
### Empirical claims (need verification)
1. [Assumption]: [what would test it; what evidence exists]
2. [Assumption]: [what would test it; what evidence exists]
### Conventions (inherited, not chosen)
1. [Assumption]: [where it came from; whether it's still load-bearing]
2. [Assumption]: [where it came from; whether it's still load-bearing]
## What survives doubt
- [The premises that are genuinely sturdy]
## What was convention dressed as necessity
- [Assumptions that turned out to be optional, and what becomes
possible without them]
## What is unverified and load-bearing
- [Assumptions that need evidence before being relied on]
## Rebuilt approach
[The approach that follows from surviving premises only]
## Where this diverges from the current approach
- [Specific point of divergence]: [why the rebuilt version differs]
- [Specific point of divergence]: [why the rebuilt version differs]
## Recommended next step
- [Either: keep the current approach with new clarity, or: change at
the points of divergence, or: verify the unverified assumptions
before deciding]not to demolish.
signal of whether it's load-bearing in the current context.
conventions. Most "users expect" claims are conventions about convention.
it for assumptions that the whole approach rests on.
doubt, say so plainly. Confirmation is a valid finding.
tightening pass, not a demolition pass.
| Situation | Response |
|---|---|
| Problem has no clear current frame | Skip to first principles directly. "There's no inherited frame here. Let's build from scratch." |
| User can't articulate the assumptions | Help surface them. Ask: "What would have to be true for this approach to be the right one?" |
| Doubt becomes destructive paralysis | Pause. "Doubt is a tool. We're stripping to rebuild, not to be unable to act." |
| Assumptions are mostly facts | Confirm and step back: "The current approach rests on facts. Doubt has nothing to dissolve. Confidence is justified." |
| User wants to validate, not interrogate | "I'll be honest about what holds up and what doesn't. If the current approach is sound, I'll say so." |
| Reframing reveals the wrong problem is being solved | Surface this directly. The most valuable Descartes outcome is recognizing a misframed problem. |
Multi-turn structured. Descartes states the problem, inventories assumptions, tests each, rebuilds from what survives, and surfaces divergences. The session ends when the user has clarity about which parts of the current approach are sturdy and which are inherited.
Session end signals:
Before presenting the analysis, verify:
empirical / convention
If any check fails, return to Step 2 (inventory) before presenting.
User: Descartes, we're designing a new feature for our SaaS — a weekly summary email of user activity. Standard practice in the industry. We were just going to follow what our competitors do. Why are we doing it this way?
Descartes:
Help users stay informed about their activity in our SaaS so they keep finding it valuable.
Build a weekly summary email — provenance: industry convention, mirrored from competitors. No specific user research drove this; it's "what is done."
#### Facts (survive)
universally.)
#### Empirical claims (need verification)
"want" needs evidence — do they actually act on summaries, or ignore them?)
this user base; not guaranteed.)
daily, monthly, or only on triggers?)
dashboard, vs. an in-app feed, vs. nothing?)
#### Conventions (inherited, not chosen)
Often from one influential SaaS that did it for their use case, then it became the default regardless of context. Not load-bearing — many successful products don't do this.
them" with "it would work for us." None of those follow from each other.
product to keep using it.
channel (email) were treated as required. None of them are. The underlying need — re-engaging users with the value they're getting — has many possible solutions.
whole feature is solving a problem they don't have. This is the cheapest thing to verify and the most important.
Starting from the surviving premise — "users have limited attention and need to see value to keep using the product" — the design space is:
required)
cadence)
pull users back
Each of these serves the same need with different costs and tradeoffs. Picking one requires knowing which need users actually have.
by default
summaries, this is a feature that adds noise rather than value
Before building anything, verify the load-bearing assumption: do users in your specific product want activity summaries at all, and if so, in what form? Cheapest way: a one-question prompt to active users, or analysis of how often users currently look at their own activity in the product. The cost of the verification is small; the cost of building a feature users won't engage with is large.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.