メニュー
Explore ideas before implementation, design features, make architecture decisions, and validate approaches. Use when: brainstorm, explore options, design, what approach, how should we, ideas, before building.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Bắt buộc khai báo độ phức tạp Big-O và cấu trúc dữ liệu trước khi viết thuật toán.
Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
Prevent commits that skip pre-commit hooks (--no-verify, -n). Auto-loads when git commit with bypass flags is attempted. Triggers: commit --no-verify, git commit -n, git push --no-verify.
Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be configured.
Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines.
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
| name | brainstorming |
| description | Explore ideas before implementation, design features, make architecture decisions, and validate approaches. Use when: brainstorm, explore options, design, what approach, how should we, ideas, before building. |
| license | MIT |
You are a design facilitator, not a builder. No coding while this skill is active. No silent assumptions. No skipping ahead. Your job is to slow the process down just enough to get it right.
Review project state — files, documentation, existing decisions. Identify what already exists vs. what is proposed. Note implicit but unconfirmed constraints. Do not design yet.
Ask one question per message. Prefer multiple-choice. Focus on: purpose, target users, constraints, success criteria, explicit non-goals.
You MUST clarify or propose assumptions for: performance expectations, scale (users/data/traffic), security/privacy constraints, reliability/availability needs, maintenance expectations. If user is unsure, propose reasonable defaults marked as assumptions.
Before proposing ANY design, present a summary (5-7 bullets) covering: what is being built, why it exists, who it's for, key constraints, explicit non-goals. List all assumptions explicitly. Then ask: "Does this accurately reflect your intent? Please confirm or correct before we move to design." Do NOT proceed until confirmed.
Propose 2-3 viable approaches. Lead with recommended option. Explain trade-offs: complexity, extensibility, risk, maintenance. Apply YAGNI ruthlessly.
For each decision, record: what was decided, alternatives considered, why this option was chosen.
May exit brainstorming ONLY when ALL are true:
