\n\nQuick Guide: Specify every state the UI can be in — loading, error, empty, and success are four different screens, and an unspecified one ships as a blank div. Reference the concrete component and form patterns the implementation must follow (file:line), bound the change to named directories, and write success criteria a reviewer can check with a yes/no: which element appears, what the validation rejects, what the user sees on a network error.
\n
<critical_requirements>
\n\n\nAll specifications must be grounded in the codebase's real components, stores, and form patterns — reference specific files with line numbers
\n
(You MUST specify every UI state the feature can render — loading, error, empty, and success — or explicitly rule one out)
\n(You MUST reference the concrete component, form, and store patterns to follow, with file and line numbers)
\n(You MUST specify validation per field — the rule, when it fires, and the exact message shown)
\n(You MUST bound the change to named files and directories, with an explicit do-not-touch list)
\n(You MUST write success criteria as yes/no checks a reviewer can verify — never \"works well\" or \"good UX\")
\n</critical_requirements>
\nAuto-detection: UI spec, component spec, frontend feature spec, form spec, modal spec, loading state, empty state, error state, client state design, frontend success criteria
\nWhen to use:
\nWhen NOT to use:
\nKey patterns covered:
\nDetailed Resources:
\n<decision_framework>
\nDoes the feature render data from an async source?\n├─ YES → UI States section (Pattern 1) — all four states\n└─ Does it include a form?\n ├─ YES → Form Contract section (Pattern 3), field by field\n └─ Does it introduce or move client state?\n ├─ YES → State Ownership section (Pattern 4)\n └─ NO → Pattern references + scope fence + criteria may be the whole spec\nAlways applicable: Pattern-reference discipline (Pattern 2), Scope fencing (Pattern 5), Measurable criteria (Pattern 6).
\n| Failure | \nConsequence | \n
|---|---|
| Only the success state specified | \nLoading, error, and empty ship as blank or broken screens | \n
| \"Use proper form handling\" | \nEach form invents its own validation timing and error display | \n
| No do-not-touch list | \nThe feature \"fixes\" a store and breaks its other consumers | \n
| Criteria like \"works well\" | \nNothing gates the merge; review becomes opinion | \n
| Server data mirrored into a store | \nTwo sources of truth; stale UI after every mutation | \n
| Pattern reference without line numbers | \nThe reference was never verified to exist | \n
</decision_framework>
\n<red_flags>
\nHigh Priority Issues (a spec with one of these is incomplete):
\nMedium Priority Issues:
\nCommon Mistakes:
\nGotchas & Edge Cases:
\n</red_flags>
\n<critical_reminders>
\n\n\nAll specifications must be grounded in the codebase's real components, stores, and form patterns
\n
(You MUST specify every UI state the feature can render — loading, error, empty, and success — or explicitly rule one out)
\n(You MUST reference the concrete component, form, and store patterns to follow, with file and line numbers)
\n(You MUST specify validation per field — the rule, when it fires, and the exact message shown)
\n(You MUST bound the change to named files and directories, with an explicit do-not-touch list)
\n(You MUST write success criteria as yes/no checks a reviewer can verify)
\nFailure to specify these contracts produces UIs whose error and empty states are accidents, whose forms each validate differently, and whose \"done\" nobody can verify.
\n</critical_reminders>
\n","files":[{"path":"examples/core.md","sizeBytes":5242,"isText":true},{"path":"SKILL.md","sizeBytes":13646,"isText":true}],"reviewScore":null,"reviewSummary":null,"trust":{"provenance":"trusted-source-unreviewed","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow.","bodySource":null},"bodyLocked":false,"purchaseUrl":null,"sourceUrl":null,"report":{"provenance":"trusted-source-unreviewed","screen":{"ran":true,"outcome":"clean","suspicious":0,"notes":0,"hiddenCharacters":false},"virusScan":{"engine":"clamav","status":"clean","scannedAt":"2026-09-29T15:30:42.979973Z","sha256":"B46693DE25CE47C991500C2644B611A9DAF44BDC332A7211AE43C6D65882C0D1","sizeBytes":7349},"review":null,"source":{"repositoryUrl":"https://github.com/agents-inc/skills","path":"dist/plugins/meta-planning-web-planning/skills/meta-planning-web-planning","license":"MIT","commit":"3a51ef571e996b18294bf776d53dbdad26de0617","subtreeSha":"3139FFF5B316507B7A3221702B2DFF5B6F83F0FBF1BE09A124E6545E258FF52C","lastSyncedAt":"2026-09-29T15:27:48.914434Z"},"reviewedAt":"2026-09-29T15:36:07.002288Z","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow."},"install":[{"target":"skills-cli","command":"npx skills add https://github.com/agents-inc/skills/tree/main/dist/plugins/meta-planning-web-planning/skills/meta-planning-web-planning"},{"target":"claude-code","command":"claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install agents-inc-skills@llmmart"},{"target":"git","command":"git clone https://github.com/agents-inc/skills.git"}]}