소스 정보
- 저장소
- 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명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
| 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