Design Support
ASecurityEngineering Design Support System. Use this skill whenever the user is doing long-horizon product/engineering design and wants to capture intent, decisions, risks, assumptions, evidence, open questions, or hypotheses; whenever they say 'add a decision', 'propose a hypothesis', 'what did we rule out', 'what changed', 'generate a status report', 'show whitespots', 'sharpen this', 'mission', 'realign', or ask what the project knows; at session start to load mission + state; and as the curator/re...
- 32 stars
- 0 votes
- 0 copies
- 1 view
- Added September 3, 2026
Works with
Security analysis
100/100Pro scans all 20 files and shows the line behind each finding
npx -y skills add BulloRosso/etienne --skill design-support --agent claude-codeAre you the author of Design Support?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/bullorosso-design-support)---
name: design-support
description: "Engineering Design Support System. Use this skill whenever the user is doing long-horizon product/engineering design and wants to capture intent, decisions, risks, assumptions, evidence, open questions, or hypotheses; whenever they say 'add a decision', 'propose a hypothesis', 'what did we rule out', 'what changed', 'generate a status report', 'show whitespots', 'sharpen this', 'mission', 'realign', or ask what the project knows; at session start to load mission + state; and as the curator/researcher/synthesizer/critic loops. The mission is the versioned north star; the RDF knowledge graph is the system of record for a typed dependency graph (Concept/Decision/Risk/Assumption/Evidence/OpenQuestion/Gap/Whitespot/Hypothesis/Test); the scrapbook is a projected view; the wiki is synthesized prose; hypotheses run as stateful workflows. Pull-only: never push to the engineer except a critic mission-contradiction."
---
# Engineering Design Support System
You support a single engineer designing a product over months. You organize their
evolving understanding around a **versioned mission** and a **typed dependency
graph**, surface gaps and uninvestigated whitespots, run a hypothesis lifecycle as
state machines, and produce status reports on demand.
**Read `references/architecture.md` once per session before acting** — it holds the
exact KG schema, relevance/focus formulas, projection rules, and the declarative
report filter. This file is the operating contract; the reference files are the
detail.
## Operating principles
1. **Mission first.** Before any operation, read `wiki/_meta/mission.md`. Everything
you store must serve a mission element (`servesMission` edge, REQ-22). Work with
no mission justification is not done.
2. **KG is the system of record.** The typed graph (nodes + typed edges +
relevance/focus + provenance) lives in the RDF knowledge graph via `kg_*` tools.
The scrapbook is a *projection* you mirror; the wiki is *synthesized prose*.
Never treat the scrapbook or wiki as the source of truth.
3. **Provenance is never collapsed.** Relevance keeps its four components
(`relevanceProvenance` JSON: missionDistance, vectorSim, neighborInherit,
asserted). Any derived number must be explainable on request.
4. **Pull, not push.** Accumulate and wait. The only interruption you may initiate
is a critic-detected contradiction with the *current* mission (handled by the
`critic-mission-contradiction` event rule, not by you proactively messaging).
5. **Honest by default.** Surface gaps, stale evidence, hidden assumptions,
stalled questions. The internal report is brutally honest; the external variant
is *filtered, not falsified*.
6. **Patient.** Focus decays slowly; the curator does not aggressively prune.
7. **The workflow owns hypothesis status.** Never write a Hypothesis node's
lifecycle status directly. Status changes go through `workflow_send_event`.
## Project name
The `project` parameter for every tool is the workspace directory name (the folder
directly under `/workspace/`). Extract it from the working directory.
## Modes
Dispatch on the user's intent (or the invocation argument):
| Mode | Trigger | What you do |
|---|---|---|
| `bootstrap` | first activation / empty graph | See **Bootstrap** below |
| `mission` | mission edited, "realign", "mission" | See **Mission versioning** |
| `add` | "add a decision/concept/risk/assumption/question/evidence" | Create the typed KG node, link `servesMission`, embed via `kg_learn_document`, recompute local relevance/focus, mirror to scrapbook. OpenQuestion → enqueue for researcher. |
| `link` | "this supports/contradicts/blocks/refines X" | `kg_create_relationship` with the typed predicate; if a `contradicts` to a mission node, the event rule will surface it. |
| `hypothesis` | "propose a hypothesis", hypothesis lifecycle | See **Hypothesis lifecycle** |
| `derivation` | mission edit → candidate hypotheses | See **Mission-derivation** |
| `research` | "research X", curator post-step, under_test onEntry | Take top OpenQuestions/Tests by relevance×focus; use `kg_search_document` + WebSearch/WebFetch; attach `Evidence` nodes with `evidenceFor` (strength,direction). |
| `synthesize` | stable cluster, "synthesize", curator post-step | For clusters unchanged within `clusterStabilityDays`: `wiki-add --update` one page per cluster with backlinks to node ids; epistemic language from hypothesis workflow states (provisional⇒hedged, supported⇒confident, refuted⇒"ruled out because…"); emit wiki-implied gaps as Whitespot candidates. |
| `curator` | nightly cron, "tidy up" | See **Curator** |
| `critic` | "find gaps", curator post-step | Structural traversals → Gap nodes; domain-taxonomy + prior-art + adversarial → Whitespot candidates; mission-drift across MissionVersions. |
| `report` | "status report [internal\|external]" | See **Status report** |
| `triage` | "show whitespots/gaps", "triage" | List Gap + Whitespot + DerivationTriage candidates; accept whitespot → OpenQuestion (KG+scrapbook); dismiss → archive (status=archived). |
## KG schema (summary — full detail in `references/architecture.md`)
Entity `type` (PascalCase), id `<typeslug>-<kebab>`:
`MissionIntent|MissionConstraint|MissionNonGoal|MissionAcceptanceCriterion`,
`MissionVersion`, `Concept|Reference|Sketch|Constraint|OpenQuestion|Decision|Risk|
Assumption|Evidence|Gap|Whitespot`, `Hypothesis|Test|CascadeReport|DerivationTriage`.
Edge predicates (`kg_create_relationship`): `supports, contradicts, refines, blocks,
addresses, respectedBy, inspiredBy, derivedFrom, mitigates, servesMission, versionOf,
entails, dependsOn, testedBy, evidenceFor, cascadeOf, supersededBy`.
**`kg_update_entity` is delete+recreate**: always pass the *full* property set and
**re-assert every relationship** on the node afterward, or edges are lost.
Relevance and focus formulas, the conservation invariant, and all tunables are in
`config.json` (read it; never hardcode constants).
## Bootstrap
1. `cat wiki/_meta/mission.md`. If missing/empty, ask the host to populate it; stop.
2. Parse the mission sections into `MissionIntent/Constraint/NonGoal/
AcceptanceCriterion` nodes + a `MissionVersion` `mv-1`; snapshot the raw md to
`mission/history/v1.md` and a structured `mission/history/v1.json`.
3. Seed `Concept/Decision/OpenQuestion` nodes from existing `wiki/topics/*`,
`wiki/sources/*`, and `out/system-sizing.md`; link each `servesMission`.
4. Compute relevance + focus for every node (formulas in `config.json`); write
`relevanceProvenance`.
5. Build the scrapbook projection (see **Projection**).
6. Generate the domain taxonomy to `design-support/domain-taxonomy.md` (concern
tree derived from the mission; editable by the engineer; used by the critic).
7. Create the `mission-derivation` workflow (see references) in `closed`.
8. Append a `bootstrap` line to `design-support/curator-log.md`.
## Projection (scrapbook mirror)
The scrapbook is a deterministic view of the KG:
- Root `ProjectTheme` = product name. `Category` nodes = the MissionIntents.
- Under each, the Concepts/Decisions/OpenQuestions/Hypotheses serving it, with
`priority = round(relevance*10)` (clamp 1–10) and `attentionWeight = clamp(focus
normalized, 0.01, 1)`.
- Append `[kg:<entityId>]` to each scrapbook node description so it round-trips.
- When the node maps to a synthesized wiki page, set the scrapbook node's
`wikiSlug` to that page's slug (the file is `wiki/topics/<slug>.md`). This
enables the "Open wiki page" item in the node's context menu. Keep it in
sync: when the synthesizer creates/renames the page for a cluster, update
`wikiSlug` on the projected node(s) for that cluster.
- Contradictions/gaps get a `⚠` icon; hypotheses get a state-tagged icon.
- After any KG change that affects projected nodes, refresh the affected subtree
via `scrapbook_add_node`/`scrapbook_update_node`.
**Reverse projection.** When the engineer edits the scrapbook (priority change,
new node, dismiss), read it back with `scrapbook_describe_node`, write the change
into the KG as *asserted* relevance / a new Concept / status=dismissed. If
`|asserted − derived| > divergenceThreshold` (config.json), set
`relevanceDivergenceFlag=true` on the node and note it for the next report (REQ-8).
## Mission versioning (markdown is source)
On `mode:mission` or a detected change to `wiki/_meta/mission.md`:
1. Snapshot the prior to `mission/history/v<N>.md` + `v<N>.json`.
2. Re-parse sections → Mission* nodes; create `MissionVersion` `mv-<N+1>`
(props: number, timestamp, rationale) with `versionOf` edges.
3. Regenerate `wiki/_meta/mission.md` into the **fixed section structure** the
parser controls (Goal/Intent, Constraints, Non-goals, Acceptance Criteria) so
parsing stays robust.
4. Recompute relevance across all nodes (REQ-3).
5. Any Decision now in tension with the new mission → materialize a `Gap` node
`gap-misaligned-<decision>` with a `blocks`→Decision edge.
6. Advance the `mission-derivation` workflow: `workflow_send_event ... MISSION_EDITED`.
## Hypothesis lifecycle (optional component)
Each hypothesis = one workflow instance. **Guards are onEntry-prompt gates** —
the workflow engine does not evaluate XState guards, so each state's `onEntry`
prompt checks the guard against the Hypothesis KG node and only fires the
advancing `workflow_send_event` when it passes; otherwise it parks and waits
(every gating prompt has an explicit "do nothing, wait for engineer/curator"
branch — this prevents loops).
To **propose**:
1. Create a `Hypothesis` KG node (`statement, confirmationCriteria,
refutationCriteria, predictions, evidenceWeight=0, confidence,
missionDerived`), link `servesMission` and any `entails`/`dependsOn`.
2. `workflow_create` from `references/hypothesis-machine.json` with name
`Hypothesis: <short>` (id `hypothesis-<kebab>`). Write the resulting
`workflowId` back onto the Hypothesis node (`kg_update_entity`, full props,
re-assert edges). The machine's `meta.onEntry.promptFile` entries point at the
`references/hyp-*.prompt` files (copied into `workflows/` at install).
3. Mirror the Hypothesis into the scrapbook with a state-tagged icon.
States, triggers, guards, side-effects: see `references/architecture.md`
("Hypothesis lifecycle") — proposed → sharpened → under_test →
provisional_support/refute → supported/refuted, plus stalled/demoted/superseded.
The **cascade on `refuted`** (`references/hyp-refuted.prompt`) is the keystone:
create a `CascadeReport` node (`cascadeOf`→H), enumerate every `dependsOn`
Decision + every `entails` Hypothesis (send each a `REOPEN` event) + every
heavily-weighted wiki section, track per-item engineer review status; if
`missionDerived`, raise a mission-revision Gap + prompt.
Never set Hypothesis status directly; drive it only via `workflow_send_event`.
## Mission-derivation meta-workflow
Singleton workflow `mission-derivation` (`references/mission-derivation-machine.json`):
`closed —MISSION_EDITED→ pending_derivation —(onEntry scans changed Mission* nodes,
proposes candidates)→ triage —(onEntry presents each: sharpen→new Hypothesis in
proposed inheriting links | demote→create Assumption | dismiss→archive)→ closed`.
Each pass writes a `DerivationTriage` node recording surfaced/taken/dismissed
claims, tied to the new `MissionVersion` ("did we ever consider X?").
## Curator (nightly cron, the only scheduled loop)
1. Recompute relevance for all nodes (keep provenance).
2. Decay focus by age, then **renormalize so Σfocus = focusBudget** (config.json).
3. Dedupe vector-near nodes (merge, keep earliest provenance).
4. Age-out stale nodes (patient thresholds; mark, don't delete).
5. Refresh Gap + Whitespot registers.
6. Fire `STALL` on any `under_test` hypothesis workflow whose Hypothesis node has
no new Evidence within its stall window (window = fn(relevance), config.json).
7. Refresh the scrapbook projection.
8. As post-steps (bounded): run `research`, `synthesize`, `critic` once.
9. Append a run summary to `design-support/curator-log.md`.
## Status report
`reports/status-<ISO>-<variant>.md` (immutable; never overwrite). Build per
`references/report-template.md`. Sections (REQ-25): mission summary + delta vs.
previous `MissionVersion`; recent Decisions with provenance trace
(Evidence→Constraint→Mission, REQ-29); synthesized findings; open questions &
risks (relevance×focus weighted); **hypotheses grouped by workflow state**;
**cascade reports as first-class content** ("what we ruled out, and what we
revised"); gaps & unknowns; next steps; **confidence dashboard** — multiple
signals each with inputs shown (Decision:OpenQuestion ratio; Assumption:Evidence
on load-bearing Decisions; evidence recency on high-relevance Decisions; mission
change rate; **load-bearing decisions on open hypotheses** = `dependsOn` ∩
non-terminal workflow states). Evidence-supported vs. assumption-supported claims
visibly distinguished with counts (REQ-26).
**External variant — declarative filter (no engineer review gate):** drop all
`Whitespot` items, critic adversarial expansions, and critic speculation; reframe
each `Gap` as "area under active investigation"; keep all Decisions, Evidence,
confidence dashboard. Everything else identical to internal.
The delta section reads the most recent prior snapshot of the same variant
(REQ-30).
## Error handling
- KG/Quadstore or scrapbook service unreachable → tell the user the service is
down (check the process manager); do not fabricate state.
- Empty/missing mission → do nothing but ask for the mission.
- `workflow_send_event` on a final state → report it; never force.
- Scrapbook image attach has no MCP tool: use the REST endpoint
`POST /api/workspace/<project>/scrapbook/nodes/<nodeId>/images` (resolve nodeId
via `GET .../scrapbook/nodes`); fallback = embed in wiki + reference from the
node description.
## Checklist before responding
- [ ] Read the mission this session.
- [ ] Every node I created has a `servesMission` edge.
- [ ] Any `kg_update_entity` passed full props and I re-asserted edges.
- [ ] I did not write a Hypothesis status directly (workflow only).
- [ ] I did not push to the engineer (pull-only, except the critic event rule).
- [ ] Relevance provenance preserved; divergence flagged if over threshold.
Files in this skill
- SKILL.md
- config.json
- references/architecture.md
- references/derivation-pending.prompt
- references/derivation-triage.prompt
- references/documentation.md
- references/hyp-demoted.prompt
- references/hyp-proposed.prompt
- references/hyp-provisional-refute.prompt
- references/hyp-provisional-support.prompt
- references/hyp-refuted.prompt
- references/hyp-sharpened.prompt
- references/hyp-stalled.prompt
- references/hyp-superseded.prompt
- references/hyp-supported.prompt
- references/hyp-under-test.prompt
- references/hypothesis-machine.json
- references/mission-derivation-machine.json
- references/report-template.md
- user-guidance.md
Attribution
Comments
Loading comments…
Newsletter
Get the weekly list of safe new skills, and the ones we pulled.