joris887
joris887/exosuit
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/joris887/exosuit --skill brainstorm命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Execute comprehensive backlog review. Analyzes story quality, Definition of Ready compliance, dependencies, zombie stories, and generates a backlog health report.
First-run framework setup. Detects existing project stack or guides new project creation from vision/braindump.
Build a project from a plain-English description. Handles all technical decisions automatically. Designed for non-technical users but useful for anyone who wants fast results.
正在显示 SKILL.md
| name | brainstorm |
| version | 2.7.2 |
| description | Use when the user has a complex idea that needs design exploration before story decomposition. |
| trigger | manual |
| depends-on | ["ideate"] |
| references | [] |
| disable-model-invocation | true |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Bash, Edit, Write, WebSearch, WebFetch, Agent, AskUserQuestion |
| argument-hint | <idea-or-topic> |
Skill metrics: Emit a start event to the activity log:
echo "{\"type\":\"skill\",\"event\":\"start\",\"skill\":\"brainstorm\",\"ts\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"}" >> docs/sessions/.activity-log.jsonl
Brainstorming: $ARGUMENTS
For complex or high-stakes brainstorms, consider using Plan Mode for Phases 1-4. This adds an extra layer of safety by preventing premature implementation during design exploration.
When to use: The idea is architecturally significant, affects multiple systems, or the user explicitly requests a careful exploration.
How: Enter Plan Mode before Phase 1. Remain in Plan Mode through Phase 4 (risk identification). Exit Plan Mode before Phase 5 (design presentation) so you can interact with the user for approval.
Understand the idea deeply before proposing solutions:
Product requirements context: Read docs/reference/PRD_SUMMARY.md if it exists. Use Section 3 (success criteria) as evaluation criteria for approaches in Phase 3. Use Section 7 (scope boundaries) to ensure no approach violates stated non-goals or implementation boundaries. Use Section 6 (NFRs) as constraints — e.g., an approach that can't meet the performance or accessibility thresholds is disqualified.
Persona context: Read docs/context/personas.md if it exists. Note each persona's goals, evaluation criteria, and failure scenarios — these inform approach scoring in Phase 3.
Ask clarifying questions if the idea is vague. Do NOT proceed with assumptions.
Investigate relevant existing code:
docs/context/system-patterns.md exists and is populated, load it. In Phase 3, score each approach's Pattern Fit: does it follow or diverge from established implementation patterns, error handling strategy, and testing conventions? Approaches that align are lower-risk. Approaches introducing new patterns must justify the divergence and note which sections of system-patterns.md would need updating.docs/architecture/ARCHITECTURE.mddocs/reference/GROUND_RULES.md (if exists) — MUST rules are hard constraints on any proposed approachBefore proposing alternatives, research them with web evidence. This step makes alternatives evidence-backed rather than relying solely on training data.
Compose the deep-research methodology (.claude/prompts/deep-research.md) at STANDARD depth:
decision-input (compact, one per approach)Research is dispatched in parallel — one subagent per approach.
Integrate findings into Phase 3 alternatives: each approach's pros/cons now include real-world evidence and citations where applicable.
Skip when: User says "no research" or "I know the approaches", or the brainstorm is about internal refactoring with no external technology choices.
Present 2-3 distinct approaches using AskUserQuestion with markdown previews for visual comparison.
For each approach, create an option with:
## [Approach Name]
**How:** [2-3 sentence description]
**Architecture:**
[ASCII diagram or file structure tree]
**Pros:**
- [benefit 1]
- [benefit 2]
**Cons:**
- [tradeoff 1]
- [tradeoff 2]
**Complexity:** [Low/Medium/High] — [N files, N new deps]
**PRD Fit:** [How well this approach meets PRD success criteria and NFRs]
**Pattern Fit:** [Aligns with / Extends / Diverges from established patterns]
If PRD was loaded: Score each approach against PRD success criteria (Section 3) and NFRs (Section 6). An approach that can't meet a stated NFR (e.g., performance target, accessibility requirement) should be flagged as non-viable.
If system-patterns were loaded: Add a Pattern Fit line to each approach. Score: Aligns (follows all documented patterns), Extends (adds a new pattern consistent with existing ones), or Diverges (contradicts a documented pattern — must justify). Approaches that Diverge carry higher implementation risk and require updating system-patterns.md.
If personas were loaded: Add a Persona Fit line to each approach's preview, evaluating how well the approach serves each persona:
State which approach you recommend and why. The user selects their preferred approach.
If the design involves API endpoints, authentication flows, data storage, service-to-service communication, or user input processing, run a quick STRIDE pass on each component in the data flow:
| Threat | Question | Example |
|---|---|---|
| Spoofing | Can an attacker impersonate a legitimate user or service? | Missing auth tokens, weak session management |
| Tampering | Can data be modified in transit or at rest? | Unsigned API payloads, unvalidated webhooks |
| Repudiation | Can an action be denied without evidence? | Missing audit logs for sensitive operations |
| Information Disclosure | Can sensitive data leak? | Verbose errors, PII in logs, secrets in config |
| Denial of Service | Can the system be overwhelmed? | Missing rate limiting, unbounded queries |
| Elevation of Privilege | Can a user gain unauthorized access? | IDOR, missing role checks, privilege escalation |
This is not full threat modeling — it's a 2-minute structured checklist. Include findings in the "Risks" section of the design brief. Any STRIDE finding should become a security acceptance criterion when the design is decomposed into stories by /ideate.
Summarize the recommended approach in a design brief:
### Design: [Idea Title]
**Problem:** [One sentence]
**Approach:** [Recommended approach name]
**Key decisions:** [Bullet list]
**Risks:** [Bullet list]
**Estimated scope:** [Small: 1-2 stories / Medium: 3-5 / Large: 6+]
After user approves the design, save the exploration to docs/brainstorms/<topic-slug>.md with frontmatter:
---
title: "<Idea Title>"
date: <YYYY-MM-DD>
status: decided # explored | decided | abandoned
decision: "<Chosen approach name>"
---
Include the design brief (from Phase 5), the approaches explored (from Phase 3), and the risks identified (from Phase 4). This document is referenced by /ideate when the idea becomes a story.
If the decision is architecturally significant (from Phase 4 assessment): also create an ADR using docs/adr/TEMPLATE.md. The brainstorm document captures the exploration; the ADR captures the decision in machine-parseable format with rejected alternatives and compliance checks. Map the brainstorm's approaches to the ADR's Alternatives Considered section (chosen → ✅, rejected → ❌ with rationale and reconsider-when conditions).
Skill metrics: Emit a completion event:
echo "{\"type\":\"skill\",\"event\":\"end\",\"skill\":\"brainstorm\",\"outcome\":\"success\",\"ts\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"}" >> docs/sessions/.activity-log.jsonl
After user approves the design:
/ideate with the approved approach to decompose into storiesdocs/brainstorms/ serves as reference during implementationInput: /brainstorm "real-time notifications"
Output: 3 approaches explored (WebSockets, SSE, polling)
Recommended: SSE — simpler, sufficient for one-way notifications
Risks: browser support for SSE reconnection, scaling beyond 1000 connections
Next Steps:
→ /ideate "real-time notifications using SSE" — decompose into stories
→ /handoff — if ending the session