Menu
Create shared technical vision for team alignment
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
One-command project setup for OpenUP - interactive initialization wizard
Mark a task as complete, update roadmap, commit changes, and prepare traceability logs
Execute an already-claimed lane's Operations boxes with script/judgment classification — script steps run directly with zero self-brief, judgment steps self-brief and execute. Handles only pick/resume; every other resolve path routes to /openup-next.
Run OpenUP Assess Results at iteration end — check evaluation criteria, demo only completed acceptance-tested work, feed discovered work back, and trigger the milestone review at a phase boundary
Run the phase milestone go/no-go — prepare derived evidence, pause for the human decision via an input-request, and record the milestone (never advance the phase itself)
Begin a new OpenUP iteration with proper phase context and task selection
| name | openup-shared-vision |
| description | Create shared technical vision for team alignment |
| model | sonnet |
| arguments | [{"name":"technical_objectives","description":"Key technical objectives to address (comma-separated)","required":false},{"name":"scope_focus","description":"Focus area for IN/OUT scope definition","required":false}] |
This skill creates a shared technical vision document that ensures alignment between stakeholders and the development team on technical objectives, scope, and key decisions.
Use this skill when:
Do NOT use this skill when:
/openup-create-vision first)/openup-create-architecture-notebook)After using this skill, verify:
Read docs/vision.md to understand:
From the vision and project status, identify:
Technical Objectives:
If $ARGUMENTS[technical_objectives] is provided:
Examples:
Create clear boundaries for what is included and excluded:
IN Scope: What features and capabilities are definitely included?
$ARGUMENTS[scope_focus] as a starting point if providedOUT Scope: What is explicitly excluded to manage expectations?
Record assumptions about the technical environment:
| Assumption | Impact | Validated By |
|---|---|---|
| Example: Chosen datastore available in all environments | Low - affects data layer | Ops |
| Example: Users on up-to-date client versions | Medium - affects UI layer | UX research |
Record known constraints that limit options:
| Constraint | Description | Mitigation |
|---|---|---|
| Example: Infrastructure budget cap | Must use cost-effective solutions | Prefer managed services |
| Example: Legacy system integration | Must work with existing APIs | Adapter pattern |
Document significant technical decisions with rationale:
Examples:
For each decision:
List questions that need answers during elaboration:
| Question | Impact | Target Phase |
|---|---|---|
| Example: How to handle offline mode? | High - affects architecture | Elaboration |
| Example: Third-party API limits? | Medium - affects design | Elaboration |
Create docs/shared-vision.md using the shared vision template with:
Add a reference in docs/vision.md:
## Technical Vision
See [Shared Vision](shared-vision.md) for detailed technical objectives, scope, and decisions.
Apply the Self-Critique SOP (docs-eng-process/sops/self-critique.md) before
returning: take a hostile-reviewer stance, surface every load-bearing assumption
into the document, and confirm the IN/OUT scope boundaries are sharp enough to
settle a real dispute and that each key decision records what it trades away.
List every weakness you find — including ones you are uncertain about — then fix
or explicitly flag each one. Rank them and record the top one or two with their
resolutions.
Returns a summary of:
docs/shared-vision.md/openup-shared-vision technical_objectives: "scalability, security" scope_focus: "user authentication"
| Error | Cause | Solution |
|---|---|---|
| Vision not found | docs/vision.md doesn't exist | Create vision first with /openup-create-vision |
| Too vague | Objectives not specific enough | Add measurable criteria |
| Missing OUT scope | Only IN scope defined | Always define both IN and OUT |
| No rationale | Decisions without justification | Add why and alternatives considered |
docs-eng-process/templates/shared-vision.mddocs-eng-process/templates/vision.mddocs-eng-process/templates/architecture-notebook.md