omakaseagent 0.1.0

package/dist/claude/.claude/skills/omakase/reference/init.md

@@ -0,0 +1,146 @@
+# Init — Bootstrap the Omakase Standard in a Project
+
+**Preferred (deterministic):** run the CLI from the project root:
+
+```bash
+npx omakase init
+# or, in the omakase repo: node bin/omakase.js init
+```
+
+This creates `.omakaseagent/`, updates `AGENTS.md`, installs the skill bundle, and registers **native agents** (`omakase-engineer`, `omakase-critic`, `omakase-archivist`, plus hidden/internal specialists) for OpenCode, Cursor, Claude Code, and Codex.
+
+**Next:** `npx omakase learn` — bootstrap Level 4 factory for this repo (`factory.md`, scenarios, gates). See `reference/learn.md`.
+
+**Skill fallback:** `/omakase init` in a harness chat follows the steps below when the CLI cannot be run — but the CLI path is strongly preferred so native agents are actually on disk.
+
+`omakase init` creates the persistent memory layer and sets the project up to use the standard.
+
+## What It Creates
+
+At minimum:
+- `.omakaseagent/` directory at project root
+- `.omakaseagent/taste.md` — running record of what good looks like for this project/team and what patterns are rejected
+- `.omakaseagent/decisions.md` — key architectural and product decisions with date + "Why"
+- `AGENTS.md` (created or enhanced) — lightweight project-level guidance including Omakase team model reference
+
+Optionally (when the project justifies it):
+- `.omakaseagent/context/` for additional high-signal reference material
+- `.omakaseagent/handoffs/` for saved handoff documents
+
+## Behavior
+
+1. **Detect existing state.**
+   - If `.omakaseagent/` already exists, read the current taste and decisions.
+   - Ask the user whether they want to refresh / expand the existing memory or leave it alone.
+   - Never silently overwrite.
+
+2. **Explore the project (light but real).**
+   - Read README, AGENTS.md / CLAUDE.md / any existing standards docs, package.json or equivalent.
+   - Note the primary language/stack and any obvious architectural patterns.
+   - Form a hypothesis about what "senior work" looks like in this codebase.
+
+3. **Create the .omakaseagent/ directory and files (exact steps).**
+   - `mkdir -p .omakaseagent`
+   - Write `.omakaseagent/taste.md` using the high-signal starter below (customize the "What Good Looks Like Here" section based on your project exploration in step 2).
+   - Write `.omakaseagent/decisions.md` with at least one initial entry capturing the current context + the decision to adopt Omakase.
+   - If this repo already has excellent examples (see the ones in this project's own `.omakaseagent/`), use those as the gold standard for tone and density rather than the generic templates.
+
+4. **Explain what was created and why it matters.**
+   - Tell the user the exact paths.
+   - Show the first few lines of taste.md and decisions.md.
+   - Explain that per SKILL.md Setup, these files are now mandatory context for every significant task (with required "Memory consulted" citation).
+
+5. **Generate or enhance AGENTS.md**
+   - Create `AGENTS.md` in the project root (or enhance it if it already exists).
+   - Add a clear Omakase section that references the core principles and the team model (Engineering, Archives, Critics).
+   - Keep the addition lightweight — link to the installed Omakase skill for the full rules and rubric.
+   - Example section to add:
+     ```markdown
+     ## Omakase Standards
+     This project follows the Omakase standard (senior craftsmanship, zero AI slop, mandatory critique gate, ruthless simplicity).
+
+     Teams:
+     - Engineering (lead: The Engineer) — primary implementation and technical work
+     - Archives (lead: The Archivist) — memory, decisions, and knowledge management
+     - Critics (lead: The Critic) — cross-cutting quality enforcement
+
+     Use `/omakase engineer`, `/omakase critique`, etc. once the skill is installed.
+     See the installed Omakase skill for the full 12 Rules and Critique Rubric.
+     ```
+
+6. **Offer the obvious next step.**
+   - Usually: "Now you can say `/omakase engineer <task>` or just describe what you want built/reviewed/planned."
+   - If the project has no prior standards, this is often the moment to do a light first critique or shape a small piece of work so the taste memory gets its first real data point.
+
+**Minimal Seed for First Task (used by SKILL.md when no .omakaseagent/ exists on first significant engineering work, and user elects to proceed without full /omakase init):**
+Create only:
+- `.omakaseagent/decisions.md` with exactly this starter (customize date/project name):
+  ```markdown
+  # Key Decisions
+
+  ## YYYY-MM-DD — Core Omakase Standards Adopted
+  **Context**: First significant engineering task on a project with no prior .omakaseagent/ memory.
+  **Decision**: Adopt core Omakase Rules + Critique Rubric immediately. Full taste.md and richer decisions will be captured on first real body of work or via explicit `/omakase init`.
+  **Why**: Prevents total context loss and generic output from the very first deliverable. Matches Rule 5 (Persistent Taste Memory) and the Setup requirement in SKILL.md. A minimal seed is better than none for Context Fidelity.
+  **Revisit if**: User runs full init or provides project-specific taste.
+  ```
+- No taste.md yet (or a 1-line placeholder directing to run init for real preferences).
+After creating, tell the user the exact path created and that the next significant output will cite this seed entry. Then proceed with the task under core + engineering (if signals) standards. This is the *only* allowed path for "proceed without init" on first heavy task.
+
+**Gold standard reference:** The `.omakaseagent/taste.md` and `decisions.md` in this very repository (the Omakase source) are the current best examples of the expected density, directness, and "Why" quality. When in doubt during init, bias toward matching that tone rather than the generic templates below.
+
+## Starter taste.md (high-signal template)
+
+```markdown
+# Omakase Taste Memory
+
+## What Good Looks Like Here
+- [Project-specific observation 1]
+- [Project-specific observation 2]
+- Ruthless simplicity is valued more than clever abstractions
+- Code that a strong mid-level engineer can understand and modify six months later
+
+## What We Reject
+- Unnecessary comments that restate the obvious
+- Defensive code around trusted paths
+- `any` casts used as escape hatches
+- Files that grow past ~1000 lines without clear justification
+- "For future flexibility" abstractions that add cost today
+
+## Current Standards
+- Every non-trivial engineering change includes a short "Why this approach" section
+- Critique gate is mandatory before significant work is considered done
+- Persistent decisions are recorded in decisions.md
+```
+
+## Starter decisions.md (high-signal template)
+
+```markdown
+# Key Decisions
+
+## YYYY-MM-DD — Decision Title
+**Context**: One sentence on the situation.
+**Decision**: What we chose.
+**Why**: The senior reasoning (trade-offs, constraints, taste).
+**Revisit if**: Conditions under which we would reconsider.
+
+---
+
+(Older decisions go below. Keep the most recent ones near the top.)
+```
+
+## Success Criteria for This Command
+
+After running `omakase init`, a new or existing project should have a clean, useful `.omakaseagent/` that the skill will actually consult on future work. The files should feel like they were written by someone with taste, not by a generic template engine.
+
+If the project already has strong standards elsewhere, `init` should acknowledge them and focus on creating the minimal bridge into the Omakase memory layer rather than fighting existing conventions.
+
+## Minimum Seed Content for First-Task / Proactive Seeding (when init is not explicit)
+
+When the router creates a seed on the first significant task (see SKILL.md Routing Logic):
+- taste.md must contain **at least three concrete, observable, task-derived entries** (not generic aspirations) in "What Good Looks Like Here" and "What We Reject", pulled directly from the files, request, or smells under discussion in the current turn.
+- decisions.md must contain the adoption entry plus the context of the triggering task.
+- After writing, the persona must re-read the created files and perform a quick internal rubric pass, recording the result in the output or decisions.md.
+- The seed must be high-signal enough that a future agent loading it 10 minutes later can make a better decision on the *same* task than it could with no memory.
+
+Generic one-line placeholders ("Core standards adopted") are a failure of Context Fidelity.

package/dist/claude/.claude/skills/omakase/reference/learn.md

@@ -0,0 +1,66 @@
+# omakase learn — repo factory bootstrap
+
+**Owner:** The Archivist (method). **CLI:** `bin/omakase.js learn` (deterministic discover + write).
+
+## Purpose
+
+Install a **Level 4 dark factory** for *this* repo — not generic templates. `learn` discovers stack and scripts, then writes:
+
+- `.omakaseagent/factory.md` — repo playbook (checks, risk classes, workflow)
+- `.omakaseagent/scenarios/` — up to 5 starter scenarios (approve before Class 2+ work)
+- `.omakaseagent/gates/` + `handoffs/` + `backlog/` — empty with README
+- Taste/decisions/AGENTS.md updates when missing factory markers
+
+Global bar: `reference/dark-factory.md`. This command installs **instrumentation**.
+
+## CLI
+
+```bash
+omakase learn              # factory + memory markers
+omakase learn --dry-run    # list paths only
+omakase learn --memory-only   # taste/decisions only, no scenarios
+omakase learn --factory-only  # factory.md + scenarios, skip taste merge
+omakase learn --project-agents-only  # project-agents/ + native emit only
+```
+
+**Precondition:** `.omakaseagent/` exists (`omakase init` first).
+
+## Agent fallback (no CLI)
+
+1. Confirm `.omakaseagent/` exists; else tell user to run `omakase init`.  
+2. Read README, `package.json`, CI workflows, main source dirs.  
+3. Propose same artifacts as CLI would write; show diffs.  
+4. **Wait for confirm** before writing.  
+5. Log decision in `decisions.md`.
+
+## After learn
+
+Agents follow **`reference/task-intake.md`** (single tasks) and **`reference/factory-orchestration.md`** (Class 2+ team loop: Engineer → critic → gate → archivist when needed). Backlog audit and execution plans: **`reference/backlog-audit.md`**, **`reference/execution-plan.md`**.
+
+- Class **0–1:** brief inline; mechanical checks; light checkpoint OK.  
+- Class **2+:** brief + scenarios (agent drafts); one confirm; gate file at end.  
+- Re-run `learn` when stack or CI changes (`--dry-run` first).
+
+## Gate report shape (minimum headings)
+
+```markdown
+# Gate: <task>
+
+## Seed
+## Scenarios
+## Mechanical evidence
+## Critic
+## Memory consulted
+## Risks / human decision
+```
+
+## Project agents (Phase G)
+
+`learn` proposes up to **3** namespaced agents under `.omakaseagent/project-agents/` from repo signals (`skill/`, `bin/`, domain dirs). On learn, stubs emit to installed harness `agents/` dirs (e.g. `.cursor/agents/omakase-<pkg>-skill.md`).
+
+- **Canonical source:** `.omakaseagent/project-agents/*.md` — edit here, re-run learn
+- **Does not replace** core leads (`@omakase-engineer`, etc.)
+- **Gate:** skill-judge report on new/changed bodies (report-only; human decides)
+- **Refresh:** `omakase learn --project-agents-only` after editing project agent files
+
+See `reference/team-architecture.md` for delegation patterns.

package/dist/claude/.claude/skills/omakase/reference/native-agents.md

@@ -0,0 +1,45 @@
+# Native Omakase Agents
+
+Portable reference (shipped with the skill). Full doc: `docs/NATIVE-SUBAGENTS.md` in the repo.
+
+## Install
+
+```bash
+npx omakase init
+```
+
+## User-facing leads
+
+| Agent id | Use for |
+|----------|---------|
+| `omakase-engineer` | Implementation, architecture, refactoring |
+| `omakase-critic` | Quality enforcement, critique |
+| `omakase-archivist` | Memory, decisions, synthesis; git recap & chat preferences (`reference/archivist-workflows.md`) |
+
+## Invoke
+
+| Harness | Command |
+|---------|---------|
+| OpenCode | `opencode run --agent omakase-engineer "…"` |
+| Grok Build | `grok --agent omakase-engineer "…"` |
+| Claude | `claude -p --agent omakase-engineer "…"` |
+| Cursor | `@omakase-engineer` |
+| Codex | `codex exec -c 'agent="omakase_engineer"' "…"` |
+
+## Delegation (leads only)
+
+Task → `subagent_type` from the lead’s delegation list (e.g. `omakase-senior-reviewer`, `omakase-skill-judge`). See each lead agent file.
+
+Specialists are **INTERNAL ONLY** — not user-facing.
+
+## Skill router (fallback)
+
+This install includes skill **`omakase-router`** at `.agents/skills/omakase/SKILL.md` (folder name `omakase`).
+
+Use for: `/omakase-router plan`, taste, handoff — **not** for `@omakase-engineer`.
+
+## Verify
+
+```bash
+npm run verify:native-agents
+```

package/dist/claude/.claude/skills/omakase/reference/plan.md

@@ -0,0 +1,79 @@
+# Plan — Senior Planning with Domain Awareness
+
+`plan` is a core command. It produces plans that a strong senior engineer or team would actually want to follow.
+
+Like `critique`, it is a smart traffic-cop: it detects the nature of the request, merges the appropriate standards, and then delivers a high-signal plan with explicit reasoning.
+
+## Core Principle
+
+A mediocre plan is worse than no plan. Every Omakase plan must itself pass the Critique Rubric (core + relevant merged extensions) before being delivered.
+
+## Detection & Merge Logic
+
+**Strong signals to merge Engineering extensions** (from `reference/engineering.md`):
+- Implementation, architecture, refactoring, performance, system design, "how should we build X"
+- Code, modules, boundaries, tech choices, team process around code
+- Any request that will result in significant code or technical decisions
+- "Sketch the core data model", "API surface", "backend service" or similar technical depth
+
+**Non-Engineering Signals (core standards only — do not merge engineering extensions)**:
+- Pure product strategy, GTM, org design, high-level roadmap, ICP/positioning/pricing work with explicit or implied "high-level" or "no implementation details" framing.
+- Writing, narrative, or process-focused requests: "develop the messaging", "write the strategy brief for execs", "design a better operating rhythm for feature requests", "critique this customer email sequence for voice".
+- Requests that actively disclaim technical depth.
+
+**Mixed / Ambiguous (common)**:
+- When the request combines product/strategy with any meaningful technical architecture, data model, or implementation implications → merge engineering extensions for the relevant portions only.
+- When in doubt (e.g., "plan improvements to the developer platform" or "add X feature" without clear qualifiers), **ask once** rather than guessing: "This plan request blends product strategy with potential technical elements. Should I produce a plan under core Omakase standards only, or merge in engineering standards (ruthless simplicity for architecture, boundary hygiene, etc.) for the technical sections?"
+
+When in doubt, ask once rather than guessing the register. The plan output must always include an explicit Domain Detection & Merge note near the top (see required elements below).
+
+## What a Senior Omakase Plan Must Contain
+
+A good plan is not a list of tasks. It is a clear, reasoned artifact that reduces ambiguity and surfaces the important thinking.
+
+Required elements:
+
+1. **Domain Detection & Merge Declaration** (mandatory, placed early — right after Goal Restatement or as a top callout box): Explicitly state the detected domain and merge decision with reasoning. Examples:
+   - "Domain: Pure product strategy / GTM. Standards: Core Omakase only (no engineering extensions merged). Reason: Request was high-level positioning and launch phases with no technical architecture or implementation content."
+   - "Domain: Mixed (product positioning + technical implementation sketch). Standards: Core + Engineering extensions (applied to data model and API sections for code judo and contract clarity). Reason: Explicit request for both strategy and core data model/API surface."
+   This fulfills the requirement that every plan (and its subsequent critique) transparently documents whether engineering standards were correctly avoided or applied.
+2. **Problem / Goal Restatement** (sharper and more precise than the original request)
+3. **Key Constraints & Non-Goals** (what we are deliberately *not* doing and why)
+4. **Recommended Approach** with explicit "Why this approach" section (trade-offs, why this shape over obvious alternatives)
+5. **Options Considered** (at least the main 2-3 alternatives and why they were rejected or deferred)
+6. **Risks, Assumptions & Open Questions**
+7. **Proposed Phasing / Order of Work** (with justification — not just a flat list)
+8. **Success Criteria** (observable, testable outcomes)
+9. **Handoff Notes** (what the implementer needs to know that isn't in the plan itself)
+
+## Quality Bar
+
+- Ruthless simplicity in the *plan itself*. Bloated plans are a smell.
+- The plan must pass the Critique Rubric (core only for pure product/strategy/writing work; core + engineering extensions when the plan contains meaningful technical decisions or architecture).
+- Every non-obvious recommendation must have "Why this approach" reasoning.
+- The Domain Detection & Merge Declaration must itself be accurate and defensible (this is part of the self-critique gate).
+- The plan should feel like it was written by someone who has actually shipped similar work and knows where things usually go wrong.
+
+## Tone
+
+Calm, senior, decisive but not arrogant. You are comfortable saying "this is the right shape" while still showing the thinking that led there. You surface uncomfortable trade-offs early.
+
+## Self-Application
+
+The output of `plan` is frequently handed to `engineer` or other agents. Poor plans create expensive downstream problems. Hold the plan to the same standard you would hold the final implementation.
+
+## Relationship to Handoff
+
+When the plan is substantial, consider also producing a crisp handoff document (see `reference/handoff.md`) for the transition from planning to execution.
+
+## Strategic plan vs execution plan
+
+| | Strategic (`reference/plan.md`) | Execution (`.omakaseagent/backlog/`) |
+|---|--------------------------------|--------------------------------------|
+| **Purpose** | Why, options, trade-offs, phasing | How — steps, excerpts, verify gates |
+| **Trigger** | `/omakase plan`, shaping direction | Backlog audit selection, "fix X" spec |
+| **Audience** | Human + Engineer deciding shape | `omakase-implementation-lead` with zero session context |
+| **Template** | Required elements in this file | `reference/execution-plan.md` |
+| **Close** | Handoff to Engineer | Factory loop: critic + gate |
+
+A strategic plan may recommend backlog items; Engineer writes execution plans when it's time to spec concrete file-level work (`reference/backlog-audit.md`).

package/dist/claude/.claude/skills/omakase/reference/skill-judge.md

@@ -0,0 +1,133 @@
+# Skill Judge — SKILL.md evaluation rubric
+
+Use this reference when auditing agent skills, `SKILL.md` packages, persona markdown, or third-party imports before they merge into Omakase. This complements the Omakase Critique Rubric for code and artifacts; it does not replace it.
+
+**Policy (non-negotiable):** Report-only. Never block merges, installs, or releases on a numeric grade. The Critic delivers the report; the human decides.
+
+## When to run
+
+- "Evaluate this skill", "audit SKILL.md", "score this persona"
+- Before siphoning an external skill into `skill/teams/` or `skill/reference/`
+- After generating or changing project agents (`omakase learn` → `.omakaseagent/project-agents/`)
+- Dark-factory Phase 4: mechanical contracts in `evals/*.eval.json` (`npm run verify:scenario-evals`); live with/without-skill runs per `reference/team-architecture.md` trigger table
+
+## Evaluation protocol
+
+1. **Knowledge delta scan (first pass).** For each major section, tag:
+   - **[E] Expert** — the model/harness genuinely benefits; keep
+   - **[A] Activation** — known material, but a brief reminder helps activation; keep if short
+   - **[R] Redundant** — tutorial filler the model already knows; delete or compress
+2. **Structure check** — frontmatter validity, description quality, line count, progressive disclosure, reference files that actually load
+3. **Score eight dimensions** — evidence per dimension, not vibes
+4. **Grade** — total out of 120; assign A–F
+5. **Report** — required output shape below; run Omakase Internal Critique Pass on the report itself
+
+## Eight dimensions (120 points)
+
+| ID | Dimension | Max | What it measures |
+|----|-----------|-----|------------------|
+| D1 | Knowledge delta | 20 | Expert-only content vs token waste (core dimension) |
+| D2 | Mindset + procedures | 15 | Thinking patterns and workflows the harness would not infer |
+| D3 | Anti-pattern quality | 15 | Explicit NEVER lists with non-obvious reasons |
+| D4 | Specification compliance | 15 | Frontmatter, description (WHAT / WHEN / keywords), activation |
+| D5 | Progressive disclosure | 15 | Layered loading; body vs references; "do not load" guards |
+| D6 | Freedom calibration | 15 | Constraint level matches task fragility (creative vs brittle ops) |
+| D7 | Pattern fit | 10 | Matches a deliberate pattern (see below) |
+| D8 | Practical usability | 15 | Decision trees, examples, error paths an agent can follow |
+
+### Grades
+
+| Grade | Score | Meaning |
+|-------|-------|---------|
+| A | 108+ (90%+) | Production-ready expert skill |
+| B | 96–107 | Good; minor fixes |
+| C | 84–95 | Adequate; clear improvement path |
+| D | 72–83 | Significant issues |
+| F | <72 | Redesign likely |
+
+### Design patterns (D7)
+
+| Pattern | ~Lines | Best for |
+|---------|--------|----------|
+| Mindset | ~50 | Taste-heavy creative work |
+| Navigation | ~30 | Distinct scenarios, routing |
+| Philosophy | ~150 | Originality-heavy creation |
+| Process | ~200 | Multi-step projects |
+| Tool | ~300 | Precise format or API operations |
+
+Wrong pattern for the job is a D7 failure even if prose is polished.
+
+## Common failure patterns (flag explicitly)
+
+1. **Tutorial** — explains basics the model already knows  
+2. **Dump** — everything in one 800+ line file  
+3. **Orphan references** — linked files never reached in workflow  
+4. **Checkbox procedure** — steps without thinking frameworks  
+5. **Vague warning** — "be careful" without invariant or example  
+6. **Invisible skill** — strong body, weak `description` (activation fails)  
+7. **Wrong location** — trigger guidance only in body, not description  
+8. **Over-engineered package** — auxiliary files without load path  
+9. **Freedom mismatch** — rigid scripts for creative work, or loose prose for fragile ops  
+
+## Omakase alignment checks
+
+In addition to the 120-point rubric, note pass/fail on:
+
+- **Zero slop** — generic AI voice, filler, engagement bait
+- **Expert-only default** — no menu of 18 shallow skills when one lead + delegation would do
+- **Native agent fit** — if this is a persona: correct `description`, lead-only specialists, no user-facing duplicate of a lead
+- **Memory contract** — significant skills mention when to read/update `.omakaseagent/` if project-scoped
+
+## Required report shape
+
+```markdown
+# Skill Evaluation Report: [name]
+
+## Summary
+- **Total score**: X/120 (Y%)
+- **Grade**: [A|B|C|D|F]
+- **Pattern**: [Mindset|Navigation|Philosophy|Process|Tool|Mixed|None]
+- **Knowledge ratio**: E:A:R = e:a:r
+- **Verdict**: [one sentence]
+
+## Dimension scores
+| Dimension | Score | Max | Notes |
+|-----------|-------|-----|-------|
+
+## Critical issues
+- [must-fix, with location]
+
+## Top 3 improvements
+1. ...
+2. ...
+3. ...
+
+## Omakase alignment
+- [bullet findings]
+
+## Internal Critique Pass
+[1–2 sentences on this report; issues found or none]
+```
+
+## Example report (abbreviated)
+
+```markdown
+# Skill Evaluation Report: omakase-router
+
+## Summary
+- **Total score**: 108/120 (90%)
+- **Grade**: A
+- **Pattern**: Navigation
+- **Knowledge ratio**: E:A:R = 8:2:0
+- **Verdict**: Thin router with strong precedence and pointers; suitable after native-agent install.
+
+## Critical issues
+- none
+
+## Top 3 improvements
+1. Keep body under ~150 lines as references grow.
+```
+
+## Lineage
+
+Rubric distilled from [softaworks/agent-toolkit skill-judge](https://github.com/softaworks/agent-toolkit/tree/main/skills/skill-judge) (MIT). Rewritten for Omakase voice and report-only policy.

package/dist/claude/.claude/skills/omakase/reference/task-intake.md

@@ -0,0 +1,94 @@
+# Task intake — agents co-create the factory setup
+
+Users say goals in plain language ("add rate limiting", "fix the CI flake"). **They should not need to know "seed", risk classes, or gate file paths.** Leads set that up.
+
+## Why intake exists
+
+The factory pattern (see `reference/dark-factory.md`) tries to **replace routine diff review with proof**. Your job at intake: turn a vague ask into an approvable brief + evidence plan so the human can say yes once, then judge **evidence at the end** — not every file during implementation.
+
+**You are not building a runner.** You are setting up **what must be proven** and **which commands prove it**.
+
+**Read first:** `reference/dark-factory.md` (goals + what automation means), `.omakaseagent/factory.md` (this repo's checks), `taste.md`, `decisions.md`.
+
+## If factory is missing
+
+On first significant task in a repo without `factory.md`:
+
+1. Tell the user briefly: Omakase works best with a one-time repo setup.  
+2. Prefer CLI: `npx omakase init` then `npx omakase learn` (or `learn --dry-run`).  
+3. If CLI unavailable: `@omakase-archivist` or router `learn` per `reference/learn.md` — propose artifacts, confirm before write.  
+4. **Do not block Class 0–1 trivia** (typo in README) on full factory — still cite memory if present.
+
+## Intake protocol (Engineer — start of non-trivial work)
+
+Replace jargon with a short **Task brief** the user can skim in one screen.
+
+### 1. Infer from the request (do not interrogate)
+
+From the user message + repo context, draft:
+
+| Field | Agent fills |
+|-------|-------------|
+| **Goal** | What should be true when done |
+| **Non-goals** | What we are not doing |
+| **Observable behavior** | What a human or test would see |
+| **Risk class** | 0–3+ using `factory.md` or `dark-factory.md` defaults |
+| **Evidence plan** | Commands from `factory.md` mechanical list + scenarios if Class 2+ |
+
+Show the brief under a heading like **Task brief** (not "Seed" unless the user is technical).
+
+### 2. When to ask the user (minimal)
+
+| Situation | Action |
+|-----------|--------|
+| Class 0–1, clear ask | Brief inline → proceed |
+| Class 2+, clear ask | Brief + propose 1–3 scenarios (new or link existing in `.omakaseagent/scenarios/`) → **one** confirm: "Proceed with this brief?" |
+| Ambiguous goal, conflicting constraints, Class 3+ | Ask clarifying questions before implementation |
+| User already gave a full spec | Brief is confirm-only or skip if redundant |
+| User points at `.omakaseagent/backlog/NNN-*.md` | Treat execution plan as charter; brief is plan summary + risk class; proceed to scenarios (Class 2+) then factory loop |
+
+Never ask the user to "create a seed file." You create the brief; they approve or correct.
+
+### Backlog execution plans
+
+When implementing from `.omakaseagent/backlog/`:
+
+1. Read the full execution plan (`reference/execution-plan.md` shape).
+2. Task brief = plan title + why + done criteria excerpt.
+3. Run drift check from plan header before editing source.
+4. Honor STOP conditions — escalate to user, do not improvise.
+5. Gate report must link the backlog plan path and record done-criteria results.
+
+### 3. Scenarios (Class 2+)
+
+- Reuse existing scenario files when they cover the work.  
+- If gaps exist, **draft** `.omakaseagent/scenarios/<slug>.md` and show content; write file after confirm (or on proceed if user said "ship it").  
+- Keep scenarios short: actor, start, action, observe, must-not, evidence.
+
+### 4. Work between gates
+
+Proceed with implementation per Engineering lead. Run mechanical checks from `factory.md`. Delegate critic when appropriate.
+
+### 5. Close with a gate report (not chat-only "done")
+
+Write `.omakaseagent/gates/<date>-<slug>-gate.md` using headings from `reference/learn.md`. Tell the user the path.
+
+For Class 0–1, a **light checkpoint** in the reply is enough; full gate file optional unless taste requires it.
+
+### 6. Plain-language close
+
+End with what changed, what was verified, and **one decision** if the human must accept/reject — not a lecture on Level 4.
+
+## Other leads
+
+| Lead | Intake role |
+|------|-------------|
+| **Critic** | Reviews evidence stack in gate reports; does not replace intake |
+| **Archivist** | `learn`, memory, chat/git workflows; may draft factory artifacts |
+
+## Anti-patterns
+
+- Waiting for the user to say "seed" or "risk class"  
+- Long factory terminology up front  
+- Skipping mechanical evidence when `factory.md` lists commands  
+- "Done" without verification or gate artifact on Class 2+

package/dist/claude/.claude/skills/omakase/reference/taste.md

@@ -0,0 +1,33 @@
+# Taste Memory Management
+
+Persistent taste lives in `.omakaseagent/taste.md` and `decisions.md` at the project root.
+
+## Core Contract
+
+- These files are **sacred context**.
+- **On every non-trivial task the skill MUST read (or have in active context) both files before reasoning.** "Attempt" or "best-effort" is not sufficient; absence of a read is a process failure.
+- The output **must** contain the "Memory consulted" declaration required by SKILL.md Setup.
+- After significant work, the skill **must** proactively update (or propose exact patch for) taste.md / decisions.md when new strong preferences or decisions surface, and declare the update in the output ("Updated decisions.md with..."). Updates are part of delivery for non-trivial engineering.
+
+## Reading
+
+- On *every* non-trivial task (engineering or otherwise where project standards apply), read both files early using available tools.
+- Weave specific preferences into reasoning ("Given that this project rejects defensive comments...") **and cite the exact entry**.
+- If the files are missing but the project would clearly benefit, gently surface the option to run `omakase init`. For first significant engineering work, the calling skill (per SKILL.md) creates a minimal seed decisions.md before or instead of asking.
+
+## Writing / Updating
+
+- Never overwrite the user's voice. Add, refine, or sharpen.
+- New entries in `taste.md` should be specific and observable ("We reject X because it caused Y in the past").
+- `decisions.md` entries must always include **Context**, **Decision**, **Why**, and **Revisit if**.
+- Keep both files relatively small and high-signal. Summarize or archive when they grow.
+
+## Quality Bar for Taste Entries
+
+An entry is good when a future agent (or human) can read it in 30 seconds and make meaningfully better decisions on the next piece of work.
+
+Vague or aspirational entries ("we like clean code") are low value and should be sharpened or removed.
+
+## Relationship to the Critique Rubric
+
+Taste memory is one of the primary mechanisms for achieving **Context Fidelity** across sessions. Weak or absent memory is a recurring source of generic output.

package/dist/claude/.claude/skills/omakase/reference/team-architecture.md

@@ -0,0 +1,38 @@
+# Team architecture patterns (Harness vocabulary, Omakase mapping)
+
+One-page reference for **when to delegate how**. Siphoned from [revfactory/harness](https://github.com/revfactory/harness) agent-design patterns — Omakase is a **curated** instance, not a harness generator.
+
+## Six patterns
+
+| Pattern | Meaning | Omakase today |
+|---------|---------|---------------|
+| **Pipeline** | Stages in order | `plan` → Engineer work → Critic → gate → Archivist memory |
+| **Expert Pool** | Lead picks specialist by signal | Engineer → implementation-lead / debugger / refactor; Critic → deslop / structural / skill-judge |
+| **Producer–Reviewer** | Build then independent review | Engineer implements → **@omakase-critic** mandatory Class 2+; Sales brief → Critic for claims |
+| **Fan-out / Fan-in** | Parallel work, merged result | Parallel Task to verifiers (Sales); multiple critic specialists → one gate `## Critic` |
+| **Supervisor** | Lead owns DAG, not every line | **@omakase-engineer** orchestrates factory-orchestration phases |
+| **Hierarchical** | Nested leads | **Avoid** — Omakase stays flat: user talks to leads only |
+
+## Omakase defaults
+
+- **User invokes leads only:** `@omakase-engineer`, `@omakase-critic`, `@omakase-archivist`
+- **Class 2+ factory:** Producer–Reviewer + Supervisor (`reference/factory-orchestration.md`)
+- **Imports / skills:** skill-judge (Critics) before merging external SKILL.md
+- **Handoffs:** `.omakaseagent/handoffs/` or `_workspace/{phase}_{agent}_{artifact}` for multi-step audit trails
+
+## Trigger evals (skill activation)
+
+From Harness skill-testing — apply with **skill-judge** and **scenario evals** (`evals/*.eval.json`):
+
+| Should activate | Should NOT activate (near-miss) |
+|-----------------|----------------------------------|
+| "Ship this PR", "fix CI", "refactor X" | "Write launch email copy" (no engineering extensions) |
+| "Critique this skill", "audit SKILL.md" | "Summarize this article" (not skill-judge) |
+| "What did I ship last week" | "Implement feature Y" (Archivist, not Engineer) |
+| Class 2+ product change | Typo fix in README (Class 0) |
+
+**With-skill vs without-skill:** For a new persona or router change, run the same prompt twice (native lead present vs absent) and compare: memory citation, gate artifact, domain declaration. Mechanical contract: `npm run verify:scenario-evals`.
+
+## Drift
+
+Archivist maintenance: `npm run verify:drift` — `skill/teams/` vs `dist/*/agents/` vs `TEAMS.md`. Re-run after `npm run build` when personas change.