メニュー
Feature design methodology. Covers research, comparison, requirements refinement, ideation, implementation planning, and DX completeness. Use when starting a new feature, planning a refactor, or designing APIs. Invoked via /design [topic].
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/robert-chiniquy/dotfiles --skill designコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Sweep open issue trackers, TODOs, active branches, and source evidence to find narrowly scoped, independent, verifiable tasks suitable for remote agents or parallel delegation. Use when asked to find pebbles, small delegatable work, fire-and-forget candidates, backlog slices, ready items, or pool/task combinations.
Write a scorecard — a dark, skimmable one-screen readout of the current situation in the user's work, rendered as a terminal (TUI) artifact by the `scorecard` binary from a structured markdown file. Use ONLY when the user explicitly asks for a scorecard (or a "readiness card" / "go/no-go card" / "coverage snapshot card"). A plain "status", "status?", or other status/situation question gets a prose answer, never this skill. NOT a web page — output is the dark TUI. Preserves older scorecards by datestamp. Triggers on: scorecard, readiness card, go/no-go card, coverage snapshot card.
Present comparisons as narrow ASCII bar charts in the terminal. Use when user asks to compare items, metrics, counts, or coverage between things.
SKILL.md を表示中
SOC 職業分類に基づく
| name | design |
| disable-model-invocation | true |
| description | Feature design methodology. Covers research, comparison, requirements refinement, ideation, implementation planning, and DX completeness. Use when starting a new feature, planning a refactor, or designing APIs. Invoked via /design [topic]. |
| argument-hint | [feature or topic] |
Structured approach to feature design. Not every step applies to every feature. Skip steps that don't add value. The sequence matters more than completeness.
What exists? Read the codebase. Read competing implementations. Read the docs. Capture findings in DATA_SOURCES.md.
How do others solve this? Build a comparison matrix: feature vs platform. Look for patterns across 3+ implementations.
Convert vague requirements ("make it fast") into measurable attributes ("p99 latency under 200ms"). Challenge ambiguous terms.
Generate concrete features with examples. Each feature gets: name, one-line description, CLI example or API shape, which attribute it serves.
Cut aggressively. What's the smallest thing that delivers the core value? Use the Level Framework: Level 0 (platform), Level 1 (workflow), Level 2 (polish). Build Level 0 first.
Vertical slices, not horizontal layers. Each slice is deployable and testable. Count lines of code per slice. If a slice exceeds 500 lines, split it.
Run /critique on the plan before implementing.
Every developer-facing feature needs three things:
If any leg is missing, the feature is incomplete.
