diff --git a/modules/home/ai-agent/skills/jury/SKILL.md b/modules/home/ai-agent/skills/jury/SKILL.md
new file mode 100644
index 0000000..fb0ffd4
--- /dev/null
+++ b/modules/home/ai-agent/skills/jury/SKILL.md
@@ -0,0 +1,51 @@
+---
+name: jury
+description: "Reconsiders the active discussion, diagnosis, plan, or implementation with independent reviewers using multiple models. Use when asked for /jury, a jury review, or a panel of second opinions to check the lead agent's reasoning."
+---
+
+# Jury
+
+Reconsider the issue under discussion by launching independent reviewers. Check the framing and evidence as well as the proposed answer. A jury can confirm a sound approach; do not manufacture objections.
+
+## Choose the jury
+
+- Read an optional positive integer immediately after the skill invocation: `/jury 8` requests eight reviewers. Accept the equivalent `$jury 8` invocation. Any remaining text narrows the review topic; otherwise review the active discussion. If the first argument is ordinary prose, treat it as the topic and use the default count.
+- If no count is provided, use **12 on work machines** (account `alebat01`) or **4 on home machines** (account `bates64`). Use the session's machine/account context, checking `id -un` if needed. If neither account nor established work/home context identifies the machine, use 4 and state that assumption.
+- Count reviewers separately from yourself: N means N additional agents. If a numeric argument is zero, negative, or fractional, ask for a positive integer before launching agents.
+- Use the agent runtime's available delegation tools and model identifiers. For N of at least 3, assign at least two reviewers a model different from your own, preferably two distinct alternative models. For N of 1 or 2, assign one reviewer an alternative model. Use your own model for the remaining reviewers unless the topic warrants another mix. Different prompts or reasoning levels on the same model do not satisfy model diversity.
+- If you cannot identify your own model, do not claim verified model diversity. If delegation, model selection, or the requested count is unavailable, disclose the limitation and return only the review you can actually obtain. Never invent reviewers, model identities, or votes.
+
+Tell the user the topic, reviewer count, and intended model mix before launching. If model identities are unavailable, label the mix unverified. Use the existing authorization to review; the jury does not authorize edits, deployments, or external messages.
+
+## Brief independent reviewers
+
+Prepare one compact brief with the user's objective, explicit constraints, relevant observations, links or file paths, and the lead agent's tentative conclusion. Separate observations from assumptions. Include enough context to assess the conclusion without presenting it as the expected answer.
+
+Assign complementary questions based on the issue, such as:
+
+- Does the framing address the user's actual goal, and which assumptions remain untested?
+- Does the evidence establish the diagnosis or conclusion? What would falsify it?
+- Is there a simpler approach or a materially different alternative?
+- Which correctness risks, failure cases, or practical tradeoffs matter?
+- Do the implementation and verification support the claims made about them?
+
+These are review lenses, not mandatory roles. Give every reviewer permission to challenge the overall direction. For larger juries, vary the concrete questions and evidence examined rather than duplicating a generic prompt.
+
+Launch fresh agents with the brief and their assigned question. Where supported, use a fresh context rather than inheriting the full conversation, especially when selecting another model. Do not share other reviewers' answers before their initial reviews are complete. Reviewers may inspect relevant artifacts, but must not edit files, publish changes, contact others, or launch additional agents.
+
+Ask each reviewer for a concise verdict, the strongest supporting evidence, material objections or alternatives, and the most useful next check. Require file/line references, sources, or concrete reasoning for substantive claims. Ask them to distinguish verified facts from hypotheses and to say when they find no material problem.
+
+## Run and reconcile
+
+Use concurrency up to the runtime's actual limit. If N exceeds that limit, run successive batches of fresh reviewers until N reviews are complete. Release completed agents if the runtime requires it. Batching must not silently reduce the jury size. Track requested, completed, and failed reviews with their actual models; count a retry as a replacement, not another opinion. If a runtime limit prevents completion, report the shortfall.
+
+While reviewers work, check the evidence behind your own conclusion or investigate a question that helps resolve the review. Keep the proposal stable during the initial reviews so the reviewers assess the same thing.
+
+After collecting the reviews:
+
+1. Group overlapping findings without treating repeated claims as independent evidence.
+2. Verify consequential claims against the artifacts or primary sources. Use focused follow-ups or checks to resolve disagreements; do not run another full jury automatically.
+3. Weigh evidence and reasoning rather than taking a majority vote. Preserve a credible minority objection, and distinguish a flawed approach from a missing verification step.
+4. Reconsider your own recommendation explicitly: keep it, revise it, or mark the question unresolved. Explain what evidence changed your judgment or supports retaining it.
+
+Return a concise synthesis with the actual reviewer count and model mix, the strongest findings, any unresolved disagreement, and your revised recommendation or next check. Do not paste N full reports. If the active request is limited to review, stop at the synthesis. Otherwise, continue any still-authorized implementation supported by the findings.