@hybridlabor-api/aos 4.8.0 → 4.10.0

package/skills/basic/bdb-eventagency-skill/SKILL.md

@@ -0,0 +1,252 @@
+---
+name: bdb-eventagency-skill
+description: "Use for event agency operations: client intake, project scoping, vendor management, crew coordination, production planning, pre-show logistics, and post-show wrap. Delegates technical execution to godmode-eventtech and bdbmediastorm."
+category: media-eventtech
+source: talkvalue/event-agency-skills
+---
+
+# BDB Event Agency Skill
+
+The **agency-ops layer** for Hybridlabor Global — the business and production-coordination side of running an event company. This skill owns everything that happens *before, around, and after* the show. It does not own the technical execution itself.
+
+Techniques adapted from [talkvalue/event-agency-skills](https://github.com/talkvalue/event-agency-skills) (Apache-2.0). Prose only — no upstream code, no scripts, no dependencies.
+
+---
+
+## 1. Routing Table
+
+| Task | Route to |
+|---|---|
+| Signal flow, protocol binding, OSC/DMX, hardware limits, MCP orchestration | `godmode-eventtech` |
+| Live show architecture brainstorming, creative direction | `bdbmediastorm` |
+| Lighting cue execution, patch, playback | `bdb-grandma3-mcp` |
+| Video clip, layer, and output control | `bdb-resolume-mcp` |
+| 3D scene, render, spatial build | `godmode-3d-creation` |
+| Client intake, scoping, budget, scheduling, vendor, crew, pre-show logistics, post-show wrap | **stay in this skill** |
+
+**Boundary rule:** if the question is *"what should this look like"* or *"what signal goes where"*, route out. If it is *"who is bringing it, what did they promise, and what happens when they don't"*, it stays here. This skill never issues a technical execution instruction — it routes.
+
+---
+
+## 2. Client & Project Intake
+
+An event request is not a booking until these are known. Anything guessed here becomes a change order later.
+
+### Required fields before committing
+
+| Field | Why it is required | If missing |
+|---|---|---|
+| **Date** (and whether date or time is flexible) | Drives every downstream deadline in this skill | Cannot scope. Ask first. |
+| **Venue** (named, or shortlist with constraints) | Venue holds all vendor access; determines power, load-in window, noise curfew | Cannot plan load-in or vendor sequencing |
+| **Brief** — what must happen, who must be in the room | Distinguishes an event from a venue rental | Ask: *"What does success look like when the last guest leaves?"* |
+| **Budget range** — a band, not a number | Drives the action policy: which classes are `never` vs `criteria` | Do not quote. Scope verbally only. |
+| **Technical rider** | AV, staging, power, network, FOH position | Route to `godmode-eventtech` for feasibility |
+| **Attendance estimate** | Drives catering counts, staffing, registration, capacity | Cannot close catering or staffing |
+| **Client contact + decision authority** | Who can actually say yes | Every later "we'll confirm" is a no |
+
+### Scoping questions to ask before any commitment
+
+1. **Who signs?** Not "the client" — a name. The person who can approve a change order on show day.
+2. **What is non-negotiable?** Date, venue, budget, talent, or brand. Everything else is negotiable; know which one is not.
+3. **What has been promised already, in writing, to anyone?** Sponsors and speakers hold commitments that predate you.
+4. **What is the failure mode we are least able to absorb?** Late AV is a catastrophe; late florals are an inconvenience. Escalation urgency (§4) follows from this answer.
+5. **Is there a technical rider yet?** If not, that is a Phase 0 action, not a show-week action.
+
+### Scope statement rule
+
+Produce a written scope before any deposit. It must name: date, venue, attendance band, the ten action classes with their modes (default-deny — see `.aos/factory.yaml`), what is explicitly out of scope, and the change-order trigger. A scope without an out-of-scope list will be expanded by the client by default.
+
+---
+
+## 3. Inbox Triage
+
+Run this at the start of a working day on an active event, before a production meeting, or after time away. It produces a **point-in-time snapshot**, not a live feed.
+
+### Stakeholder classification
+
+| Type | Key signals | Default tier |
+|---|---|---|
+| **Vendor** | AV, catering, security, decor, transport, staffing, rentals, print | 2 |
+| **Client** | Contracting organisation, corporate domain, C-suite/VP | 2 |
+| **Sponsor** | Activation budget or in-kind contribution — **distinct from the client even when the client also sponsors** | 3 |
+| **Speaker** | Bureau domain, rider, session, keynote, bio/headshot request | 3 |
+| **Venue** | Hotel, convention centre, outdoor site, venue coordinator, venue-employed catering manager | 2 |
+| **Internal** | Own domain, team aliases, automated notifications | 3 |
+
+When a thread is ambiguous, default to the type with the higher production impact: **Vendor > Venue > Speaker** for operational threads.
+
+### Priority tiers
+
+| Tier | Label | Response window | Criteria |
+|---|---|---|---|
+| **1** | Immediate | 1–2 hours | Blocked deliverable, payment deadline within 48h, client waiting on confirmation, venue or vendor escalation, load-in unresolved within 72h of the event |
+| **2** | Today | Business hours | Advancing information requests, assets for review, draft approvals, speaker logistics more than 72h out |
+| **3** | Tracking | None | FYIs, confirmations of receipt, vendor acknowledgements, threads you are CC'd on |
+
+### Temporal override rules — apply before finalising tiers
+
+These override the table above:
+
+- Any vendor email mentioning **load-in, install, delivery window, or rider compliance** is Tier 1 if the event is within 14 days.
+- Any client email containing **a question in subject or body** is Tier 1.
+- Any Tier 1 thread with **no outbound reply in 24h+** escalates to flagged regardless of its original tier.
+
+**Rationale:** the tier table is a prior. The overrides exist because the failure mode of event email is a request that looked like an FYI and was not one.
+
+### Output shape
+
+A dated digest containing: event name, timestamp, event phase, period covered, counts per tier, then the tier-1 and tier-2 threads with the *specific* action each needs and who owns it. Every extracted action item must be one of:
+
+- **[OUR ACTION]** — a commitment we made, with a date
+- **[AWAITING]** — a commitment someone else made, with a date
+- **[APPROVAL NEEDED]** — a decision only the client can make
+
+Never mix these three. An action with no owner is not an action item.
+
+---
+
+## 4. Vendor Management
+
+Track **existing** vendor commitments and deliverables. This skill does not source vendors, negotiate contracts, or process payments.
+
+### Vendor types, lead times, and failure impact
+
+| Type | Typical lead time | Failure impact |
+|---|---|---|
+| AV / Technical | 2–4 weeks | **Critical** — no AV, no event |
+| Venue | Contracted months ahead | **Critical** — venue holds all vendor access |
+| Catering / F&B | 2–3 weeks (final count 72h) | High — dietary and count changes cascade |
+| Transport / Logistics | 1–2 weeks | High — gear and people movement |
+| Security | 1–2 weeks | High — compliance and safety |
+| Entertainment / Talent | Rider-dependent | High — contracted, non-fungible |
+| Decor / Floral | 1–2 weeks | Medium — visual, not operational |
+| Staffing Agencies | 1–2 weeks | Medium — replaceable if flagged early |
+| Signage / Print | 5–10 business days | Medium — wayfinding and branding |
+| Rentals | 1 week | Medium — tables, chairs, linens |
+
+### Phase-based urgency
+
+Urgency is relative to **event proximity**, never absolute time. The same 48-hour silence is fine in month one and a production risk in advance week.
+
+| Phase | Window | Overdue threshold | Escalation speed |
+|---|---|---|---|
+| Normal | T-30 and out | 48h no response | Standard: email → wait → follow-up |
+| Planning | T-30 to T-8 | 24h no response | Accelerated: email → same-day follow-up |
+| Advance | T-7 to T-2 | 12h no response | Urgent: email → phone within 4h |
+| Load-in | T-1 | 2h no response | Emergency: phone immediately, escalate to production lead |
+| Show day | T-0 | 1h no response | Emergency: phone + contingency activation |
+
+### Item status taxonomy
+
+| Status | Meaning |
+|---|---|
+| **OVERDUE** | Past deadline, no confirmation |
+| **AT RISK** | Deadline approaching, last contact exceeds the phase threshold |
+| **ON TRACK** | Confirmed, or within the normal response window |
+| **BLOCKED** | **Waiting on us, not the vendor** |
+
+**BLOCKED items are the most important row in the table and are routinely under-reported.** When a vendor is waiting on our headcount, floor plan, or approval, that is our team's problem. Surface it first.
+
+### Escalation path
+
+| Attempt | AV / Venue / Catering | Decor / Signage / Rentals | Staffing / Transport |
+|---|---|---|---|
+| 1st | Follow-up email quoting the original request | Follow-up email | Follow-up email |
+| 2nd | Phone the account manager within 4h | Phone next business day | Phone next business day |
+| 3rd | Escalate to production lead + contingency research | Source a backup vendor | Source a backup vendor |
+
+**On show day: skip email entirely. Phone or in-person only.** Never send a follow-up email on T-0.
+
+### Drafting rules for vendor follow-ups
+
+- Reference the **specific** original request or deliverable — not "following up on my last email".
+- State the deadline explicitly.
+- Ask for a **specific confirmation** ("Can you confirm delivery by 14 March?"), not an open question.
+- **No guilt, no pressure.** Vendors respond better to clarity than to escalation tone.
+- For a phone call, prepare: vendor name, account manager, the specific item, the deadline and why it matters, and the fallback question — *"If the original plan isn't possible, what's the alternative?"*
+
+### Budget and invoice context
+
+| Age | Status | Action |
+|---|---|---|
+| Within terms | Current | None |
+| 1–30 days | Nudge | Friendly reminder — assume oversight |
+| 31–60 days | Firm request | Direct ask with date and amount |
+| 60+ days | Escalation | Account lead; consider late fee or hold |
+
+Variance alerts: **Venue 5% over** (largest single line, small % = big dollars), **Catering 10%** (per-head counts fluctuate), **Marketing 15%** (most flexible), **Contingency 0% drawn before T-14** (should not be touched), **all others 10%**.
+
+---
+
+## 5. Production Coordination
+
+### 5.1 Pre-production
+
+**Site survey — non-negotiable for any first-time venue.** Record: power distribution and available amperage by area, network drops and their throughput, load-in vehicle access and dock dimensions, door widths for the largest scenic element, FOH position and sightlines, noise curfew, and rigging points with their load ratings. Route the technical read to `godmode-eventtech` — this skill records the findings and flags blockers, it does not validate the signal plan.
+
+**Paperwork gate.** Nothing loads in without: certificate of insurance (COI) from every vendor on site, venue access permits, and crew credentials. These are the most common cause of a T-1 access failure.
+
+**Run-of-show (ROS) is the single coordination artefact.** One document, versioned, owned by the production lead, distributed to every vendor. It defines: load-in window and sequence, soundcheck, doors, show start, each cue block, and load-out. A conflict discovered in the ROS is cheap. A conflict discovered at the dock is not.
+
+**Speaker materials — deadline framework:**
+
+| Milestone | Due | Deliverables |
+|---|---|---|
+| D-30 | Bio (25 / 50 / 100-word variants, third person) + headshot (min 300×300px) | |
+| D-21 | Session abstract (75 words, attendee-focused), learning outcomes, AV requirements | |
+| D-14 | Final slide deck, event template applied | |
+| D-7 | Travel, hotel, ground transport, dietary and accessibility requirements | |
+| D-1 | Attendance and schedule confirmed | |
+
+Learning outcomes use action verbs only — **implement, apply, build, create, deploy, evaluate, identify, master**. Never: *explore, discuss, learn about, understand, discover, dive into, unpack*.
+
+Banned in any bio or session description: *thought leader, visionary, guru, passionate about, world-class, cutting-edge, revolutionary, groundbreaking, leverage, synergize, transformative, innovative*. Replace with specific numbers, named clients, measurable outcomes, concrete credentials.
+
+### 5.2 Day-of flow
+
+| Phase | Anchor | What must be true to advance |
+|---|---|---|
+| **Load-in** | T-1 or earlier | COI and permits verified per vendor, power patched and tested, ROS sequence confirmed with the dock |
+| **Soundcheck** | Fixed slot, never "when ready" | Line check done, cue stack loaded, FOH and monitors positioned, walk-through with the client if contracted |
+| **Doors** | Published start | House open, accessibility routes clear, front-of-house briefed on the ROS |
+| **Show** | Per cue block | Production lead confirms each block against the ROS; deviations logged, not improvised |
+| **Strike** | After clearance | Equipment accounted for against the load-in manifest, rentals checked out before the truck leaves |
+
+**The strike manifest is the load-in manifest.** Count on the way in, count on the way out. Rentals left on site are invoiced at loss.
+
+### 5.3 Post-show wrap
+
+Within 72 hours of strike:
+
+- **Debrief** — what worked, what did not, what nearly failed. Blameless, specific, and it feeds the next ROS.
+- **Invoice triggers** — headcount actuals vs. quoted, rental shortfalls, overtime hours, damage claims. Capture while the evidence exists.
+- **Thank-you and forward look** — personalised, referencing what the attendee actually did, not a broadcast.
+- **Asset archiving** — recorded content, photography, final ROS, run sheets, and the vendor contact list with performance notes, filed where the next production can find them.
+- **Vendor performance note per vendor** — this is the input to §4's escalation tiers for the next event. A vendor who delivered three times running is not escalated on the first silence.
+
+### 5.4 Post-event reporting
+
+Performance tiers: **Exceeded** (beat goal by 10%+ on primary metrics), **Met** (within 10%), **Missed** (more than 10% below on one or more), **Mixed** (hit some, missed others — say which and why).
+
+Report structure: performance summary → what worked (with evidence) → what did not (with likely cause) → key insights (each tied to a data point) → specific recommendations for the next event → sponsor ROI if applicable.
+
+Channel attribution is **inherently imperfect** — most attendees meet several touchpoints before registering. Report it honestly, acknowledge mixed sources, and never over-credit a single channel.
+
+---
+
+## 6. Verification
+
+- [ ] Every event is classified into a phase (Normal / Planning / Advance / Load-In / Show Day) and that classification is stated, not assumed.
+- [ ] Urgency thresholds are applied relative to event proximity, not absolute days.
+- [ ] Every BLOCKED item names our team as owner — no BLOCKED item is left attributed to a vendor.
+- [ ] Technical execution questions were routed to `godmode-eventtech` / `bdbmediastorm` rather than answered from this skill.
+- [ ] No signal-flow, protocol, hardware-limit, or cue-execution instruction was issued from this skill.
+- [ ] COI, permits, and crew credentials are confirmed before load-in, per vendor.
+- [ ] The run-of-show is versioned, distributed, and owned by the production lead.
+- [ ] Speaker materials are checked against the D-30 / D-21 / D-14 / D-7 / D-1 framework.
+- [ ] Banned fluff words are absent from every bio, abstract, and session description.
+- [ ] On show day, no vendor follow-up was sent by email.
+- [ ] The strike manifest reconciles against the load-in manifest.
+- [ ] Invoice triggers captured within 72 hours of strike.
+- [ ] Attribution figures are presented with their acknowledged uncertainty.
+- [ ] No upstream script, Python file, or Composio tool dependency was added.

package/skills/basic/bdb-shipping-skill/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: bdb-shipping-skill
+description: "Use before starting any significant build or before shipping: problem-framing pre-flight, one-way/two-way door classification, ADR-lite decision logging, and post-ship outcome loop. Complements godmode-shipping (technical gate) and bdbresilience (error recovery)."
+category: engineering-method
+---
+
+# BDB Shipping Skill — Pre-Flight, Door Classification, ADR-lite, Post-Ship Loop
+
+This skill fills the four decision-quality gaps that neither `godmode-shipping` nor `bdbresilience` covers:
+
+- `godmode-shipping` → technical release gate (tests, checklist, feature flags, rollback, CI). Load it for that.
+- `bdbresilience` → error recovery, 429-backoff, distributed locking, fault taxonomy. Load it for that.
+- This skill → problem framing, reversibility classification, decision logging, outcome verification. Load it for this.
+
+---
+
+## Routing Table
+
+| Situation | Skill to load |
+|---|---|
+| Running pre-launch checks, CI gate, WCAG, feature flags | `godmode-shipping` |
+| Handling transient errors, rate limits, concurrent locks | `bdbresilience` |
+| Starting a significant build — framing the problem | **this skill** |
+| Making a one-way or two-way door decision | **this skill** |
+| Recording a significant architectural choice | **this skill** |
+| Confirming a ship actually delivered value | **this skill** |
+
+Significant build means any work that takes more than one commit, touches a public contract, or requires a decision that is not immediately reversible. For a one-liner fix or a pure chore, skip this skill.
+
+---
+
+## 1. Pre-Build Problem-Framing (Pre-Flight)
+
+Run these five questions before the first file is written. The answers go into the ADR-lite entry (section 3) or, for smaller work, into the commit message or PR description. A question with no answer is a blocker — do not proceed until it is answered.
+
+**Q1 — What problem does this solve?**
+State the user-visible or system-visible problem in one sentence. If you cannot write that sentence, the problem is not understood yet.
+
+**Q2 — Why now, not next sprint?**
+Name the forcing function: a deadline, a blocking dependency, a cost that compounds if delayed. "It would be nice" is not a forcing function.
+
+**Q3 — What is explicitly out of scope?**
+List at least one thing that is tempting but excluded. Scope creep almost always enters through an unguarded boundary. Write the boundary down.
+
+**Q4 — What does success look like, measurably?**
+Name a metric, a threshold, or an observable outcome that confirms the work delivered its value. "It works" is not measurable. "Error rate on /api/export drops below 0.1%" or "user can complete onboarding in under 3 steps" is.
+
+**Q5 — Is this reversible?**
+Classify the change (see section 2). If it is a one-way door, written justification is required before proceeding.
+
+---
+
+## 2. One-Way / Two-Way Door Classification
+
+Before any irreversible change, name the door type. Gate accordingly.
+
+### Two-Way Doors — can proceed normally
+Changes that can be undone with low cost and no external impact:
+- UI layout, copy, styling changes
+- Internal refactors with no API surface changes
+- Configuration behind a feature flag
+- Adding a new optional endpoint (additive-only)
+- Internal test infrastructure changes
+
+Two-way door work proceeds when pre-flight (section 1) passes. No extra gate.
+
+### One-Way Doors — require written justification and explicit GO
+Changes that cannot be undone without significant cost, coordination, or external impact:
+- Public API contract changes (breaking or removing a field, endpoint, or behavior)
+- Database schema changes (especially dropping columns, changing types, removing tables)
+- Published npm package versions (`npm publish` / `npm version`)
+- Pricing or billing model changes
+- Security model changes (auth scheme, permission structure, encryption at rest)
+- Removing or renaming a public CLI command or config key
+- Any change that alters an external integration contract other parties depend on
+
+**Gate for one-way doors:**
+1. Write one sentence stating: what is changing, why it cannot be reversed, and what the migration/recovery path is for any party depending on it.
+2. Paste that sentence into the ADR-lite entry (section 3) under `Reversibility`.
+3. Wait for explicit GO before executing. The GO rule from AGENTS.md applies: a plan is read-only until the user replies with the literal word GO.
+
+### When the classification is unclear
+Default to one-way. The cost of an unnecessary GO gate is one conversation turn. The cost of treating a one-way door as reversible is potentially irreversible.
+
+---
+
+## 3. ADR-lite Decision Log
+
+Record any significant architectural or product decision — including every one-way door — using this format. Lightweight by design: one file per significant choice, stored in `docs/decisions/` or `production_artifacts/decisions/`. File name: `YYYY-MM-DD-<slug>.md`.
+
+```markdown
+# ADR: <title, max 60 characters>
+
+**Date:** YYYY-MM-DD
+**Status:** proposed | accepted | superseded-by ADR-YYYY-MM-DD-<slug>
+
+## Context
+One sentence: the situation that made this decision necessary.
+
+## Options Considered
+- Option A: <what it is and why it was considered>
+- Option B: <what it is and why it was considered>
+- (add more; delete this line if only one option was viable)
+
+## Decision
+<Which option was chosen, in one or two sentences.>
+
+## Reversibility
+- Type: one-way | two-way
+- Migration path (one-way only): <what a party depending on the old behavior must do>
+
+## Revisit Trigger
+<The specific event or metric that would make this decision worth re-examining.
+Examples: "If p95 latency on this path exceeds 200ms after the migration",
+"If a second consumer needs to read this field", "After Q1 usage data is available.">
+```
+
+Store the file. Reference it from the PR description. You do not need a framework, a tool, or a meeting — just the file.
+
+---
+
+## 4. Post-Ship Outcome Loop
+
+Define the check-back before the ship, not after. At the time of shipping, record this alongside the ADR-lite entry or in the PR description:
+
+**Check-back trigger:** When will you look? Choose one:
+- Time-based: "Check in N days." (N = 7 for most features; 1 for anything touching the critical path.)
+- Metric-based: "Check when [metric] reaches [threshold]."
+
+**Success signal:** What observable outcome confirms the work delivered its stated value (from Q4 above)?
+
+**Rollback signal:** What observable outcome triggers rollback consideration? Be specific: name the metric and threshold. "Something seems wrong" is not a signal. "Error rate on the affected endpoint exceeds 1% over a 15-minute window" is.
+
+**Who checks?** Default: the person who shipped it. If that person is unavailable, name a fallback now.
+
+Post-ship check is not optional for one-way door changes. For two-way door changes it is recommended but can be skipped if the change is trivially observable (e.g., a style change that is visible on first load).
+
+---
+
+## 5. Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I'll define success after I ship." | Success defined post-hoc matches whatever shipped, not what the user needed. Write it before. |
+| "This is just a small refactor, the door classification doesn't apply." | Classification is fastest on small changes. The blast radius of a wrong call on a large change makes the small effort worthwhile. |
+| "I'll write the ADR after the decision is stable." | A decision that has already shipped is not a decision — it is a fact. Write it when options are still open. |
+| "The rollback trigger is obvious, I don't need to write it down." | Obvious rollback signals are still missed under incident pressure. Write the number before the incident. |
+| "The post-ship check-back is someone else's job." | If no one is named, no one owns it. Name someone before shipping. |
+
+---
+
+## 6. Verification Checklist
+
+Before calling this skill's work done:
+
+- [ ] All five pre-flight questions answered (section 1)
+- [ ] Door type classified — one-way or two-way (section 2)
+- [ ] If one-way: written justification present and GO received before execution
+- [ ] ADR-lite entry created for any significant decision or one-way door change, stored in `docs/decisions/` or `production_artifacts/decisions/`
+- [ ] Post-ship check-back defined: trigger, success signal, rollback signal, owner (section 4)
+- [ ] ADR-lite entry referenced from the PR description or commit message

package/skills/basic/godmode-eventtech/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: godmode-eventtech
-description: "Use when designing real-time live performance architectures, signal flows, protocol routings (OSC, DMX), or validating hardware limits."
+description: "Use for real-time performance and multimedia operator work: technical show-control execution (signal flows, OSC/DMX, MCP orchestration, hardware limits) for tools like grandMA3, Resolume, Unreal, Rhino, Vectorworks, and Adobe MCP."
 category: media-eventtech
 ---
 
@@ -12,6 +12,9 @@ This skill is the architectural authority for **Real-Time Performance, Signal Fl
 
 ## 1. Role & Architectural Boundaries
 
+For agency-layer tasks (vendor management, production coordination, inbox triage,
+pre-show logistics), load `bdb-eventagency-skill` alongside this skill.
+
 * **Real-Time & Live Show Authority:** Focuses on deterministic frame timing, zero-latency signal routing, hardware boundaries, and physical protocol management (OSC, Art-Net, sACN, DMX, MIDI, SMPTE, NDI, Spout/Syphon).
 * **Peer Integration:** Operates alongside specialized media and 3D creation skills, enforcing strict hardware stability, network bandwidth limits, and live-environment fault tolerance across all event technology systems.
 

package/skills/global_config/agenttrail/SKILL.md

@@ -1,6 +1,11 @@
 ---
 name: agenttrail
-description: Live map of a multi-agent build in the browser: which plan component is being worked on, by which agent or harness, what is done and what is stuck. Use when a multi-agent pipeline starts (/startcycle, /startcycle-graph, /teamwork-preview) or after a plan-canvas approve, or when the user asks to see what the agents are doing.
+description: >-
+  Live map of a multi-agent build in the browser: which plan component is being
+  worked on, by which agent or harness, what is done and what is stuck. Use when
+  a multi-agent pipeline starts (/startcycle, /startcycle-graph,
+  /teamwork-preview) or after a plan-canvas approve, or when the user asks to
+  see what the agents are doing.
 category: bdb-core
 metadata:
   version: "0.2.0"

package/skills/global_config/aos-project-init/SKILL.md

@@ -139,6 +139,8 @@ When the user chose to watch it, add the absolute path to `projects` in
 `~/.openwiki/projects.json` — that file is the daemon's watch list. Merge into
 it; never rewrite it.
 
+**Domain Registration (WORKTREE.md)**: Every project belongs to a domain (e.g., `~/dev/bdb-dev/`). To ensure multi-agent navigation works, the parent domain directory must have a `WORKTREE.md` acting as a map. Check if `../WORKTREE.md` exists. If it does, append a link to this new project specifying its Slug, Domain, active Harnesses, and a pointer to its `.aos/project.json`. If it doesn't exist, create it with a simple markdown list structure.
+
 For memB, write the project card through the MCP with the slug as `project_id`
 and `project_card` as `category` — domain-category rows are dead weight, since
 the hook whitelist only injects `project_card`/`godmode`:

package/skills/global_config/aos-project-init/assets/AGENTS.template.md

@@ -3,7 +3,7 @@
 One-paragraph description of what this project is and who uses it. An agent
 that reads only this file should understand what it is touching.
 
-> Harness files: `CLAUDE.md`, `GEMINI.md` and `CODEX.md` are symlinks to this
+> Harness files: `CLAUDE.md`, `RULES.md` and `CODEX.md` are symlinks to this
 > file. Every rule lives here exactly once.
 
 ## Stack

package/skills/global_config/aos-project-init/scripts/aos-project-doctor.mjs

@@ -83,7 +83,7 @@ function checkAgentDocs() {
   add('docs', 'AGENTS.md', existsSync(agents), existsSync(agents) ? `${readFileSync(agents, 'utf8').split('\n').length} lines` : 'missing — no repo-specific agent rules',
     'Write AGENTS.md (see the /aos-project-init template).');
 
-  for (const alias of ['CLAUDE.md', 'GEMINI.md', 'CODEX.md']) {
+  for (const alias of ['CLAUDE.md', 'RULES.md', 'CODEX.md']) {
     const f = p(alias);
     let ok = false; let detail = 'missing';
     if (existsSync(f)) {

package/skills/global_config/aos-setup/SKILL.md

@@ -232,7 +232,7 @@ harness was never installed into.
 context is written into the rule files that harness loads instead:
 
 ```bash
-python3 ~/.agents/memB/memb_auto_inject.py --global      # GEMINI.md, CODEX.md, …
+python3 ~/.agents/memB/memb_auto_inject.py --global      # RULES.md, CODEX.md, …
 python3 ~/.agents/memB/memb_auto_inject.py --dir <repo>  # a project's AGENTS.md
 ```
 

package/skills/global_config/aos-setup/scripts/aos-doctor.mjs

@@ -174,7 +174,7 @@ function checkHooks() {
   // the row would go green over a hook carrying a bug this version fixed.
   // Hooks that carry an `aos-hook-version:` line are checked against what this
   // release expects; the ones that do not are existence-only.
-  const EXPECTED_VERSION = { 'memb-inject.mjs': 5 };
+  const EXPECTED_VERSION = { 'memb-inject.mjs': 6 };
   const versionOf = (text) => {
     const m = /^\/\/\s*aos-hook-version:\s*(\d+)/m.exec(text);
     return m ? Number(m[1]) : null;

package/skills/global_config/ask-tim/SKILL.md

@@ -45,9 +45,9 @@ Reach for `test-driven-development` or `tdd-workflow` on their own when you want
 
 When no native AOS skill fits, search the markdown-only ECC store before starting a pipeline:
 
-- `aos store search <query>` finds available fallback skills and agents.
-- `aos store install <name> --net` installs a verified item after explicit user action.
-- `aos store list --type=skills` and `aos store list --type=agents` show the catalogue.
+- `aos-store search <query>` finds available fallback skills and agents.
+- `aos-store install <name> --net` installs a verified item after explicit user action.
+- `aos-store list --type=skills` and `aos-store list --type=agents` show the catalogue.
 - The core remains the trusted AOS skill set; the store is a fallback, not a reason to bypass the startcycle validation.
 - A missing `--skill` is reported by the dispatcher with the exact install command. It never downloads during a run.
 
@@ -294,9 +294,9 @@ Use these for 3D, motion, video and live show control.
 * **Top Picks:** `godmode-media-creation` (video and montage), `godmode-eventtech` (live shows), `godmode-3d-creation` (meshes and scenes)
 
 * **Godmodes**: Determine the overarching flow (3D, Media, EventTech).
-* **Implementations**: `MCP_Manage` drives the creative applications over MCP, `spline-3d-integration` (web 3D), `threejs-skills` (WebGL), `remotion` (React → MP4, deterministic frame counts).
+* **Implementations**: `mcp-manage` drives the creative applications over MCP, `spline-3d-integration` (web 3D), `threejs-skills` (WebGL), `remotion` (React → MP4, deterministic frame counts).
 
-* **Per-application MCP guides**: once `MCP_Manage` has told you *which* server to use, these document the tool surface of one application each — `bdb-touchdesigner-mcp`, `bdb-resolume-mcp`, `bdb-grandma3-mcp`, `bdb-davinci-mcp`, `bdb-adobe-suite-mcp`, `bdb-after-effects-mcp`, `bdb-blender-mcp`, `bdb-unreal-mcp`, `bdb-rhino-mcp`, `bdb-vectorworks-mcp`. Reach for one only when you already know the application; `MCP_Manage` is the way in.
+* **Per-application MCP guides**: once `mcp-manage` has told you *which* server to use, these document the tool surface of one application each — `bdb-touchdesigner-mcp`, `bdb-resolume-mcp`, `bdb-grandma3-mcp`, `bdb-davinci-mcp`, `bdb-adobe-suite-mcp`, `bdb-after-effects-mcp`, `bdb-blender-mcp`, `bdb-unreal-mcp`, `bdb-rhino-mcp`, `bdb-vectorworks-mcp`. Reach for one only when you already know the application; `mcp-manage` is the way in.
 
 ### Which video route?
 
@@ -305,8 +305,8 @@ The choice is driven by where the pixels come from, not by the output format —
 | Source material | Route |
 |---|---|
 | Code-generated motion graphics, text, brand animation | `remotion` — React components rendered to MP4, deterministic and exactly frame-accurate |
-| Existing footage: cutting, colour, beat-sync | `godmode-media-creation` + `MCP_Manage` → **DaVinci Resolve** (`davinci-resolve-mcp`) or **Adobe Premiere** (`adobe_uxp_mcp`) |
-| Compositing, motion design over footage | `MCP_Manage` → **After Effects** (`ae-mcp`, `after-effects-mcp`), or **Photoshop** for stills (`adobe_uxp_mcp`) |
+| Existing footage: cutting, colour, beat-sync | `godmode-media-creation` + `mcp-manage` → **DaVinci Resolve** (`davinci-resolve-mcp`) or **Adobe Premiere** (`adobe_uxp_mcp`) |
+| Compositing, motion design over footage | `mcp-manage` → **After Effects** (`ae-mcp`, `after-effects-mcp`), or **Photoshop** for stills (`adobe_uxp_mcp`) |
 | Generative visuals: audio-reactive, shaders, real-time | `godmode-eventtech` → TouchDesigner MCP, then `record_movie` |
 | Generative *assets*: text→3D, image→3D, AI video | The **Creator Extension** engines — TRELLIS and TripoSR (3D), Text-to-CAD, OpenMontage (multimodal montage), Video-Shotcraft (shot direction), Palmier-Pro (timeline and grading), driven through `comfyui-mcp`. Installed as a separate power-up module, not a skill in this catalogue. |
 | Concept not settled yet | `bdbmediastorm` first — it runs the grilling interview for show-control and media work |