website-standards-auditor

Website Standards Auditor

This skill audits a website against one fixed set of organization standards and then fixes the gaps. It works on a brand new project, a project still in development, or an already live site. It always runs in two phases with a hard approval gate between them: first it produces a written gap report (gap_identification.md), then, only after the user explicitly approves, it repairs the approved items and reconciles .gitignore and README.md.

The standards are fixed and bundled with this skill. Do not invent new rules and do not drop existing ones. The three pillars are:

1. Engineering and content rules (see references/coding_rules.md)
2. Mandatory git policy and the standard .gitignore (see references/git_policy.md and references/gitignore_standard.txt)
3. Website quality criteria covering SEO, GEO, AEO, structured data, performance, and more (see references/website_criteria.md)

Operating principles (these are binding for every run)

These principles come from the organization rules and override convenience at every step.

• Never make assumptions. Detect facts from the repository, the served site, and the user's words. When a fix needs a value that cannot be derived from those sources (for example the canonical domain, the default language and locale, the legal or brand name, social profile URLs, or contact name, address, and phone), do not guess and do not insert a plausible placeholder as if it were real. List the item under "Information required from user" in the gap report and ask for it before writing anything that depends on it.
• Never use the em dash. Do not use the em dash character in anything you write or edit, including this skill's own output files (gap_identification.md, fix_summary.md) and any site content you touch. Use a comma, colon, parentheses, or a reworded sentence instead. The audit also treats every em dash already present in the target site as a defect to be fixed.
• Always keep .gitignore and README.md up to date. Every run ends by reconciling these two files against the current state of the project, even if the user only asked for an SEO check.
• Never change existing UI/UX. When fixing gaps or scaffolding new pages, preserve all existing font stacks, color tokens, spacing, border radii, shadow, and layout. New pages (privacy, 404, offline, or any other page created during a fix run) must inherit the project's existing design system. Read the project's CSS, design tokens, or component library before writing a new page. If no design system is detectable, use the bundled template defaults from assets/ and note in fix_summary.md that the user should update the tokens. This rule applies to every file the skill touches, not only to HTML pages.