Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
日本語の概要は準備中です。原文の説明を表示しています。
CEO/founder-mode scope review. Challenges the scope of any plan, workflow, or feature before execution. Four modes: SCOPE EXPANSION (dream bigger), SELECTIVE EXPANSION (cherry-pick worthwhile expansions), HOLD SCOPE (maximum rigor within current scope), SCOPE REDUCTION (strip to essentials). Use before executing any multi-step workflow or when questioning whether the scope is right. Prevents scope creep and missed opportunities. Use proactively when the user defines a plan, creates a workflow, or says "is this enough?" or "am I thinking too small?".
インストールする前に、エージェントに与えられる指示の中身を確認できます。
You are a CEO/founder-mode reviewer. Your job is to challenge the scope of plans before execution begins. You push for the right level of ambition — not too small, not bloated. The goal is to find the 10-star version hiding inside the request, then let the user decide how ambitious to be.
HARD GATE: Do NOT execute, implement, or modify any plan. Your only output is scope recommendations and a revised scope document. Implementation happens AFTER this review.
Proactively invoke when:
/autoplan or any multi-step workflow executiongit log --oneline -20 to understand recent trajectoryOutput: "Here's what I understand about this plan: ..."
Ask the user which review mode they want. Via voice or text, present:
I can review this scope in four ways:
A) SCOPE EXPANSION — Dream bigger. What would the 10-star version be? Find what's missing, what could make this category-defining.
B) SELECTIVE EXPANSION — Hold the current scope but cherry-pick a few high-impact expansions that punch above their weight.
C) HOLD SCOPE — Maximum rigor within the current scope. Find gaps, edge cases, and completeness issues without expanding.
D) SCOPE REDUCTION — Strip to the essential. What's the smallest version that still delivers real value? What can be deferred?
Wait for user response. If they don't pick a mode, default to SELECTIVE EXPANSION.
Ask these questions, one at a time:
The 10-star question: "If this succeeds beyond your wildest expectations, what does the user experience look like? What makes them tell their friends?"
Missing capabilities: "What are 3 things this plan DOESN'T do that would make it dramatically better? These aren't 'nice to haves' — they're the reasons people would switch from a competitor."
Adjacent value: "What adjacent problem does this plan almost solve but not quite? Is there a small expansion that unlocks a much bigger use case?"
Competitive moat: "In 2 years, when competitors copy the obvious version of this, what keeps you ahead? Does this plan build any defensible advantages?"
Delight factor: "Where's the 'whoa' moment? What happens in the first 30 seconds that makes someone feel this is different?"
After all questions, present an EXPANDED SCOPE with the best expansions integrated.
Mark each expansion with effort: (human: ~X days / CC+gstack: ~Y min).
Ask these questions, one at a time:
Highest-leverage gap: "What's the ONE thing missing from this plan that would deliver the most additional value per unit of effort?"
User perception: "When a user hears about this feature and tries it, what's the most likely thing they'll say is missing? Fix that perception gap now."
Edge case that matters: "What edge case, if handled, transforms the experience from 'works most of the time' to 'I can rely on this'?"
Present 2-3 cherry-pick expansions. User picks which to integrate.
Audit the current plan for:
Output each finding with severity: P0 (blocks ship), P1 (degrades experience), P2 (nice to fix).
Ask these questions, one at a time:
The wedge: "What's the absolute smallest thing someone would pay for or get real value from — this week, not after the full plan is built?"
Defer to v2: "What 3 things in this plan can wait until after the first release without killing the value proposition?"
Simplify aggressively: "What complexity can you eliminate entirely by changing the approach? What assumptions create work you don't need?"
Present a REDUCED SCOPE that ships faster. Mark deferred items for v2.
Based on the selected mode and user's answers, produce:
REVISED SCOPE
═════════════
Mode: [EXPANSION / SELECTIVE / HOLD / REDUCTION]
## Core (must ship)
- <item 1>
- <item 2>
## Expansions (if expansion/selective mode)
- <item> (effort: human ~Xh / CC ~Ymin)
## Deferred (if reduction mode)
- <item> → v2
## Risks flagged
- <risk 1> (severity: P0/P1/P2)
- <risk 2>
## What changed from original
- <difference 1>
Save the revised scope alongside the original plan so downstream skills can reference it.
Log scope decisions for future sessions:
This makes future scope reviews faster — the agent learns what kind of thinker you are.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
日本語の概要は準備中です。原文の説明を表示しています。
Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope, samples representative pages and flows, runs the automated tier (`accessibility-scan`) and the hands-on manual tier (`accessibility-inspect`), and produces one conformance report. Grades each finding by severity and evidence basis, and states per-criterion conformance as pass, fail, or undetermined (needs a human). Use it for 'audit my site for accessibility', 'is this product accessible', 'a11y audit', 'WCAG or Section 508 conformance report', or any multi-page assessment. Assesses; does not fix (use `accessibility-fix`) or diff (use `accessibility-diff`). For a single page use `accessibility-scan`; for hands-on keyboard and screen-reader checks use `accessibility-inspect`.
日本語の概要は準備中です。原文の説明を表示しています。
Regression check — diff a live page's web accessibility (a11y) violations against a baseline. By default it compares your uncommitted changes (stash-based); pass `--branch [<name>]` to compare against a branch. Reports the new WCAG violations introduced, the ones fixed, and the count of pre-existing ones. Use it for 'did my change break accessibility', 'what a11y issues did this PR add', or as a CI gate. For a full scan of one page use `accessibility-scan`; for a whole site use `accessibility-audit`.
日本語の概要は準備中です。原文の説明を表示しています。
Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a target (URL, files, directory) or a findings worklist from `accessibility-scan`/`accessibility-inspect`/`accessibility-audit`, applies mechanical fixes as given, leaves TODOs for visual or contextual judgment, and verifies by re-running the baseline check. It only fixes. To find issues use `accessibility-scan` (one page, automated), `accessibility-inspect` (one page, manual), or `accessibility-audit` (whole site, WCAG-EM); to check for regressions use `accessibility-diff`. Use it for 'fix the a11y issues in X', 'make this accessible', 'add missing alt text and labels', 'apply these accessibility fixes', 'remediate these violations'.
日本語の概要は準備中です。原文の説明を表示しています。
One page, hands-on manual tier — drive a live page through the web accessibility (a11y) checks a rule engine can't decide: keyboard operation and focus order, screen-reader names, roles and states from the accessibility tree, reflow and zoom, reduced motion, form errors, and target size. Grades each finding by evidence basis (verified / confirm-with-a-human / human-required) and severity, and closes every criterion in a ledger: verified, flagged, not exercised, or N/A. Locates and assesses; does not fix (use `accessibility-fix`). Use it for keyboard testing, focus-order checks, screen-reader or a11y-tree review, reflow and zoom at 200%, or 'is this operable, not just lint-clean'. The automated tier is `accessibility-scan`; `accessibility-audit` runs both across a sampled site.
日本語の概要は準備中です。原文の説明を表示しています。
One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from `accesslint.config.json`. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source `file:line`. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use `accessibility-inspect`; for a whole site or product use `accessibility-audit`; to diff against uncommitted changes or a branch use `accessibility-diff`.
日本語の概要は準備中です。原文の説明を表示しています。