AI Skill Report Card

Coding HTML5 Markup

A-87·Sep 3, 2026·Source: Web
14 / 15

Given an instruction (e.g. "create a responsive login form with username, password, remember me") and optional existing HTML files:

  1. Parse the instruction into a change plan (create/insert/replace/remove/update-attr/wrap/extract).
  2. Generate or patch semantic, accessible HTML5.
  3. Validate against W3C HTML5 rules until 0 errors / 0 warnings (or max attempts reached).
  4. Deliver:
    • PASSEDpatched_output.zip (/patched/, /originals/, patch_report.txt, metadata.json, validation_logs/)
    • FAILEDpatch_report.txt + metadata.json + validation_logs/ only, with remediation steps, and last attempt labeled UNVALIDATED — DO NOT USE IN PRODUCTION

Never deliver a ZIP with outstanding validator errors or warnings.

Recommendation
Add an example showing a FAILED validation case with the resulting report-only output and remediation steps, since this is a core branch of the workflow but isn't demonstrated concretely
15 / 15

Progress:

  • Parse instruction → canonical ops + ambiguity level (LOW/MEDIUM/HIGH)
  • Pre-check environment (parse existing DOM, checksum inputs, copy to /originals/)
  • Plan minimal patch (document alternatives if creative solutions allowed)
  • Generate semantic, accessible HTML5
  • Run static sanity checks (balanced tags, unique IDs, required meta/title/lang)
  • Validate with W3C validator; auto-fix and retry up to max_attempts (default 3)
  • Run accessibility/smoke checks
  • Package output and write patch_report.txt
  • Deliver ZIP (PASSED) or report-only (FAILED)

Step details:

  1. Parse Instruction — Map verbs to ops: create, insert, replace, remove, update-attr, wrap, extract. Extract target selectors, scope, accessibility flags. If ambiguity is HIGH, pause and ask for confirmation before proceeding — do not guess on high-risk changes.

  2. Pre-check — Verify <!doctype html>, <head>, <body> exist in any uploaded file. Compute SHA-256 checksums. Preserve originals verbatim.

  3. Plan — Define minimal change set. If allow_creative_solution=true, note alternative approaches and why one was chosen.

  4. Generate — Use semantic elements (header, nav, main, section, article, footer) over generic div/span. Add accessibility defaults: <label for>, aria-*, alt, skip links. Keep CSS/JS external unless told otherwise.

  5. Static checks — Balanced tags, no duplicate IDs, valid attributes, <meta charset>, <title>, lang on <html>.

  6. Validate — Run the HTML5 validator. On failure, auto-fix and retry (log each attempt's diff). After max_attempts, mark FAILED and stop — do not force a passing state.

  7. Package & Report — Build ZIP only if PASSED. Always produce patch_report.txt and metadata.json.

Recommendation
Clarify what 'W3C validator' means in execution context (e.g., is this a real tool call, an API, or simulated) since Claude can't literally run the W3C Nu validator without tooling
job_id, timestamp, instruction (verbatim), preferred_style,
allow_creative_solution, tool_versions

Per file:
  original_path
  before_snippet (3-8 lines)
  after_snippet (3-8 lines)
  changes_summary (bullets)
  accessibility_notes
  validation_summary (attempts, errors, warnings)
  assumptions

Overall:
  status: PASSED | FAILED
  attempts: N
  diff_summary: lines_added, lines_removed
  checksums: original_files, patched_files, final_zip (SHA-256)
  remediation_steps (required if FAILED)
16 / 20

Example 1 — Create login form Input: "create responsive login form with username, password, remember me, accessible labels" Output:

HTML
<form role="form" aria-label="Login" method="post" action="/login"> <label for="username">Username</label> <input id="username" name="username" type="text" autocomplete="username" required> <label for="password">Password</label> <input id="password" name="password" type="password" autocomplete="current-password" required> <label><input type="checkbox" name="remember"> Remember me</label> <button type="submit">Login</button> </form>

Validation: PASSED (0 errors, 0 warnings).

Example 2 — Targeted text change Input: change title to "Dashboard" on a file with <title>My Page</title> Output: <title>Dashboard</title> — only this line changes; rest of file untouched. Validation: PASSED.

Example 3 — Navbar with skip link Input: "add top navbar with Home, About, Contact and skip link" Output:

HTML
<a class="skip-link" href="#main">Skip to content</a> <nav role="navigation" aria-label="Main navigation"> <ul> <li><a href="/home">Home</a></li> <li><a href="/about">About</a></li> <li><a href="/contact">Contact</a></li> </ul> </nav>

Example 4 — Accessibility fix Input: "ensure all images have alt" Before: <img src="hero.jpg"> After: <img src="hero.jpg" alt=""> (decorative) or meaningful alt text if content is known — flag ambiguous cases in the report rather than guessing.

Recommendation
Define default values for parameters like allow_creative_solution and preferred_style referenced in the report template but never explained
  • Prefer semantic tags over div/span; use lists for nav items.
  • Add accessibility features by default (labels, alt, aria-*, skip links) even if not explicitly requested.
  • Keep diffs minimal — change only what the instruction targets; justify any extra change in the report.
  • Treat validator warnings as blocking, same as errors.
  • Keep CSS/JS external by default; inline only on explicit request or for tiny demo snippets.
  • Always preserve originals byte-for-byte in /originals/.
  • Log tool versions and exact validator commands for reproducibility.
  • Don't deliver a ZIP when the validator reports any error or warning — report-only output with remediation steps instead.
  • Don't silently modify untargeted content — every change outside the explicit request must be documented and justified.
  • Don't inject external resources (CDNs, analytics, third-party scripts) without explicit user consent.
  • Don't guess on HIGH-ambiguity instructions — pause and confirm instead of proceeding with assumptions.
  • Don't skip accessibility basics (missing labels, missing alt, missing lang/meta charset) even for "quick" requests.
  • Don't exceed max_attempts silently — stop and report FAILED with clear next steps.
0
Grade A-AI Skill Framework
Scorecard
Criteria Breakdown
Quick Start
14/15
Workflow
15/15
Examples
16/20
Completeness
18/20
Format
14/15
Conciseness
14/15