菜单
Create Issue Flow Decision and Visual Plan JSON artifacts with separated lifecycle stages, architecture and runtime models, reviewable structured facts, and plan-kit validation.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/LianjiaTech/bella-knowledge --skill vision-plan命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | vision-plan |
| description | Create Issue Flow Decision and Visual Plan JSON artifacts with separated lifecycle stages, architecture and runtime models, reviewable structured facts, and plan-kit validation. |
Use this skill to create or update Issue Flow review artifacts:
.issue-flow/issues/{issue-slug}/decision/data/decision.json.isv for a pre-plan decision review when the requirement has contradictions, ambiguous scope, or user choices that must be answered before a plan is generated..issue-flow/issues/{issue-slug}/plan/data/plan.json.isv for a visual implementation plan.For newly authored visual artifacts, the .isv suffix is the Preview discovery contract regardless of file name or directory. Legacy Markdown and fixed-name JSON previews remain supported for compatibility. Keep the JSON artifact field as decision or plan so the Engine selects the correct review experience without changing the Visual Engine Schema.
The JSON is the semantic source of a review surface, not a document dump. It should help the user understand the proposal faster and help an implementation agent execute it correctly. Issue Flow Engine renders the JSON with fixed components, layout, styles, diagrams, review anchors, comments, and approval controls.
This skill is active only when the source issue has feature:visual-plan:on. Without that label, Issue Flow uses the Markdown Plan workflow and this skill must not replace it.
Before writing artifact JSON, read references/engine-json-contract.md. It is the complete Engine type manual and defines every supported section, field, alias, review path, and validation rule. Do not invent component types or fields outside that contract.
Start each artifact from its source data.
visual-brief.mddecision/data/decision.json.isv.Separate source of truth from presentation.
plan/data/plan.json.isv.decision/data/decision.json.isv.decision.html, plan/index.html, artifact CSS, artifact JavaScript, SVG, or copied rendering assets. The only exception is one or more self-contained Demo HTML files explicitly referenced by custom-html Plan sections.Keep the decision gate and implementation plan as separate lifecycle stages.
issue-flow pr submit plan --artifact decision; publishing keeps the Plan branch/MR open and sets flow::clarify.issue-flow pr submit plan --artifact plan; it updates the same Plan branch/MR and sets flow::approve.decision/ directory before committing. The Plan commit and eventual merge must not retain the superseded Decision artifact.Use diagrams instead of prose when structure is the point.
Keep language shallow and obvious.
Use a custom-html Plan section when reviewers need to understand the proposed frontend as a real, operable page rather than a structural sketch. When the product is page-centric and includes multiple user interactions or responsive requirements, the Plan should include an interactive Demo.
.html file in the same directory as plan.json.isv.file field; never place HTML, CSS, or JavaScript inside JSON.wireframe when static information architecture is sufficient or the page is only a small supporting part of the task.custom-html when the page itself is the product surface and reviewers need to exercise several actions, state changes, feedback paths, or responsive layouts before implementation.The temporary visual-brief.md must include these fixed field names because plan-kit/check.mjs verifies them:
- **Core outcome**: What will be built, in one direct sentence?
- **Main contradiction**: What is the real tension or risk?
- **Primary visual model**: What is the main diagram/view?
- **Model justification**: Why this model reveals the risk better than prose?
- **Supporting views**: What secondary diagrams/tables close gaps?
- **Interaction model**: Static, path toggle, stepper, tabs, or none.
- **Must show / must avoid**: What must be visible, and what should not be included?
Use architecture models as a selection guide, not as labels to show the user.
| Review question | Use this view | When to choose it |
|---|---|---|
| What is inside this system, and what is outside? | System boundary diagram | Users, third-party services, external APIs, payments, storage, or trust boundaries matter. |
| Which services/apps/stores own the behavior? | Service/data-store architecture diagram | Most backend/platform plans need this first. It shows applications, data stores, responsibilities, and communication. |
| Which modules inside one service own business rules? | Internal responsibility diagram | Use only when module ownership affects the implementation or refactor risk. |
| What happens at runtime for this scenario? | Runtime flow / sequence / dynamic diagram | Use for callbacks, retries, queues, worker handoff, agent loops, and multi-step workflows. |
| What states can this object move through? | State machine / lifecycle diagram | Use for refunds, jobs, tasks, approvals, sync, retries, and failure recovery. |
| Where does data originate, transform, and persist? | Data flow / provenance diagram | Use for forms, extraction, agent outputs, imports, audit trails, and generated content. |
| Who owns each action across roles or systems? | Responsibility lane diagram | Use when humans, agents, services, or workers share a workflow. |
| Which paths are allowed, denied, blocked, or partial? | Path matrix | Use for permissions, policy, validation gates, fallback paths, and risk coverage. |
| What proves this plan works? | Validation matrix | Use in every plan. Each risk or invariant should have at least one validation row. |
For many software tasks, the right structure is:
Decision JSON describes a decision form, not a preface to the Plan and not a workflow report.
Include only:
If removing a field would not change the reviewer's choice, remove it. If there is no unresolved choice after repository inspection, do not generate Decision JSON; generate the Plan directly.
Use a selectable choice only when the reviewer must choose between materially different paths. Use an approval item only for a real yes/no confirmation. Criteria, evidence, consequences, and explanation support the decision; they are not separate approvals.
Order sections[] so the rendered Plan follows this reading order:
Keep simple tasks simple. If a bug fix has one part and one state change, use one small architecture sketch plus a path matrix; do not build a large framework diagram.
The Engine provides the artifact table of contents and continuous document layout. Give every major section a concise title and keep the JSON section order readable from top to bottom.
After selecting the review models, use the Engine manual to encode them as artifact JSON.
custom-html Demo exception.Run the checker exactly as documented in the Engine manual before committing and publishing. Fix every failure. Treat warnings as real review risks unless there is a clear reason.