@synap-core/workspace-templates 0.3.0 → 0.4.0

package/package.json

@@ -1,18 +1,28 @@
 {
   "name": "@synap-core/workspace-templates",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "type": "module",
+  "packageManager": "pnpm@9.15.4",
   "description": "Canonical workspace definitions — YAML source + typed exports for browser, backend, CLI, and marketplace",
   "exports": {
     ".": {
-      "types": "./dist/index.d.ts",
-      "default": "./dist/index.js"
+      "types": "./src/index.ts",
+      "node": "./dist/index.js",
+      "default": "./src/index.ts"
     }
   },
   "files": [
     "dist",
     "src"
   ],
+  "scripts": {
+    "type-check": "tsc --noEmit",
+    "build:yaml": "node build.mjs",
+    "build": "node build.mjs && tsc -p tsconfig.build.json",
+    "provision": "node scripts/provision.mjs",
+    "eval": "node scripts/eval-standard.mjs",
+    "prepublishOnly": "node build.mjs && tsc -p tsconfig.build.json"
+  },
   "dependencies": {
     "zod": "^3.0.0",
     "js-yaml": "^4.1.0"
@@ -24,16 +34,15 @@
   },
   "publishConfig": {
     "registry": "https://registry.npmjs.org",
-    "access": "public"
-  },
-  "scripts": {
-    "type-check": "tsc --noEmit",
-    "build:yaml": "node build.mjs",
-    "build": "node build.mjs && tsc -p tsconfig.build.json",
-    "provision": "node scripts/provision.mjs",
-    "eval": "node scripts/eval-standard.mjs"
-  },
-  "main": "./dist/index.js",
-  "module": "./dist/index.js",
-  "types": "./dist/index.d.ts"
-}
+    "access": "public",
+    "main": "./dist/index.js",
+    "module": "./dist/index.js",
+    "types": "./dist/index.d.ts",
+    "exports": {
+      ".": {
+        "types": "./dist/index.d.ts",
+        "default": "./dist/index.js"
+      }
+    }
+  }
+}

package/src/agent-fleet.yaml

@@ -1016,6 +1016,44 @@ playbooks:
 onboarding:
   goal: "Capture the agent fleet the user runs — the agents themselves, the model providers behind them, the skills they carry, and the projects they work — so the workspace reflects their real AI operation."
   framing: "Act as a pragmatic AI ops lead. Tease out which agents are live, what models and providers power them, what each agent can do, and what work they're pointed at. Translate that into agents, providers, skills, and projects."
+  expertise:
+    starters:
+      - >
+        For every live agent, pin down the trio that actually matters: model, provider, and daily
+        budget ceiling. "I have an agent" is not an entity — "a Coder agent on Claude via OpenRouter,
+        capped at $5/day" is. Lead by capturing that trio for the one agent running most, then fan
+        out. An agent with no budget number is an uncapped spend waiting to happen.
+      - >
+        Capture each provider as its own entity with cost-per-token AND key health, not just a name.
+        Propose logging the provider behind your busiest agent first, with its input/output token
+        cost and when the key expires — because the two ways a fleet dies are a blown budget and an
+        expired key, and both live on the provider, not the agent.
+      - >
+        Scope each agent to ONE role and catalogue the specific skills it carries, with a trust
+        level on each. Lead with "what is this agent FOR, and what exactly can it do?" A named,
+        scoped agent with three trusted skills beats one vague "assistant" agent that can supposedly
+        do everything.
+    blindSpots:
+      - >
+        Untracked spend is the fleet-killer. Agents burn tokens silently — a runaway loop, a retry
+        storm, a context window nobody trimmed — and the first signal is the invoice. Surface daily
+        budget ceilings and weekly actual spend per provider proactively; the CFO view (which work
+        is burning budget) is the one nobody builds until it's too late.
+      - >
+        The "one agent for everything" anti-pattern feels efficient and is the opposite. A single
+        generalist agent with every skill and every key is un-auditable, un-scopeable, and a fat
+        blast radius when a skill goes rogue. Push toward scoped agents — Coder, Researcher, Ops —
+        each with only the skills and provider budget its job needs.
+      - >
+        Single-provider risk hides until the provider has an outage or rate-limits you mid-run.
+        Teams wire every agent to one provider and have no fallback, so one 429 halts the whole
+        fleet. Capture provider fallback intent (primary + backup) so a single vendor's bad day
+        isn't your whole operation's bad day.
+    bar: >
+      A great result is a fleet you can run like an operation, not a pile of daemons: every live
+      agent has a model, a provider, a budget, and a scoped set of trusted skills; every provider
+      shows its cost, key health, and spend-against-budget; and you can answer "which agent is
+      burning the most, on whose key, and what happens if that provider goes down?" in one glance.
   collect:
     - profileSlug: agent
       what: "The agents they run and what powers each"

package/src/brand-library.yaml

@@ -518,6 +518,43 @@ onboarding:
     colors, type), and the non-negotiable rules. Translate fuzzy vibes into
     concrete voice guides and rules. Reference the Foundation (mission, audience,
     positioning) so the brand expresses the strategy, never contradicts it.
+  expertise:
+    starters:
+      - >
+        Adjectives don't define a voice — "friendly, bold, human" describes every
+        brand and constrains none. Propose voice as a small set of DO / DON'T pairs
+        instead ("say 'you', not 'users'"; "short declaratives, never hedged
+        qualifiers"). Pairs are testable; adjectives are decoration.
+      - >
+        A voice guide is only real if it survives a sentence test. Take one actual
+        line from their site or a competitor's and rewrite it in the proposed voice
+        on the spot — if the rewrite looks identical to the original, the voice isn't
+        differentiated yet. Push until the two versions are visibly different.
+      - >
+        Build the palette around ROLES, not just favorite colors. Pin the semantic
+        roles first — primary, surface, text, and one restrained accent — and make
+        the accent earn its keep. Most brands leak trust by using three "brand
+        colors" as accents; propose one hero accent and demote the rest to support.
+    blindSpots:
+      - >
+        "Brand = logo" is the classic trap. The logo is the least-used, most-argued
+        asset; the voice, the color roles, and the do/don't rules drive 90% of what
+        anyone actually ships. If they lead with the logo, redirect to how the brand
+        SOUNDS and behaves in a paragraph of copy.
+      - >
+        Rules with no severity are ignored. A pile of equally-weighted "guidelines"
+        gives an AI or a teammate nothing to obey — mark each as mandatory,
+        important, or guideline so the non-negotiables (clearspace, accessibility
+        contrast, forbidden words) actually hold under pressure.
+      - >
+        Color contrast is a silent brand-killer: a beautiful palette that fails WCAG
+        AA on text is off-brand the moment it's inaccessible. If they've picked
+        colors without checking text-on-surface contrast, flag it before it's
+        codified into tokens.
+    bar: >
+      A stranger handed the voice pairs, the color roles, and the rules could write a
+      new paragraph and pick a button color that both read unmistakably as THIS brand —
+      and every rule is testable on a real sentence or a real screen, not a vibe.
   collect:
     - profileSlug: brand-identity
       what: The core brand identity — name, essence, and how it presents itself.

package/src/builder.yaml

@@ -1266,6 +1266,42 @@ onboarding:
     lives (repos + local paths), what runs behind each app, where it deploys, and what's on
     the bench right now. Prefer concrete over aspirational — a repo URL beats a wish. Tie the
     roadmap back to the Foundation's mission and audiences: the surface exists to serve them.
+  expertise:
+    starters:
+      - >
+        Don't ask "what do you want to build?" — ask what's already running. Propose starting from
+        the ONE app that's live today, its primary deploy target, and the single feature in flight
+        right now. One real node with a repo URL beats ten aspirational ones. The map grows from
+        what exists, not from the org chart you wish you had.
+      - >
+        For each app, capture the deploy path end to end: repo → branch that auto-deploys → target
+        (Vercel/Coolify/bare VPS) → the URL it lands on. A node that says "app" but can't answer
+        "how does a commit reach production?" is a label, not a map.
+      - >
+        Lead with the in-flight work as first-class entities, not a backlog dump. Take the feature
+        being coded this week, give it a status and an acceptance criterion, and link it to its app.
+        That single live thread is what makes the workspace a command center instead of a wiki.
+    blindSpots:
+      - >
+        The map is worthless the moment it drifts from reality. Founders capture the IDEAL
+        architecture (the clean diagram) instead of the system AS IT IS — the hacky cron, the
+        service everyone forgot owns auth, the package no one dares upgrade. Capture the mess;
+        the mess is where the incidents come from.
+      - >
+        "We'll document it later" is how tribal knowledge dies. The one engineer who knows why
+        service X can't be restarted during a deploy leaves, and it becomes a 2am incident. Capture
+        the non-obvious operational facts (decision records, gotchas) NOW, while someone still
+        remembers the why — not after the outage.
+      - >
+        Packages and their dependency edges are the silent killer. Founders track apps but not the
+        shared substrate underneath — so a "small" bump to a core package breaks three apps nobody
+        connected to it. Capture what depends on what; the blast radius lives in the edges, not the
+        nodes.
+    bar: >
+      A great result is a graph you can navigate in any direction to answer a real operational
+      question — "if I bump this package, what breaks?", "how does a commit reach prod for app X?",
+      "what's actually in flight and who's on it?" — and every answer matches what's true in the
+      terminal right now, not what was true at kickoff.
   collect:
     - profileSlug: devplane_app
       what: The apps that are shipped or actively being built — with where their code lives and what stack they run on.

package/src/content-os.yaml

@@ -1009,6 +1009,37 @@ playbooks: []
 onboarding:
   goal: "Capture the user's brand voice, audience, content pillars, and publishing rhythm across channels — so the workspace reflects how they actually create and distribute content, not a generic calendar."
   framing: "Act as a seasoned content strategist. Tease out their voice and positioning, who they're talking to, the recurring themes they own, the channels they publish on, and how often. Translate that into pillars, platforms, and a seeded content calendar."
+  expertise:
+    starters:
+      - >
+        Most creators over-index on one format and burn out. Propose 3–4 pillars
+        that mix TEACH (how it works), PROVE (customer/results), and PROVOKE
+        (point of view) — then adapt the mix to their niche. Don't ask for pillars
+        from a blank slate; offer a starting set and let them react.
+      - >
+        Better to own ONE channel consistently than be thin on four. If they list
+        many platforms, propose a primary channel + a cadence they can actually
+        sustain, and treat the rest as repurposing targets, not separate efforts.
+      - >
+        Every pillar should ladder to a business goal — awareness, trust, or
+        conversion. If a pillar is just "stuff we post", propose the job it should
+        do and tie it to a specific audience segment.
+    blindSpots:
+      - >
+        Distribution is the silent killer — great content nobody sees. If they
+        haven't said HOW each piece gets discovered (SEO, a platform's algorithm,
+        an email list, founder-led amplification), raise it before moving on.
+      - >
+        No repurposing plan = 5× the work for 1× the reach. If they treat each
+        post as one-and-done, propose a chain: one deep piece → clips → posts →
+        newsletter.
+      - >
+        Pillars with no audience attached reach no one. Tie each pillar to a
+        specific segment — "content for everyone" is content for nobody.
+    bar: >
+      The pillars + primary platform + cadence read like a system a small team
+      could actually run for 3 months without burning out — where every pillar has
+      a clear audience, a clear job, and a way to get discovered.
   collect:
     - profileSlug: pillar
       what: "Their recurring content themes / brand voice — the lenses their audience knows them for, and who each speaks to"

package/src/content-studio.yaml

@@ -298,6 +298,44 @@ onboarding:
     and series they actually run, not one-off ideas. Pull voice and visual identity
     from Brand and target audience from Foundation so every piece lands on-brand.
     Be concrete about specs; a fuzzy "we make videos" helps no one.
+  expertise:
+    starters:
+      - >
+        Produce in BATCHES, not one-at-a-time. Setup — lighting, wardrobe, template
+        loading, brand assets — is the real cost; shooting or composing five pieces
+        in one session amortizes it. Propose a batch cadence (e.g. one shoot day →
+        a month of cuts) rather than a per-video pipeline.
+      - >
+        The hook is 80% of the view. On a 9:16 feed the first 1–2 seconds decide
+        whether the piece is watched at all, so it's worth more iteration than the
+        rest combined. Propose a template whose title card / cold-open IS the hook,
+        and treat the hook as its own reusable asset.
+      - >
+        Design every shoot for REPURPOSING before you roll. One long-form capture
+        should yield the long cut, several vertical clips, and stills — but only if
+        it's framed and shot with those crops in mind. Propose the repurpose chain
+        up front so the raw footage is cut-once, use-many.
+    blindSpots:
+      - >
+        The velocity-vs-quality tradeoff is a real dial, not a failing — a weekly
+        show that's "good enough and on time" beats a cinematic piece that ships
+        quarterly. If they're chasing polish on a high-cadence line, name the
+        tradeoff and propose a quality bar that survives the schedule.
+      - >
+        No reusable templates = every video rebuilt from scratch, and brand drift
+        creeps in. If they're producing on a cadence but have no locked
+        intros/outros/lower-thirds, that's the gap — templates are what make output
+        both fast AND on-brand. Surface it.
+      - >
+        Aspect ratio and platform are a production decision, not an export
+        afterthought. Shooting 16:9 and cropping to 9:16 later loses the frame and
+        the hook. If a pipeline's platform doesn't match how it's actually shot,
+        flag the mismatch before it's baked into every render.
+    bar: >
+      The studio reads like a production LINE: recurring shows with locked specs,
+      reusable templates that carry brand into every render, and asset sources feeding
+      a batch-then-repurpose flow — so a producer could ship the next episode this week
+      without reinventing the format or fighting brand drift.
   collect:
     - profileSlug: content-pipeline
       what: The recurring productions you run — the shows, series, or content lines that generate output on a cadence (e.g. weekly reels, product demos, explainer drops).

package/src/crm.yaml

@@ -620,6 +620,64 @@ profiles:
           - healthy
           - at_risk
           - critical
+  - slug: partner
+    displayName: Partner
+    icon: handshake
+    color: teal
+    description: A partner relationship — both a referral source and a co-delivery collaborator, distinguished by partner type.
+    properties:
+      - slug: partnerStatus
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues:
+          - active
+          - paused
+          - churned
+      - slug: partnerType
+        label: Partner Type
+        valueType: string
+        inputType: select
+        enumValues:
+          - referral
+          - co-delivery
+          - both
+      - slug: accountManager
+        label: Account Manager
+        valueType: string
+        inputType: text
+      - slug: engagementStartDate
+        label: Engagement Start
+        valueType: date
+        inputType: date
+      - slug: satisfactionScore
+        label: Satisfaction
+        valueType: number
+        inputType: number
+      - slug: lifetimeValue
+        label: Lifetime Value
+        valueType: number
+        inputType: number
+      - slug: notes
+        label: Notes
+        valueType: string
+        inputType: textarea
+      - slug: contractValue
+        label: Contract Value
+        valueType: number
+        inputType: number
+      - slug: renewalDate
+        label: Renewal Date
+        valueType: date
+        inputType: date
+      - slug: healthScore
+        label: Health
+        valueType: string
+        inputType: select
+        enumValues:
+          - healthy
+          - at_risk
+          - critical
   - slug: contact
     displayName: Contact
     icon: user
@@ -1555,6 +1613,21 @@ entityLinks:
   - sourceProfileSlug: deal
     targetProfileSlug: pipeline
     type: belongs_to
+  - sourceProfileSlug: client
+    targetProfileSlug: company
+    type: belongs_to
+  - sourceProfileSlug: client
+    targetProfileSlug: contact
+    type: primary_contact
+  - sourceProfileSlug: partner
+    targetProfileSlug: company
+    type: works_with
+  - sourceProfileSlug: partner
+    targetProfileSlug: contact
+    type: primary_contact
+  - sourceProfileSlug: partner
+    targetProfileSlug: client
+    type: refers
 displayTemplates:
   - name: Deal Card
     description: Sales deal with pipeline stage, value, probability, and linked company
@@ -2145,6 +2218,45 @@ integrations:
 onboarding:
   goal: Capture the user's sales pipeline shape, their key accounts/contacts, and how they qualify and move deals — so the CRM reflects their real revenue motion, not a generic template.
   framing: "Act as a sharp revenue/sales-ops lead. Tease out how they actually sell: who they sell to, what stages a deal moves through, where leads come from, and what 'qualified' means to them. Translate their words into pipeline config, companies, contacts, and deals."
+  expertise:
+    starters:
+      - >
+        Don't ask for stages on a blank slate — infer the motion first and propose
+        a default pipeline for it. PLG: Signup → Activated → PQL → Expansion.
+        Sales-led: Discovery → Qualified → Demo → Proposal → Negotiation → Closed.
+        Agency/retainer: Lead → Scoping → Proposal → Won → Delivery. Offer the one
+        that fits and let them cut stages, rather than starting from nothing.
+      - >
+        Define every stage by a BUYER action, not a seller activity — "Demo booked"
+        or "Security review passed", not "Following up" or "Sent email". Seller-verb
+        stages are why pipelines rot: they describe effort, not progress. If they
+        name an activity stage, reflect it back as the buyer commitment it's meant
+        to prove.
+      - >
+        Anchor qualification to a named framework, don't leave "qualified" as a
+        feeling. Propose BANT for transactional deals or MEDDIC for enterprise, then
+        make the exit criteria out of it — e.g. a deal can't leave Qualified without
+        a known budget, an identified economic buyer, and a compelling event.
+    blindSpots:
+      - >
+        The "everything is 'in progress'" pipeline. If most deals sit in middle
+        stages with no close date or next step, that's not a pipeline, it's a
+        graveyard — hygiene has collapsed. Push for a next step + a date on every
+        open deal, and be willing to mark the dead ones lost.
+      - >
+        A stage with no exit criteria is a wish, not a stage. If they can't tell you
+        the ONE thing that must be true to advance a deal, the stage is theater.
+        Force a crisp gate for each — what the buyer must have done to move forward.
+      - >
+        Founders track deal value but not the two numbers that actually predict
+        revenue: win rate by stage and average sales-cycle length. Without them you
+        can't forecast or spot where deals stall. Surface both early even if the
+        first answer is a rough guess.
+    bar: >
+      The pipeline stages mirror how a buyer actually commits (not how the rep works
+      their day), each stage has a one-line exit gate, "qualified" maps to a real
+      framework, and every live deal on the board has an owner, a value, a next step,
+      and a close date — so a glance at the board tells the truth about revenue.
   collect:
     - profileSlug: pipeline
       what: Their real deal stages in order (e.g. Lead → Qualified → Demo → Proposal → Won/Lost)

package/src/dev-dashboard.yaml

@@ -888,6 +888,43 @@ bento:
 onboarding:
   goal: "Capture the user's infrastructure surface — the services they run, the repositories behind them, their environments, the vendors they depend on, and their credentials inventory — so the command center reflects their real stack."
   framing: "Act as a staff platform engineer doing an infra walkthrough. Tease out what's running in production, where the code lives, how environments are laid out, which third parties they depend on, and what secrets need tracking. Translate that into services, repositories, environments, vendors, and credentials."
+  expertise:
+    starters:
+      - >
+        Start from what's serving live traffic RIGHT NOW, not the architecture diagram. Walk the
+        request path: what does a user hit first, and what does that call, and what does THAT call?
+        Capture each hop as a service with its host and health-check URL. The production edge is the
+        map's anchor; everything else hangs off it.
+      - >
+        For every third party, capture the cost AND who owns the account. Propose logging each
+        vendor with its pricing model and monthly spend the moment you name it — the €12/mo that
+        became €400/mo is always a vendor nobody was watching. An untracked line item is a future
+        surprise on the card.
+      - >
+        Inventory credentials by their EXPIRY, not their existence. For each secret, capture where
+        it's stored (vault ref), what it unlocks, and when it expires or was last rotated. The
+        credential nobody wrote down is the one that expires at 3am and takes prod with it.
+    blindSpots:
+      - >
+        The untracked credential is the classic infra time-bomb: the SSH key on one laptop, the API
+        token in someone's .env, the cert that auto-renewed until it didn't. Teams track services
+        obsessively and secrets not at all — surface expiry dates and rotation policy proactively,
+        because the outage is silent until the exact moment it isn't.
+      - >
+        Vendor cost creep has no owner. Each SaaS was signed up "just to try," and now the monthly
+        bill is a mystery no single person can explain line by line. Force a monthly-cost number and
+        an owner on every vendor — the sum is almost always higher than anyone guessed.
+      - >
+        "Works on my machine" is environment drift, and it hides until deploy day. Staging runs a
+        different Node, prod has an env var dev doesn't, the migration ran here but not there. Map
+        each environment EXPLICITLY with its branch and base URL so the deltas between prod, staging,
+        and dev are visible instead of discovered during an incident.
+    bar: >
+      A great result is a command center where you can answer, without SSHing anywhere: what's
+      serving traffic and is it healthy, which credential expires next and who rotates it, what each
+      vendor costs and who owns it, and exactly how prod differs from staging. The value is in the
+      facts nobody keeps in one place — expiry dates, cost owners, environment deltas — surfaced
+      before they become incidents.
   collect:
     - profileSlug: service
       what: "The services / apps they run and their stack"

package/src/finance.yaml

@@ -362,6 +362,45 @@ onboarding:
     leaves. Push for real numbers over estimates, flag anything that doesn't add
     up, and tie revenue back to the company's positioning and pricing (from
     Foundation) so the model is grounded in strategy, not spreadsheets.
+  expertise:
+    starters:
+      - >
+        Don't reconstruct a full P&L on day one — default the model to the three
+        numbers that keep a startup alive: cash in bank, monthly net burn, and
+        runway (cash ÷ burn, in months). Propose those first and layer detail later;
+        a founder who knows their runway to the month is ahead of one with a
+        beautiful chart of accounts.
+      - >
+        Add a small set of unit economics, not a whole finance stack: gross margin,
+        CAC, and LTV (or at minimum LTV:CAC ratio). Propose sensible defaults —
+        payback under ~12 months, LTV:CAC above ~3:1 — as reference points to react
+        to, rather than asking them to define metrics from scratch.
+      - >
+        Model cash on a timing basis, not an accrual one. When they give you revenue,
+        ask when the cash actually LANDS — Net-30/60 invoices, annual prepay,
+        Stripe payout lag — and capture that gap explicitly, because a profitable
+        month can still run the account dry.
+    blindSpots:
+      - >
+        Revenue ≠ cash. Founders book an annual contract and feel rich, but the cash
+        arrives monthly or after Net-60 — meanwhile payroll is due Friday. If they
+        conflate the two, separate signed bookings from collected cash before
+        computing anything.
+      - >
+        Runway is THE number that predicts survival, and it's the one most often
+        stale. If there's no current runway figure — or it hasn't been recomputed
+        since the last big hire or price change — that's the first gap to close.
+        Everything else is secondary to "how many months of oxygen is left".
+      - >
+        Bookings, revenue, and cash are three different numbers and founders routinely
+        merge them. A signed deal (booking), revenue recognized over its term, and
+        the money in the account are rarely equal in any given month. Name which one
+        each figure is, or the whole model lies.
+    bar: >
+      A stranger could open the workspace and answer three questions in ten seconds:
+      how much cash is in the bank, how much it burns a month, and how many months of
+      runway that leaves — with revenue captured on a cash-timing basis, bookings kept
+      distinct from collected cash, and at least a rough gross margin and LTV:CAC in view.
   collect:
     - profileSlug: account
       what: The bank and credit accounts holding company cash, with current balances.

package/src/foundation.yaml

@@ -254,6 +254,40 @@ onboarding:
     THE COFOUNDER: Act as a sharp, skeptical co-founder. Pressure-test why-now, why-you, and
     why-this. Refuse fuzzy answers; push for specifics and evidence. Be
     respectful but direct — a vague mission helps no one.
+  expertise:
+    starters:
+      - >
+        A mission is a CHANGE in the world, not a description of the product
+        ("make complex products understandable", not "we make explainer videos").
+        If they describe the deliverable, reflect the underlying change back and
+        propose THAT as the mission.
+      - >
+        Positioning is sharpest as ONE sentence — "the <X> for <who>" or "the only
+        <category> that <wedge>". If they give you a vague "we help companies with
+        Y", propose a crisp category+wedge framing from what they've told you and
+        let them sharpen it — never file the vague version.
+      - >
+        Audience is a SPECIFIC buyer at a specific stage ("Head of Product
+        Marketing at Series A–B technical SaaS"), not a market ("SaaS companies").
+        Push from the market to the person who actually signs off.
+    blindSpots:
+      - >
+        Founders skip the NON-goal — what they deliberately DON'T do. A company
+        with no "no" has no focus. If they haven't named boundaries, ask what they
+        turn down.
+      - >
+        A differentiator that's just "we're better / faster / care more" isn't
+        defensible. Push for a structural moat a competitor can't easily copy — and
+        if it's founder-dependent (bus-factor), capture that honestly rather than
+        dressing it up.
+      - >
+        The #1 tells of fuzzy strategy: a mission that's really a deliverable, and
+        positioning that's really a feature list. When you see either, name it and
+        dig.
+    bar: >
+      A stranger could read the mission, audience, and positioning and instantly
+      explain WHO this is for, WHAT changes for them, and WHY this company over the
+      alternatives — in one breath, with no fluff.
   collect:
     - profileSlug: mission
       what: The one mission that anchors the company — what we serve, what we change, why now.

package/src/hr.yaml

@@ -328,6 +328,47 @@ onboarding:
     Foundation values and reflect them back as the hiring bar and review rubric.
     Be direct about gaps (no owner on a policy, a role open with no hiring manager),
     but never clinical — these are people.
+  expertise:
+    starters:
+      - >
+        Don't ask for a hiring wishlist — propose the first roles by what unblocks
+        the FOUNDER. Whatever the founder is the bottleneck on (sales they can't
+        scale, product they can't ship fast enough, ops eating their week) is the
+        next hire. Reflect their week back and name the role that buys their time
+        back, rather than filling an org chart.
+      - >
+        Hire for the next 12 months, not the dream team. Propose the role at the
+        seniority the company needs NOW — often a scrappy generalist over a
+        specialist VP who'll be bored and expensive. Push back on premature senior
+        hires the stage can't feed with real scope.
+      - >
+        Anchor the hiring bar and review rubric to the company's actual values
+        (pull them from Foundation), not generic competencies. Propose 3–4 concrete
+        "must be true" signals per role derived from those values, so "a great hire"
+        means something specific here rather than "smart and nice".
+    blindSpots:
+      - >
+        Culture is not perks — it's what you REWARD and what you TOLERATE. Founders
+        describe culture as ping-pong and free lunch; the real culture is who gets
+        promoted and what bad behavior goes unchecked. If they answer "culture" with
+        benefits, redirect to: what do you celebrate, and what do you refuse to
+        put up with?
+      - >
+        Onboarding and role clarity beat headcount. A team that doesn't know who owns
+        what will thrash no matter how many people you add. Before proposing new
+        hires, check that existing roles have clear ownership and every new hire has a
+        30/60/90 plan — hiring into ambiguity just scales the confusion.
+      - >
+        An open role with no hiring manager, or a policy with no owner, is a gap
+        hiding in plain sight. Surface these directly: unowned reqs stall for months
+        and unowned policies get ignored. Every role needs a decision-maker; every
+        policy needs someone accountable for it.
+    bar: >
+      The org is honest — real people with clear ownership and no orphaned roles or
+      policies — the open roles map to what actually unblocks the founder at the right
+      seniority for the stage, "a great hire" is defined by concrete signals tied to
+      the company's real values, and every new hire lands into role clarity and a
+      30/60/90 plan rather than ambiguity.
   collect:
     - profileSlug: team-member
       what: The people currently on the team, with their role, department, and status.

package/src/legal.yaml

@@ -368,6 +368,49 @@ onboarding:
     renews, what filings and obligations have deadlines, and what IP is worth protecting.
     Be precise about dates and counterparties; flag risk plainly; never invent legal
     conclusions. Turn their answers into entities, contracts, compliance items, and IP assets.
+  expertise:
+    starters:
+      - >
+        Start by mapping the corporate skeleton, then hang contracts off it. Ask what the
+        top-level entity is, where it's incorporated (Delaware C-corp? a local Ltd/GmbH?),
+        and whether any subsidiaries or branches exist — because a contract's counterparty
+        and an IP asset's owner only mean something once you know which entity signed or
+        holds it. Seed the entities first; everything else references them.
+      - >
+        For each contract they name, capture the RENEWAL and NOTICE dates, not just the
+        signing date. The dangerous field is the auto-renew clause with a 30/60/90-day
+        notice window — that's what silently locks a company into another year. Propose
+        the renewal date and renewal type up front so the workspace can surface it before
+        the window closes.
+      - >
+        Frame the whole session as surfacing RISK, not giving advice. Capture what exists
+        and flag what's missing for a real lawyer to review — never state whether something
+        is enforceable, compliant, or "fine". Turn "is this okay?" into a captured gap:
+        "contract with no signed copy on file — flag for counsel", not a legal opinion.
+    blindSpots:
+      - >
+        The handshake-deal risk: real obligations — a vendor arrangement, a co-founder
+        split, a customer commitment — exist with no signed paper behind them. Ask
+        explicitly what agreements are operating verbally or by email only, and capture
+        each as a contract in "draft" with a flag; an unpapered deal is a dispute waiting
+        to happen, and it's invisible unless you go looking for it.
+      - >
+        Missing IP assignment is the classic startup landmine: founders, early employees,
+        and especially contractors who wrote code or designed the brand without a signed
+        IP-assignment / work-for-hire clause. The company may not legally own its own
+        product. Probe for it directly — "did every contributor sign IP assignment?" — and
+        log any gap as a high-priority matter, because it kills fundraises and acquisitions.
+      - >
+        Renewal, expiry, and filing dates that nobody owns: trademark renewals, annual
+        registered-agent/franchise-tax filings, insurance and license expirations, data-
+        privacy obligations. These lapse silently and are expensive to revive. Every date
+        captured needs an OWNER and a deadline — an unowned deadline is a missed one.
+    bar: >
+      A GREAT result is an accurate, date-aware risk map: the real legal entities and
+      where they sit, the live contracts with their renewal/notice dates and owners, the
+      compliance obligations with deadlines and owners, and the IP the company actually
+      needs to own — with every gap and unpapered deal explicitly FLAGGED for a real
+      lawyer, and not one invented legal conclusion anywhere in it.
   collect:
     - profileSlug: legal-entity
       what: The company's legal entities and the jurisdictions they operate in.