ソース情報
- リポジトリ
- joris887/exosuit
- ソースの最終更新活動
- 2026年8月20日 09:35
- 検出された SKILL.md の言語
- 英語
- スター
- 4
- フォーク
- 1
インストール方法
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
ソースファイルを確認
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
メニュー
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/joris887/exosuit --skill ideateコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか?SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
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.
Use when the user has a complex idea that needs design exploration before story decomposition.
| name | ideate |
| version | 2.10.2 |
| description | Use when the user has an idea or requirement to decompose into backlog stories. |
| trigger | manual |
| depends-on | [] |
| references | ["references/story-template.md"] |
| disable-model-invocation | true |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Bash, Edit, Write, WebSearch, WebFetch, Agent |
| argument-hint | <idea-or-requirement> |
Skill metrics: Emit a start event to the activity log:
echo "{\"type\":\"skill\",\"event\":\"start\",\"skill\":\"ideate\",\"ts\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"}" >> docs/sessions/.activity-log.jsonl
Transforming idea into backlog stories: $ARGUMENTS
Before starting, verify:
docs/reference/backlog/ directory exists (create if missing)docs/reference/BACKLOG_INDEX.md is readableIf prerequisites fail, inform the user and stop — don't consume context on doomed work.
Check if a sprint is currently active (branch matches sprint-* or docs/progress.md shows an in-progress sprint). If so, display a notice:
Sprint [N] is in progress (goal: "[sprint goal]"). New stories will be added to the backlog, not the current sprint. Adding stories to a running sprint increases sprint churn — target is <20%.
This is informational, not blocking. The user may legitimately need to ideate during a sprint. But it prevents accidental scope creep where new stories get silently mixed into active sprint work.
Check for prior brainstorm artifacts: Search docs/brainstorms/ for existing design documents matching the topic. If a brainstorm doc exists with status: decided, load it as context — the design exploration and key decisions have already been made.
Understand the idea or requirement from $ARGUMENTS and any additional context the user provides.
Ask clarifying questions if the idea is too vague:
Do NOT write any stories to backlog files, create epic files, or update BACKLOG_INDEX.md until the user has explicitly approved the decomposition. Present the stories, wait for approval.Explore the codebase to understand:
docs/architecture/ARCHITECTURE.md)docs/reference/GROUND_RULES.md if exists) — stories must not require MUST violationsRead docs/context/personas.md if it exists. When present, note each persona's goals, frustrations, and evaluation criteria — these inform story decomposition and acceptance criteria. Note the primary persona (★) for prioritization decisions.
Read docs/reference/PRD_SUMMARY.md if it exists. When present, extract:
If the idea involves external dependencies, unfamiliar technology, or integration with third-party services, perform a quick feasibility check before decomposition.
Compose the deep-research methodology (.claude/prompts/deep-research.md) at QUICK depth:
evidence-check (yes/no/maybe with evidence)If feasibility is uncertain: Add a Spike/Research story to the decomposition to resolve the uncertainty before implementation stories begin.
Skip when: The idea uses only well-understood, established technologies already present in the codebase, or when a prior brainstorm/research doc already covers feasibility.
When a story fails the cohesion test (see references/story-template.md), apply these five splitting patterns in order of preference:
Each resulting story must be a vertical slice (UI + logic + data), not a horizontal layer.
When PRD requirements use EARS acceptance criteria, convert them to story-level Given/When/Then:
WHEN [trigger] THE SYSTEM SHALL [behavior] → Given [precondition state], When [trigger occurs], Then [behavior is observed]
PRD Properties (invariants) become test assertions. PRD edge case tables become additional test scenarios.
Break the idea into properly typed stories. For each story, determine the best type:
| Story Type | Template | Output |
|---|---|---|
| Feature | "As a [user], I want [capability], so that [benefit]." | Working code + tests |
| Bug Fix | "Fix: [defect description]. Expected: [behavior]. Actual: [behavior]." | Fix + regression test |
| Refactoring | "Refactor [component] to [improvement] without changing behavior." | Restructured code |
| Spike/Research | "Investigate [question]. Time-box: [hours]. Decision criteria: [list]." | Decision document or ADR |
| Infrastructure | "Set up [tooling/config] to enable [capability]." | Scripts/config + verification |
| Testing | "Add [test type] coverage for [component/feature]." | Test code + coverage |
| Documentation | "Document [topic] for [audience]." | Updated docs |
| Security | "Harden [component] against [threat]. Verify with [method]." | Hardened code + audit |
| Performance | "Optimize [operation] to meet [target]. Baseline: [current]." | Optimized code + benchmarks |
| Skill/Tooling | "Create [skill/tool] to automate [workflow]." | New skill + docs |
Size follows conceptual cohesion, not file count (canonical policy: references/story-template.md). Each story is:
If a story fails the cohesion test, split it. When genuinely uncertain, prefer the larger coherent story — re-splitting later is cheap; reassembling artificially severed work is not.
Follow the story template in references/story-template.md. Use YAML frontmatter for machine-parseable metadata, checklist-style AC as the default, and explicit verification commands.
For each story, produce:
---
id: [PROJECT]-[NUMBER]
title: [Clear, one-line summary of what changes]
type: feature|bugfix|refactor|spike|infra|testing|docs|security|performance|skill
priority: P0|P1|P2|P3
size: TRIVIAL|SMALL|STANDARD|LARGE|XL
status: draft
created: YYYY-MM-DD
---
# [Title]
## Why
[1-2 sentences: What problem does this solve? What user/business value?]
## Context
- **Current state**: [What exists now — behavior, relevant code, prior decisions]
- **Affected files**: [Explicit list. Short for TRIVIAL–STANDARD; LARGE and XL legitimately touch more]
- **Follow patterns in**: [Path to exemplar file in codebase]
- **Dependencies**: [Story IDs that must be complete first, or "None"]
- **Personas**: [P1 (Name — Role), P2 (Name — Role) | or "internal" for infra/refactoring stories]
## Acceptance criteria
- [ ] [Specific, testable outcome — WHAT not HOW]
- [ ] [Edge case or error condition]
- [ ] Given [precondition], when [action], then [verifiable result]
## Verification
```bash
[exact commands that prove completion]
```
## Out of scope
- [Explicit exclusion to prevent scope creep]
- [Constraint: Must NOT modify X]
Checklist AC is the default — each item maps to a testable assertion. Use Given/When/Then only for complex behavioral scenarios with multiple preconditions. Acceptance criteria scale with size: target 3–7 per story, but LARGE and XL stories may exceed 3–7 with criteria grouped under sub-headings — a long AC list is only a splitting signal when the criteria describe unrelated topics.
For TRIVIAL/SMALL stories, use the lightweight template in references/story-template-lightweight.md.
Apply type-specific variations from references/story-template.md (Bug Fix → Bug section, Spike → Research questions, Refactoring → Constraints, Performance → Metrics).
If docs/context/personas.md was loaded, link each story to persona(s):
Personas: field in the story's Context section (e.g., P1 (Marcus — Power User), P3 (Admin))Personas: internalSkip when: docs/context/personas.md doesn't exist or contains only template placeholders.
For each story, check if the required skills exist:
.claude/skills/SKILLS_INVENTORY.mdIf PRD Section 6 (NFRs) exists and contains measurable thresholds, generate dedicated stories for each NFR not already covered in the backlog:
These stories ensure NFRs become tracked, tested work items rather than implicit expectations.
For stories touching authentication, authorization, user data handling, API endpoints, file uploads, or session management, auto-append security acceptance criteria using Given/When/Then format:
# Injection defense (for any story handling user input)
- [ ] Given a user submits input containing SQL/XSS/command injection payload, When the input is processed, Then the system rejects or sanitizes the input and returns a generic error
# Auth enforcement (for any story adding/modifying endpoints)
- [ ] Given an unauthenticated request to a protected endpoint, When the request is processed, Then the system returns 401/403 and logs the attempt
# Input validation (for any story accepting user data)
- [ ] Given input exceeding expected size/type/format constraints, When submitted, Then the system rejects with a clear validation error
Select 1-2 criteria relevant to the story type — not all three for every story. These are in addition to the story's functional acceptance criteria.
Evil user stories (for stories explicitly about security features): Generate an attacker-perspective story variant:
If vision/external-dependencies.md exists (generated by /discover), read it and generate an Infrastructure setup story for each external service listed.
Each setup story:
infra with clear setup instructions in the bodySMALL (most setups take 15-30 min).env (or project secrets), connectivity verified with a smoke testIf vision/external-dependencies.md doesn't exist, scan docs/reference/DECISION_LOG.md for dimension decisions (D05-D10) that selected external services — any service requiring an account, API keys, or external infrastructure. Generate setup stories for each external service found, using the same pattern above.
Organize stories in a logical order that enables incremental testing:
Key principle: Each story should be independently verifiable. Tests from earlier stories should keep passing as later stories are delivered.
If the idea involves multiple stories:
Present the decomposed stories to the user:
### Backlog: <Idea Title>
**Stories:** [count] | **Sizes:** [X TRIVIAL, Y SMALL, Z STANDARD]
#### Story Order (dependency-resolved):
| # | ID | Title | Type | Size | Priority | Depends On |
|---|-----|-------|------|------|----------|------------|
| 1 | PROJ-001 | [Title] | feature | SMALL | P0 | None |
| 2 | PROJ-002 | [Title] | feature | STANDARD | P1 | PROJ-001 |
#### Detailed Stories:
[Full story definitions using the template structure above]
#### Dependency Graph:
[Simple ASCII or description of dependencies]
Before presenting stories, validate each against the Definition of Ready checklist (from references/story-template.md):
Stories passing all criteria → status: ready. Stories missing criteria → status: draft with a note listing what's missing.
Before presenting for approval, dispatch a fresh sub-agent to test the story decomposition from a reader's perspective:
Review findings. Fix genuine gaps in the stories before presenting to user.
Ask user for approval before writing to backlog files.
After user approval:
Use the epic template from docs/reference/backlog/_EPIC_TEMPLATE.md. Each epic file has:
id, title, status, priority, target- [ ] ID — Title (Priority, Status)references/story-template.md Embedded Format section)docs/reference/backlog/docs/reference/BACKLOG_INDEX.md:
echo "{\"type\":\"story\",\"event\":\"created\",\"id\":\"<id>\",\"story_type\":\"<type>\",\"size\":\"<size>\",\"priority\":\"<priority>\",\"status\":\"<ready|draft>\",\"ts\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"}" >> docs/sessions/.activity-log.jsonl
echo "{\"type\":\"skill\",\"event\":\"end\",\"skill\":\"ideate\",\"outcome\":\"success\",\"ts\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"}" >> docs/sessions/.activity-log.jsonl
Input: /ideate "user authentication with email/password"
Output: 5 stories decomposed:
S01: Testing infrastructure (fixtures, test helpers) [Testing]
S02: User model + migration [Feature]
S03: Registration endpoint with validation [Feature]
S04: Login endpoint with JWT tokens [Feature]
S05: Auth middleware for protected routes [Feature]
Dependency graph: S01 → S02 → S03/S04 → S05
Next Steps:
→ /sprint-start — create a sprint branch to start implementing
→ /story-cycle "S01: Testing infrastructure" — deliver the first story
docs/reference/CODING_STANDARDS.mddocs/reference/TESTING_STRATEGY.mddocs/architecture/ARCHITECTURE.mddocs/reference/GROUND_RULES.md (if exists) — no story should require a MUST violation