Systems Engineering

源文件边界

本页为人类读者重排 skills/systems-engineering/SKILL.md 中的关键判断，不替代可安装的完整 prompt；事实、修改权和未展示的运行说明仍属于源文件。

安装与日常使用

npx skills add lidessen/rossovia --skill systems-engineering

安装后直接向 agent 描述目标；只有在需要强制选择时才显式点名 skill 或内部 operation。

它负责的判断

Own one judgment: under the actual goal, operating conditions, failure consequences, and acceptable residual risk, how should fallible parts be related, observed, corrected, and governed so the whole behaves reliably enough to use and maintain?

Reliability here is approximate and evidence-relative. Humans, models, tools, and reviewers will make mistakes. Engineering does not make each part perfect; it makes material error observable, bounded, correctable, or explicitly accepted at a cost proportionate to consequence.

This Skill designs the system relation. It does not execute a Work Cell or Swarm, prove a model primitive, invent domain acceptance, choose every local task packet, or approve its own result. It is not a mandatory preflight and does not turn every task into a control diagram.

原则脉络

Primary: P03

Supporting: P04, P13, P15

如何工作

1. Define sufficient behavior, not perfection. State the outcome, operating range, acceptance condition, failure consequence, and tolerable residual risk. “No mistakes” is not an engineering specification. Make risk tolerance specific enough to distinguish harmless variation, recoverable failure, and unacceptable escape.

2. Model the whole path. Follow the real movement from inputs and source state through judgments, effects, verification, acceptance, and later use. Name actors and components only where their relation changes behavior. A list of Agents, tools, or workflow stages is not yet a system model.

3. Identify disturbances and failure paths. Include semantic error, stale context, omitted obligations, correlated model error, protocol failure, external change, unsafe effect, reviewer miss, false-positive burden, and resource exhaustion when relevant. Do not invent an exhaustive hazard register for a reversible low-risk task.

4. Find the principal control gap. Select the failure path whose containment or correction most changes the whole. Preserve secondary hard constraints, but do not answer every risk with more stages, more prompts, or more Cells.

5. Make the material state observable. Decide which signal can expose the failure in time to act: source-linked evidence, a deterministic check, structured status, disagreement, usage variance, production outcome, or a later practice result. A control that cannot observe its target is ceremony. Agent self-report and terminal success remain claims until their designated verification and settlement. State the semantic property that must be observed before selecting its representation. A whole-source claim must be resolved against whole-source evidence before acceptance, but this Skill does not decide which domain field or runtime protocol carries that evidence.

6. Assign authority and response. State who may observe, propose, verify, intervene, commit effects, roll back, accept residual risk, and reopen the case. Keep decision and execution authority distinct where consequence requires it. Do not make a worker or review ensemble accept its own output.

7. Choose the minimum sufficient control structure. Select only mechanisms that interrupt the named failure path:

   • prevent by improving input, context, boundaries, or task form;
   • detect through independent evidence, tests, comparison, or observation;
   • contain with limited authority, blast radius, staging, or reversible effects;
   • recover through retry, repair, rollback, reuse, or escalation; and
   • tolerate through justified redundancy or resource margin.

   Match control cost to failure consequence. A reversible documentation edit may need one meaningful check; an irreversible production or strategic decision may justify diverse independent review, repeated labor, deterministic gates, prepared recovery, and explicit human acceptance. More controls are not automatically more reliable: they can add delay, correlated error, coordination failure, and review burden. At a boundary owned by another method or runtime, specify the required control property, observable signal, authority, and failure response, then hand it off. Do not invent a terminal-tool field, domain packet, deployment threshold, sample size, time window, or organization role without source evidence and the owner’s authority.

8. Engineer independence, not vote count. Repetition helps only when the compared attempts can expose different failure modes. Identical context, model, prompt, and method may reproduce one systematic error. Vary evidence boundaries, method, role, model, verifier, or deterministic surface only where correlated failure matters. Resolve factual disagreement against sources and designated verification, never by majority alone.

9. Fit Agent nodes after the system relation is known. Use task-shaping when one required contribution must be compiled into a stable Agent unit. Use model-evaluation when its capability is unevidenced. Use a domain Skill to define semantic partitions and acceptance. The Work Cell or orchestration runtime carries prepared execution; none of them decides the whole system relation by default.

10. Budget for completion and recovery. Begin from necessary work and risk, then use work-estimation to convert it into profile-specific resources. Prefer a realistic estimate, explicit margin for important uncertainty, a high emergency ceiling only when required by the carrier, and post-run audit of expected versus actual use. Do not treat low token use as quality or a routine context ceiling as an engineering budget. Estimate variance is normally a post-run correction signal; it does not itself authorize interruption, replanning, or escalation during useful work. Add an in-run resource control only when exhaustion is a named safety or availability failure and its owner authorizes that response.

11. Close the loop in operation. Observe end-to-end outcomes, material defects caught and escaped, false-positive repair burden, recovery, latency, cost per useful result, and estimate variance. Compare with the unchanged system when claiming improvement. Revise the system model, control, or risk acceptance from what actually happened; do not merely append another rule.

Before making any control concrete, apply this authority-and-evidence gate:

Is the mechanism, threshold, duration, schema, or role fixed by source evidence
and owned here?
  yes -> specify it and cite or name the governing source
  no  -> state only the required property, mark the representation
         `[owning domain/runtime to determine]`, and route it

“Independent verification,” “staged effects,” and “recoverable rollback” may be valid system requirements while their exact implementation remains a domain or runtime decision. Unknown specificity is a discovery item, not an invitation to invent plausible numbers.

边界与完成

职责与边界

Need	Owner
Decide whether the whole is sufficiently reliable under disturbance	systems-engineering
Determine whether one Agent operation fits an evidenced execution envelope	task-shaping
Establish reusable model/provider/harness capability evidence	model-evaluation
Form domain-specific review, refactoring, cognition, or other semantic packets	owning domain Skill
Deliver authoritative context to one prepared unit	context-engineering
Estimate necessary work and convert it into time, tokens, or money	work-estimation
Run Cells, queues, retries, concurrency, and providers	Work Cell or orchestration runtime
Verify domain facts and accept residual risk or effects	designated verifier and human or host authority
Select the next bounded practice after observing operation	practice-cycle

Do not use systems-engineering as a synonym for architecture, project planning, generic rigor, or “use more reviewers.” Do not hide a domain judgment inside a control label. Do not claim end-to-end reliability from component success, schema validity, test count, reviewer count, or one clean run. Do not repair a semantic control gap by changing a generic runtime contract unless runtime evidence identifies that contract as the owner and the change is separately authorized.

完成标准

The engineering judgment is ready when it defines sufficient whole behavior, models the real effect and acceptance path, identifies the principal material failure/control gap, connects an observable signal to an authorized response and recovery, selects controls proportional to consequence, names residual risk and its acceptance owner, and states an operational observation capable of showing the design is wrong or incomplete.

For a consequential case, readiness also requires independent source-and-owner verification of newly introduced specifics. Without that verification, report a candidate. Without representative operation evidence, report a proposed system design or trial—not a reliable system.

阅读完整技能

本页有意省略 prompt 的内部装配说明。需要安装、审查或修改这个技能时，请回到 完整源文件。