@synap-core/workspace-templates 0.3.0 → 0.5.0

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.
@@ -292,7 +326,7 @@ app:
 layout:
   defaultView: Mission & Vision
   defaultApp: null
-  pinnedApps: [dashboard, data, intelligence]
+  pinnedApps: [dashboard, data, chat]
   sidebarItems:
     - kind: view
       viewName: Mission & Vision

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.
@@ -358,7 +399,7 @@ app:
 layout:
   defaultView: Team
   defaultApp: null
-  pinnedApps: [dashboard, data, intelligence]
+  pinnedApps: [dashboard, data, chat]
   sidebarItems:
     - kind: view
       viewName: Team

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.
@@ -398,7 +441,7 @@ app:
 layout:
   defaultView: Contracts
   defaultApp: null
-  pinnedApps: [dashboard, data, intelligence]
+  pinnedApps: [dashboard, data, chat]
   sidebarItems:
     - kind: view
       viewName: Contracts

package/src/life-os.yaml

@@ -1012,7 +1012,7 @@ app:
   cellKey: entity-detail
 
 layout:
-  pinnedApps: [dashboard, data, intelligence]
+  pinnedApps: [dashboard, data, chat]
   defaultApp: dashboard
   sidebarItems:
     - kind: app
@@ -1060,7 +1060,7 @@ layout:
       label: Areas
       icon: Compass
     - kind: app
-      appId: intelligence
+      appId: chat
       label: Agent
       icon: Sparkles
 
@@ -1330,6 +1330,44 @@ profileEntityBentoTemplates:
 onboarding:
   goal: Capture the shape of the user's life — their areas of focus, current goals, active projects, key people, and what they're reading or learning — so the second brain starts grounded in who they actually are.
   framing: Act as a thoughtful personal-knowledge coach. Gently tease out the domains they care about, what they're working toward, what's in motion, who matters to them, and what they're consuming. Translate that into areas, goals, projects, people, and books.
+  expertise:
+    starters:
+      - >
+        Lead with their AREAS, not a note dump. Ask them to name the handful of life
+        domains they're permanently responsible for — Health, Finances, Career,
+        Relationships, a side project — and seed one Area each. Areas are the PARA-style
+        shelves everything else hangs off; without them the second brain is a flat pile.
+        Skip the GTD jargon ("contexts", "tickler files") — nobody thinks in those.
+      - >
+        For every goal they mention, propose it WITH a linked project or a concrete next
+        action attached. "Get fit" alone is a wish; "Get fit → project: 3x gym/week
+        through March" is trackable. If they can't name the first move, capture it as an
+        Area standard to maintain rather than a Goal to hit.
+      - >
+        When they name something in motion, decide OUT LOUD whether it's an Area (ongoing,
+        no finish line — "stay healthy") or a Project (finite, has a done state — "run a
+        half-marathon in May"), and file it accordingly. Getting this split right on day
+        one is what keeps the system from rotting into an undifferentiated to-do heap.
+    blindSpots:
+      - >
+        The "capture everything, revisit nothing" trap: people hoard highlights, articles,
+        and notes into an inbox they never process. Capture is worthless without a review
+        loop — surface it early. Propose an inbox-zero-style status flow (inbox →
+        processing → evergreen) and a weekly review habit, not just more collection.
+      - >
+        Goals with no next action are wishes, not goals. People list aspirations
+        ("learn Spanish", "write more") with no project or first step behind them, then
+        wonder why nothing moves. Flag any goal that isn't wired to a project or an action.
+      - >
+        People conflate Areas with Projects and drown finite work inside never-ending
+        buckets — or worse, treat a lifelong responsibility as a project they can "finish"
+        and abandon. If "Health" shows up as a Project or "launch the app" as an Area,
+        catch it: the confusion is the single most common reason PARA-style systems fail.
+    bar: >
+      A GREAT result is a small, LIVING skeleton, not an exhaustive archive: 3-5 real
+      Areas covering their actual life, each with 1-2 current Goals or Projects hanging
+      off it, a few key people, and what they're reading right now — every goal wired to
+      a next action, and a review habit named so the system gets revisited, not just fed.
   collect:
     - profileSlug: area
       what: The ongoing areas of life / responsibility they want to keep standards in
@@ -1339,6 +1377,10 @@ onboarding:
       what: The goals they're currently working toward
       cardinality: few
       keyFields: [title, target-date, area, progress]
+    - profileSlug: project
+      what: The active projects in motion (the concrete efforts that advance their goals)
+      cardinality: few
+      keyFields: [title, status]
     - profileSlug: person
       what: The key people in their world
       cardinality: several

package/src/marketing.yaml

@@ -204,6 +204,43 @@ onboarding:
     stay on-strategy and on-brand. Push for the concrete: real channels, real
     numbers, real segments — not "we do social." Ask where leads come from and
     where they stall. Be warm but relentless about specifics.
+  expertise:
+    starters:
+      - >
+        One channel to competence before the next. Spraying across email, social,
+        paid, and events at once means all of them stay mediocre. Propose ONE
+        primary channel to get working end-to-end (message → creative → conversion)
+        and treat the others as experiments, not commitments.
+      - >
+        Growth is a chain: ICP → message → channel fit. The message that lands is
+        the one that names the ICP's specific pain in their words, and the channel
+        that works is where that ICP already is. If a campaign has a channel but no
+        named segment and no sharp message, propose filling those first.
+      - >
+        Anchor every campaign to a pipeline metric, not a vanity one. Impressions,
+        followers, and open rates feel good and predict nothing. Propose the campaign
+        target as leads, qualified pipeline, or CAC — the number a founder would
+        actually defend in a board meeting.
+    blindSpots:
+      - >
+        The "spray across every channel" reflex is the #1 growth failure — it
+        guarantees no channel reaches the volume needed to learn what works. If they
+        list four channels for one campaign, push back: which ONE gets real budget
+        and attention this quarter?
+      - >
+        Attribution is where growth stories quietly lie. If they can't say where
+        their best leads actually come from — not where they THINK, but what the data
+        shows — the pipeline is being optimized blind. Surface the tracking gap.
+      - >
+        A leaking funnel beats a full top. Founders obsess over more leads while
+        leads pile up and stall at one pipeline stage. If a stage is a graveyard, the
+        fix is conversion there, not more volume up top — name the stall before
+        proposing new campaigns.
+    bar: >
+      Each live campaign has a named ICP segment, a sharp message that segment would
+      recognize, one channel it's genuinely committed to, and a pipeline metric it's
+      judged on — so a growth lead could tell at a glance what's working, what's
+      leaking, and where the next dollar should go.
   collect:
     - profileSlug: campaign
       what: The campaigns live or planned right now — one per real initiative, with its channel and goal.

package/src/operations.yaml

@@ -348,6 +348,45 @@ onboarding:
     vagueness: every workflow has an owner and a cadence, every SOP has a
     trigger. Translate their answers into SOPs, workflows, vendors, tools, and
     rituals.
+  expertise:
+    starters:
+      - >
+        Don't map the whole org or every process — start with the few recurring
+        processes that actually BREAK: the ones that cause fire drills, missed
+        handoffs, or "who was supposed to do that?" moments. Ask what went wrong last
+        month and reverse-engineer the workflow from the failure, not from an
+        idealized flowchart.
+      - >
+        SOP the highest-frequency × highest-pain work first. A daily task that hurts
+        every time beats a quarterly one that's annoying once. Propose that
+        prioritization out loud — "let's document the thing you do 50 times a month
+        before the thing you do twice a year" — instead of documenting alphabetically.
+      - >
+        Give every workflow a single named owner and a cadence before anything else.
+        Refuse "the team owns it" — that means no one does. If they can't name one
+        accountable person, that's the finding, and the workflow's real status is
+        "at risk", not "active".
+    blindSpots:
+      - >
+        A process nobody owns doesn't exist — it just hasn't failed publicly yet.
+        Hunt for the workflows that run on habit and goodwill with no owner; those
+        are the ones that collapse the week someone is on holiday.
+      - >
+        "It's all in my head" is a single point of failure, not a system. The most
+        dangerous SOPs are the undocumented ones the founder or one key person runs
+        from memory. Ask directly: what breaks if that person is out for two weeks? —
+        and document those first.
+      - >
+        Founders confuse activity with process. A recurring meeting or a busy Slack
+        channel isn't a workflow unless it has a defined input, a defined output, and
+        a trigger. If a "process" has no clear input→output, it's a habit; name it as
+        one and either give it structure or drop it.
+    bar: >
+      The workspace captures the handful of processes that actually run (and break)
+      the business — each with one accountable owner, a cadence, and a clear
+      input→output — the highest-frequency/highest-pain procedures are documented as
+      SOPs so they survive the owner leaving, and nothing critical lives only in one
+      person's head.
   collect:
     - profileSlug: sop
       what: The core documented procedures / runbooks — the repeatable ways of doing key things.
@@ -382,7 +421,7 @@ app:
 layout:
   defaultView: SOPs
   defaultApp: null
-  pinnedApps: [dashboard, data, intelligence]
+  pinnedApps: [dashboard, data, chat]
   sidebarItems:
     - kind: view
       viewName: SOPs

package/src/personal.yaml

@@ -92,6 +92,44 @@ onboarding:
     You're here to understand their world, not audit it — curious, warm, never
     pushy. Meet them where they are: a couple of honest notes beat a perfect
     system. Reflect back what you hear so it feels captured, not interrogated.
+  expertise:
+    starters:
+      - >
+        Start from ONE real recurring need, not a structure. Ask "what do you keep losing
+        track of?" — the tab you meant to read, the idea you forgot, the link you can't
+        find again — and seed that single thing. A personal space earns trust by solving
+        one nagging friction, then grows; it dies if it opens as an empty filing cabinet.
+      - >
+        Propose the 2-3 things they ACTUALLY want to track, then stop. Most people need
+        exactly: a place for stray notes, a reading list, and a bookmark pile. Name those,
+        seed one item in each, and resist adding projects/tags/statuses they didn't ask
+        for. The default here is deliberately lean — under-structure on purpose.
+      - >
+        Mirror their own capture habit instead of imposing one. Ask what a jotted thought
+        usually looks like for them — a link, a one-liner, a voice-note-to-self — and map
+        the workspace to that shape. If they dump links, lead with bookmarks; if they
+        write, lead with notes. Match reality; don't teach them a new ritual.
+    blindSpots:
+      - >
+        The productivity-system graveyard: elaborate setups — nested tags, six statuses,
+        color-coded areas — built with enthusiasm on day one and abandoned by day seven.
+        The failure mode is over-structuring, not under-structuring. Every field you add
+        is a field they must maintain; keep it embarrassingly simple and let it grow later.
+      - >
+        People try to design the "perfect system" before they have any content, and stall.
+        Structure should emerge FROM real notes, not precede them. If they're deliberating
+        over categories with an empty workspace, cut it short — capture three real things
+        first, and let the shape reveal itself.
+      - >
+        A reading list nobody triages just becomes guilt. People pile "to-read" articles
+        and never mark anything read or dropped, so the list rots into a backlog they
+        avoid. Give it a lightweight status (to-read / reading / read / archived) and
+        normalize archiving unread — a shrinking list is a healthy one.
+    bar: >
+      A GREAT result is TWO OR THREE things they genuinely care about, each with a real
+      item already in it — not an empty scaffold. It should feel like a lean personal
+      shelf they'll actually open tomorrow, with nothing to maintain that they didn't ask
+      for. If it looks like a "productivity system", it's already too much.
   collect:
     - profileSlug: project
       what: The handful of things they're actively working on or care about right now.

package/src/project-management.yaml

@@ -717,6 +717,44 @@ playbooks:
 onboarding:
   goal: "Capture the user's goals, the projects in flight, the current sprint, and who's involved — so the workspace mirrors how their team actually plans and delivers."
   framing: "Act as a sharp delivery lead / chief of staff. Tease out what outcomes matter this quarter, what's actively being worked, what's in the current cycle, and who owns what. Translate that into OKRs, projects, a sprint, and people."
+  expertise:
+    starters:
+      - >
+        Don't collect a wishlist of goals — force ONE north-star metric and 2-3 key results that
+        move it. Propose "the single number that means this quarter succeeded" first, then the
+        handful of measurable KRs under it. Five objectives is zero objectives; a team that's aiming
+        at everything is aiming at nothing.
+      - >
+        Capture what's actually in flight and impose a WIP limit as you go. Ask "what's genuinely
+        being worked THIS week" — not the backlog — and if it's more than the team can finish,
+        that's the finding. Too many projects in progress means nothing ships; the map should make
+        the overload visible.
+      - >
+        Every project and KR gets a named owner before anything else. Lead with "who owns this?" —
+        a goal with no owner is a hope, and it will quietly slip. Capture the person on the project
+        the moment you capture the project; ownerless work is the first thing to surface, not the
+        last.
+    blindSpots:
+      - >
+        "Everything is P1" is the prioritization failure that guarantees the wrong things ship. When
+        every project is Critical, priority carries no information and the team defaults to whatever's
+        loudest. Push back on the priority field — force a real ranking, because if you can't say
+        what's LESS important, you haven't prioritized at all.
+      - >
+        A goal with no owner is a hope, and hopes don't ship. Teams write beautiful OKRs with an
+        empty owner field, and the KR that belongs to "the team" belongs to no one. Surface every
+        ownerless objective, project, and KR — accountability is a name, not a shared intention.
+      - >
+        Too much work-in-progress is the silent throughput killer. Founders equate "many things
+        started" with progress, but a dozen 60%-done projects deliver nothing while three finished
+        ones deliver value. Watch the count of In-Progress items and flag when it exceeds what the
+        team can actually close in a cycle.
+    bar: >
+      A great result is a workspace where the line from a single north-star metric down to the task
+      in flight this week is unbroken: one clear objective with measurable KRs, every project and
+      goal owned by a named person, a real priority ranking (not all-P1), and a WIP that matches
+      capacity. You can answer "are we on track, who owns the thing that's slipping, and what should
+      we STOP to ship what matters?" in one look.
   collect:
     - profileSlug: okr
       what: The goals / OKRs that define success this quarter

package/src/radar.yaml

@@ -189,6 +189,40 @@ onboarding:
     THE SCOUT: Act as a sharp market scout. Curious, factual, neutral. Surface who
     else plays here, where the market is moving, and who's worth learning from.
     Always cite a source when you can.
+  expertise:
+    starters:
+      - >
+        Don't just log named rivals — map the CATEGORY. Buyers compare across three
+        tiers: direct competitors, adjacent tools that solve the same job
+        differently, and the status quo ("a spreadsheet", "do nothing"). Propose
+        entries in all three, because the status quo is usually the real competitor.
+      - >
+        Track positioning by CONTRAST, not features. For each rival, capture the
+        one axis where you're deliberately opposite ("they're enterprise-heavy, we're
+        self-serve") — that contrast is what a buyer remembers. If they only give you
+        a feature list, reflect the underlying axis back and propose that.
+      - >
+        Separate LEADING from LAGGING signals. Pricing changes, hiring sprees, and
+        docs/changelog velocity predict where a competitor is going; press releases
+        and funding rounds only confirm where they've been. Prioritize the leading
+        indicators when you propose what to watch.
+    blindSpots:
+      - >
+        "We have no competitors" is a red flag, not a moat — it usually means the
+        category is undefined or the buyer's alternative (a manual workaround) hasn't
+        been named. Push to name what a buyer does TODAY instead of buying anything.
+      - >
+        Founders over-watch the loud incumbent and miss the fast-moving insurgent
+        one tier down. The threat that kills you is rarely the market leader — it's
+        the well-funded startup attacking your exact wedge. Surface the insurgents.
+      - >
+        A trend with no direction or timing is just a headline. Every trend needs a
+        stance: is it rising, steady, or fading, and does it help or hurt you? An
+        untimed "AI is big" tells strategy nothing — force the "so what for us".
+    bar: >
+      The landscape reads like a real map: every rival placed on a contrast axis, the
+      status-quo alternative named, and each trend carrying a direction and a "so what"
+      — so a strategist can see the open lane you should own, not just a list of logos.
   collect:
     - profileSlug: competitor
       what: Rivals and alternatives a buyer would seriously compare you to.
@@ -219,7 +253,7 @@ app:
 layout:
   defaultView: Competitors
   defaultApp: null
-  pinnedApps: [dashboard, data, intelligence]
+  pinnedApps: [dashboard, data, chat]
   sidebarItems:
     - kind: view
       viewName: Competitors