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/re...
Scanned 9/3/2026
Install to Claude Code
npx -y skills add BulloRosso/etienne --skill design-support --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Design Support?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/bullorosso-design-support-etienne)More formats (shields.io, HTML) on the badges page.
---
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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!