design-api — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited design-api (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.
Built on the "Design It Twice" principle from "A Philosophy of Software Design": your first idea is unlikely to be the best one. Generate several radically different design options, then compare.
Before designing, understand:
Ask: "What should this module do? Who will use it?"
Launch 3+ sub-agents simultaneously via the Task tool. Each must produce a radically different approach.
Prompt template for each sub-agent:
Design an interface for: [module description]
Requirements: [gathered requirements]
Constraints for this design: [assign a different constraint to each agent]
- Agent 1: "Minimize method count - aim for 1-3 methods max"
- Agent 2: "Maximize flexibility - support many use cases"
- Agent 3: "Optimize for the most common case"
- Agent 4: "Take inspiration from [specific paradigm/library]"
Output format:
1. Interface signature (types/methods)
2. Usage example (how caller uses it)
3. What this design hides internally
4. Trade-offs of this approachShow each design with:
Present the designs sequentially so the user can absorb each approach before comparing.
After showing all options, compare them by:
Discuss trade-offs in prose, not tables. Highlight the points where the designs diverge most.
Often the best design combines ideas from several options. Ask:
From "A Philosophy of Software Design":
Interface simplicity: fewer methods, simpler parameters — easier to learn and use correctly.
Generality: capable of handling future scenarios without changes. But beware of over-generalization.
Implementation efficiency: does the interface shape allow an efficient implementation? Or does it force awkward internals?
Depth: a small interface hiding significant complexity = a deep module (good). A large interface with a thin implementation = a shallow module (avoid).
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.