toga-ai 1.0.44 → 1.0.45

package/knowledge.js

@@ -145,6 +145,31 @@ function coreReposFor(registry, framework) {
     return registry.filter(r => r.framework === framework && r.role === 'core').map(r => r.repo);
 }
 
+/* ------------------------------------------------------------------ */
+/* command: manifest — compact pickable lists for kickoff (one call,   */
+/* no profile reads). Prints minified JSON {repos:[...],clients:[...]}. */
+/* ------------------------------------------------------------------ */
+
+function cmdManifest() {
+    const registry = loadRegistry();
+    const repos = registry.map(r => ({ repo: r.repo, project: r.project, framework: r.framework, role: r.role }));
+    const clients = [];
+    const clientsDir = path.join(ROOT, 'clients');
+    if (fs.existsSync(clientsDir)) {
+        for (const slug of fs.readdirSync(clientsDir, { withFileTypes: true }).filter(e => e.isDirectory()).map(e => e.name)) {
+            const profile = path.join(clientsDir, slug, 'profile.md');
+            let title = slug, framework = '';
+            if (fs.existsSync(profile)) {
+                const { data } = parseFrontmatter(fs.readFileSync(profile, 'utf8'));
+                title = data.title || slug;
+                framework = data.framework || '';
+            }
+            clients.push({ slug, title, framework });
+        }
+    }
+    console.log(JSON.stringify({ repos, clients }));
+}
+
 /* ------------------------------------------------------------------ */
 /* command: deps                                                       */
 /* ------------------------------------------------------------------ */
@@ -379,8 +404,9 @@ function main() {
         case 'index': return cmdIndex();
         case 'deps': return cmdDeps(args);
         case 'validate': return cmdValidate();
+        case 'manifest': return cmdManifest();
         default:
-            console.log('Usage: node knowledge.js <search|index|deps|validate> [--flags]');
+            console.log('Usage: node knowledge.js <search|index|deps|validate|manifest> [--flags]');
             process.exitCode = 1;
     }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "toga-ai",
-  "version": "1.0.44",
+  "version": "1.0.45",
   "description": "TOGA Technology Team Claude Knowledge System — shared AI coding harness with skills, knowledge base CLI, and project installer for Claude Code.",
   "keywords": [
     "claude",

package/skills/capture/SKILL.md

@@ -11,17 +11,10 @@ assume**. Nothing is written until the developer approves your proposal.
 
 ### Contribution model
 
-Every `/capture` automatically pushes new knowledge back to the team git repo after
-validate + index succeed:
-
-- Teammates get it on their **next `npx toga-harness`** run, which pulls the git repo
-  before installing — so the two-way loop is:
-  1. `npx toga-harness` seeds knowledge from the npm bundle
-  2. `/capture` grows the knowledge base and pushes it back to git
-  3. Teammates run `npx toga-harness` → git pull delivers the new docs → they get it
-- The push is **non-blocking**: if offline or credentials are missing, capture is still
-  successful and you report a reminder to push manually.
-- Only `knowledge/` files are ever staged — source code is never touched.
+Every `/capture` validates, indexes, then **pushes** `knowledge/` to the team git repo
+(only `knowledge/` is ever staged — never source code). Teammates receive it on their next
+`npx toga-ai` run (which git-pulls before installing). The push is **non-blocking**: if
+offline or unauthenticated, the capture still succeeds — report a manual-push reminder.
 
 ## Core data model (same as `knowledge/CONVENTIONS.md` and the `kickoff` skill)
 
@@ -392,34 +385,15 @@ Who the client is and what their integration does.
 
 ### After Capture
 
-Once you have completed a capture session and confirmed the changes are committed to
-the knowledge base, suggest the following to the developer:
+After the push is confirmed, suggest the developer persist session state:
+> "Captured. If you might not finish this thread in one sitting, run `/session-save` to
+> record what worked, what failed, what's pending, and your next step — so you can resume
+> later without losing context."
 
-> "Session captured successfully. If you're done for today or may not finish this
-> thread in one sitting, run `/session-save` to persist your session state. This
-> records exactly what worked, what failed, what's pending, and your exact next step —
-> so you can resume without losing context, even days later."
-
-Provide the suggested command with a name hint:
-```
-/session-save <suggested-slug-based-on-what-was-worked-on>
-```
-
-For example, if the session was about "ClickUp deploy worker actions", suggest:
-```
-/session-save clickup-deploy-worker
-```
+Suggest a slug from the work, e.g. `/session-save clickup-deploy-worker`.
 
 ### PostToolUse hook auto-validation
 
-The `.claude/settings.json` in this repo includes a `PostToolUse` hook that
-automatically runs `node knowledge.js validate` after any file write to `knowledge/`.
-This means:
-
-- As each doc is written during the capture step, validation runs immediately.
-- You will see inline output with any `ERROR:` or `OK` messages.
-- If validation fails after a write, address the error before writing the next doc —
-  do not proceed to Step 6's explicit `validate` run while errors are outstanding.
-- Step 6's explicit `node knowledge.js validate` call is still required as the final
-  gate — the hook fires per-write, but the explicit call confirms global consistency
-  after all writes are complete.
+`.claude/settings.json` runs `node knowledge.js validate` after every write to `knowledge/`,
+so `ERROR:`/`OK` output appears inline as each doc is written — fix any error before writing
+the next. Step 6's explicit `validate` is still required as the final global-consistency gate.

package/skills/kickoff/SKILL.md

@@ -14,7 +14,7 @@ shortcut the flow.
 - **Step 0 (auto-update check) ALWAYS runs first**, with or without arguments.
 - Use the argument text to **pre-fill answers** to the Step 2 interview (framework, layer,
   repo, client, task). Only ask about whatever is still missing or ambiguous.
-- Never treat the argument as an instruction to start coding before Steps 0–5 complete.
+- Never treat the argument as an instruction to start coding before Steps 0–6 complete.
 
 ## Step 0 — Auto-update check (runs before anything else, even with arguments)
 
@@ -107,52 +107,26 @@ When resolved, if there was no `team-repo-path` memory, **write one** (memory ty
 
 ## Step 2 — Interview the developer (ask the work questions FIRST)
 
-Ask these in one message. **Present the repos/projects you already know** (read
-`registry.json`) so the developer can just pick:
+Get the pickable lists in **one call**: `node "<TEAM_REPO>/knowledge.js" manifest` returns
+minified JSON `{repos:[{repo,project,framework,role}], clients:[{slug,title,framework}]}`.
+**Do not read `registry.json` or any `profile.md` to build these lists.** Ask all questions
+in one message:
 
 1. **Framework** — 1.0, 2.0, or **both**?
 2. **Layer** — front-end, back-end, or hybrid?
-3. **Repo(s) / project(s)** — **list EVERY registered repo for the chosen framework(s)** —
-   do not abbreviate or show only a few. **This is a multi-select (checkbox), not a single
-   choice;** a session often spans more than one repo/project, so always let the developer
-   pick several. If they pick a repo not listed, run **New-repo onboarding** (below) for
-   each new repo before continuing.
-4. **Client** — which client is this for, or "shared / internal"? **List EVERY client by its
-   formal name** — read the `title:` field from each `knowledge/clients/<slug>/profile.md`
-   and show the **formal name, not the slug** (fall back to a title-cased slug only if the
-   profile is missing). Include "shared / internal" and "a new client". Do not show only a
-   subset.
+3. **Repo(s) / project(s)** — list EVERY manifest repo for the chosen framework(s).
+   **Multi-select (checkbox), not single choice** — a session often spans several repos. If
+   they name a repo not listed, run **New-repo onboarding** (below) for each before continuing.
+4. **Client** — list EVERY manifest client by its **`title`** (the formal name, not the slug),
+   plus "shared / internal" and "a new client".
 5. **What are you building or changing?** (a sentence — used to pick relevant feature docs.)
 
-If any answer is unclear, ask again. Do not guess the framework, repo, project, or client.
+If any answer is unclear, ask again. Do not guess framework, repo, project, or client.
 
-### How to present the repo and client choices (questions 3 and 4)
-
-**Do NOT use the option-chip / radio question control for questions 3 and 4.** That
-control caps at ~4 options, which silently truncates the list — with 7+ repos or 3+
-clients the developer never sees the full set. Instead, **render the full list as a
-numbered markdown list in a normal message** and ask the developer to reply with the
-numbers they want (e.g. "1, 3, 5"). This shows every repo and every client with no cap
-and naturally supports multi-select.
-
-```
-**Which repo(s)/project(s)?** (reply with the numbers, multiple OK)
-  1. _underscore  (_Underscore — 2.0 core)
-  2. worker2      (Worker — 2.0 app)
-  3. api2         (API — 2.0 app)
-  ... every registered repo for the chosen framework(s) ...
-  N. a new repo not listed
-
-**Which client?** (one, or "shared / internal")
-  1. Compass Canada
-  2. Compass USA
-  3. Elite
-  ... every client's FORMAL name (from clients/<slug>/profile.md `title:`), not the slug ...
-  S. shared / internal
-  X. a new client
-```
-
-Framework (q1) and layer (q2) have ≤4 options, so the chip control is fine for those.
+**Presenting q3 and q4:** do NOT use the option-chip / radio control — it caps at ~4 options
+and silently truncates a 7-repo / 5-client list. Render the full list as a numbered markdown
+list and have the developer reply with numbers (e.g. "1, 3, 5") — no cap, supports
+multi-select. Framework (q1) and layer (q2) have ≤4 options, so chips are fine there.
 
 ## Step 3 — Resolve the repos this work needs (local paths, lazily)
 
@@ -251,7 +225,7 @@ If they have already run `/session-resume` and are now running `/kickoff`, proce
 normally — the session context they loaded will complement the framework knowledge
 loaded here.
 
-## Step 5 — Propose a multi-agent workflow plan
+## Step 6 — Propose a multi-agent workflow plan
 
 After loading context, analyze what the developer said they're building and **propose a
 concrete agent plan before writing a single line of code**. This gives them visibility