القائمة
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.