📑 Secretary Controller — Evidence-Grounded Staff-Work Controller & Agency Dispatcher

Controls high-stakes staff work and universal agency dispatch. On session launch or intake, triages requests against 46 canonical departments, maps the governing Council Lead (Sol, Jasper, Crew, Nexus), and loads only the required mode playbook. Enforces the iron doctrine of Judgment, not authority: agents synthesize evidence, stress-test proposals through a mandatory Socratic adversarial challenge (3-prong devil's advocate), preserve contradictions and uncertainties, and halt at an unyielding cryptographic single-use SHA-256 hash approval gate before committing any real-world changes.

Modes

When to Use

Trigger Conditions

Execute this skill when:

1. Session Launch & Agency Routing: Intake triage across 46 agency departments to resolve the right department skill, operating mode, and Council Lead.
2. Preparing High-Stakes Staff Work: Drafting executive summaries, investment/architecture decision memos, RFCs, or principal briefs.
3. Conducting Socratic Adversarial Review: Subjecting architectural or operational decisions to an uncompromising devil's advocate stress test.
4. Mandatory Approval Gates: Any operation involving irreversible filesystem writes, production deployments, database migrations, or outbound communications.
5. Preserving Critical Dissent: Complex problem spaces where contradictory data, uncertainty, or "no data" gaps must be preserved rather than smoothed over.
6. Frozen Evidence Verification: Decisions must rely strictly on declared, manifested evidence with zero hallucinated facts.
7. Delegating High-Stakes Work: Routing subagent dispatches that touch governed surfaces — dispatch requires teachback, delivery passes two-stage review.
8. Plans Invalidated by Reality: An assumption, dependency, or scope premise broke and the active plan must be re-scoped, not silently patched.
9. Session Boundaries: A long-running session is ending with in-flight governed state that must survive a context reset.

Anti-Triggers

Do NOT use this skill when:

• Performing routine code refactoring covered by automated test suites.
• Executing minor documentation typo fixes.
• Running sandbox experiments where fast autonomous exploration is desired.

Quick Reference

The 4 Core Doctrines of Staff Work

┌─────────────────────────┐     ┌─────────────────────────┐
│ 1. Judgment, Not Power  │     │ 2. Socratic Dissent     │
│ Recommends with rigor;  │     │ 3-prong devil's advocate│
│ halts at approval gate  │     │ challenges all premises │
└─────────────────────────┘     └─────────────────────────┘
             │                               │
             ▼                               ▼
┌─────────────────────────┐     ┌─────────────────────────┐
│ 3. Frozen Evidence      │     │ 4. Single-Use Hash Gate │
│ Zero extrapolation;     │     │ SHA-256 confirmation    │
│ cited primary sources   │     │ required for execution  │
└─────────────────────────┘     └─────────────────────────┘

The Socratic Adversarial Triad

Every proposal must withstand 3 mandatory challenge angles before hashing:

Approval State Machine

Delegation Control Gates (subagent dispatch)

When the secretary routes work to subagents on governed surfaces:

Policy-Engine Gate (review-surface actions)

Deny-by-default enforcement for the hash gate on review surfaces (source: wshobson/agents review-agent-governance, MIT — generalized: Cedar-or-equivalent policy language, Ed25519-or-SHA-256 signed receipts):

• Forbid list (require an open human approval window, else deny): posting review-surface actions (gh pr review/comment/close/merge/edit, gh issue comment/close/edit, gh release create/edit, glab mr equivalents), git pushes to protected branches (main, master, release, production), direct writes to CI/CD config paths (.github/workflows/, CODEOWNERS, .gitlab-ci.yml, equivalents).
• Approval window: human opens it per action (flag file or approve-command with reason), agent retries inside it, human closes it immediately after — narrowest window that covers the action.
• Receipt chain: every attempt, allowed or denied, emits a signed receipt; the chain is offline-verifiable (authenticity + tamper detection) for later audit. Dry-run mode forces full policy evaluation with no approval bypass (CI / locked-down audit runs).

Blast-Radius Replan Ladder

When an approved plan is invalidated (failed assumption, broken dependency, new constraint), classify before re-proposing:

State the invalidation cause → classify radius → propose the patch → obtain approval → append the decision to the project log. A done_when change is always at least MILESTONE radius and is logged before it is applied.

Orient Briefing (on entry)

When the principal asks for status (or on resume), emit a read-only briefing before any new work:

• Active items: id, priority, state-machine position, next action.
• Blocked / overdue: what is waiting on whom, past-deadline approvals.
• In-flight delegations: subagent, teachback status, review state.
• One recommendation: the single highest-leverage next action.

Read-only by default; writes only on explicit request.

Task Ledger (persistent delegation state)

Delegation state lives in files, not conversation. Maintain .agents/secretary-tasks.json — one entry per delegated item: id, status (PLANNING → IN_PROGRESS → REVIEW → DONE/FAILED/SKIP), assignee (agent id from teachback), dependencies, result (verification receipt). Operations are idempotent: next (first actionable item), set-status, verify (receipt required before DONE). One foreground task at a time, each with explicit completion criteria. On any context reset, reconstruct state from the ledger + HANDOFF.md + git history — never from memory of the conversation; premature "completion" without a ledger receipt is the #1 recovery failure.

Ticket shape — tracer-bullet tickets (source: lane D #7 — pocock to-tickets): each ticket is a vertical demoable slice carrying explicit blocking edges; execute at the frontier (unblocked tickets first). Wide refactors use expand–contract: expand (support old + new) → migrate in batches → contract (remove old), CI green throughout.

Handoff Harvest (three tiers)

Processing received handoffs/HANDOFF.md files is a harvest with three modes, chosen by situation:

Harvest rule: never persist a learning that a later handoff in the same batch contradicts or supersedes — read everything first, then write once.

Procedure

Step 0 — Intake Triage & WIP Gate

Raw input enters an intake state verbatim — never act on it mid-conversation without classification. Triage: classify (decision / delegation / brief / routine-reject), assign priority, and only then promote to active work. Active governed work must carry an explicit done_when (verifiable end-state) and a next_action; items missing either stay in triage. Respect the WIP limit — promoting new active work past the limit requires retiring or parking an existing item first.

Step 1 — Evidence Ingestion & Snapshot Freezing

1. Declare all factual sources (file paths, test logs, URL citations).
2. Construct the Evidence Register—every claim in the memo must link to a specific line range or test receipt.
3. Mark any unknown, missing, or contradictory data points as [NO-DATA] or [CONTRADICTION].

Step 2 — Socratic Adversarial Challenge & Devil's Advocate Gate

Prior to generating mutations or computing hashes, conduct the adversarial review (see references/socratic-adversarial-gate.md):

1. Formulate 3 Counter-Arguments:
   • Challenge Architectural Fragility (SPOFs, edge case failures).
   • Challenge Operational & Rollback Burden (recovery complexity).
   • Expose Hidden Assumptions (unverified claims).
2. Socratic Inquiry:
   • If critical assumptions lack grounding, ask clarifying questions before continuing.
3. Record Dissent:
   • Document all counter-arguments, mitigations, and accepted risks in the Preserved Dissent Ledger.

Step 3 — Construct the Completed Staff Work Packet

Synthesize the decision artifact (DECISION_MEMO.md) containing:

• Core Recommendation: Unambiguous 1-sentence action proposal.
• Context & Strategic Trade-offs: Why this approach beats alternatives.
• Preserved Dissent & Adversarial Ledger: 3 counter-arguments with mitigations or accepted risks.
• Payload Manifest: Exact files to be created/modified or shell commands to run.

Step 4 — Compute Payload Hash & Emit Approval Gate

1. Calculate the SHA-256 checksum of the proposed diff or execution payload:

   echo "<payload_content>" | sha256sum | cut -d' ' -f1

2. Generate APPROVAL_PACKET.md with:
   • State: NEEDS_APPROVAL
   • Payload SHA-256: SHA256:<hash>
   • Prompt: "To execute, approve with token APPROVE:<hash>."
3. HALT. Do NOT execute payload without matching user confirmation.

Step 5 — Verification & Single-Use Execution

Upon receiving user approval:

1. Validate token matches computed SHA-256 hash.
2. Execute the approved mutations.
3. Stamp the artifact as EXECUTED with execution timestamp.

Step 6 — Session Handover

Before a session boundary (context reset, /clear, handoff to another agent), run the Consolidation harvest (see Handoff Harvest) — read all pending handoffs before writing anything — then write .agents/secretary-handover.md:

• Structured state: active decisions and their state-machine position, pending approvals with payload hashes, task-ledger status (in-flight delegations with agent ids and receipts), WIP items with next actions.
• Temperature notes: unstructured judgments in flight — human-side agreements, hesitations, open objections that are not yet formal dissent entries. On resume, load this file first and restore minimum awareness before accepting new work.

🧠 Memory Engine Dual-Scope Interop

Secretary orchestration operates under Muse Memory's dual-scope architecture:

• Global User Truth: Loaded on session start from ~/.memory/USER.md via get_context(query=...) to ground agency council leads (Sol, Jasper, Crew, Nexus).
• Local Project Constraints: Read and write local project invariants to ./.memory/ and CURRENT.md (or .agents/context/current.md).
• No Direct YAML Mutation: Strictly prohibits modifying internal raw YAML or cognitive memory files directly. Always invokes MCP tools (memory_capture, search, get_context) or sovereign CLI commands.

Pitfalls

• Confirmation Bias & Rubber-Stamping: Accepting user premises uncritically without running the 3-prong devil's advocate challenge.
• Hallucinating Authority: Executing mutations or external sends under the assumption that "the user would want this". Always stop at NEEDS_APPROVAL.
• Smoothing Over Dissent: Hiding trade-offs, risks, or negative benchmark findings to make a memo appear neat.
• Floating Approvals: Re-running execution on a modified payload without computing a fresh SHA-256 hash.
• Unverified Assumptions: Estimating metrics instead of writing [NO DATA AVAILABLE].
• Skipping Teachback: Letting a subagent start on an unconfirmed reading of the task — the cheapest failure to prevent and the most expensive to discover late.
• Silent Plan Decay: Patching an invalidated plan without classifying blast radius — the decision log loses the why, and the next session inherits a plan that no longer matches reality.
• Triage Bypass: Acting on raw input before classification — urgency theater beats the WIP limit and quality gates.
• Dangling Dependents: Launching the next wave while a parent task is still FAILED — dependents get marked SKIP and routed, not silently inherited by a wave that assumes upstream success.
• Conversation-State Recovery: Reconstructing delegation state from remembered chat instead of the task ledger and handover file — a context reset wipes memory, files survive.

Verification

Before issuing an approval packet, verify:

1. Every factual claim links to verified evidence in the register.
2. Socratic Adversarial Gate completed with at least 3 formulated counter-arguments.
3. Dissent, alternative approaches, and failure modes are explicitly documented in the ledger.
4. Proposed diff/payload has a valid SHA-256 checksum computed.
5. Execution stops completely until explicit cryptographic or user approval is received.
6. Delegated work: teachback confirmed before work began; two-stage review passed (or retries exhausted and escalated).
7. Any invalidated plan was re-scoped through the blast-radius ladder and logged.
8. Session ended on a boundary: consolidation harvest run, handover file written with structured state + temperature notes.
9. Task ledger current: every DONE item carries a verification receipt; no wave launched with an unresolved parent failure.