Menu
Use this skill for DSG multi-source governance work that combines UI trust upgrades, action-layer permission gates, deterministic execution, marketplace/enterprise cutover, portable SaaS architecture
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Call the externally deployed DSG QUBO Policy Optimizer API to run a deterministic QUBO/Ising policy optimization. Use when a user wants to run a real optimization against the hosted service rather than the local Kotlin engine: registering/logging in for an api_key, checking account usage, and submitting an optimization run for a regulatory domain under a budget cap. Auth is an `api_key` query parameter that must come from runtime env, never from the repo. Running a real optimization may trigger solver work and may incur cost under the service's pricing tier.
Reason about deterministic QUBO/Ising policy optimization and Z3/SMT-style formal constraint verification using the Compliance-ising-z3-Deterministic engine. Use when a user asks to optimize a policy/control selection under a budget, verify logical constraints (implication, equivalence, mutual exclusion, at-least-one, cost cap), run a what-if counterfactual on budget shifts, or produce a reproducible, hash-chained compliance decision. The underlying engine is native Kotlin (no external Z3 process); constraint checks are Z3/SMT-style, implemented deterministically.
Run a studio-style agent control layer that turns a user goal into an explainable plan, deterministic decision flow, permission verdicts, and browser-first execution after approval. Use when the user
Use this skill when creating, packaging, validating, publishing, or maintaining DSG GitHub Marketplace Actions. It turns DSG control-plane, action-layer permission gates, deterministic GO/NO-GO valida
Use this skill for DSG multi-source governance work that combines UI trust upgrades, action-layer permission gates, deterministic execution, marketplace/enterprise cutover, portable SaaS architecture
Apply the DSG ONE / ProofGate truth boundary and claim policy. Use when writing or reviewing any status, readiness, compliance, or capability statement destined for code, docs, commits, PRs, issues, comments, logs, or a response. Classifies each statement as verified fact / inference / pending / blocked / not verified, and flags forbidden readiness claims that require fresh evidence.
| name | dsg-multi-governance-orchestrator |
| version | 1.0.0 |
| author | DSG Team |
| license | MIT |
| description | Use this skill for DSG multi-source governance work that combines UI trust upgrades, action-layer permission gates, deterministic execution, marketplace/enterprise cutover, portable SaaS architecture |
This skill coordinates multi-source governance work across the DSG Control Plane — combining UI trust upgrades, deterministic gate execution, marketplace cutover, architecture documentation, and production GO/NO-GO validation into a single explainable plan.
| Trigger phrase | Task |
|---|---|
| "DSG multi" / "ผสานมัลติ" | Multi-source governance orchestration |
| "M1 cutover" / "M2 hardening" | Milestone cutover planning and validation |
| "marketplace cutover" | Enterprise marketplace launch readiness |
| "architecture page" / "DSG ONE architecture" | Architecture page generation |
| "action layer gate" | Permission gate integration across multiple services |
| "deterministic execution" | Deterministic pipeline coordination |
| "production GO/NO-GO" | Full production readiness gate |
| "Termux/Codex/Multica bootstrap" | Mobile/local agent setup |
| "5 files" / "ทำเป็นสกิว" | Multi-file governance deliverable |
| "launch readiness" | M1/M2 launch checklist and validation |
Required green gates before M1 GO:
GET /api/health → { ok: true }GET /api/readiness → { ok: true, db: true }GET /api/agent/status → correct commit + environmentPOST /api/dsg/v1/gates/evaluate → PASS with proof hashnpm run go:no-go <production-url> → PASSDefault posture: NO-GO until all gates above are green with current evidence.
Additional gates for M2:
npm run ccvs:pipeline)npm run test:secrets or gitleaks CI)When the user says "plan the governance for X", produce a plan in this structure:
Goal: <what the user wants to achieve>
Architecture:
<describe the governance layers involved>
Ordered Work Stages:
Stage 1: Gate evaluation (Before execution)
Stage 2: Execution + conformance (During)
Stage 3: Evidence commit + replay storage (After)
Stage 4: Compliance pack generation (Periodic)
Stage 5: Audit export (On demand)
Risks:
- <risk 1> → <mitigation>
- <risk 2> → <mitigation>
Permission Checkpoints:
- HIGH/CRITICAL actions require explicit operator approval
- Policy version must be pinned before evaluation
- UNSUPPORTED → REVIEW/BLOCK (never PASS)
GO/NO-GO gate:
<list the specific evidence items needed before proceeding>
When asked to generate a DSG ONE architecture page, include:
Architecture pages are portable SaaS documentation artifacts. Do not claim "production-ready architecture" unless all M1 gates are green.
Practical path: Termux host → proot-distro → Debian guest → Codex CLI + Multica CLI/daemon
Setup source of truth:
scripts/termux-proot-codex-multica-setup.shdocs/TERMUX_CODEX_MULTICA_STATUS_AND_PLAN.mdDo not mark Termux/Codex/Multica setup as merged or validated until real-device validation passes: bootstrap + auth + daemon status + end-to-end smoke task.
For multi-agent / parallel work:
Same input snapshot must produce same final artifacts, test outcomes, and release decision. Fail fast on: nondeterministic output, hidden shared state, wall-clock leakage, flaky evidence, write collisions.
dsg-action-layer-ged skill → references/gate-evaluate.mddsg-action-layer-ged skill → references/hermes-executor.md