Avalon 8 10p

8–10-Player Avalon

This skill layers a complete base game of Avalon on top of the Room communication kernel. The Room system prompt already defines public @<member> wakes and the built-in nexus Room tools; this skill defines only the game contract. The host Agent is always the moderator and never a player.

Game Setup

Resolve participation and player count before assigning roles:

1. Exclude the host Agent from roles, leadership, teams, votes, and win-condition counts.
2. Ask the user exactly once whether to join as a player or spectate, using AskUserQuestion, unless the opening request already states that choice explicitly. Use the exact choices 参加本局 and 仅旁观.
3. If the opening request explicitly names 8, 9, or 10 players, use that count. Reject any unsupported count instead of silently changing it.
4. Otherwise choose the largest supported count in the order 10, 9, 8 that the Room can fill. A participating user occupies one player seat; a spectating user occupies none.
5. Randomly select the required non-host Agent players. Extra Agents and a spectating user remain spectators and receive no role card or game wake.
6. If the requested count cannot be filled, stop before dealing roles and state the exact number of missing players. If no count was requested and fewer than eight seats can be filled, report how many players are missing for an eight-player game.
7. Use 用户玩家 as the participating user's stable public name. A participating user enters the same randomized role pool as every Agent player and can receive any role, become leader, join a quest, and vote.

Use exactly this role table:

Shuffle roles across all active players, then independently randomize the circular seating order and first leader. Announce only the player count, active roster, seating order, and first leader. Keep the participation answer, role mapping, and inactive candidate list private.

Lake Lady, Lancelot, and Excalibur are optional variants and are not enabled. Do not add them or substitute a different role distribution unless the user explicitly requests a variant before setup.

Wake Plumbing

The game has three execution channels:

• Public feed: a normal public reply containing a non-code @<member> wakes that Agent. An Agent handoff has exactly one naked @; a handoff to the user has none.
• Agent private channel: use nexus.send_message with destination=current_room and visibility=private for Agent role cards, hidden votes, quest cards, assassination choices, and host state.
• User private channel: only the host uses AskUserQuestion for participation, the user's role card, and every hidden user choice. Player Agents never use it to contact the user.

用户玩家 is not an Agent recipient or wake target. Never place it in send_message.recipients, wake_targets, or a naked public @. A user continues a public turn by posting a normal Room message and uses a real @<next Agent> only when an Agent must run next.

A user message counts as a proposal, speech, or other game action only while host state is waiting for that exact user turn. Spectator comments and out-of-turn messages never change game state.

For every ordered public chain, expose only the current handoff as a naked @. Write future names without @ or inside code spans. Public actions must contain only the player's public persona; never leak role truth or private reasoning.

Collect hidden Agent choices one at a time with an explicit private handback:

{
  "tool": "nexus.send_message",
  "arguments": {
    "destination": "current_room",
    "visibility": "private",
    "recipients": ["<player>"],
    "wake_policy": "immediate",
    "reply_route": {
      "mode": "private",
      "recipients": ["<host>"],
      "wake_policy": "immediate"
    },
    "content": "<legal choices and exact reply format>"
  }
}

The Agent player answers with only the requested plain-text final reply. It must not call a Room tool or send the answer twice. Queue the next hidden actor and output <nexus_room_no_reply/> until the collection is complete.

If the final hidden actor is an Agent, set reply_route.next_reply_route.mode = "public" on that Agent's original directed message. If the final hidden actor is the user and an Agent acts immediately before it, set that preceding Agent message's next_reply_route to public; the resumed host turn asks the user and publishes the result naturally. If the collection contains only the user, ask from the current public host turn.

Store minimal authoritative game state in a record-only private message to the host with wake_policy="none" and reply_route.mode="none": player count, seating order, roles, current leader, quest number, proposal attempt, approved team, quest results, and rejection count.

Role Knowledge

Deliver each Agent role as a record-only private message. Deliver a participating user's role through AskUserQuestion with one acknowledgement choice. Include only the knowledge that role is entitled to receive:

• Merlin sees every Evil player except Mordred. Merlin therefore sees Oberon when Oberon is present.
• Percival sees Merlin and Morgana as two unordered candidates and is not told which is which.
• Evil players other than Oberon know one another. They do not see Oberon as Evil.
• Oberon learns no Evil teammates, and no teammate learns Oberon's identity.
• Loyal Servants and the Minion receive no additional identities.

Never publish role knowledge before the game ends.

Board And Win Conditions

All supported player counts use quest teams 3, 4, 4, 5, 5 for quests 1 through 5.

• Quests 1, 2, 3, and 5 fail with at least one 失败 card.
• Quest 4 requires at least two 失败 cards to fail; zero or one failure means the quest succeeds.
• Three failed quests immediately give Evil the win.
• Three successful quests start the assassination phase; Good has not won yet.
• Four consecutive rejected proposals make the fifth leader's finalized team execute the current quest without another team vote. Reset the proposal attempt and rejection count after every quest.

Do not replace the forced fifth proposal with an automatic Evil victory.