recon-e9b77a — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited recon-e9b77a (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.
A decision brief — one opinionated document (~200 lines max) that reads like a 30-minute briefing from a senior consultant who's built 10 of these. Not a research report. Not a comprehensive survey. A ranked list of what actually matters for this project at this scope, with traps and edges treated as equal halves of the work.
The consultant's job has two sides:
Recon does both, balanced. Pure worry is useless. Pure optimism is useless. Calibrated judgment is the product.
| Mode | Trigger | Output |
|---|---|---|
| Full | /recon or /recon [project description] | Single decision brief + sources appendix |
| Focused | /recon [specific question] | Mini decision brief on that question |
Distinguish by intent: "building a task management app" = full. "auth patterns for multi-tenant SaaS" = focused.
Determine what to research from the argument, conversation context, open files, and project state.
Scope calibration — mandatory. Before any research, lock these down. This is what keeps recon from applying enterprise worries to prototypes (and enterprise aspirations to weekend hacks).
If any of these are unclear from context, ask ONE question to lock them:
"I see you're building [X]. Is this a prototype to validate the idea, a production system with real users, or something bigger? And what's the timeline?"
Every finding downstream gets filtered against this scope. A "performance cliff at 10M rows" is not relevant to a 50-user internal tool — and recon won't mention it. A "category-defining distribution play" is not relevant to a personal weekend project — recon won't mention that either.
Calibrate depth. If the user signals domain expertise ("I've built 3 of these"), focus on what's changed recently and what's non-obvious. Skip basics. If the user is entering unfamiliar territory, cover fundamentals too.
Before any research, identify two lenses. Both are required. Neither dominates.
Domain lens: [specific expert who's built 10 of these — "someone who's built Asana, Linear, and Todoist" or "someone who's shipped 3 real-time collaborative editors"]. Knows the category deeply: what's table stakes, what's actually hard, what most teams get wrong.
>
Strategist lens: [someone who ships category-defining products — "a principal who's taken products from me-too to category leader in this space"]. Knows where the edge is: what's fashionable vs what actually works, what assumptions are ripe to break, what capabilities just became cheap that nobody's using yet.
The lenses are not decorative. They change what you search for.
Both lenses research in parallel, equal effort.
Generate two question banks before hitting any search tool. Equal weight.
From the domain lens. What breaks, what's irreversible, what's non-obvious about failure modes at this project's scope (Phase 0 filters aggressively — don't generate trap questions that only apply at enterprise scale for a prototype project).
Load references/expert-questions.md and adapt the relevant project type's trap templates. Add project-specific trap questions that aren't in the templates.
From the strategist lens. Where the outlier move is for this specific project.
Load the Strategist questions (all project types) block at the top of references/expert-questions.md. Those apply universally. Add project-specific edge questions on top.
Examples of good edge questions:
Print both question banks to the conversation before researching. Then pause — don't start searching yet. The questions frame the investigation, and the user may redirect ("skip the pricing stuff, focus on auth") or add context ("we're using Postgres, not Mongo"). If the user says "go" or stays quiet, proceed to Phase 3.
Use multiple sources. Every finding must be traceable to a source.
Full mode: Launch parallel research agents — one thread for traps, one thread for edges, equal effort. This is the core balance. Neither bank is "priority."
Focused mode: Single sequential thread. Each query builds on the last.
Don't accept mediocre results. If a search returns listicles or shallow advice, reframe:
For traps:
For edges:
Prefer primary sources over secondary:
If after 2-3 searches on a topic you're only finding category 7 sources, flag it — either the domain is too niche for web research, or the query framing needs rethinking.
Load references/research-categories.md. Select categories relevant to the project's scope (set in Phase 0).
Priority by scope, not hardcoded:
[Hypothesis] — do not present it as discovered fact. This closes the "made-up worry" and "manufactured edge" failure modes.Output is ONE file: _docs/recon.md — the decision brief.
Plus _docs/sources/[topic].md — raw research threads with links (traceability only, not meant to be read end-to-end).
No pitfalls.md, architecture-notes.md, best-practices.md, feature-expectations.md, security-notes.md. Those were research-report scaffolding. The brief is the product.
# Recon: [Project]
> [YYYY-MM-DD] | Scope: [Prototype/Production/Enterprise] | Timeline: [X] | Stakes: [Reversible/Load-bearing/Foundational]
> Lenses: [Domain expert archetype] + [Strategist archetype]
## What this project is
[1 paragraph — what it does, what success looks like, what's in scope and what's out. Grounds every finding below against this target.]
## What matters (ranked)
### 1. [Decision] — [Trap / Edge / Both] — Irreversibility: [High/Medium/Low]
[2-3 sentences. Opinionated. What the decision is, what most people get wrong or miss, what the recommendation is. If Edge, why it's under-pressed. If Trap, why it bites.]
### 2. [Decision] — [Trap / Edge / Both] — Irreversibility: [High/Medium/Low]
[...]
(Include as many as genuinely matter for this project. Could be 2. Could be 8. No forced count. Rank by cost-of-being-wrong for traps and upside-of-getting-right for edges. Mix traps and edges freely in a single ranked list — a consultant doesn't split their advice into two separate reports.)
## What doesn't matter for this project
[Explicitly dismiss off-scope worries AND off-scope aspirations. Examples: "Don't waste cycles on multi-region deploy — you have 50 users." "Skip real-time collab — this is a solo tool." "Ignore category-defining distribution plays — this is an internal tool, not a product." This section is what makes the brief usable instead of overwhelming.]
## Biggest unknown
[The area where research was thinnest — what you'd want to investigate further before committing. Honest gap acknowledgment. If everything genuinely checked out, say so.]
## Sources
[Appendix. Links to `_docs/sources/` files and external URLs. Every claim in the brief above should be traceable here.]Single file: _docs/recon-[topic-slug].md. Same structure, but the ranking is narrower. Still includes "What matters" ranked list, "What doesn't matter for this question," and sources.
After writing the brief, check if _docs/ is in .gitignore. If not and this is a repo (especially public), note:
_docs/contains internal research — add it to.gitignoreif this is a public repo.
Print _docs/recon.md to the conversation. Then:
Anything here surprise you, or an area you want me to dig deeper on? A trap or edge you think I'm wrong about?
If the user wants to dig deeper on a point, research that specific area further and update the brief. If the user is satisfied, recon is done — the brief persists as reference for the build.
Two lenses, equal weight — non-negotiable. Domain lens without strategist lens produces anxious research. Strategist lens without domain lens produces aspirational nonsense. Both balanced, produce judgment.
Scope calibration up front — non-negotiable. Without it, recon applies enterprise worries to prototypes and enterprise aspirations to weekend hacks. This is the single biggest source of "this isn't actually relevant to me" noise.
Opinionated > comprehensive. Rank. Dismiss. Choose. A consultant who hands you 47 unranked considerations isn't doing their job. Neither is recon.
Honest about gaps. If research turns up little, say so. Niche domains have less prior art — that's fine. Padding with generic advice is worse than admitting thinness.
Inference is hypothesis. Every claim needs a source or a [Hypothesis] label. No made-up worries, no invented edges. This closes the hallucination hole.
The brief IS the product. One file, ranked, opinionated. No multi-file research-report structure. Sources are appendix for traceability — not meant to be read end-to-end.
Don't duplicate other skills. Landscape decision intelligence, not knowledge extraction from a specific URL (/eat), not project architecture (/architect), not testing strategy (/fortify), not engineering standard enforcement (/prodev).
Time-sensitivity awareness. Include research date in the brief header. Flag findings that may have short shelf life. Both traps ("this was a problem in Next.js 12 but fixed in 14") and edges ("this was a differentiator in 2023 but now table stakes") decay.
Respect the user's time. The brief is ~200 lines max. If it's longer, something went wrong — consolidate or cut. The user reads the brief and decides. Don't expect them to wade through sources.
Contextual triggering. When contextual triggers fire (user starting a new project, entering unfamiliar domain), don't silently launch into research. Suggest it in one line:
"This looks like new territory — want me to run /recon on [X] before you start building?"
Let the user accept or decline. Never auto-run the full skill uninvited.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.