page-inventory-audit

Audits every visible string on a dashboard page against the SOP and removes nonconforming UI elements.

Updated Apr 19, 2026
One-click install
npx skills add https://github.com/divinaarmuela/Content --skill page-inventory-audit-divinaarmuela
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: page-inventory-audit
Source: https://github.com/divinaarmuela/Content/tree/main/.claude/skills/page-inventory-audit
Command: npx skills add https://github.com/divinaarmuela/Content --skill page-inventory-audit-divinaarmuela

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code-level tests and pure-function reviews never see what a page actually draws, so leftover links, wrong-role buttons, and hidden sections survive every audit. This Skill forces a complete inventory of every visible string on a page, judged line-by-line against the team's SOP, before anyone claims a page works. ## Core Features & Use Cases - Full String Inventory: Lists every title, label, hint, placeholder, button, chip, empty state, and help text with file:line, role, and display state in a table. - SOP Verdicts: Marks each string as keep, reword, remove, or move based on the Playbook, catching leftovers like stale links and pickers the SOP never asks for. - Conditional Render Checks: Verifies that in the empty/new state everything the copy references is actually drawn, and pins removals in render-gate tests. - Use Case: After rebuilding a dashboard page, run this audit to find a deliverables section hidden behind a length check, a leftover "Open Drive folder" link, and a picker that belongs to another role, then render the page per role to confirm. ## Quick Start Audit the editor's New card page against the SOP, inventory every visible string, and render the empty and filled states for each role.

Frequently Asked Questions about page-inventory-audit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit a dashboard page against an SOP?

Open the page's tsx and every component it draws, list every visible string in a table with file:line, role, and state, then give each a keep, reword, remove, or move verdict based on the SOP. Finish by rendering the page in a real browser per role before claiming it is checked.

Why do code-level tests miss UI problems on a page?

Unit tests and pure-function walks never see what a page actually draws, so hidden sections, leftover links, and wrong-role buttons pass unnoticed. Only a full visible-string inventory plus a real browser render in empty and filled states catches them.

What are common leftovers found in a page inventory audit?

Typical finds are links to retired pages, pickers the SOP never requests, hints pointing at sections that are not drawn, manager buttons on a maker's page, and more columns than the SOP specifies. Conditional renders that hide sections in the empty state are also frequent.

Does this audit require rendering the page in a browser?

Yes. A page counts as checked only after both the string inventory and a real browser render, using Chrome MCP as the owner's account or Playwright, in the empty state and a filled state for each role that sees it.

When should I not claim a page has been checked?

Never claim a page is checked until both the inventory and the render are complete. Until then, report it as not yet looked at, since skipping either step is how hidden sections and stale elements survive audits.