← All projects

18trees-website-analysis

A cross-tool AI skill that retrieves a site's publicly observable non-functional implementation, analyzes it across eight dimensions, and archives it as a reusable template.

On this page[4]

What it is

18trees-website-analysis is a cross-tool AI skill codebase: it takes a small website apart to show how it was built, then archives that as a template someone else can reuse directly.

It solves a concrete problem. You find a small site that is really well made and want to know where it is deployed, what it cost, what it is built with, and how its privacy policy was written. The usual move is to ask an AI, which hands back a plausible guess nobody has verified. This skill turns that into a process: retrieve the publicly observable evidence item by item, analyze it across eight dimensions, and store the source files byte-for-byte.

“Non-functional” is a deliberate boundary: features, content, and business logic are explicitly excluded. It answers how a site is built, never what it does. It is meant for Claude Code, Codex, and any AI tool that can fetch web pages and read/write files.

How it is structured

18trees-website-analysis Architecture A architecture diagram generated by Archify. Rule source Packaging & delivery Archive output SKILL.md · principles · workflow · Rule source SKILL.md principles · workflow References · 3 rule files · Rule source References 3 rule files build-dist.sh · one file from rules · Packaging & delivery build-dist.sh one file from rules Plugin Manifests · Claude Code · Codex · Packaging & delivery Plugin Manifests Claude Code · Codex Single-File Guide · no external refs · Architecture component Single-File Guide no external refs AI Tool · fetch · write files · Architecture component AI Tool fetch · write files Archive Index · README.md · Archive output Archive Index README.md Analysis Report · fixed section order · Archive output Analysis Report fixed section order Source Snapshot · kept byte-for-byte · Archive output Source Snapshot kept byte-for-byte rules refs generates installs paste writes indexes

The repository has three layers, and the rules are written once — the other two layers are derived from them.

Rule layer. The rules live in exactly one place, skills/website-analysis/. SKILL.md holds the core principles, the phased workflow, the eight dimensions, and the edge cases. The three files under references/ each cover one part: recon-checklist.md holds the paths to probe, the response-header fingerprints, and the platform detection table; report-template.md holds the report skeleton and the depth calibration; case-notes.md holds two worked examples and a contrast table. agents/openai.yaml is Codex UI metadata.

Packaging and delivery. scripts/build-dist.sh concatenates SKILL.md and the three references into dist/website-analysis.md, a single-file version with zero external references that can be handed over whole as instructions to an AI tool which can execute commands but does not support the skill mechanism. The same rules also ship as a set of plugin manifests (.claude-plugin/ and .codex-plugin/) that install the skill into Claude Code and Codex.

Archive output. Whichever path it was installed by, a run produces the same archive directory: README.md as the index, 分析报告.md for the eight dimensions, and source/ holding the retrieved source files byte-for-byte.

Design decisions worth noting

One source for the rules, no hand-maintained generated file. skills/ is the single source of truth and dist/ is produced by the script; after a rule changes you re-run the script, and two runs should produce no difference at all. The split version and the single-file version can never drift apart.

A fixed report section order, so archives can be compared side by side. report-template.md pins the order — overview, deployment, structure, tech stack, SEO, domain, legal, distribution, cost, comparison, reusable takeaways, plus the source-file index appendix — and new sections may only be appended at the end. Archives of different sites can therefore be diffed and lined up.

Evidence before conclusions. Every conclusion has to trace back to a fetched file or response header, and anything inferred must be labelled as speculation. A platform detection table — default domain patterns, characteristic response headers, error-page shapes — makes the hosting platform identifiable even when the source is closed.

It says up front what it cannot be used for. The README states plainly that web-based chatbots cannot run this skill: a model without tool access can only fabricate a report from impressions, which defeats the reason the skill exists. The test is whether a skill needs to execute commands or reach the filesystem — the same organization’s writing skill is a pure text transformation and can be pasted in, this one cannot.

Contributors add evidence, not impressions. CONTRIBUTING.md requires a new platform fingerprint to come with an actually observed default domain, response header, and error-page shape; a PR that only says a platform “is distinctive” will not be merged, and only incremental improvement is accepted.

What problems it solves

  • Working out how a small site is built no longer means trying things one by one: the probe paths, header fingerprints, and platform table turn it into a checklist.
  • Conclusions stop depending on a model’s impressions — each one traces to a fetched file or response header, and inferred parts are labelled.
  • The deliverable is not only conclusions but the source files in source/, preserved byte-for-byte: those are exactly what you edit when adapting the site.
  • The archive is written for a stranger with zero context, with a fixed section order and no context-dependent references, so another agent can pick it up cold.
  • Large files are downloaded rather than written through a tool, HTML legal pages are converted to markdown, and binary assets are only recorded — so archiving never loses content to a truncated write.
0