session-orchestrator 3.24.0 → 4.0.0

package/skills/journey-audit/SKILL.md

@@ -1,270 +0,0 @@
----
-name: journey-audit
-description: >
-  Use this skill when the user wants the PRODUCT audited from the outside in — what the website
-  promises vs what the code does vs what a real user experiences vs what actually arrives by mail
-  vs what the data says is used. Runs a 7-role read-only wave (R5 writes only under an explicit
-  SAFETY block) against a per-repo `.orchestrator/journey-manifest.md` and writes a dossier to
-  docs/audits/. Distinct from /discovery, which checks code quality inside-out — this checks
-  product truth outside-in; they complement, neither replaces the other. Triggers "journey audit",
-  "Nutzersicht-Audit", "audit the product from the user's side", "/journey-audit".
-model: inherit
-color: purple
-tools: Read, Grep, Glob, Bash, Write, Task
----
-
-# Journey Audit
-
-> Outside-in product audit as a repeatable deep session. Code review checks code against code;
-> this checks the product against the user's experience. Quarterly, never a CI component.
-
-## Purpose
-
-The most expensive defects of a consumer product's first run (session id redacted) — a core
-feature with no entry point anywhere in the UI, burned free quota, a plan gate that could be
-bypassed, a claim-vs-code contradiction, EUR copy in a USD context — are **invisible to every
-code-centric check**. They are not bugs in a function; they are gaps between five surfaces —
-marketing copy, code constants, live UI, outbound mail, real usage data — that no single
-surface can reveal.
-
-This skill dispatches seven roles that each own one surface, then makes the coordinator personally
-re-verify every P0 before it is written down. The re-verification is the value, not the fan-out:
-the first run caught 2 agent errors that way and confirmed 3 real P0s.
-
-## Phase 0: Gates
-
-### 0.1 Bootstrap Gate
-
-Read `skills/_shared/bootstrap-gate.md` and execute the gate check. GATE_CLOSED → invoke
-`skills/bootstrap/SKILL.md` first. GATE_OPEN → continue.
-
-### 0.2 Manifest HARD-GATE
-
-<HARD-GATE>
-Read `.orchestrator/journey-manifest.md` in the target repo (or the path passed as `$ARGUMENTS`).
-
-**A — File missing or empty → REFUSE the whole run.** Say exactly this, then stop:
-
-> `/journey-audit` needs `.orchestrator/journey-manifest.md` in this repo and it is not there.
-> The audit is repo-specific: without personas, entry points, truth-SSOTs, the chat-interview key
-> and the SAFETY block, seven agents would invent their own definition of "correct" and every
-> finding would be unfalsifiable.
-> Copy the template — `templates/_shared/journey-manifest.md` in the session-orchestrator plugin —
-> to `.orchestrator/journey-manifest.md`, fill it in, then re-run `/journey-audit`.
-
-**B — Manifest present, `## SAFETY` heading absent or its body empty → REFUSE R5 ONLY.** R5 is the
-only role that touches production with a real account. Say:
-
-> The manifest has no filled `## SAFETY` block, so R5 (real end-to-end run against production) is
-> NOT dispatched. Running as dry-run: R1–R4 + R7 (R6 additionally needs the read-only DB
-> credentials named in the manifest). Fill in allowed accounts/events, no-go actions, the checkout
-> limit and the cleanup rule to enable R5.
-
-Do NOT infer a SAFETY block from other sections, do NOT ask the operator to dictate one into chat,
-do NOT dispatch R5 "read-only, just this once". A production write without a written, committed
-safety envelope is the one thing this skill never does.
-</HARD-GATE>
-
-Both gates are cheap and mechanical:
-
-```bash
-MANIFEST="${1:-.orchestrator/journey-manifest.md}"
-[ -s "$MANIFEST" ] || { echo "GATE-A: no manifest"; exit 1; }
-awk '/^## SAFETY/{f=1;next} /^## /{f=0} f&&NF{c++} END{exit c>0?0:1}' "$MANIFEST" \
-  || echo "GATE-B: SAFETY block absent or empty → R5 disabled"
-```
-
-### 0.3 Peer-session check (before dispatch, not after)
-
-Run `ListAgents` / read `.orchestrator/` session locks and check for peer sessions in this working
-copy per `.claude/rules/parallel-sessions.md`. A journey audit reads wide and R5 writes to
-production — a peer holding the same files must know before the wave starts, not from the diff.
-Announce the audit and the file scope you will touch; the audit itself claims almost no write
-scope, which is exactly why it is easy to forget.
-
-## Phase 1: Read the manifest
-
-Parse the manifest into `$MANIFEST` and derive per-role inputs. Every role prompt below is filled
-from these fields — an empty field is reported to the operator, never guessed:
-
-`personas` · `entry_points` · `truth_ssots` · `touchpoints` (template dir, send path, cron sources,
-render idiom) · `chat_interview` (question → expected answer → SSOT) · `safety` · `credentials`
-(env-var NAMES) · `realdata_queries` · `platform_expectation` · `known_exceptions`.
-
-## Phase 2: The wave — R1–R7
-
-All roles are **read-only** except R5. All run in parallel in one wave; none depends on another's
-output (the coordinator, not an agent, joins their findings).
-
-| R | Rolle | Generisch | Aus dem Manifest |
-|---|-------|-----------|------------------|
-| R1 | Flow-Zensus | Trigger→Empfänger→Zeitpunkt→Dedupe map of every outbound touchpoint (mail/push/webhook) | Template dir, send path, cron sources |
-| R2 | Artefakt-Rendering | Render templates to HTML, screenshots desktop/mobile/dark, consistency matrix | Render idiom, example props |
-| R3 | Claim-vs-Code-Matrix | Every marketing/FAQ/chat claim against the SSOT constants; feature inventory × surfaces | SSOT files, i18n namespaces, chat fact source |
-| R4 | Anonymer Live-Rundgang | agent-browser desktop+mobile, chat interview against the truth key, dead links, console | Route list, chat questions + expected answers |
-| R5 | Echter E2E-Durchstich | Prod, real account, actually execute each core flow, DB counter-check, mail-log reconciliation | **SAFETY block (mandatory)** |
-| R6 | Realdaten-Funnel | Usage funnel, never-fired flows, delivery defects, name what is not measurable | Read-only DB access, identity rules, mail-provider API |
-| R7 | Plattform-Ausnutzung | Self-built vs platform matrix (hosting/DB/realtime/queues/CDN/WAF), limits at 10× | CLI logins, expected plan, open perf issues |
-
-### Shared prompt preamble (prepend to every role)
-
-> You are role `<R#>` of a journey audit of `<repo>`. Manifest: `.orchestrator/journey-manifest.md`
-> — read it first; it is your only definition of "correct". You are **read-only**: no `Edit`, no
-> `Write` outside your own report, no git write operations (PSA-007), no production writes.
-> Every distributional claim ("all N routes", "no template does X") carries the executed command
-> and its output (PSA-006). A finding you cannot reproduce with a quoted command is a suspicion —
-> label it as one. Findings listed under `Bekannte Ausnahmen` in the manifest are reported as
-> `known-exception`, never as new. Severity: **P0** = money, data loss, or a core flow unreachable ·
-> **P1** = a broken flow or a UX dead end · **P2** = content/platform. Return the FULL report as
-> your last message.
-
-### Role prompt skeletons
-
-Each is self-contained; fill the `<…>` from `$MANIFEST`.
-
-**R1 — Flow-Zensus.** Inputs: template dir `<…>`, send path `<…>`, cron sources `<…>`.
-Task: enumerate every outbound touchpoint and produce one row per flow: trigger (code location) →
-recipient (which persona) → timing → dedupe/idempotency → is it reachable at all. Grep the send
-path for callers; a template with zero callers is a P1 finding, a caller with no dedupe on a
-money-relevant flow is P0. Output: Markdown table + a list of `never-fired` candidates with the
-grep that proves zero callers.
-
-**R2 — Artefakt-Rendering.** Inputs: render idiom `<…>`, example props `<…>`.
-Task: render every template found by R1's directory to HTML, screenshot desktop + mobile + dark,
-and build a consistency matrix (logo, sender, footer, legal block, CTA, language, currency).
-Output: matrix table + the artifact paths under `.orchestrator/journey-audit/<date>/`, plus every
-divergence as a finding. Do not fix a template; report it.
-
-**R3 — Claim-vs-Code-Matrix.** Inputs: SSOT files `<…>`, i18n namespaces `<…>`, chat fact source `<…>`.
-Task: extract every quantitative or capability claim from marketing pages, FAQ, pricing, chat facts
-and mail copy; compare each against the SSOT constant. One row: claim · where it is said · SSOT
-value · verdict (`match` / `drift` / `unbacked`). Then a feature inventory × surfaces grid: a
-feature that exists in code but appears on no surface is a P0 candidate ("no entry point").
-**i18n files are owned by R3 alone** — no other role opens them.
-Output: two tables + findings.
-
-**R4 — Anonymer Live-Rundgang.** Inputs: route list `<…>`, chat questions + expected answers `<…>`.
-Task: `agent-browser`, logged OUT, desktop and mobile viewport. Walk every route: dead links,
-console errors, layout breaks, CTA that goes nowhere. Then run the chat interview verbatim and
-score each answer against the expected answer from the manifest (`match` / `drift` / `refused` /
-`hallucinated`). Output: route table (status, console, findings), interview table, screenshots.
-Read-only: never submit a form that creates data, never sign up.
-
-**R5 — Echter E2E-Durchstich.** Inputs: SAFETY block `<…>`, credentials by env-var NAME `<…>`.
-Task: with the allowed account only, actually execute each core flow end to end in production;
-counter-check in the DB read-only that the expected records exist; reconcile against the mail log.
-**Before every step, re-read the SAFETY block and state which rule permits this step.** Stop at the
-first no-go, do not improvise around a block, honour the checkout limit exactly, and run the
-cleanup rule at the end and prove it ran. Output: per-flow trace (step → observed → expected →
-verdict), the DB counter-check output, the cleanup proof.
-
-**R6 — Realdaten-Funnel.** Inputs: read-only queries `<…>`, identity rules `<…>`, mail-provider API `<…>`.
-Task: run the manifest's `SELECT`s only. Build the funnel per persona, list flows that never fired
-in production, and pull delivery defects from the mail provider (bounces, suppressions, a
-permanently silenced owner address). Then name explicitly what the data CANNOT answer — an unnamed
-blind spot reads as a zero. Output: funnel table, never-fired list, delivery-defect list,
-`not-measurable` list. No writes, no schema changes, no query outside the manifest.
-
-**R7 — Plattform-Ausnutzung.** Inputs: CLI logins `<…>`, expected plan/tier `<…>`, open perf issues `<…>`.
-Task: self-built vs platform matrix across hosting, DB, realtime, queues, CDN, WAF, cron, mail:
-what does the repo hand-roll that the paid platform already provides, and what breaks at 10× today's
-load (quote the actual limit from the provider CLI/API, not from memory). Output: matrix
-(capability · self-built? · platform feature · effort to switch · limit at 10×) + findings.
-
-## Phase 3: Koordinator-Disziplin
-
-Numbered MUSTs. This phase is the skill; the wave is only its input.
-
-1. **Every P0 claim is re-verified by the coordinator, individually, with its OWN grep/curl/DB read,
-   before it enters the dossier.** Not "the agent quoted a command" — you run one yourself, and the
-   dossier carries YOUR command and output. An unreproduced P0 is downgraded to P1 with the note
-   `agent claim, not reproduced`, or dropped. First run: 2 of 5 P0 claims were agent errors
-   ("instantly unreachable" — it was selectable in the UI; "USD on prod" — a session artifact).
-2. **A finding is attributed.** Every dossier row names the role that found it and the command that
-   proves it — the reader must be able to re-run it without asking anyone.
-3. **i18n files are owned by exactly ONE agent (R3).** They were the known contention point in the
-   first run: many roles want to quote them, and a second reader turns into a second writer the
-   moment a fix is suggested. Same rule for any other file two roles both want.
-4. **Peer-session check before the wave starts** (Phase 0.3), not after the diff.
-5. **The coordinator never lets an agent write the dossier.** Agents return reports; the joining,
-   de-duplication and severity decision are the coordinator's, because contradictions between two
-   agents are only visible in one place.
-6. **Contradictions are reported as contradictions.** Two roles disagreeing is a finding about the
-   product, not a merge conflict to smooth over.
-7. **No fixes during the audit.** Findings only. The fix wave is Phase 5 and is a separate decision.
-
-## Phase 4: Dossier
-
-Write `docs/audits/YYYY-MM-DD-user-journey-audit.md` with this fixed section order:
-
-1. `## P0 — Geld & Kern-Flows` (each: symptom · evidence (coordinator's own command + output) ·
-   impact · suggested fix · role)
-2. `## P1 — Flows`
-3. `## P1 — UX`
-4. `## P2 — Inhalt`
-5. `## P2 — Plattform`
-6. `## Realdaten` (funnel, never-fired flows, delivery defects, explicitly not-measurable)
-7. `## Marketing-Hebel` (what the product does well and says nowhere)
-
-Header carries: date, repo, HEAD SHA, roles dispatched (and which were skipped, with the reason —
-"R5 skipped: no SAFETY block" is a result, not a gap), manifest path, artifact directory.
-
-## Phase 5: Closing AskUserQuestion
-
-One `AskUserQuestion` call, per `.claude/rules/ask-via-tool.md` (option 1 `(Recommended)`, every
-description carries reason + cost + consequence, `header` ≤ 12 codepoints):
-
-```
-AskUserQuestion({ questions: [
-  { question: "Which fix packages should the follow-up wave carry?",
-    header: "Fix-Wellen", multiSelect: true,
-    options: [
-      { label: "P0 money+core (Recommended)", description: "The <N> P0s I re-verified myself. Blocks revenue/core flow today; ~<X>h; freezes nothing else." },
-      { label: "P1 flows",  description: "<N> broken/undedupliced flows. ~<X>h; needs the R1 map as input." },
-      { label: "P1 UX",     description: "<N> dead ends. Cheap individually, touches i18n — one owner." },
-      { label: "P2 content+platform", description: "<N> items. No user impact today; do in cooldown." } ] },
-  { question: "Create issues for the selected packages?",
-    header: "Issues", multiSelect: false,
-    options: [
-      { label: "Yes, batch now (Recommended)", description: "One issue per finding via gitlab-ops; labels priority::critical|high|medium + area:* + type:bug/feature. ~<N> issues; respects issue-budget." },
-      { label: "Dossier only", description: "No issues; the dossier stays the record. Choose when the backlog is already over budget." } ] } ] })
-```
-
-Issue creation follows `skills/gitlab-ops/SKILL.md` § Label Taxonomy: `priority::critical` for P0,
-`priority::high` for P1, `priority::medium` for P2, plus the repo's `area:` and `type:` axes. Each
-issue links back to the dossier section that produced it.
-
-## Offload note (R6/R7)
-
-R6 and R7 are pure CLI/API roles — no browser, no repo writes — so they can run headless on a
-second machine (`claude -p "<prompt>"`, see the `m5-offload` skill). Two rules from the first run,
-both learned the hard way:
-
-- **`claude -p` prints only the LAST message.** The prompt MUST end with: *"Return the complete
-  report in your last message — not a summary, not a pointer to a file. Nothing you say before the
-  last message will be read."*
-- **No background processes.** The prompt MUST forbid `&`, `run_in_background`, and any "I'll keep
-  it running" pattern: the process is killed when `-p` returns, and a half-finished role looks
-  identical to a clean one.
-
-## Cadence & Abgrenzung
-
-- **Quarterly, or after a large feature drop.** Deliberately **not a CI component** — it is
-  expensive and judgment-heavy, and a judgment-heavy gate that runs on every pipeline becomes a
-  rubber stamp.
-- **Optional monthly light variant:** R3 + R4 only, as a scheduled cloud session.
-- **vs `/discovery`:** discovery checks code quality inside-out (probes over the tree);
-  journey-audit checks product truth outside-in (five user-facing surfaces against each other).
-  Neither replaces the other; a repo needs both.
-- **Follow-through:** after each run, freeze the mechanizable parts per repo — a `report:*` script,
-  a claim-drift test pinned to the SSOT constant — so the next run is cheaper. The audit's job is
-  to find what no test knows how to look for yet.
-
-## Anti-Patterns
-
-- Dispatching R5 without a SAFETY block "because the operator said it's fine in chat" — the block
-  is a committed artifact for a reason.
-- Copying an agent's P0 into the dossier because its command looked convincing (Phase 3.1).
-- Two roles both editing/owning the i18n files (Phase 3.3).
-- Running the audit as a CI job to "keep it honest" — it turns into a stamp nobody reads.
-- Fixing findings mid-audit, so the later roles measure a moving product.

package/skills/skill-creator/SKILL.md

@@ -1,168 +0,0 @@
----
-name: skill-creator
-description: Use when creating a new skill from scratch, modifying an existing skill, or optimizing a skill's triggering description. Guides intent capture, structure, writing patterns, and progressive-disclosure organization so skills reliably trigger and stay maintainable. Trigger on phrases like "turn this into a skill", "write a skill for X", "improve this skill", "my skill isn't triggering".
-model: sonnet
----
-
-# Skill Creator
-
-A process skill for writing skills well.
-
-Adapted from [anthropics/skills/skill-creator](https://github.com/anthropics/skills/tree/main/skills/skill-creator) — we keep the authoring workflow and progressive-disclosure guidance but drop the Python eval-viewer harness (not part of our stack).
-
-## The loop
-
-1. **Capture intent** — what should the skill do? When should it trigger?
-2. **Draft** SKILL.md with frontmatter + body
-3. **Test** — 2–3 realistic prompts, see if Claude triggers + executes right
-4. **Improve** based on failures (wrong trigger, wrong output, over-verbose, etc.)
-5. **Optimize description** if triggering is unreliable
-
-## 1. Capture Intent
-
-If the user said "turn X into a skill", extract from conversation history: the tools used, the sequence of steps, corrections the user made, input/output formats observed. Confirm gaps before proceeding.
-
-Ask explicitly:
-1. What should this skill enable Claude to do?
-2. When should it trigger? (user phrases / contexts)
-3. What's the expected output format?
-4. Does this skill have objectively verifiable outputs? (if yes, test cases help; if subjective like writing style / art, skip them)
-
-## 2. Write the SKILL.md
-
-### Frontmatter
-
-```yaml
----
-name: kebab-case-name
-description: One or two sentences covering what it does AND when to trigger. Mention multiple trigger phrases/contexts (Claude tends to UNDER-trigger — err on "pushy").
----
-```
-
-**Description anti-patterns:**
-- ❌ "How to build a dashboard." (no triggers)
-- ✅ "Use when building a dashboard, visualizing data, or displaying metrics — trigger even if the user doesn't say 'dashboard' but mentions charts, KPIs, or metric displays."
-
-### Body anatomy
-
-```
-skill-name/
-├── SKILL.md           (required — frontmatter + body, <500 lines ideal)
-├── scripts/           (optional — executable code for deterministic/repetitive tasks)
-├── references/        (optional — docs loaded into context only when needed)
-└── assets/            (optional — templates, fixtures)
-```
-
-### Progressive disclosure
-
-Skills load in three levels:
-1. **Frontmatter** — always in Claude's context (~100 tokens)
-2. **SKILL.md body** — loaded when skill triggers (keep <500 lines)
-3. **Reference files** — loaded on demand (unlimited size, cite with clear "read when X" guidance)
-
-If SKILL.md exceeds 500 lines, split by domain:
-
-```
-cloud-deploy/
-├── SKILL.md              (workflow + "if AWS: read references/aws.md")
-└── references/
-    ├── aws.md
-    ├── gcp.md
-    └── azure.md
-```
-
-## 3. Writing patterns
-
-### Imperative voice
-
-Prefer "Write tests for X" over "Tests should be written for X". Agents respond better to direct instruction.
-
-### Explain the WHY
-
-LLMs are smart. When you write a rule, explain why — the agent can then handle edge cases intelligently. If you find yourself writing ALWAYS or NEVER in all caps, that's a yellow flag: reframe and explain.
-
-**Bad:** "ALWAYS use parameterized queries."
-**Good:** "Use parameterized queries. Reason: string-concatenation SQL is the #1 injection vector in our incident history."
-
-### Output format blocks
-
-When the skill produces structured output:
-
-```markdown
-## Report structure
-Always use this exact template:
-# [Title]
-## Executive summary
-## Key findings
-## Recommendations
-```
-
-### Examples
-
-```markdown
-## Commit message format
-**Example 1:**
-Input:  Added user authentication with JWT tokens
-Output: feat(auth): implement JWT-based authentication
-```
-
-## 4. Test cases
-
-Write 2–3 realistic test prompts — the kind a real user would actually type (include file paths, specific contexts, casual speech, typos). Run Claude with + without the skill and compare.
-
-**Bad test prompts:** "Format this data", "Create a chart" — too abstract.
-**Good test prompts:** "ok so my boss sent me Q4_sales_FINAL_v2.xlsx and wants a profit-margin column (revenue col C, cost col D)" — concrete, realistic.
-
-Coordinator-direct in our harness: dispatch two Agent() calls (one with skill-path, one without) and compare outputs qualitatively. We do NOT run the upstream Python eval viewer — that's over-engineered for our workflow.
-
-## 5. Description optimization
-
-If the skill doesn't trigger reliably, the description is usually at fault.
-
-Generate 20 eval queries:
-- 8–10 **should-trigger** (different phrasings, casual/formal, edge cases)
-- 8–10 **should-not-trigger** — near-misses that share keywords but need different handling
-
-Score the current description against these queries. Rewrite → re-score → iterate.
-
-**Key insight:** Claude only consults skills for tasks it can't easily handle on its own. Simple queries ("read this file") won't trigger skills regardless of description quality. Write eval queries that are substantive enough to actually benefit from the skill.
-
-## Improvement heuristics
-
-When revising based on failures:
-
-1. **Generalize from feedback** — one user's test case is a proxy for millions of invocations. Don't overfit.
-2. **Keep it lean** — remove instructions that aren't earning their token cost. Re-read transcripts to see where the model wastes time.
-3. **Explain the WHY** — always.
-4. **Look for repeated work** — if every invocation writes the same helper script, bundle it in `scripts/`.
-
-## Anti-patterns
-
-- ❌ MUSTs and NEVERs without explanation
-- ❌ Monolithic SKILL.md >500 lines without reference-file split
-- ❌ Description that only lists what the skill does, without trigger phrases
-- ❌ Test prompts that are too abstract to be realistic
-- ❌ Skills that duplicate what existing tools already do well
-
-## Model Tier Selection
-
-When adding `model:` frontmatter to a new skill, apply these criteria:
-
-| Tier | When to use | Examples |
-|---|---|---|
-| `opus` | Complex multi-step reasoning, planning, architecture, open-ended synthesis | session-plan, plan, architecture |
-| `sonnet` | Workhorse tasks: orchestration, analysis, code generation, aggregation | session-start, wave-executor, discovery, evolve, skill-creator |
-| `haiku` | Routing, lookup, triage, reference reads, driver wrappers, simple file writes | gitlab-ops, quality-gates, mode-selector, daily, peekaboo-driver |
-| `inherit` | Skill runs inside coordinator's context and should match the coordinator's tier; also for `disable-model-invocation: true` skills | session-start, session-end, domain-model, ubiquitous-language |
-
-Decision rule: if the skill reasons over many options or produces a structural plan, use `opus`. If it executes defined steps, use `sonnet`. If it reads a config and emits a fixed output, use `haiku`. If it is a pass-through that the coordinator controls, use `inherit`.
-
-## Checklist
-
-- [ ] Frontmatter has `name` + `description` with explicit trigger phrases
-- [ ] Frontmatter has `model:` set per the Model Tier Selection table above
-- [ ] Body uses imperative voice
-- [ ] WHYs explained for any rules
-- [ ] Large sections split into `references/` if >500 lines
-- [ ] At least 2 realistic test prompts drafted
-- [ ] Examples in input/output format where relevant

package/skills/ubiquitous-language/SKILL.md

@@ -1,97 +0,0 @@
----
-name: ubiquitous-language
-description: Use when the user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions "domain model" or "DDD". Extracts a DDD-style glossary from the current conversation into UBIQUITOUS_LANGUAGE.md, flags ambiguities and synonyms, and proposes opinionated canonical terms.
-model: inherit
-disable-model-invocation: true
-derived-from: mattpocock/skills@90ea8ee
-license: MIT
-upstream-url: https://github.com/mattpocock/skills/tree/main/ubiquitous-language
----
-
-# Ubiquitous Language
-
-Extract and formalize domain terminology from the current conversation into a consistent glossary, saved to a local file.
-
-## Process
-
-1. **Scan the conversation** for domain-relevant nouns, verbs, and concepts
-2. **Identify problems**:
-   - Same word used for different concepts (ambiguity)
-   - Different words used for the same concept (synonyms)
-   - Vague or overloaded terms
-3. **Propose a canonical glossary** with opinionated term choices
-4. **Write to `UBIQUITOUS_LANGUAGE.md`** in the working directory using the format below
-5. **Output a summary** inline in the conversation
-
-## Output Format
-
-Write a `UBIQUITOUS_LANGUAGE.md` file with this structure:
-
-```md
-# Ubiquitous Language
-
-## Order lifecycle
-
-| Term        | Definition                                              | Aliases to avoid      |
-| ----------- | ------------------------------------------------------- | --------------------- |
-| **Order**   | A customer's request to purchase one or more items      | Purchase, transaction |
-| **Invoice** | A request for payment sent to a customer after delivery | Bill, payment request |
-
-## People
-
-| Term         | Definition                                  | Aliases to avoid       |
-| ------------ | ------------------------------------------- | ---------------------- |
-| **Customer** | A person or organization that places orders | Client, buyer, account |
-| **User**     | An authentication identity in the system    | Login, account         |
-
-## Relationships
-
-- An **Invoice** belongs to exactly one **Customer**
-- An **Order** produces one or more **Invoices**
-
-## Example dialogue
-
-> **Dev:** "When a **Customer** places an **Order**, do we create the **Invoice** immediately?"
-> **Domain expert:** "No — an **Invoice** is only generated once a **Fulfillment** is confirmed. A single **Order** can produce multiple **Invoices** if items ship in separate **Shipments**."
-> **Dev:** "So if a **Shipment** is cancelled before dispatch, no **Invoice** exists for it?"
-> **Domain expert:** "Exactly. The **Invoice** lifecycle is tied to the **Fulfillment**, not the **Order**."
-
-## Flagged ambiguities
-
-- "account" was used to mean both **Customer** and **User** — these are distinct concepts: a **Customer** places orders, while a **User** is an authentication identity that may or may not represent a **Customer**.
-```
-
-## Rules
-
-- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.
-- **Flag conflicts explicitly.** If a term is used ambiguously in the conversation, call it out in the "Flagged ambiguities" section with a clear recommendation.
-- **Only include terms relevant for domain experts.** Skip the names of modules or classes unless they have meaning in the domain language.
-- **Keep definitions tight.** One sentence max. Define what it IS, not what it does.
-- **Show relationships.** Use bold term names and express cardinality where obvious.
-- **Only include domain terms.** Skip generic programming concepts (array, function, endpoint) unless they have domain-specific meaning.
-- **Group terms into multiple tables** when natural clusters emerge (e.g. by subdomain, lifecycle, or actor). Each group gets its own heading and table. If all terms belong to a single cohesive domain, one table is fine — don't force groupings.
-- **Write an example dialogue.** A short conversation (3-5 exchanges) between a dev and a domain expert that demonstrates how the terms interact naturally. The dialogue should clarify boundaries between related concepts and show terms being used precisely.
-
-<example>
-
-## Example dialogue
-
-> **Dev:** "How do I test the **sync service** without Docker?"
-
-> **Domain expert:** "Provide the **filesystem layer** instead of the **Docker layer**. It implements the same **Sandbox service** interface but uses a local directory as the **sandbox**."
-
-> **Dev:** "So **sync-in** still creates a **bundle** and unpacks it?"
-
-> **Domain expert:** "Exactly. The **sync service** doesn't know which layer it's talking to. It calls `exec` and `copyIn` — the **filesystem layer** just runs those as local shell commands."
-
-</example>
-
-## Re-running
-
-When invoked again in the same conversation:
-
-1. Read the existing `UBIQUITOUS_LANGUAGE.md`
-2. Incorporate any new terms from subsequent discussion
-3. Update definitions if understanding has evolved
-4. Re-flag any new ambiguities
-5. Rewrite the example dialogue to incorporate new terms

package/skills/vault-sync/package-lock.json

@@ -1,40 +0,0 @@
-{
-  "name": "@session-orchestrator/vault-sync",
-  "version": "0.1.0",
-  "lockfileVersion": 3,
-  "requires": true,
-  "packages": {
-    "": {
-      "name": "@session-orchestrator/vault-sync",
-      "version": "0.1.0",
-      "dependencies": {
-        "yaml": "^2.5.0",
-        "zod": "^3.24.0"
-      }
-    },
-    "node_modules/yaml": {
-      "version": "2.8.3",
-      "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.8.3.tgz",
-      "integrity": "sha512-AvbaCLOO2Otw/lW5bmh9d/WEdcDFdQp2Z2ZUH3pX9U2ihyUY0nvLv7J6TrWowklRGPYbB/IuIMfYgxaCPg5Bpg==",
-      "license": "ISC",
-      "bin": {
-        "yaml": "bin.mjs"
-      },
-      "engines": {
-        "node": ">= 14.6"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/eemeli"
-      }
-    },
-    "node_modules/zod": {
-      "version": "3.25.76",
-      "resolved": "https://registry.npmjs.org/zod/-/zod-3.25.76.tgz",
-      "integrity": "sha512-gzUt/qt81nXsFGKIFcC3YnfEAx5NkunCfnDlvuBSSFS02bcXu4Lmea0AFIUwbLWxWPx3d9p8S5QoaujKcNQxcQ==",
-      "license": "MIT",
-      "funding": {
-        "url": "https://github.com/sponsors/colinhacks"
-      }
-    }
-  }
-}