A5 — Web Audit
Skill2 starsChanged 5 months agoApache-2.0View on GitHub
Research the world. Real web research to find what the best teams do for every technology and pattern in the build, then implement superior approaches now (not later). The only lens that brings outside knowledge.
In this repository22 other files it gives its agents.
- A1 — Design & Master-Spec ConsistencySkill
- A2 — Spec ReviewSkill
- A3 — PolishSkill
- A4 — North Star DirectionSkill
- AcceptSkill
- AmendSkill
- BrainstormSkill
- ClarifySkill
- ClosureSkill
- ConstituteSkill
- DesignSkill
- DiscoverSkill
- FeatureSkill
- Final — The F-PassSkill
- HelpSkill
- ImplementSkill
- InitSkill
- MicroSkill
- North StarSkill
- ResumeSkill
- SpecifySkill
- StatusSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 25
Degrade gracefully: if the web is unavailable, log a skip and do not block the pipeline (run it when connectivity returns).
- Very specific: line 26
Write the report to audits/{scope}-a5.md: research areas searched (and why), per-finding source URL + relevance + category + action taken + …
- Distinctive: line 33
Read the prior A5 report to know what's covered.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
A5 — Web Audit (Research the World)
The outside-knowledge check — the only lens that brings information from beyond the project. A5 performs real web research (live searches, fetching real URLs, citing real sources) to find what the best teams in the world do for every significant technology, pattern, and domain in the implementation, then evaluates the build against world-class practice. Superior approaches it discovers are implemented immediately, not deferred.
Inputs
- The implementation code in scope (to extract research topics) · the micro specs · the constitution (the tech stack)
- Prior A1–A4 reports · the live web (search + fetch) · the project mode
- On a re-run: the prior A5 report and prior
research-learnings.md
Process
- Identify search topics — analyze the code/templates and extract technologies, patterns, problem domains, and specific challenges; each becomes a research thread.
- Search the web per topic, targeting authoritative sources: official docs and engineering blogs, conference talks and papers, RFCs and standards bodies, industry-leading implementations, UX/design-pattern libraries. (Content/process mode researches how professionals in the domain do their work.)
- Evaluate each finding: relevant to what we built (confidence 1–10)? credible source? better than our current approach? implementable now or blocked?
- Categorize: Superior approach → implement NOW · General learning → log it · Confirms our approach → record as validation · Not applicable → discard with a reason.
- Implement superior approaches immediately — fixed on the branch, like A2/A3 fixes. If too large to do now, create a new tracked micro spec — never merely note it.
- Persist general learnings to
research-learnings.md, tagged with technology, domain, and source URL — they carry across features. - Degrade gracefully: if the web is unavailable, log a skip and do not block the pipeline (run it when connectivity returns).
- Write the report to
audits/{scope}-a5.md: research areas searched (and why), per-finding source URL + relevance + category + action taken + confidence, the improvements implemented, the learnings recorded, validations, reasoning traces, and a competitive-position analysis.
A5 findings carry three extra fields: Source (URL), Relevance (why the source matters), Confidence (1–10).
The Re-Run Protocol
An A5 re-run is not a verification pass (verifying fixes landed is what A2/A3 re-runs do). Because A5 is the only lens importing outside knowledge, every run is a fresh research expedition. A re-run (run N > 1) must:
- Read the prior A5 report to know what's covered.
- Research the fixes themselves — run 1's improvements are now part of the codebase; are they world-class? are there better alternatives?
- Go deeper and wider — subtopics, adjacent domains, genuinely new developments (the web moves).
- Compound on prior learnings — use prior notes as search seeds.
- Record new learnings and append new findings; prior findings keep their Fixed status.
A re-run is clean when fresh research across new angles yields zero actionable findings — a judgment call. A clean re-run should still produce learnings even when it files no findings: knowledge always accrues even when nothing needs changing. That is the heart of the protocol.
Shared machinery
Finding format, zero-tolerance loop, and conviction: see docs/the-audit-system.md. A5 runs last in the per-group sequence; after it is clean, run /genesis-accept for the group.
Natural language triggers
- "a5 audit group 1"
- "web audit"
- "research world-class approaches"Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

