discord-manager: Skill for Claude Code

Orchestration

Everything here documents the repository as it is on main. If main disagrees with this file, main wins: follow it and flag the drift.

Delegation only works when the orchestrator treats every subagent claim as unverified and every judgment call as its own. These rules were each paid for by a real incident.

Charters

A charter is the task prompt a subagent receives. Requirements:

• Reference every document by absolute path — a relative path resolves differently (or not at all) in the agent's working directory.
• When parallel lanes could touch the same module, name the sibling lanes and give each an explicit do-not-touch list of files/functions the others own. For genuinely shared append-only files (the MCP tool registry, the jobs array, migrations), say up front that rebase conflicts there resolve keep-both.
• Assign each subagent an explicit scratch-file namespace — its lane or task name as a filename prefix — and forbid it from writing any shared scratchpad file, above all the orchestrator's LEDGER.md. Parallel agents that share a scratch filename clobber each other's state, and a fix agent that writes its own notes over the session ledger destroys the orchestrator's recovery record.
• Include a stop-on-contradiction clause: if the charter's factual premise (a claimed bug, a claimed missing feature, a spec citation) doesn't survive verification against the primary source, the agent halts that item and reports with citations instead of inventing. "Verified already correct, no change made" is a valid, expected outcome. Charter-supplied names — tool names, slugs, feature labels — fall under the same clause: an agent that discovers the real feature differs from the charter's name must correct the name and flag it, not ship correct content under a stale identifier.
• When two reference sources disagree, the charter names the conflict for adjudication — it never silently picks one. A charter's factual claims are no more trustworthy than a builder's until verified.
• A charter for any agent whose output ships anywhere public — code, copy, test fixtures, an issue, a PR body, review comments — forbids personal data from real Discord data (usernames, user ids, message content) unless strictly necessary, and when the source material the charter hands over (an issue, a transcript) itself carries real names, the charter lists those exact strings as a deny-list. Before shipping, the orchestrator greps the diff and the published artifacts for them: the generic prohibition alone has failed twice — a real person's email shipped inside a published investigation issue, and a real name traveled from an issue's text into a tool's schema copy and test fixtures despite a charter clause forbidding it, costing a remediation cycle.
• Instruct agents to run slow verification commands (pnpm run tsc, pnpm run test:unit, pnpm run test:e2e) synchronously in the foreground. A workflow agent that backgrounds a check and ends its turn waiting on a notification is terminally stalled — its turn ending is final.
• Write each new charter/script fresh with the Write tool. Deriving one by programmatically splicing a previous one introduces silent syntax errors.
• A parameterized script must parse args defensively (string-or-object) and hard-throw on any missing required field — a silently-undefined interpolation produces a plausible-looking empty result that reads as a clean pass.
• A slice that ships an MCP tool, a gateway handler, or an ingestion path must drive that surface live at least once — a real MCP client session over stdio, or a scripted gateway event through the real business function — before handoff. A unit-only exit bar passes code whose query crashes at runtime or whose tool schema rejects every real input.
• A live proof binds only the commits that preceded it. Sequence the end-to-end MCP session as the charter's last step, after the final commit, and redo it after any later change to the proven surface — a proof that predates a schema or handler commit is evidence of nothing, and a redone proof regularly catches what the suite missed (a coercion regression, a serialization mismatch).
• A review-fan-out charter carries the orchestrator's accepted-decisions list: every settled divergence and deliberate design ruling the work under review already argued, stated as do-not-report items. Without it, finders re-litigate settled calls and the verify stage burns its budget refuting them; with it, every surviving finding is news. The list names decisions, never files — a finder must still probe the implementation of an accepted decision for holes (an accepted "guard exists" ruling does not shield a hole in that guard).
• A skeptic or verifier charter carries TWO acceptance rubrics, not one: a finding stands if either (a) its concrete-input failure scenario occurs at runtime, or (b) it identifies a violation of a codified house rule or doctrine in the work under review. A runtime-only rubric refutes correct doctrine findings — a migration that models a reversible toggle as one action-enum table where the database-design skill prescribes paired event tables — exactly when the fix is cheapest. Doctrine findings against unmerged schema or shape default to fix-now, because schema shapes are effectively permanent once merged.