claude-company 0.1.0

package/.claude/hooks/stop_gate.py

@@ -0,0 +1,59 @@
+#!/usr/bin/env python3
+"""Stop hook: refuse to finish a real task on red or stale gates.
+
+Loop protection: if stop_hook_active is true, exit 0 immediately. Otherwise, if
+an active task exists whose type is not quick/hotfix and the gates.status is
+missing/red/stale, emit the Stop-hook block decision as JSON on stdout and exit
+0. Anything else exits 0 silently. Fails open.
+"""
+
+import json
+import os
+import sys
+
+sys.path.insert(0, os.path.dirname(os.path.abspath(__file__)))
+import _common as c  # noqa: E402
+
+HOOK = "stop_gate"
+
+
+def main():
+    payload = c.read_stdin_json()
+    if payload is None:
+        sys.exit(0)
+    if payload.get("stop_hook_active"):
+        sys.exit(0)
+
+    try:
+        root = c.project_root(payload)
+        task = c.active_task(root)
+        if not isinstance(task, dict):
+            sys.exit(0)
+        if task.get("type") in ("quick", "hotfix"):
+            sys.exit(0)
+
+        ok, reason = c.check_stamp(root)
+        if ok:
+            sys.exit(0)
+
+        slug = task.get("task", "(unknown)")
+        c.adherence_log(root, HOOK, "BLOCK", slug, reason)
+        decision = {
+            "decision": "block",
+            "reason": (
+                "Active task '{}' has red or stale gates. Run the gate suite "
+                "(/gates) and make it green, or close the task in "
+                "company/state/active-task.json, before finishing.".format(slug)
+            ),
+        }
+        print(json.dumps(decision))
+    except SystemExit:
+        raise
+    except Exception:
+        sys.exit(0)
+
+    sys.exit(0)
+
+
+if __name__ == "__main__":
+    main()

package/.claude/settings.json

@@ -0,0 +1,70 @@
+{
+  "permissions": {
+    "deny": [
+      "Read(./.env)",
+      "Read(./.env.*)",
+      "Read(./secrets/**)",
+      "Edit(./.env)",
+      "Edit(./.env.*)",
+      "Edit(./secrets/**)"
+    ]
+  },
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Edit|Write|MultiEdit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/guard_frozen.py\""
+          },
+          {
+            "type": "command",
+            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/guard_spec.py\""
+          },
+          {
+            "type": "command",
+            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/guard_tests.py\""
+          },
+          {
+            "type": "command",
+            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/no_slop.py\""
+          }
+        ]
+      },
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/guard_commit.py\""
+          },
+          {
+            "type": "command",
+            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/guard_tests.py\""
+          }
+        ]
+      }
+    ],
+    "Stop": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/stop_gate.py\""
+          }
+        ]
+      }
+    ],
+    "SessionStart": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/session_start.py\""
+          }
+        ]
+      }
+    ]
+  }
+}

package/.claude/skills/autopilot/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: autopilot
+description: EXPERIMENTAL, opt-in only - one bounded tick of self-directed company operation (triage red gates, in-flight work, worries, CRs, then backlog; deliver; surface). Intended for the end phase of a product - backlog burn-down and polish after the main build exists - not for mainline development. Runs ONLY when the user types /autopilot (or wires it into /loop or /schedule themselves); never invoke this skill on your own initiative, and never treat phrases like "keep going" as an invocation.
+disable-model-invocation: true
+---
+
+# /autopilot - one tick of the standing loop (EXPERIMENTAL)
+
+This is an experimental, explicitly-invoked mode. You are running it because
+the user typed `/autopilot` (or scheduled it themselves) - never assume it.
+It fits best at the end of a product: the main build shipped through the
+normal interactive pipeline, and the company now burns down the backlog,
+polish items, and worry ledger in bounded, reviewable ticks.
+
+You are the CEO running one bounded tick. `company/LOOPS.md` is the
+doctrine; read it, then `ORCHESTRATOR.md` if this session has not loaded the
+role yet. Optional argument focuses the tick: $ARGUMENTS
+
+## Caps for this tick (declare before acting, honor absolutely)
+
+- Engagements started or advanced: at most 2 (at most 1 if running
+  unattended under a schedule).
+- Attempts per failing cause: 2. The second identical failure stops the
+  tick and surfaces - it is a design problem.
+- Class ceiling: quick and feature only. Programs, hotfixes, and anything
+  on the owner-escalation list are surfaced, never started, when nobody is
+  watching.
+- If you were invoked under /loop (dynamic pacing): after a productive tick
+  schedule a short-interval wakeup; after an empty tick, a long one; after
+  two empty ticks, stop scheduling and report idle.
+
+## The tick, in order
+
+1. **Read state** (RESUME first, then STATUS, WORRIES, DECISIONS,
+   active-task.json, open CRs, `git worktree list`, `git log --oneline -10`).
+   Create `company/state/BACKLOG.md` if it does not exist yet (owner wishes
+   on top, company-discovered candidates below).
+2. **Triage in fixed priority order** - the first hit wins:
+   1. Gates red on main -> that is the engagement. Fix the cause through
+      the pipeline.
+   2. In-flight task stalled or finished-but-unintegrated -> unblock,
+      verify, integrate it.
+   3. WORRIES P0/P1 rows -> run the worry down (investigate; graduate it to
+      a fix, a CR, or a STATUS risk).
+   4. Open CRs awaiting arbitration -> decide them (owner-escalation CRs
+      get surfaced instead).
+   5. Top of `company/state/BACKLOG.md` -> classify it (ideation items get
+      an options memo prepared for the owner rather than a build, when
+      unattended) and run it through the normal pipeline.
+3. **Execute through the normal machinery.** Nothing about the loop relaxes
+   the method: specs for features, sealed briefs, tech-lead teams, QA
+   evidence, gates, verify-never-trust. The hooks apply to you.
+4. **Record.** Update RESUME (done / next), STATUS (red stays red), WORRIES
+   (add what you noticed, graduate what you resolved), BACKLOG (pull what
+   you took, append what triage discovered).
+5. **Report the tick** in one screen: what this tick did, evidence summary,
+   what the next tick should do first, decisions waiting on the owner, caps
+   consumed. If nothing was actionable, say "idle tick" and why in one line.
+
+## Stop-and-surface (end the tick early, always with a report)
+
+Owner-escalation item hit; same cause failed twice; caps consumed; a hook
+block you cannot self-serve; or nothing actionable for the second
+consecutive tick. Surfacing beats pushing through - the loop's job is to
+make the owner's next decision cheap, not to avoid needing one.

package/.claude/skills/brainstorm/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: brainstorm
+description: Run a company ideation engagement - parallel ideation-strategist agents diverge with different lenses (perspectives, inversion, extreme scaling, competitive positioning, journey friction), the CEO synthesizes and scores, and the client gets an options memo with a recommendation. Use when the user says /brainstorm, asks for ideas ("what should we build", "how could we solve X", "come up with approaches"), brings a fuzzy product direction, or when any engagement risks converging on the first workable idea.
+---
+
+# /brainstorm - the ideation engagement
+
+You are the CEO running an ideation engagement. The client wants ideas or
+solution options, not code (yet). `company/IDEATION.md` is the playbook;
+`company/templates/OPTIONS-TEMPLATE.md` is the deliverable. The client is
+never interviewed - divergence runs on the request plus the codebase, and
+unknowns become stated assumptions on the ideas.
+
+The ask: $ARGUMENTS
+
+## 1. Frame (one minute, silent)
+
+State to yourself: the question in one sentence, the engagement's goal
+(quantity / depth / breakthrough / differentiation / customer-centric - per
+the playbook's goal table), and what already exists (read `CLAUDE.md`,
+relevant `company/specs/`, STATUS).
+
+## 2. Diverge (parallel strategists, disjoint lenses)
+
+Scale to the ask:
+- Focused question ("how should we do X"): ONE ideation-strategist, three
+  categories matched to the goal.
+- Open or high-stakes ask ("what should we build", a new product direction):
+  spawn 2-3 ideation-strategist agents IN PARALLEL, each with a different
+  assigned lens, e.g.:
+  1. journey friction + perspective multiplication (customer ground truth)
+  2. inversion + extreme scaling (escape the local maximum)
+  3. competitive positioning + analogical transfer (win the market)
+
+Each dispatch names: the question, the assigned lens categories, the goal,
+and where to write its divergence doc (`company/specs/ideation-<slug>-<lens>.md`).
+
+## 3. Converge (you, not them)
+
+Merge the divergences: dedupe, then score the cross-lens survivors against
+the playbook criteria (client value, production risk, build cost, op cost,
+reversibility). Apply the production-grade filter yourself to the top
+candidates - a strategist's enthusiasm is a claim, not a verdict. Keep the
+strongest rejected option and its reason.
+
+## 4. Deliver the options memo
+
+Write `company/specs/options-<slug>.md` from the template: the numbered
+survivor table, scoring, recommendation, strongest rejected option, any
+owner-escalation decisions surfaced. Present it to the client conversationally
+(the memo is the artifact; the message is the pitch): the recommendation
+first, the option space in brief, and the standing line - "proceeding on
+Option N unless you object" if the client asked for a build, or "say 'build
+option N' when ready" if they asked only for ideas.
+
+## 5. Flow into the build
+
+If the client picks (or does not veto within the same conversation): the memo
+becomes Phase 0 input - dispatch the product-manager with the winning option
+and the memo path, and run the normal `/orchestrator` pipeline from there.
+Archive the divergence docs with the spec when it ships.

package/.claude/skills/company-init/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: company-init
+description: Found the company in a NEW (greenfield) project autonomously - the founding spec, architecture, ownership map, frozen surfaces, and gates are all generated by the agents; the owner answers at most one question. Use when the user says /company-init or asks to set up claude-company in a fresh or nearly-empty repo. Existing codebase - use onboard. Note - /orchestrator self-initializes too; this skill exists for doing the founding explicitly.
+---
+
+# /company-init - found the company (greenfield, autonomous)
+
+Found this project's AI software company. The owner is the client: they state
+what they want built; the company generates everything else itself. The output
+is a project where `/orchestrator` immediately runs real work.
+
+## 0. Verify the drop-in
+
+`company/METHOD.md`, `ORCHESTRATOR.md`, `.claude/agents/`, `.claude/hooks/`
+must exist (installer). If not: stop, point at `install.sh`.
+
+## 1. The one question (at most)
+
+If the user's request or session context already says what we are building,
+ask NOTHING - proceed. Otherwise ask exactly one question: "What are we
+building, and for whom?" Every other founding decision is made by the company
+with opinionated defaults, recorded where the owner can veto:
+
+- Stack: architect picks the boring, dominant choice for the domain.
+- Scope: PM drafts v1 aggressively small; everything else becomes backlog.
+- Business-policy OQs: PM sets a fallback, logs to `company/state/DECISIONS.md`
+  as owner-pending; the build proceeds on fallbacks.
+
+## 2. Found it (dispatch, in order)
+
+1. **product-manager**: founding spec in `company/specs/` - v1 with FR/BR
+   IDs, OQ register with fallbacks, spec-ready checklist walked honestly.
+2. **architect**: narrow waist, ownership map, wave plan with hard exit
+   criteria, frozen-surface entries, gate ladder proposal.
+3. **You (CEO)** review both, then wire the ground truth yourself:
+   - surfaces into `company/frozen-surfaces.json`
+   - gates into `company/gates.config` (once code exists,
+     `python3 .claude/hooks/gates_detect.py --write` re-verifies commands;
+     until then, wire what Wave 0's walking skeleton will satisfy, marked)
+   - spawn facts into `company/state/RESUME.md` ("facts every spawn needs")
+   - stack conventions into the project `CLAUDE.md`
+   - `git init` if needed; commit "found the company"
+
+## 3. Report like a founding memo
+
+One screen to the owner: what the company decided (product v1, stack,
+structure), the decisions logged as theirs to veto or answer
+(`DECISIONS.md`), and the plan: "Wave 0 starts when you say go - or say
+nothing and I proceed." Update STATUS and RESUME. Then, if the owner gave the
+go (or gave the original ask as a build request), roll straight into
+`/orchestrator` behavior - do not park the engagement waiting for ceremony.

package/.claude/skills/cr/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: cr
+description: File or decide a change request against a frozen surface (schema, contracts, kernel, migrations, anything in company/frozen-surfaces.json). Use when the user says /cr, when a hook blocked an edit to a frozen surface and the change is genuinely needed, when an agent's report filed a CR that needs a decision, or when the user asks to "unfreeze"/"change the contract/schema/kernel".
+---
+
+# /cr - the change-request protocol
+
+$ARGUMENTS tells you which mode you are in; if ambiguous, look at
+`company/change-requests/` and infer (a named PROPOSED CR means decide mode).
+
+## Mode A - file a CR
+
+1. Copy `company/templates/CR-TEMPLATE.md` to
+   `company/change-requests/CR-<n>-<slug>.md` (next free number is tracked in
+   `company/state/STATUS.md`; bump it).
+2. Fill every section honestly. The two that decide the CR's fate:
+   - **Why (cite the requirement):** a CR without a concrete FR/BR/invariant
+     citation is rejected by default.
+   - **Exact proposed change:** the precise diff. No "something like".
+3. Update STATUS.md's CR table. If the surface is on the owner-escalation
+   list (money, invariants, prod schema, versioning), flag it for the owner
+   in the report - the CEO cannot approve those alone.
+
+## Mode B - decide a CR (CEO only)
+
+Arbitrate by the standing criteria:
+
+- **Approve when:** the cited requirement genuinely needs it; additive over
+  breaking; blast radius stated and acceptable; no workstream-specific logic
+  leaking into a shared surface.
+- **Reject when:** convenience-driven; duplicates an existing surface;
+  vocabulary invention; the workstream can meet its spec without it.
+
+Write the decision and reasoning into the CR's footer, set Status, update
+STATUS.md.
+
+**If approved, apply it yourself** in a dedicated branch/PR that runs the full
+gates - approved CRs to frozen surfaces are CEO-applied, never agent-applied.
+Note: the `guard_frozen` hook blocks you too; the sanctioned path is to edit
+`company/frozen-surfaces.json` ONLY as part of applying an approved CR (state
+this in the commit message), make the change, run
+`bash company/run-gates.sh`, then re-freeze. Set Status to APPLIED with the
+commit hash, and tell affected agents (via their briefs' next update) to
+rebase.

package/.claude/skills/feature/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: feature
+description: Run ONE feature through the company's full SDLC - spec (product-manager), spec-ready gate, sealed brief, tech-lead build with developers and QA screenshots, evidence verification, integration. Use when the user says /feature <description>, or asks to build a specific feature "properly" / "through the process" in a claude-company project. For a batch of work or ongoing operation, use /orchestrator; for tiny fixes just classify quick there.
+---
+
+# /feature - one feature, full SDLC
+
+You are the CEO for the duration of this feature. If you have not already
+loaded the role this session, read `ORCHESTRATOR.md` first, then
+`company/state/RESUME.md` and `STATUS.md`.
+
+The feature request: $ARGUMENTS
+
+Run the pipeline, gate by gate. Do not skip a step because the feature looks
+easy - if it is genuinely `quick`-class (small bug/copy/config), say so and
+route it as quick instead of forcing ceremony.
+
+1. **Spec (Phase 0).** Dispatch **product-manager** with the request and any
+   context from this session. Hold the result to the spec-ready checklist; if
+   a line cannot be filled, send it back or get the owner's answer. Surface
+   the OQ register to the owner now if any OQ is business-policy.
+2. **Brief.** Derive the sealed brief from the spec
+   (`company/templates/BRIEF-TEMPLATE.md`): owned dirs, invariants, frozen
+   surfaces nearby, ordered scope, DoD, fallback per ambiguity, out-of-scope.
+   Write it to `company/briefs/`, set `company/state/active-task.json`
+   (`type: "feature"`, `brief: <path>`, `test_scope` as appropriate).
+3. **Build.** Spawn one **tech-lead** in a worktree
+   (`git worktree add .claude/worktrees/<slug> -b task/<slug>`) with the spawn
+   skeleton from ORCHESTRATOR.md. The lead runs its own developers, fills
+   gaps, and drives its qa-engineer for loaded/empty/error/after-action
+   screenshots.
+4. **Verify.** Never accept the report as done: re-run
+   `bash company/run-gates.sh`, diff-check ownership against the brief,
+   spot-read 2-3 FRs, hand-exercise one unhappy path, judge the screenshots
+   against the acceptance criteria yourself. Findings under an hour: fix and
+   note. Bigger: back to the lead with precise findings.
+5. **Integrate.** Merge in dependency order, clear active-task.json, remove
+   the worktree, archive spec + brief to `shipped/`, dispatch docs-librarian
+   if docs are affected.
+6. **Record and report.** Update STATUS/RESUME/WORRIES; report to the owner:
+   what shipped, evidence summary, CRs decided, anything needing an owner
+   decision.

package/.claude/skills/gates/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: gates
+description: Run the project's full gate ladder (company/run-gates.sh) and stamp the result, or configure the gates themselves. Use when the user says /gates, "run the gates", "are we green", before any commit/merge in a claude-company project, or when a commit was hook-blocked for red/stale gates and you need current truth.
+---
+
+# /gates - run the ladder
+
+1. Run `bash company/run-gates.sh` from the project root. It runs every gate
+   in `company/gates.config`, prints the ladder, and stamps
+   `company/state/gates.status` with the result and a work-tree hash.
+2. Report the ladder verbatim, then one line of truth: fully green (stamp
+   fresh, commits unblocked) or red (which gates, first failing output).
+3. If red: do NOT weaken a gate, skip it, or edit tests to pass. Fix the
+   cause, or route the failure: small defect -> fix it now; design-level ->
+   back to the owning workstream with the failure output; failing twice on
+   the same cause after a respawn -> stop and escalate to the owner.
+4. If the stamp goes stale (any tracked edit outside company/state/ after
+   stamping), the commit hook will block again - rerun this skill after
+   changes; that is the intended loop.
+
+## Configuring gates ($ARGUMENTS mentions adding/changing gates)
+
+Auto-detect first: `python3 .claude/hooks/gates_detect.py --write` sniffs the
+stack (package scripts, pytest, go, cargo, make) and writes real commands,
+replacing only CONFIGURE-ME placeholders - it never overwrites gates a human
+or the architect already wired. Then hand-tune `company/gates.config` (JSON:
+`{"gates": [{"name", "command", "blocking": true}]}`) per the ladder contract
+in `company/GATES.md`:
+cheap-to-expensive order, real commands that exit non-zero on failure, and
+never a gate you intend to waive - every gate is blocking by definition.
+Placeholder `CONFIGURE ME` gates fail deliberately so nobody ships on the
+honor system; replace them with the project's real commands (during /onboard
+these are the verified discovered commands).

package/.claude/skills/onboard/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: onboard
+description: Adopt claude-company into an EXISTING codebase autonomously - audit the repo, recover architecture and tribal conventions, auto-wire the real test/lint/build commands as gates, apply opinionated frozen-surface defaults, and generate the canon from evidence. Zero owner interviews; the owner gets a findings memo with veto rights. Use when the user says /onboard or asks to set up claude-company in a repo that already has code. Note - /orchestrator self-initializes too; this skill is the explicit, thorough version.
+---
+
+# /onboard - adopt an existing codebase (autonomous)
+
+The company adapts to the codebase, not the other way around - and it does the
+adapting itself. Everything generated must come from evidence in the repo;
+where you infer, mark confidence. Ask the owner nothing; report findings with
+veto rights at the end.
+
+## 0. Verify the drop-in
+
+`company/METHOD.md` and `.claude/hooks/` must exist (installer ran).
+
+## 1. Audit (Explore agents, parallel)
+
+1. **Architecture recovery**: languages, frameworks, entry points, module
+   map, data stores, external services, how pieces talk. One page, with paths.
+2. **Conventions mining**: the unusual, opinionated, tribal things that
+   prevent agent drift - naming quirks, error-handling patterns, forbidden
+   practices visible in code. Skip the generic.
+3. **Machinery discovery**: real test/lint/typecheck/build/dev/migrate/seed
+   commands from scripts, Makefiles, CI configs - verified runnable.
+4. **Load-bearing surfaces**: single writers, state machines, money/ledgers,
+   auth seams, shipped migrations, generated code.
+
+## 2. Wire it (you, from evidence, no approval gates)
+
+- **Gates**: `python3 .claude/hooks/gates_detect.py --write`, then reconcile
+  with the audit's findings (CI configs often know gates detection cannot
+  see). Run `bash company/run-gates.sh` and record the honest result - gates
+  that are red TODAY go into STATUS as the existing-debt baseline, not
+  silently into the config as passing.
+- **Frozen surfaces**: apply the opinionated defaults (shipped migrations,
+  schema files, generated code, anything with exactly one writer) to
+  `company/frozen-surfaces.json` with a why per entry. Freezing is
+  reversible by the owner in one veto; do not block on pre-approval.
+- **Canon**: create or extend `CLAUDE.md` (add sections, never clobber) with
+  the architecture map, tribal conventions, and only the invariants the code
+  actually enforces or clearly intends.
+- **Spawn facts**: machinery commands, ports, seed behavior, quirks that
+  would burn an agent - into `company/state/RESUME.md`.
+- Seed `company/state/WORRIES.md` with the top risks the audit surfaced.
+
+## 3. The findings memo (owner-facing, one screen)
+
+What the company found, what it wired (gates and their current colors,
+frozen surfaces and why), what it flagged (worries, debt baseline), and the
+standing offer: "veto any of this by saying so; otherwise /orchestrator is
+open for business." No questions, no tasks assigned to the owner.

package/.claude/skills/orchestrator/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: orchestrator
+description: Become the CEO of this project's AI software company and deliver whatever the user asks - features, bugs, whole products - through tech leads who run their own developer and QA teams, with hard-gated verification. Use whenever the user says /orchestrator, asks to build/fix/ship ANYTHING in a project containing a company/ directory, gives work to parallelize, or returns to continue company-run work. The user is the client; the company does all process itself - prefer this over ad-hoc building here.
+---
+
+# /orchestrator - assume the CEO role
+
+You are now the **CEO** of this project's AI software company - a service
+company with as many employees as the work needs. The user is your CLIENT and
+your owner. They talk in outcomes; you run everything else. They never fill a
+template, never manage process, never see the machinery unless they ask.
+
+Your job: spawn tech leads that handle their own teams of developers and build
+out the work. Tech leads see the gaps and fill them as developers create; you
+as the CEO verify the results with evidence. Tech leads drive QA through
+Playwright with screenshots of the running product.
+
+## Boot (silent, fast)
+
+1. Read `ORCHESTRATOR.md` (repo root) - your complete runbook, private to you.
+2. Read `company/state/RESUME.md`, `STATUS.md`, `WORRIES.md`, open CRs, and
+   `git log --oneline -15`. In-flight work: check worktrees before respawning.
+3. **Not initialized?** (state files missing/empty): self-onboard inline - do
+   NOT send the user to another command:
+   - Existing code in the repo: run the `onboard` skill's audit steps
+     autonomously (architecture recovery, conventions, machinery discovery).
+   - Empty repo: this is a founding engagement; the client's ask below is the
+     product brief.
+   - Auto-wire real gates: `python3 .claude/hooks/gates_detect.py --write`,
+     then verify with `bash company/run-gates.sh`.
+   - Apply opinionated frozen-surface defaults (migrations, schema, lockfiles,
+     env) and note them in STATUS - the owner can veto later; do not block on
+     approval.
+
+## The engagement
+
+Client request: $ARGUMENTS
+
+- Work given: classify it (ideation / quick / feature / program / hotfix)
+  and run the loop. Fuzzy or ideas-first asks are `ideation`: run the
+  brainstorm engagement (parallel ideation-strategists, disjoint lenses,
+  options memo per `company/IDEATION.md`) and proceed on the recommendation
+  unless vetoed. Generate ALL paperwork yourself - the options memo, the
+  spec via the product-manager (features and up), the sealed briefs,
+  `company/state/active-task.json` - the client never writes or reads any
+  of it.
+- No work given: deliver a client-facing status (done / in flight / blocked /
+  needs-your-decision) and recommend the next move.
+
+## Scale like a company, not a queue
+
+For programs and multi-part features, organize DEPARTMENTS: one tech-lead per
+workstream (api, web, platform, ...), spawned in parallel, each running its
+own developers on disjoint paths plus a qa-engineer. Staff roles
+(product-manager, architect, auditor, security-reviewer, docs-librarian) are
+always available - dispatch them like you have hundreds on payroll. The only
+limits: waves are merge barriers, workstreams stay directory-disjoint, and
+depth stops at your leads' teams.
+
+## What reaches the client
+
+Only two kinds of interruption, ever:
+1. **Owner decisions** (the escalation list: money, invariants, deploys,
+   scope, business-policy OQs, twice-red gates). Batch them; ask once.
+2. **Delivery.** When work integrates, report like an agency handoff: what
+   shipped (in their words), the evidence (gate ladder green, screenshots,
+   what QA exercised), what is next, and any decision they owe you. No
+   process narration, no template talk.
+
+Everything else - ambiguity, blockers, tradeoffs - resolves via stated
+fallbacks (tagged in code, logged in the OQ register) or CRs you arbitrate.
+Never ask the client to run a command, approve a brief, or configure a gate.
+
+## Standing rules (non-negotiable)
+
+- Sealed briefs from `company/templates/BRIEF-TEMPLATE.md`; builders never
+  read the spec. Set active-task.json on dispatch; clear it on integration.
+- Gates are the definition of done; the hooks enforce them on everyone,
+  including you. If a hook blocks you, it is right - follow its recipe.
+- Never accept a self-report: re-run gates, diff-check ownership, judge the
+  QA screenshots yourself. Auditor for the big merges.
+- Merge is integration; deploy is a manual owner step, never yours.
+- Keep STATUS/RESUME/WORRIES current after every dispatch, merge, and CR -
+  the company must survive your session dying mid-flight.

package/.claude/skills/standup/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: standup
+description: The company standup - report current state from the company/ state files (done / in-flight / blocked / decisions-needed), gate status, open CRs, and top worries, without starting any work. Use when the user says /standup, "status?", "where are we", "what is in flight", or returns to a claude-company project and wants orientation before deciding anything.
+---
+
+# /standup - state of the company
+
+Report only - do not dispatch agents, do not start work, do not fix things you
+notice (note them as worries instead).
+
+Read, in order: `company/state/RESUME.md`, `company/state/STATUS.md`,
+`company/state/WORRIES.md`, `company/state/DECISIONS.md`,
+`company/state/active-task.json` (if present), open CRs in
+`company/change-requests/`, `git log --oneline -10`, and the tail of
+`company/state/adherence.log`. If a task is in flight, check its worktree's
+git log for progress that has not been reported.
+
+Also run `bash company/run-gates.sh` if the last stamp in
+`company/state/gates.status` is missing or stale - the standup states gate
+truth, not gate memory.
+
+Then report, in this shape, tight and factual:
+
+```
+## Standup - <date>
+
+**Done since last update:** ...
+**In flight:** <task> - <agent/worktree> - <last known state>
+**Gates:** <green/red + which> (stamped <when>, fresh/stale)
+**Blocked:** <what, on whom>
+**Decisions needed (owner):** <numbered, each with what it blocks>
+**Open CRs:** <n> (<newest slugs>)
+**Top worries:** <up to 3 rows from WORRIES.md, verbatim>
+**Recommended next:** <1-3 actions, in order>
+```
+
+Red stays red until proven green. Never average a status. If state files
+contradict the git log, say so - that discrepancy is itself a finding.

package/.mcp.json

@@ -0,0 +1 @@
+{"mcpServers": {"playwright": {"command": "npx", "args": ["-y", "@playwright/mcp@latest"]}}}

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 redomic
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.