메뉴
Create vision.md docs — problem statement, proposed solution, user experience, scope boundaries. Triggers on 'vision', 'feature vision', 'product vision', 'goals doc'.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Review recently changed code for reuse, simplification, efficiency, and consistency cleanups, then apply the fixes. Quality only — doesn't hunt for bugs. Triggers on 'simplify', 'clean this up', 'simplify this diff'.
Rigorous code review of completed implementation before committing. Use for features, refactors, and critical-path changes — not trivial changes (this is expensive).
Post-implementation checklist — docs, code quality, conventions, visual verification, issue hygiene. Triggers on 'finalize', 'ready to merge', 'preflight check', 'wrap this up', 'final review'.
Run the full pre-merge pipeline and create a PR. Triggers on 'ship', 'ship it', 'ready to ship', 'prep for PR', 'create PR', 'ready to merge'.
Spin up an isolated git worktree in its own tmux session — coding agent in one window, dev stack in another, git UI in a third — with the agent briefed and already working. Use for spinning up a worktree, starting a feature/branch/task in isolation, handing work to a fresh agent (Claude/Codex), or setting up an isolated tmux dev session.
Read, send input to, or spawn other tmux panes, windows, and sessions - including agents (Claude Code, Codex), REPLs, and TUIs running in them. Use when the user references another pane, window, or agent.
| name | feature-vision |
| description | Create vision.md docs — problem statement, proposed solution, user experience, scope boundaries. Triggers on 'vision', 'feature vision', 'product vision', 'goals doc'. |
| disable-model-invocation | true |
Structured command to help create vision documents by guiding through focused discovery phases and building each section systematically following our established feature development process.
Create a vision document following the established feature development process. First, read the feature development guide at @~/.local/share/dotfiles/ai/guides/feature-development-process.md to understand the vision document structure and approach.
Note: If the project has a local copy of the guide at @project/guides/feature-development-process.md, you may reference that instead for project-specific modifications.
IMPORTANT: Start by creating a TODO list to track the 5 phases of vision document creation. Mark the first phase as "in_progress" and others as "pending".
Our vision documents are lean and focused - typically 100-150 lines, never more than 200. They flow from general to specific:
Required sections:
What does NOT belong in vision:
Ask focused questions to understand:
ONE QUESTION AT A TIME - Wait for answers before proceeding. NO CORPORATE SPEAK - Keep language conversational and direct.
Ask about:
Use consolidated user roles at vision level:
Avoid fine-grained role distinctions - detailed role breakdown goes in requirements document.
For each consolidated role, ask ONLY:
STOP THERE. Don't ask about "current pain points" or "how success looks different" - that creates redundancy with the Problem section and belongs in requirements.
Ask about:
Key: Get detailed, concrete information about what v1 will actually deliver - this becomes the bridge to requirements.
Before generating, ruthlessly eliminate redundancy:
Then generate three documents:
1. vision.md - The lean, focused vision document:
2. future.md - Detailed future enhancements:
3. discussion-summary.md - Living discussion summary document:
Flow from General to Specific: Start with high-level problems and solutions, end with concrete scope details that bridge naturally to requirements.
Scope Section is Critical: This should be a concrete LIST of what v1 delivers. Think: bullet points of capabilities/tools/features. This bridges vision to requirements.
BUT don't include:
Separate Future Content: Create detailed future.md document for all future features. Vision should only have brief future overview.
No Corporate Speak: Write for humans first. Use clear, simple language. Avoid jargon and unnecessarily complex terminology.
User Role Consolidation: Keep user roles consolidated at vision level. Detailed role breakdowns belong in requirements.
Eliminate Redundancy (CRITICAL): We're a small team that values lean, readable documents. Every section must add NEW information. Before including a section, ask: "Does this repeat something already said?" If yes, DELETE IT.
Common redundant patterns to AVOID:
Keep It Short: Vision documents should be 100-150 lines MAX. If you're over 200 lines, you're repeating yourself or including spec/requirements-level detail.
This document should be structured to accumulate context across all feature development phases. For vision phase, create the full document structure:
Document Structure:
# Feature Name: Discussion Summary
Living document capturing technical discussions, research, decisions, and
context from all phases of feature development.
## Table of Contents
- [Vision Phase](#vision-phase)
- [Requirements Phase](#requirements-phase)
- [Spec Phase](#spec-phase)
- [Plan Phase](#plan-phase)
- [Key Decisions Log](#key-decisions-log)
- [Technical Context](#technical-context)
## Vision Phase
[Vision phase content goes here]
## Requirements Phase
*To be added during requirements phase.*
## Spec Phase
*To be added during spec phase.*
## Plan Phase
*To be added during plan phase.*
## Key Decisions Log
| # | Decision | Rationale | Phase |
|---|----------|-----------|-------|
[Decisions from vision phase]
## Technical Context
### Files Referenced
[Backend and frontend files referenced]
### Related Features
[Related feature references]
Vision Phase Content to Include:
Key Decisions Log:
Technical Context:
Purpose: This document serves as institutional memory across the entire feature lifecycle. Each phase adds its section, and the Key Decisions Log and Technical Context accumulate across all phases.