toga-ai 1.0.5 → 1.0.8

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "toga-ai",
-  "version": "1.0.5",
+  "version": "1.0.8",
   "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

@@ -100,38 +100,68 @@ report success on an inconsistent knowledge base.
 
 ## Step 7 — Auto-push to share with teammates
 
-After validate + index succeed, stage and push only `knowledge/` changes to a
-**personal branch** so a maintainer can review before merging to main.
+After validate + index succeed, run through these checks in order before pushing.
+**Never skip straight to the push — the repo must be verified first.**
 
+### Pre-push checklist (run each check, stop at the first failure and fix it)
+
+**Check 1 — Is TEAM_REPO a git repository?**
+```bash
+git -C "<TEAM_REPO>" rev-parse --is-inside-work-tree
+```
+If this fails: the team repo is an npm bundle extract, not a git clone. Run:
 ```bash
-# Derive branch name from git user — e.g. knowledge/john-smith
-BRANCH="knowledge/$(git -C "<TEAM_REPO>" config user.name | tr ' ' '-' | tr '[:upper:]' '[:lower:]')"
+git clone https://github.com/agilantsolutions/claude "<TEAM_REPO>"
+```
+Then re-run validate + index inside the freshly cloned repo before continuing.
 
-# Stage only knowledge/ — never stages source code
-git -C "<TEAM_REPO>" add knowledge/
-git -C "<TEAM_REPO>" diff --cached --quiet || git -C "<TEAM_REPO>" commit -m "knowledge: <brief description of what was captured>"
+**Check 2 — Is origin set to the right remote?**
+```bash
+git -C "<TEAM_REPO>" remote get-url origin
+```
+Expected: `https://github.com/agilantsolutions/claude` (or the SSH equivalent).
+If wrong or missing: `git -C "<TEAM_REPO>" remote set-url origin https://github.com/agilantsolutions/claude`
+
+**Check 3 — Are the knowledge docs in TEAM_REPO, not just the project?**
+
+The docs you wrote in Steps 5–6 must exist inside `<TEAM_REPO>/knowledge/`, not only
+in `<project>/.claude/knowledge/`. If you wrote them to the project's `.claude/knowledge/`
+but not to `<TEAM_REPO>/knowledge/`, copy them now:
+```bash
+# Example — adjust paths to match what was written
+cp "<project>/.claude/knowledge/<path-to-doc>" "<TEAM_REPO>/knowledge/<path-to-doc>"
+```
+Then re-run `node "<TEAM_REPO>/knowledge.js" validate` to confirm they're valid there too.
 
-# Push to personal branch — does not touch main
-git -C "<TEAM_REPO>" push origin HEAD:"$BRANCH"
+**Check 4 — Are there actually staged changes to push?**
+```bash
+git -C "<TEAM_REPO>" status --short knowledge/
 ```
+If nothing shows: the docs were never written to TEAM_REPO. Go back to Check 3.
 
-Replace `<brief description of what was captured>` with a one-line summary of the docs
-written this capture (e.g. `"knowledge: add clickup-deploy feature doc for worker2"`).
+---
 
-**If push succeeds:** report
-> "✓ Knowledge pushed to branch `knowledge/<your-name>` — a maintainer will review and merge to main"
+### Push (only after all 4 checks pass)
+
+```bash
+# Stage only knowledge/ — never stage anything else
+git -C "<TEAM_REPO>" add knowledge/
+git -C "<TEAM_REPO>" diff --cached --quiet || \
+  git -C "<TEAM_REPO>" commit -m "knowledge: <brief description of what was captured>"
 
-**If push fails** (offline, no credentials, diverged branch, or any other error): do
-**NOT** error out. Report:
-> "⚠ Could not push — run `git -C <TEAM_REPO> push origin HEAD:knowledge/<your-name>` when ready"
-and still consider the capture session successful.
+# Push to the active development branch
+git -C "<TEAM_REPO>" push origin HEAD:feature/ai-harness-improvements
+```
+
+**If push succeeds:** report
+> "✓ Knowledge pushed to `feature/ai-harness-improvements` — CI will publish a new npm version. Teammates get it on their next `npx toga-ai`."
 
-Never stage anything outside `knowledge/`. If `git diff --cached` would include files
-outside `knowledge/`, abort the commit and warn: "Unexpected staged files outside
-`knowledge/` — push skipped. Review and push manually."
+**If push fails** — show the developer the exact git error output, then report:
+> "⚠ Push failed: `<error>`. Fix credentials or run manually:
+> `git -C <TEAM_REPO> push origin HEAD:feature/ai-harness-improvements`"
 
-**Devs do not need write access to main.** They only need permission to push to
-`knowledge/*` branches. A maintainer reviews the branch and merges via PR.
+Never stage anything outside `knowledge/`. If `git diff --cached` shows files outside
+`knowledge/`, abort and warn before committing.
 
 ## Step 8 — Report
 

package/skills/kickoff/SKILL.md

@@ -150,32 +150,89 @@ 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 — Surface ECC power-ups for the work type
+## Step 5 — Propose a multi-agent workflow plan
 
-After loading TOGA context, tell the developer which ECC specialist capabilities are available for this session's work type:
+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
+into how the work will be done and a chance to adjust scope.
 
-**For PHP development:**
-- `/code-review` — ECC php-reviewer + TOGA pattern overlay (use after writing any PHP)
-- ECC security-reviewer fires automatically on security-sensitive code
+The developer does not know what "sub-agents" or "loops" are — do not use that jargon.
+Frame everything in plain terms: "Here's my plan."
 
-**For feature implementation:**
-- `/code-review` triggers ecc:planner with your loaded TOGA architecture context
-- The php-reviewer agent runs automatically after every PHP file edit
+### Plan template
 
-**For debugging / build errors:**
-- ecc:build-error-resolver + TOGA framework context = fast diagnosis
+```
+Here's how I'll approach this:
+
+1. [First step — e.g. "Map the existing code and create a phased plan"]
+2. [Build step — e.g. "Write the worker class and controller method"]
+3. [Verify step — e.g. "Run specialist reviewers on the PHP and SQL before showing you the result"]
+
+To do this well, I'll use specialist reviewers that run automatically as I write —
+they catch framework violations and security issues without you needing to ask.
 
-**For SQL/DB work:**
-- sql-reviewer agent fires automatically on PHP files with DB patterns
-- ecc:database-reviewer provides deep query analysis
+**I'll need access to:**
+- Read: [list relevant repo paths]
+- Write/edit: [list the specific files or folders I plan to create or modify]
+- Shell: [any commands I'll run, e.g. "php -l to lint files"]
 
-**For documentation:**
-- `knowledge-writer` agent writes correct TOGA frontmatter automatically
+Claude Code will ask you to approve each action as I go. If you'd rather I just
+proceed without interrupting you, say "go ahead" and I'll work through it and
+show you the finished result.
 
-End the kickoff with:
+Ready to proceed?
 ```
-Context loaded for <repo> (Framework <fw>). 
-ECC agents active: php-reviewer, database-reviewer, security-reviewer, planner, build-error-resolver.
-Run /kickoff again if you switch to a different repo or client.
-What are you building?
+
+**Always wait for a yes before starting.** If the developer says "go ahead", "just do it",
+or "you have full access" — proceed without further permission prompts, but still flag any
+write outside the expected scope.
+
+---
+
+### Agent selection (how to build the plan internally)
+
+Spawn specialists via the `Agent` tool. Grant only the tools the agent needs.
+
+| Work type | Agent to spawn | Tools to grant |
+|-----------|---------------|----------------|
+| New feature design | `ecc:planner` with TOGA context prefix | Read, Grep, Glob |
+| Write/edit PHP | `ecc:php-reviewer` after each file written | Read, Grep, Glob |
+| SQL / DB queries | `ecc:database-reviewer` with TOGA DB context | Read, Grep, Glob |
+| PHP errors / build broken | `ecc:build-error-resolver` with TOGA error patterns | Read, Write, Edit, Bash, Grep, Glob |
+| Security audit | `ecc:security-reviewer` | Read, Grep, Glob |
+| Document a feature | `knowledge-writer` TOGA agent | Read, Write, Bash, Grep, Glob |
+| Large refactor | `ecc:code-reviewer` then `ecc:planner` | Read, Grep, Glob |
+
+Always inject the TOGA context prefix when spawning any ECC agent. The prompts in
+`.claude/agents/toga/php-reviewer.md` and `planner.md` show the exact prefix format.
+
+---
+
+### When to use an iterative loop
+
+Run an agent, review findings, fix, repeat — when:
+- Build errors are present (keep looping until output is clean)
+- The developer says "make sure this is right" or "check everything"
+- You're creating more than 3 PHP files in one task
+
+Tell the developer when you enter a loop:
 ```
+I'll write the code, then run it through the PHP reviewer. If issues are found
+I'll fix them automatically before showing you the final result. This may take
+a few passes — I'll let you know when it's clean.
+```
+
+---
+
+### End-of-kickoff output
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Context: <repo> · Framework <fw> · Client: <client>
+Specialists on standby: php-reviewer, database-reviewer, security-reviewer, planner
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+What are you building today?
+```
+
+After the developer describes the task, present the plan (template above) and wait
+for confirmation. Then begin immediately — do not ask "shall I start?" a second time.