@synap-core/cli 1.12.2 → 1.13.1-next.20261102.ec3d166

package/skills/agent-os/SKILL.md

@@ -6,7 +6,7 @@ description: >
   my company", "launch agent OS", "build my company OS", "onboard my company",
   "add a Marketing workspace", "this project doesn't have a CRM". NOT for a
   lasting goal a project pursues (grow the newsletter, the build) — that is a
-  track (synap_start_track), not a workspace. Find existing
+  goal (synap_start_track), not a workspace. Find existing
   workspace → marketplace template → confirm → packages/apply. NOT the skill
   for "the user stated an intent, what graph should exist" — that conductor is
   system/synap/from-intent (orient, questions, extend-first, then load THIS
@@ -179,7 +179,7 @@ For each domain slug, apply the template's `PackageDefinition`. If you have a
 stamps `project --uses--> workspace` as an INDEX** of domains this engagement
 runs through — not an ACL, and not a nested project. Seed entities still file
 via `belongs_to_project`. **Do not invent a child/nested project** for "the
-Marketing half" — that index edge is enough; a lasting goal is a track, a unit of
+Marketing half" — that index edge is enough; a lasting goal is a goal (a track), a unit of
 work is a session (below).
 
 Templates come from `@synap-core/workspace-templates` (shared by CLI, CP
@@ -262,22 +262,22 @@ skill for the exact sequence.)
 the **<project>** project when one exists, otherwise pod-wide. Then: "I've
 onboarded CRM (pipeline + 4 accounts). Want to onboard the others now, or later?"
 
-## Goals → tracks; "sub-project", blockers → sessions (never nested projects)
+## Goals (tracks); "sub-project", blockers → sessions (never nested projects)
 
 There are **no nested projects**, and a workspace never stands for a goal or a method.
 
 - **A lasting goal the project pursues** ("grow the newsletter", "the
-  build") is a **track**: `synap_list_tracks` → none? `synap_start_track`
+  build") is a **goal** (a _track_ in tool names; say "goal" to the person): `synap_list_tracks` → none? `synap_start_track`
   (`name`, `direction`; no method, no stages). Work in it = `synap_start_session`
   with `trackId`. A repeatable way to do that work is a playbook a session or
-  worker follows (`work-model`). Installing a pack does not start its tracks —
+  worker follows (`work-model`). Installing a pack does not start its goals —
   start each one.
 - **"Sub-project", "blocked on X", one bounded piece of work** is a
   **session**: `synap_start_session` with `projectId` and a clear `goal`, plus
-  `trackId` when it belongs to a track. Decompose with `parentSessionId` and/or
+  `trackId` when it belongs to a goal. Decompose with `parentSessionId` and/or
   `blockedBySessionIds` (edges `spawned_from` / `blocked_by`).
 
-Keep the project as the long-lived commitment; tracks are its lasting goals;
+Keep the project as the long-lived commitment; goals (tracks) are what it pursues;
 sessions are the short work.
 
 ## Adding ONE domain to an existing project (the common in-conversation case)
@@ -286,7 +286,7 @@ You don't only run this for whole-company setup. The frequent case: you're
 working inside a project and notice it's **missing an operational domain it
 needs** — new kinds of things must be recorded that no workspace owns (see the
 "notice a missing method or domain" reflex in the core `synap` skill; a missing
-_goal_ is a track, not this loop) —
+_goal_ is `synap_start_track`, not this loop) —
 you're logging leads but there's no CRM, or drafting posts with no Content OS to hold them. Offer it
 in one line; if the user says yes, run a **trimmed Loop 1** for that single
 domain: