git:20260824.ecdb344 to git:20260825.d79c613

---

name: moor

description: After building any UI component or resolving a notable engineering outcome, extract what matters and save it to the correct project file — the UI registry for UI patterns, the session-state file for everything else. So every future session builds on what's already established instead of drifting from it.

---

## Context Contract

**Required:** the component file(s) or engineering outcome being captured ·

the resolved destination file for the tier and capture type (see Step 1).

**Conditional:** every existing UI component file in the project — audit

mode only, to build the whole-codebase baseline.

**Excluded by default:** width/height, layout mechanics, positioning,

animation/transition timing, and responsive breakpoint variants — Step 2

lists these as deliberately not extracted.

**Outputs:** a registry or session-state entry (single-capture mode), or a

proposed baseline plus a deviation list (audit mode) — audit mode's baseline

is written only after developer confirmation.

**Write authority:** the one resolved destination file for the capture type

(UI registry or session-state file, by tier), append/update in place — never

a file outside that resolved destination.

## Resolve Banka state first

Before reading or writing project state, inspect `AGENTS.md`, the complete

contents of `CLAUDE.md`, `/core/`, `/context/`, and the required tier files.

Active schema 2 requires one complete Banka block in `AGENTS.md` containing

these exact comments exactly once and in this order: `<!-- BANKA:START -->`,

`<!-- BANKA:STATE-SCHEMA: 2 -->`, exactly one of

`<!-- BANKA:TIER: Minimal -->`, `<!-- BANKA:TIER: Core -->`, or

`<!-- BANKA:TIER: Standard -->`, then `<!-- BANKA:END -->`. The declared tier

must match the filesystem shape and required files. `CLAUDE.md` must be exactly

`@AGENTS.md`; if it is missing, schema 2 is still

active for a runtime that discovers `AGENTS.md` directly, but report that

Claude Code compatibility is unavailable.

A matching Minimal shape has neither `/core/` nor `/context/`. Core has

`/core/` and its `overview.md`, `architecture.md`, `design.md`, and

`progress.md`, with no `/context/`. Standard has `/context/` and its

`project-overview.md`, `architecture.md`, `build-plan.md`, `code-standards.md`,

`library-docs.md`, `ui-tokens.md`, `ui-rules.md`, `ui-registry.md`, and

`progress-tracker.md`, with no `/core/`.

Stop for competing authority, malformed/partial/duplicate or unknown Banka

markers, a non-exact `CLAUDE.md` beside schema 2, an exact shim with missing

authority, both state directories, tier mismatch, or missing required tier

files. Do not choose, repair, or normalize any of these states.

Without valid schema 2, recognize legacy Banka state only when `CLAUDE.md` has

the `# Project Operating Protocol` heading and exactly one complete legacy tier

shape, with or without an old AGENTS block pointing to it. Legacy is

compatibility-read-only, while moor requires a state destination: report the

classification and stop until an explicitly requested, previewed, and

confirmed migration completes. Incomplete legacy state or a broken old shim is

also a stop condition. If neither schema 2 nor recognizable legacy state

exists, stop because no defined destination exists. Never create Banka state

implicitly.

For active schema 2, resolve destinations from the declared tier: Standard uses

the nine files under `/context/`, Core uses the four files under `/core/`, and

Minimal uses the Banka-owned block in `AGENTS.md`. A Minimal write changes only

that block and preserves all content outside it.

UI consistency and institutional memory depend on every session capturing what

it settled in a place a future session — possibly using a different

user-selected model — will read before building something similar.

## How to Invoke

Claude Code: `/moor`, `/moor [filepath]`, or `/moor audit`.

Codex: `$moor`, `$moor [filepath]`, or `$moor audit`.

If no filepath is given, identify recently created/modified component files automatically.

**Use audit mode when:** the project's UI already exists and consistency is uncertain, multiple sessions have passed without invoking moor, something looks visually off but it's hard to pinpoint why, or before establishing `ui-registry.md` for the first time on an existing project.

---

## Step 1 — Determine what's being captured

- **A UI component pattern** (background, border, radius, text roles, spacing, interactive states, shadow, accent usage — not width/height, layout positioning, or responsive variants, which are too context-dependent to be a consistency rule) → goes to the UI registry (Minimal: a Component Registry note inside the Banka-owned `AGENTS.md` block's Project Overview; Core: `core/design.md`; Standard: `context/ui-registry.md`).

- **A general engineering outcome, decision, or resolved problem** → goes to the session-state file (Minimal: the Banka-owned `AGENTS.md` block's Session Notes; Core: `core/progress.md`; Standard: `context/progress-tracker.md`).

- **A changed global token, folder structure, or invariant** → update the file that actually owns it directly (Minimal: inside the Banka-owned `AGENTS.md` block; Core: `core/design.md` for tokens, `core/architecture.md` for structure/invariants/conventions; Standard: `ui-tokens.md`, `architecture.md`, `code-standards.md` respectively) — never just log that it changed, actually update the source.

## Step 2 — Extract only what matters for consistency (UI capture)

**Extract:** background, border, border color/width, border radius, text color roles, text size/weight, spacing/padding/gap, interactive states (hover/focus/active), shadow, accent usage.

**Do not extract:** width/height, flex/grid layout mechanics, positioning (absolute/relative/z-index), animation/transition timing (that's the Design Craft Add-on's domain if installed — Section 7.7), responsive breakpoint variants (capture the base pattern only).

## Step 3 — Write the entry

```markdown

### [Component Name]

File: [filepath]

| Property | Class/Value |

| -------- | ----------- |

| Background | |

| Border | |

| Border radius | |

| Text — primary | |

| Text — secondary | |

| Spacing | |

| Hover state | |

| Shadow | |

**Pattern notes:** [why a choice was made, what future components should match, what variation is allowed]

```

Append — never overwrite an existing entry for the same component type; update it in place instead.

## Step 4 — Confirm what was captured

```

Moored [Component Name] → [AGENTS.md Banka block / core/design.md / context/ui-registry.md]

Captured: [brief list]

Any future component of this type should match these patterns.

```

Flag anything inconsistent or surprising found during extraction.

---

## Audit Mode

Scans the whole codebase, finds conflicts, establishes a clean baseline before any further single-component capturing happens.

1. **Scan** every UI component file. Build a complete picture of current visual patterns in use.

2. **Identify conflicts** — for each property, list every variation found (with file references) and a recommendation on which to standardize on. Flag every hardcoded value found.

3. **Wait for developer confirmation** before writing anything — present the audit, do not fix or update the registry yet.

4. **Write the confirmed baseline** once approved, labeled clearly as established via audit, with a date.

5. **List what needs fixing** — every component that deviates from the new baseline, so it can be addressed systematically or as encountered.

## The Rule

Build something worth remembering. Invoke moor. Move on. A registry that's sometimes updated is unreliable — consistency is a habit, not a feature.