Skill This
AI Skill Report Card

HTML5 Coding Assistant

A-85·Sep 3, 2026·Source: Web
Markdown
---
name: html5-coding-assistant
description: Creates, modifies, and validates HTML5 markup from natural-language instructions, producing W3C-valid output, structured patch reports, and validation logs. Use when a user needs HTML files created or edited (forms, navbars, titles, elements removed/added) with strict validation guarantees, accessibility improvements, and auditable before/after documentation. Delivers a ZIP only when validation passes with 0 errors and 0 warnings.
---

# HTML5 Coding Assistant
Quick Start14 / 15

Given an instruction like:

"Add a login form with email and password fields to index.html"

  1. Parse instruction → operation: insert, target: <body> of index.html, content: login form.
  2. Generate semantic, accessible markup:
HTML
<form action="/login" method="post" aria-labelledby="login-heading">
  <h2 id="login-heading">Log In</h2>
  <div>
    <label for="email">Email</label>
    <input type="email" id="email" name="email" required autocomplete="email">
  </div>
  <div>
    <label for="password">Password</label>
    <input type="password" id="password" name="password" required autocomplete="current-password">
  </div>
  <button type="submit">Log In</button>
</form>
  1. Insert into target file, preserving everything else untouched.
  2. Validate with HTML5 validator; iterate up to max_attempts on failures.
  3. Package outputs; deliver ZIP only if PASSED.
Recommendation▾
Trim the report template slightly or move to a reference file to reduce line count
Workflow15 / 15

Progress:

  • Step 1: Parse instruction into operation(s), target(s), options
  • Step 2: Pre-check existing HTML (doctype, structure, parse errors)
  • Step 3: Plan minimal patch; propose creative solution if ambiguous and allow_creative_solution=true
  • Step 4: Generate semantic HTML5 markup per preferred_style (minimal/verbose), with accessibility defaults
  • Step 5: Run sanity checks (balanced tags, valid attributes, resource paths)
  • Step 6: Validate with HTML5 validator; auto-fix loop up to max_attempts, logging each attempt
  • Step 7: Build package: /patched/, /originals/, patch_report.txt, metadata.json, validation_logs/
  • Step 8: Deliver ZIP only if status is PASSED; otherwise deliver report + logs + remediation steps

Step Details

1. Parse instruction Map verbs to operations:

  • "add", "insert", "create" → insert
  • "change", "update", "replace" → replace / update-attr
  • "remove", "delete" → remove

Identify: target file(s), target element(s)/selector, and any options (style, position). If instruction is ambiguous and allow_creative_solution=true, choose the most conventional semantic solution and document the assumption in the report. If allow_creative_solution=false and instruction is ambiguous, flag it and request the minimal safe interpretation, documenting the choice.

2. Pre-check

  • If html_files provided: parse each, confirm <!DOCTYPE html>, verify <html>, <head>, <body> present. Record parse errors.
  • If no files provided and instruction implies creation: start from a valid HTML5 skeleton.

3. Plan patch Compute the minimal change set that satisfies the instruction. Never touch unrelated elements. If a change requires touching adjacent structure (e.g., closing a mismatched tag) to remain valid, document why under assumptions.

4. Generate markup

  • minimal style: no extra wrapper divs, compact attributes.
  • verbose style: explicit id/class naming, comments marking inserted blocks (<!-- BEGIN: navbar (added) --> ... <!-- END: navbar -->).
  • Always apply accessibility defaults: alt on <img>, <label for> on inputs, aria-* where semantics aren't native, landmark elements (<nav>, <main>, <header>, <footer>) for structural additions.
  • Keep CSS/JS external via <link>/<script src> unless user explicitly requests inline.

5. Sanity checks

  • Tag balance and nesting validity.
  • Attribute validity (no invented attributes; use data-* for custom hooks).
  • Verify referenced resource paths exist among provided files, or flag as external/unverified in report.

6. Validate

  • Run HTML5 validator (e.g., vnu.jar / Nu Html Checker) against each patched file.
  • Log exact command and tool version, e.g.: 
    java -jar vnu.jar --format text patched/index.html
Tool: Nu Html Checker (vnu) 20.6.30
  • If errors/warnings found: attempt automatic remediation (fix tag nesting, add missing attributes, correct doctype, etc.), re-validate. Repeat until PASSED or max_attempts reached.
  • Each attempt logged separately in validation_logs/attempt_N.log.

7. Package

patched_output.zip
├── patched/                # modified files, full content
├── originals/               # untouched copies of all input files
├── patch_report.txt
├── metadata.json
└── validation_logs/
    ├── attempt_1.log
    ├── attempt_2.log
    └── final.log

8. Deliver

  • Status PASSED (0 errors, 0 warnings on final attempt): deliver full ZIP.
  • Status FAILED (after max_attempts): deliver patch_report.txt, metadata.json, validation_logs/ only — no ZIP. Include clear remediation steps for the remaining issues.
Recommendation▾
Add an edge case for malformed/missing input files beyond 'no files provided' scenario
Report Template (`patch_report.txt`)
JOB ID: <uuid>
TIMESTAMP: <iso8601>
INSTRUCTION: "<original user instruction>"
TOOL VERSIONS: vnu.jar 20.6.30, html5-coding-assistant v1.0

--- FILE: index.html ---
BEFORE:
<snippet>

AFTER:
<snippet>

CHANGES SUMMARY: Inserted login form after <header>, before <main> content.
ACCESSIBILITY NOTES: Added <label for> on both inputs; form has aria-labelledby.
ASSUMPTIONS: Interpreted "login form" as email+password (no username field) per common convention.
VALIDATION SUMMARY: 0 errors, 0 warnings (attempt 1/3)

--- OVERALL STATUS: PASSED ---
DIFF SUMMARY: 1 file modified, 1 file untouched (style.css)
CHECKSUMS:
  originals/index.html: sha256:...
  patched/index.html:   sha256:...
REMEDIATION STEPS: (none — PASSED)
Examples18 / 20

Example 1: Add login form Input: instruction="Add a login form with email and password to index.html" Before:

HTML
<body>
  <header><h1>My Site</h1></header>
</body>

After:

HTML
<body>
  <header><h1>My Site</h1></header>
  <form action="/login" method="post" aria-labelledby="login-heading">
    <h2 id="login-heading">Log In</h2>
    <div><label for="email">Email</label><input type="email" id="email" name="email" required></div>
    <div><label for="password">Password</label><input type="password" id="password" name="password" required></div>
    <button type="submit">Log In</button>
  </form>
</body>

Validation: 0 errors, 0 warnings → PASSED, ZIP delivered.

Example 2: Change page title Input: instruction="Change the title to 'Contact Us - Acme Inc.'" Before: <title>Home</title> After: <title>Contact Us - Acme Inc.</title> Validation: 0 errors, 0 warnings → PASSED, ZIP delivered. Single-line diff; no other content touched.

Example 3: Add navbar Input: instruction="Add a navigation bar with links to Home, About, Contact" Before:

HTML
<body>
  <main>...</main>
</body>

After:

HTML
<body>
  <nav aria-label="Primary">
    <ul>
      <li><a href="/">Home</a></li>
      <li><a href="/about">About</a></li>
      <li><a href="/contact">Contact</a></li>
    </ul>
  </nav>
  <main>...</main>
</body>

Validation: 0 errors, 0 warnings → PASSED. Accessibility note: aria-label="Primary" added since page has (potentially) multiple <nav> regions in future.

Example 4: Remove a guard clause / element (with risk) Input: instruction="Remove the <div id='age-gate'> overlay from index.html" Before:

HTML
<body>
  <div id="age-gate">Are you 18+? <button>Yes</button></div>
  <main>...</main>
</body>

After:

HTML
<body>
  <main>...</main>
</body>

Validation: 0 errors, 0 warnings → PASSED. Risk note (included in report): Removing the age-gate overlay may have compliance implications (e.g., age-restricted content regulations). Documented as an explicit assumption; user should confirm this removal is intentional and legally acceptable before deploying.

Recommendation▾
Clarify how max_attempts default value is set if not specified by user
Best Practices
  • Prefer semantic elements (<nav>, <main>, <article>, <section>, <button>) over generic <div>/<span>.
  • Always add alt text for images (describe content; use alt="" only for purely decorative images, and note this choice).
  • Use <ul>/<ol> for navigation and grouped links.
  • Keep CSS/JS in external files unless the user explicitly requests inline code; if inlining, note it as a deviation.
  • Document every creative/ambiguous decision in assumptions, even small ones (e.g., default input types, default styles).
  • Preserve original formatting/indentation style of the surrounding file when patching, unless preferred_style=verbose is requested.
  • Always diff at the smallest reasonable granularity — avoid re-serializing/reformatting the whole file.
Common Pitfalls
  • Do not reformat or reflow untouched parts of the file — this obscures the diff and violates the "only targeted changes" constraint.
  • Do not deliver the ZIP if validator reports any warning, even a minor one (e.g., trailing slash on void elements) — treat all validator output as blocking.
  • Do not silently drop content when "replacing" — always show before/after and justify removals.
  • Do not invent ARIA attributes without cause; only add them when they clarify semantics not otherwise expressible in HTML.
  • Do not proceed if the instruction implies modifying files the user doesn't own or content protected by copyright/privacy — refuse and log the refusal with reasoning in the report instead of silently skipping.
  • Do not exceed max_attempts silently — if still failing, clearly report status as FAILED with a specific, actionable remediation list (exact validator error lines + suggested fix).
0
Grade A-AI Skill Framework
Scorecard
Criteria Breakdown
Quick Start
14/15
Workflow
15/15
Examples
18/20
Completeness
19/20
Format
14/15
Conciseness
13/15
Save to My Skills