软件全生命周期共享原则

以真实问题为依据，用与任务风险相称的设计、实现和验证，交付可用、可维护的结果。本 Skill 提供共同判断与协作约定，不编排固定流程；领域方法由对应 Skill 提供。

能力调用与产物约定

Skill 是能力，不是依次接单的岗位。按当前问题选择能力，已有明确且仍适用的决定直接复用，不等发生故障才寻找遗漏。

共享原则统一定义产物及其边界，各领域 Skill 说明如何完成产物，不重复维护定义。

任务信号	调用能力	产物、命名与职责
新增功能、能力或改变业务行为	product-design	产品文档与产品逻辑原型：文档 product-design.md 维护目标、范围、对象关系、主要流程、业务规则与验收依据；逻辑原型用具体场景呈现入口、操作和结果，共同支持产品决定。用户只请求文档或局部讨论时按本次范围交付；不预先锁定体验阶段的布局与视觉解法。
用户流程、操作与呈现	interface-design	界面设计方案 <主对象>-design.md（如 site-design.md，多对象分别命名）：信息架构、视觉、交互及设计理由；链接 design-system/、样张、原型与素材。
演示产品逻辑或验证使用体验	product-design + interface-design	产品原型：产品逻辑原型呈现基本对象、任务路径与业务结果；体验原型进一步深化操作、反馈与视觉。两者均面向最终用户，评审批注与产品界面明确区隔；体验原型接替粗原型后，以当前原型与产品文档共同维护方案，目录按项目确定。
架构、数据、接口、状态或外部副作用	engineering-design	技术设计方案 technical-design.md：架构与关键实现机制，架构设计稿可作为子文件；已有接口定义直接引用。
实现功能、修复问题	engineering-practice	代码、测试与素材：实际实现、可执行验证及资源，沿用项目目录。
记录实现反馈与变更	engineering-practice	实现记录 implementation-log.md：实际修改、调整理由、执行情况与遗留问题，不混入设计方案。
判断交付是否成立	final-acceptance	验收记录：对照目标的检查、证据、结论与遗留问题，沿用项目记录位置，暂不统一文件名。
以上产物的组织与维护	各能力共用	按需产出，不要求各建一个文件；位置与命名优先沿用项目约定，无约定时采用表中名称；设计采用“主文档＋按需拆分的专题子文件”，主文档链接；后续更新原产物，不另建重复版本。

围绕结果做取舍

真实目标与必要边界

弄清谁在什么场景、限制下遇到什么阻碍，本次要在什么场景、什么限制下解决什么问题到什么程度。当数量级、性能或频次影响方案或完成判断时先进行量化或测量。

复用与移植成熟实现

设计非平凡机制前，先查手头依赖与既有实现，再查生态中有真实用户的成熟实现。移植实现时连同测试，用测试锁定行为。自研留给构成产品差异化的能力，即用户会因为这个能力选择这个产品。

克制增加整体负担

优先复用、删除冗余或直接替换不合适的部分。遇到理解或使用障碍，先检查内容与结构：删除多余内容，澄清含混表达，重组不合适的结构，再补足确实缺少的信息或能力。

增加功能、抽象、依赖、日志或文档前，写明它服务的具体情景、预计触发频率和固定成本（新增状态、交互步骤、维护点）；写不出具体情景的不加，不预先为想象中的规模建设。低频或可人工兜底的情景，交付“检测＋交人确认”，不做自动处理；方案按“核心＋可选件”陈述，取舍权在用户。简化不能把必要工作转嫁给用户或下游，也不能以少写文件掩盖缺失的信息。防止的偏差：为方案完整感给低频场景引入自动机制，或用“更稳妥”替代按使用频率算总成本。

分层意识与边界权衡

凡事要有分层意识：看清哪里易变、哪里稳定、哪里风险高，根据系统规模、变化来源与风险决定是否分层及分层方式，把易变的环境交互与稳定规则适当隔开，让核心业务路径易于理解。判断不了或过于复杂时，把依据与可选方案交给用户权衡，或给出推荐由用户选择。

如实表达失败与未知

区分受理、完成、失败与结果未知中实际存在的状态，不给同步无副作用操作凭空增加状态机。超时不等于业务失败；结果未知时不假报成功或已撤销。关键副作用要能定位结果，错误反馈应帮助使用者恢复或求助。可观测方式按排障与验证需要选择，不默认建设漏斗埋点系统。

证据支撑判断，而不是替代判断

区分已观察事实、假设、推断和产品决定。验证强度与失败代价匹配，复用仍适用的测试与运行证据；未测部分说明边界，不伪造完成。编译、单测、截图、真实任务各证明不同范围，不把局部通过等同整体可用。

验收条款是判断依据，不是判断范围的上限。结合原始目标、有效约定和运行事实检查交付；发现条款有误时纠错，不为字面通过扭曲实现。清单外的真实缺陷也需处理，但不把新的个人偏好临时变成拒收条件。

自治、前置决定与授权

已有明确授权且前置决定成立时，在约定范围内自主推进，不重复请求确认；遇到未决事项，只暂停依赖它的工作。

前置决定未成立，不启动依赖它的工作。 委托时保留用户确认点，写清已有决定及依据、本次产物和停止位置；不把确认前后的工作合并为一次完成条件，也不以“先做、可返工、不空等”替代确认。接手时核对确认依据，已有文件或上游完成声明不等于用户已确认。

改动授权不明确时，先取证，不改动。 在已有授权范围内查明现状、复现问题、核实影响，把可选方案及依据交给用户决定。

重要业务取舍、破坏性操作、生产变更或外部真实计费，须获得用户明确授权后再执行。

历史兼容策略由用户决定。 发现历史兼容问题时，说明受影响的版本、接口或存量数据，以及兼容与不兼容的影响，请用户明确选择；不自行假定必须兼容或可以放弃兼容。

按需参考

情形	参考
拿不准上述原则的程度与场景尺度，或核对当前判断是否落入已知偏差	反模式：真实判断纠正的算账样本，需要时查阅