ワンクリックでManusで任意のスキルを実行

pulseengine-feature-loop

スター0

フォーク0

更新日2026年6月11日 05:34

This skill should be used when doing a feature end-to-end on a PulseEngine project (rivet, spar, witness, sigil, meld, loom, synth, wohl, kiln) — including "implement a feature", "add a new requirement", "extend the architecture", "write a new pass", "ship a feature end-to-end", "do this properly with traceability", "model-driven implementation", or any feature work that should pass through the full AADL → WIT → typed traceability → oracle-gated code → MC/DC → attestation → verify loop. ALWAYS use this skill when the user authorizes feature work on a PulseEngine project and the work touches more than a single file.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

pulseengine

pulseengine/pulseengine.eu

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

関連職種SOC

SOC 職業分類に基づく

ソフトウェア開発者コンピュータ・数学職·SOC 15-1252

SKILL.md

readonly

このリポジトリの他の Skills

同じリポジトリ

oracle-gate-a-change

pulseengine/pulseengine.eu

This skill should be used whenever proposing, designing, landing, or evaluating a consequential change on a PulseEngine project (rivet, spar, witness, sigil, meld, loom, synth, wohl) — including "propose a change", "add a feature", "fix a bug", "is this safe to land", "what verifies this", "what's the gate", "how do we know this is correct", "before merging this", or whenever a code change needs a mechanical check to back it. ALWAYS use this skill before claiming a property holds and before recommending a change be merged.

2026-07-100

release-execution

pulseengine/pulseengine.eu

This skill should be used when cutting, shipping, or finishing a release — including "ship it", "cut a release", "tag this", "release v0.X.Y", "take this to release", "work the PR queue to green", "finish the release tail", "publish", or any end-to-end release work that involves PRs, reviewers, merging, CI, tagging, GitHub Release, and crates.io publish. ALWAYS use this skill when the user authorizes autonomous release work or asks to "go as long as you can" on a release campaign.

2026-07-100

proof-synthesis

pulseengine/pulseengine.eu

This skill should be used when writing, repairing, or strengthening a machine-checked proof, spec, contract, or invariant in ANY PulseEngine verification backend — Verus (SMT/Z3), Rocq/Coq, Lean 4, Dafny, Kani (bounded model checking), or scry (sound abstract interpretation) — and whenever a proof obligation, assertion, or verification job is failing and needs an iterative generate→verify→refine loop. Backend-agnostic by design: the verifier's own output is the oracle, never an LLM's opinion. Fires across gale, scry, the rules_* proof toolchains, and any repo that carries proofs. Use it for the production of proofs; pair it with oracle-gate-a-change (the verifier is the gate) and stpa-audit/feature-loop (which say *what* must be proven).

2026-07-080

claim-verification

pulseengine/pulseengine.eu

This skill should be used whenever writing or editing a README, a badge, a project description, a blog claim, an honesty ledger, a dossier, or ANY document that asserts what the system does, is, or proves — especially verification claims ("formally verified", "proven", "sound", "verified N/N", trusted-base counts). It treats a document's load-bearing claims as requirements that must stay true over time: mark the assertion, bind it to checkable evidence, and gate it so drift fails the build. Use it to author an honest claim, to audit a doc whose claims may have drifted from reality, or to stand up the claim-check gate in a repo. Composes with traceability-audit (requirements↔tests), oracle-gate-a-change (the gate), and clean-room-verification (review the claim cold).

2026-07-080

issue-hunt

pulseengine/pulseengine.eu

This skill should be used to run an incremental bug/feature hunt over a repo's issue tracker — pick up everything NEW since the last pass (new issues and new comments), digest and triage it, work the actionable items through the verification chain, and accumulate toward a feature release. Use it when the user says "hunt the issues", "do a bug/feature hunt", "look into the issues and work them", "loop through the issues", "digest the new issues and comments since last time", or wants a standing loop (via /loop or a scheduled agent) that drives the tracker toward releases. One invocation is one pass; the "since last time" watermark is what makes it a loop rather than a full re-scan. Composes with release-planning (land + ship), the feature loop, and the operating contract.

2026-06-110

report-tool-friction

pulseengine/pulseengine.eu

This skill should be used whenever a PulseEngine tool (rivet, spar, witness, sigil, meld, loom, synth, kiln, gale, scry, smithy, thrum, temper, mcp — the roster lives in the pulseengine-toolchain memory) produces friction during real work — it errors, crashes, produces wrong or surprising output, is missing a capability you needed, has confusing/undocumented behavior, or forced you into a workaround. ALWAYS use this skill the moment you notice yourself working *around* a tool instead of *with* it, or saying "this should just work but doesn't." The friction is the signal; capturing it as an issue in the tool's own repo is the action. Fires inside [`pulseengine-feature-loop`] and [`release-execution`] and any standalone tool use.

2026-06-100

name	pulseengine-feature-loop
description	This skill should be used when doing a feature end-to-end on a PulseEngine project (rivet, spar, witness, sigil, meld, loom, synth, wohl, kiln) — including "implement a feature", "add a new requirement", "extend the architecture", "write a new pass", "ship a feature end-to-end", "do this properly with traceability", "model-driven implementation", or any feature work that should pass through the full AADL → WIT → typed traceability → oracle-gated code → MC/DC → attestation → verify loop. ALWAYS use this skill when the user authorizes feature work on a PulseEngine project and the work touches more than a single file.
metadata	{"author":"pulseengine.eu","version":"0.1.0"}

PulseEngine feature loop

When this fires

End-to-end feature work on a PulseEngine project where the methodology actually composes: spar (AADL architecture) → rivet (typed traceability) → code (agent-written, oracle-gated) → witness (MC/DC on Wasm) → sigil (signed attestation) → smithy (clean-room verify). This is the "MBSE is mandatory infrastructure for AI-authored safety code" claim made concrete.

Use this when the feature touches more than one layer of the stack. Single-file refactors don't need the full loop; reach for [oracle-gate-a-change] alone.

Standing practice across every step

Friction is data. At any step below, if a tool errors, produces wrong output, lacks a capability you needed, or forces a workaround, file it via [report-tool-friction] in that tool's repo as you hit it — then continue. A workaround you don't report is friction the next feature re-hits. This is woven through the whole loop, not a phase of it.

This is a long-running explorer (see [pulseengine-operating-contract]): self-verify at a concrete interval — before every tag, and at least every ~2 features/releases in a round (not "at some point") — with fresh-context subagents ([clean-room-verification]) — re-checking both the work (against requirements/architecture) and the campaign machinery (is the merge gate actually non-empty? is everything claimed "released" really tagged with a success CI run, not cancelled? — the campaign invariants in the operating contract). Across a multi-feature round the machinery failures are the ones per-feature review misses.

The compose loop (ordered steps, each producing a concrete artifact)

1. Start in spar — model the architecture

If the feature changes architecture (new component, new mode, new interaction, new resource sharing):

Edit / create the AADL model in spar's .aadl files.
Run the relevant spar analysis passes:
- EMV2 fault trees if it touches safety.
- ARINC 653 partitioning if it's an avionics-style isolation question.
- ASIL decomposition if it's automotive.
- Modal-filtered scheduling + piecewise-affine TSN arrival curves if it touches timing.
Confirm the analysis passes are green for the new model.
Artifact: updated .aadl files + spar analysis output.

2. Generate WIT from spar

WIT interfaces are derived from AADL via spar, never hand-written. From wohl/spar-generates-wit.md.

Run the spar → WIT generator.
The new WIT lands in the consumers (wohl, witness, etc.).
Artifact: updated .wit files. Their diff against main is a function of the AADL change, not a manual edit.

3. Write typed requirements / decisions / tests in rivet

For each new property the feature claims:

Add a requirement / decision / test artifact in the project's rivet directories.
Use the appropriate schema (STPA, ASPICE, IEC 61508, DO-178C, EN 50128, EU AI Act, or custom).
Link via rivet's typed predicates: verifies, implements, traced-by.
Run rivet validate and rivet check — both must be green.
Artifact: new YAML in requirements/, decisions/, tests/. rivet coverage should show the trace topology now covering the new property.

4. Write the code, oracle-gated per change

Per [oracle-gate-a-change]:

Identify the mechanical oracle for each property the code claims (rivet check / Kani / Verus / fuzz / witness gap / sigil verify / nm symbol check).
Write missing oracles first.
Land code that flips the oracle from red to green.
Each PR passes through oracle-gate-a-change.
Artifact: code diff + a now-green oracle traceable to the rivet requirement.

5. Witness — MC/DC truth table on the Wasm artifact

If the feature lands a new branch / decision / variant:

Run witness on the relevant Wasm component.
Inspect the truth table (not the coverage percentage) — confirm masking / unique-cause vectors exist for each new condition.
If gaps appear, witness-viz suggests test stubs — add them, rerun.
Artifact: truth table file under witness-out/ (or similar) showing zero unresolved gap rows.

6. Sigil — sign the attestation chain

If the feature lands a new build artifact or a new build-stage:

Run sigil to sign the relevant outputs.
Confirm the verification chain end-to-end: detached verifier accepts the signed artifact.
Artifact: signed component manifest, verifiable detached.

Recurring N/A is a backlog item, not an exemption. Steps 5 and 6 are conditional ("if the feature lands…"), which makes them easy to wave off. If you mark either one N/A for the same reason three features running, file it (an issue / [report-tool-friction]) — that pattern is exactly how a real-flight MC/DC gap and a missing attestation chain stayed hidden across ~20 features.

7. Clean-room verify the whole loop

Per [clean-room-verification]:

Write the feature's claims as discrete falsifiable claims.
Spawn smithy (or equivalent subagent) cold — no inherited framing.
Reconcile.

8. Land via release-execution

When the feature is green end-to-end, ship it via [release-execution]. Its traceability completeness gate is where this loop gets audited at release time: every approved/implemented artifact must have the full V closed — requirement → architecture → implementation, and up the right side (tests via verifies, witness MC/DC with zero gap rows, sigil attestation). If a step here was skipped, that gate is where it surfaces as a blocker. Include the falsification statement for the new behavior in the release notes.

Own the merge-wait — don't delegate and assume. The merge must block on the required gate: a PR that landed in seconds didn't wait for CI, and a tag on that commit is not verified. Confirm the merge actually waited (HEAD run completed/success, not cancelled by a merge-train and not skipped on an empty gate) before treating the feature as shipped. This is the same assert release-execution makes — the loop doesn't get to skip it just because it handed the merge off. (Restated inline for execution-time reachability — the deliberate redundancy exception to single-source; see [pulseengine-operating-contract] → "Single-source by default". Keep in sync; don't drift-sweep it away.)

What "MBSE is mandatory infrastructure" means here

This loop is not optional ritual. It's the cheap version of safety-critical engineering — agent-minutes replace half-a-day-per-requirement, the model drives the build instead of sitting alongside it, and the alternative (untraceable AI-authored code) is unshippable in regulated domains.

The loop's cost is now in tooling, not labor. Skipping a step skips the corresponding evidence; assessor confidence is the metric, not throughput.

Anti-patterns

Hand-writing WIT files. Spar generates them; if WIT changes, the AADL changed first.
Writing code before the rivet typed artifacts exist. The traceability must lead, not follow.
Trusting witness coverage percentages. Read the gap rows in the truth table. From witness-the-truth-table-not-the-percentage and witness-wasm-mcdc.
Skipping sigil "because internal." If the artifact ever leaves your machine — including to CI — the attestation chain is the gate that lets others trust what you built.
Inlining clean-room verification or oracle-gating instead of pointing at those skills. Duplication is the failure mode this whole stack is designed to avoid.
Working around a tool silently. If you hand-edit generated WIT, || true a failing check, or do a step outside the tool "for now," that's friction — file it via [report-tool-friction]. Unreported workarounds are how the tools stop improving.
Calling the feature "done" before all eight steps have a green artifact.

Where this composes

Sits at the top of the composition tree. Calls [oracle-gate-a-change] per change. Calls [clean-room-verification] for the verify step. [report-tool-friction] runs as a standing practice across every step. Hands off to [release-execution] when green — whose traceability completeness gate audits the artifacts this loop produced.