メニュー
Generate a UI feature plan (plan.md) and eval_criteria.yaml from NFRs, acceptance scenarios, and architecture preflight. Use when the user asks to plan a UI feature or invokes /govkit-ui-spec-planning.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | govkit-ui-spec-planning |
| description | Generate a UI feature plan (plan.md) and eval_criteria.yaml from NFRs, acceptance scenarios, and architecture preflight. Use when the user asks to plan a UI feature or invokes /govkit-ui-spec-planning. |
You are performing Spec Planning for a UI feature. Determine the feature name from the user's request; if it is not provided, ask before proceeding.
Read the following before proceeding:
features/<feature_name>/acceptance.featurefeatures/<feature_name>/nfrs.mdfeatures/<feature_name>/architecture_preflight.mddocs/ui/architecture/MVVM_CONTRACT.mddocs/ui/evaluation/eval_criteria.mdgovernance/ui/templates/plan.mdgovernance/ui/schemas/eval_criteria.schema.jsonProduce or update features/<feature_name>/plan.md and features/<feature_name>/eval_criteria.yaml.
One paragraph describing the feature from the user's perspective.
Populate the plan's ### Out of scope from nfrs.md ## Out of scope:
nfrs.md has a non-empty ## Out of scope section, copy its entries into the plan verbatim (author-declared — no marker).## Out of scope is missing or empty, infer the deferred capabilities from the spec's negative space, then BOTH:
<!-- INFERRED: not declared in nfrs.md ## Out of scope; confirm with feature owner --> directly under the plan's ### Out of scope heading, andFor each layer:
Ordered list of implementation increments. Each increment must be independently testable and deployable.
List any backend endpoints this feature depends on. Flag any that are not yet available.
For each Gherkin scenario tagged @accessibility: describe the WCAG criteria and test approach.
evaluation_prediction:
first:
fast: { score: 0-5, evidence: "..." }
isolated: { score: 0-5, evidence: "..." }
repeatable: { score: 0-5, evidence: "..." }
self_verifying: { score: 0-5, evidence: "..." }
timely: { score: 0-5, evidence: "..." }
average: 0.0
virtues:
working: { score: 0-5, evidence: "..." }
unique: { score: 0-5, evidence: "..." }
simple: { score: 0-5, evidence: "..." }
clear: { score: 0-5, evidence: "..." }
easy: { score: 0-5, evidence: "..." }
developed: { score: 0-5, evidence: "..." }
brief: { score: 0-5, evidence: "..." }
average: 0.0
accessibility:
predicted_axe_violations: 0
wcag_level: AA
thresholds_met: true|false
Scoring rubrics: docs/ui/evaluation/FIRST_SCORING_RUBRIC.md and docs/ui/evaluation/VIRTUE_SCORING_RUBRIC.md
Do not proceed to Implementation Planning if thresholds_met is false, predicted FIRST average is below 4.0, or predicted Virtue average is below 4.0.
Plan implementation work as a sequence of the smallest independently demonstrable increments. Use when given a feature request, a body of work, or any implementation task that must be broken down or sequenced BEFORE coding — it classifies the request, identifies the next demonstrable behaviors, and recommends (advisory) an appropriate model tier for implementing each increment. This skill plans; it does not write code, tests, commits, or architecture.
Write or improve unit tests following a strict determinism, F.I.R.S.T., and fast-feedback-budget discipline. Use when asked to write tests, improve tests, review test quality, classify tests, or assess a test suite against a 30-second fast-feedback budget. Invokes a structured output protocol that identifies behaviors under protection, classifies each test by level and feedback loop, and flags nondeterminism risks.
Standards for writing, reviewing, and evaluating unit tests. Use whenever writing new tests, reviewing existing tests, deciding what to test, assigning a test to a fast vs. full feedback loop, or diagnosing flaky, slow, or low-value tests. Covers structural fidelity, the FIRST properties, behavioral invariants, and coverage-as-diagnostic.
Zero-One-Many Representation Evolution — use this skill whenever working with existing code that needs to change, grow, or be refactored. Triggers include: "refactor this", "add a new X to this", "this is getting messy", "how should I represent this", "there's a lot of duplication here", or any time numbered variables, growing conditionals, repeated parameter groups, or scattered constants are observed. Also use proactively when reviewing code for design quality, assessing coherence and development level, or applying the 8 Code Virtues framework. Do not wait to be asked — if you see representation pressure in the code, surface it.
Author an Architecture Decision Record for a new pattern, exception, or boundary change. Use when the user asks to write an ADR or invokes /govkit-adr-author.
Validate architecture boundaries, standards alignment, and ADR need before planning a feature. Use when starting a new feature or invoking /govkit-architecture-preflight.