<!-- Generated by apps/dreamboard-cli/scripts/sync-skill-docs.ts. -->
<!-- Source: docs/reference/rule-authoring.mdx -->

# Rule authoring

Reference for authoring Dreamboard rule.md files.

`rule.md` is the game-design source of intent for a Dreamboard project. Use it
to describe the rules in plain language before you commit to reducer state,
manifest, or UI details.

## Responsibility

Use `rule.md` for:

- the game objective and match shape
- setup, turn flow, scoring, and victory rules
- player actions and their legality constraints
- visibility rules and information flow
- edge cases and deterministic tie-break rules

## Recommended structure

Use the same section order for every `rule.md`.

### `Overview`

State the core promise of the game in one short section.

- supported player count
- objective
- expected match length
- one-paragraph summary of how a turn feels

### `Components`

List the components the rules assume exist.

- cards, zones, boards, pieces, dice, and resources
- public versus hidden information
- per-player versus shared components
- hard limits such as hand size, stock limits, or caps

### `Setup`

Describe the initial state in ordered steps.

- how players are seated
- which player acts first
- which components start in which locations
- any setup options or setup-profile differences

### `Gameplay`

Describe the game loop in the order the reducer should implement it.

For each phase, name:

- who is allowed to act
- which actions are legal
- what input each action requires
- what ends the phase
- which phase follows next

When a game has repeated rounds, document the round loop explicitly instead of
implying it.

### `Scoring and progression`

Describe how players gain or lose progress.

- points, tracks, resources, or thresholds
- when scoring happens
- round-end or trick-end resolution
- tie-breakers for intermediate rankings

### `Winning conditions`

State the exact end trigger and winner resolution rule.

- when the game ends
- how the winner is chosen
- how ties are broken
- what happens if multiple end conditions become true at once

### `Special rules and edge cases`

List rules that are easy to miss during implementation.

- simultaneous actions
- empty-deck or empty-pool behavior
- no-op or invalid actions
- forced actions versus optional actions
- what happens when a player cannot act

## Example template

```markdown
# <Game name>

## Overview

- Players: <min-max> (optimal: <n>)
- Objective: <how a player wins>
- Duration: <target minutes>

## Components

- Shared components:
- Per-player components:
- Public information:
- Hidden information:

## Setup

1. ...
2. ...
3. ...

## Gameplay

### Phase 1: <name>

- Acting player(s):
- Allowed actions:
- Validation:
- Completion:
- Next phase:

### Phase 2: <name>

- ...

## Scoring and progression

- ...

## Winning conditions

- End trigger:
- Winner determination:
- Tie-breaker:

## Special rules and edge cases

- ...
```
