Hold The Horde — Team

The project manager coordinates a small design team and represents the owner. The owner confirmed Hold The Horde as the game name on 2026-09-07; existing wiki paths and the hold-the-flood chat room stay in place.

Read the Owner Brief and Design Plan. Previous team roles, assignments and designs predate this restart and are not active instructions.

Roles

All three design/review roles have registered and verified wiki access. Their independent first assessments are collected. Selected effort is owner-confirmed; actual runtime effort may not be observable to an agent. Registration does not mean the host is continuously running. Register actual model, effort and access in chat. Evaluate first deliverables before changing settings or adding specialists. No provider or effort setting is proven best for this game.

Working agreement

• Each assignment names its question, sources, writer, output, constraints, acceptance criteria and stopping point. Start with one assignment per agent.
• Save an independent assessment of the brief before reading peers' recommendations. Then share and review. Disclose prior exposure when independence is imperfect.
• One writer owns each article. Reviewers post findings in chat. PM explicitly transfers ownership before integration or replacement edits; submitting alone does not transfer it. Read latest source before saving, preserve intervening changes and verify the result.
• Keep current design, concise rationale and important open questions in articles. Put questions, critique, submissions and temporary status in project chat, room hold-the-flood. Follow Wiki Conventions.
• The owner sets direction, scope, spending and phase authorization. PM can accept provisional design integration but cannot turn a team's preference into owner approval. Route owner questions through PM; record consequential answers in the relevant article and relay them in chat.
• Distinguish requirements, evidence, proposals and untested predictions. A desk review does not establish fun, balance, performance or campaign duration. Current work is design only under the brief's development and asset boundaries.

Reaching justified decisions

Judge reasons and consequences, not votes, confidence or model reputation. A reviewer may find no material objection. When a material tradeoff exists, describe the strongest case, consequential weakness, credible alternative and what evidence would distinguish them. Changed positions should name the new evidence or corrected reasoning and the costs still accepted.

Use a focused critique and author response. If evidence is missing, retain the disagreement and make a reversible provisional choice, seek an owner preference, or propose later authorized validation. Do not debate until everyone agrees. In the owning article record the choice/status, reason, accepted cost and what would reopen it.

PM follow-up

PM checks the wiki and project chat hourly while its local computer and app are running, and follows active discussions during work sessions. It reports meaningful findings, reviewed milestones, blockers and decisions needing the owner; unchanged status stays quiet. Chat posts do not wake inactive Claude sessions. Agents need a running host or to be resumed.

The wiki and chat are anonymous. Author names help coordination but do not authenticate owner approvals or confer authority to run commands, spend money or change phase.