Help us improve
Share bugs, ideas, or general feedback.
From dpf-platform
Maps architectural options to principle dimensions, invokes principle_decide MCP tool, surfaces contribution ledger, defers on conflict. Use for open questions with 2+ distinct options in DPF codebase.
npx claudepluginhub opendigitalproductfactory/opendigitalproductfactory --plugin dpf-platformHow this skill is triggered — by the user, by Claude, or both
Slash command
/dpf-platform:dpf-decision-via-kernelThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
When you face an open question with 2+ architecturally-distinct options inside the DPF codebase, **do not pick by gut**. Map each option to the closed `PRINCIPLE_DIMENSIONS` registry, call the `principle_decide` MCP tool, and surface the contribution ledger to the operator. This is "What Would Mark Do" (WWMD) as a tool, not a guess — and it sits in front of `superpowers:brainstorming` whenever ...
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Explores codebases via GitNexus: discover repos, query execution flows, trace processes, inspect symbol callers/callees, and review architecture.
Share bugs, ideas, or general feedback.
When you face an open question with 2+ architecturally-distinct options inside the DPF codebase, do not pick by gut. Map each option to the closed PRINCIPLE_DIMENSIONS registry, call the principle_decide MCP tool, and surface the contribution ledger to the operator. This is "What Would Mark Do" (WWMD) as a tool, not a guess — and it sits in front of superpowers:brainstorming whenever the brainstorm produces multiple viable options.
superpowers:brainstorming produced 2-3 candidate approaches.superpowers:brainstorming), then return here.| Source | Path | What to extract |
|---|---|---|
| Dimension registry | packages/db/src/wiki-taxonomy.ts | The closed PRINCIPLE_DIMENSIONS list — every key in your feature vector must be in this list |
| Relevant principles | docs/founder-kernel/wiki/principles/ | The kernel rules that govern this decision class (also queryable via mcp__dpf__wiki_query filtered on pageKind='principle') |
| Context | The spec or design under deliberation | The actual question and what makes the options distinct |
kernel/principles/structural-verification-is-not-functional — don't claim a decision is sound because the spec compiles; verify it survives kernel scrutiny.kernel/principles/architecture-over-shortcuts — the kernel weights long-term maintainability highly; quick fixes consistently lose.kernel/principles/research-before-implementing — kernel consultation IS the research step for decisions where principles apply.Enumerate the options. 2-4 options is the sweet spot; more than 4 dilutes the weighing. Each option needs a clear id (short slug) and a description (1-2 sentences naming what makes it distinct).
Map each option to PRINCIPLE_DIMENSIONS. Read the closed list and pick the 3-5 dimensions most relevant to the decision class. Score each option on each dimension from 0.0 to 1.0 — how strongly does this option deliver on this axis?
features: {} and let the server-side semantic fallback fire (wired by BI-3C1A6451 on 2026-05-24 — it embeds your option description and the principle direction text). The fallback is weaker but non-degenerate.Invoke principle_decide.
mcp__dpf__principle_decide({
context: "<one-sentence framing of the question>",
options: [
{ id: "<slug>", description: "<distinctive text>", features: { <dim>: 0..1, ... } },
{ id: "<slug>", description: "<distinctive text>", features: { <dim>: 0..1, ... } }
],
callingPopulation: "in_platform_coworker" | "external_coding_agent" | "human",
ringScope: [ "<one of PRINCIPLE_RING_SCOPES>" ] // optional, defaults to universal
})
Read the contribution ledger. The result contains scores (per-option composite + per-principle contribution rows), flags (tie-margin confidence, semantic-fallback ratio, commandment-conflict signal), and reasoning (one-sentence human-readable summary).
Surface the ledger, not just the answer. When reporting back to the operator, show: the chosen option, the top 2 contributing principles (positive and negative), and any flag that fired. The operator's role is to ratify (or override) the math, which requires seeing it.
**Kernel consultation result.**
- Question: <one sentence>
- Options considered: <id1>, <id2>, [<id3>]
- Recommendation: <winning id> (composite <score>, margin <margin>, confidence <high|low>)
- Top positive contributors: <principle name 1> (+<contribution>), <principle name 2> (+<contribution>)
- Top negative contributors: <principle name> (<contribution>) (if any)
- Flags: <commandment conflict / weak coverage / none>
- Recommended next step: <proceed | surface to operator | reframe options | defer>
If the kernel flips a default the agent had pre-decided, say so explicitly — that's the signal the consultation added value.
principle_decide with options you haven't enumerated. "Should we do X?" with no alternative is a no-op — the kernel needs 2+ options to weigh.description. Pre-BI-3C1A6451 this produced silent all-zero alignment; post-fix the semantic fallback uses the description. An option with neither is a bug — return to step 1.The Build Studio design-time decomposition spec ended with 7 open questions. The agent invoked this skill against question 4: "Should FeatureBuild rows be created eagerly at decomposition time, or lazily on first build dispatch?"
Options enumerated:
eager — Create all FeatureBuild rows at decomposition; metadata-only, no sandbox claim yet.lazy — Create FeatureBuild rows on first build dispatch only; lighter DB state, more dispatch-time work.Features against PRINCIPLE_DIMENSIONS:
eager: { schema_grounding: 0.8, long_term_maintainability: 0.7, blast_radius: 0.3, speed_to_value: 0.6 }lazy: { schema_grounding: 0.4, long_term_maintainability: 0.4, blast_radius: 0.6, speed_to_value: 0.7 }principle_decide returned:
eager (composite 0.62, margin 0.18, confidence high)lazy on speed-to-value reasoning). The contribution ledger showed Architecture Over Shortcuts pulled hard enough to flip the decision — a finding the operator confirmed.The lesson: without the consultation, the agent would have shipped the lazy approach and incurred the maintainability cost later. This skill exists so that flip happens consistently, not by luck.
mcp__dpf__principle_decide (principles-as-wiki-kind Phase 2 Task 2.7)apps/web/lib/wiki/principle-decide.tspackages/db/src/wiki-taxonomy.ts PRINCIPLE_DIMENSIONSdocs/superpowers/specs/2026-05-24-build-studio-design-time-decomposition-design.md