toga-ai 1.0.0

package/skills/session-resume/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: session-resume
+description: Resumes a previously saved session by loading its context into the current session. Lists available sessions, loads the requested one, presents a structured briefing with what works, what to avoid, and the exact next step. Trigger when the user says "session-resume", "resume session", "resume my last session", "load session", "continue where I left off", or names a session to resume ("session-resume auth-refactor", "session-resume latest").
+---
+
+# Session Resume — reload a saved session and brief the developer
+
+You are restoring context from a prior session so that work can continue without
+information loss. The briefing you provide must be actionable and explicit about what
+NOT to do — failed approaches from prior sessions are as important as what worked.
+
+## Arguments
+
+```
+/session-resume [name | "latest"]
+```
+
+- `name` — the exact session name slug (e.g. `auth-refactor`). Matches against the
+  filename: `~/.claude/session-data/*-<name>-session.md`.
+- `latest` — loads the most recently created session file (newest by filename date).
+- If omitted, list available sessions and ask the developer which to load.
+
+---
+
+## Step 1 — Discover available sessions
+
+Read the `~/.claude/session-data/` directory. If it does not exist or is empty:
+
+```
+No saved sessions found in ~/.claude/session-data/
+
+To save a session at the end of your current work: /session-save [name]
+```
+
+Then stop.
+
+Otherwise, list sessions sorted **newest first** (by the `YYYY-MM-DD` prefix):
+
+```
+Available sessions (newest first):
+  1. 2026-06-08 — auth-refactor        ~/.claude/session-data/2026-06-08-auth-refactor-session.md
+  2. 2026-06-07 — worker-cron-fix      ~/.claude/session-data/2026-06-07-worker-cron-fix-session.md
+  3. 2026-06-05 — api2-pagination      ~/.claude/session-data/2026-06-05-api2-pagination-session.md
+```
+
+---
+
+## Step 2 — Resolve which session to load
+
+- If `latest` was specified, take the newest file.
+- If a name was specified, find the file whose filename contains that name slug.
+  - If multiple files match, take the newest.
+  - If none match, say: "No session found matching '<name>'. Available: [list names]."
+- If no argument was given, ask: "Which session should I load? (Enter a number or name)"
+
+---
+
+## Step 3 — Load and parse the session file
+
+Read the session file. Parse these sections:
+- **Task** — the one-sentence summary
+- **Project/Repo** — repo and framework
+- **Date** — when it was saved
+- **What WORKED** — the confirmed successful approaches
+- **What did NOT work** — the failed approaches with exact failure reasons
+- **Not tried yet** — candidate approaches for this session
+- **Current file state** — files changed and their current status
+- **Decisions made** — architectural/design decisions with rationale
+- **Blockers** — any unresolved blockers
+- **Exact next step** — the specific first action to take
+
+---
+
+## Step 4 — Present the briefing
+
+Output a structured briefing in this exact format:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Session Resume: <name>
+Saved: <YYYY-MM-DD> | Repo: <repo> (<framework>)
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+TASK
+<one-sentence task summary>
+
+WHAT WORKS (confirmed)
+  • <item>
+  • <item>
+
+⛔ DO NOT RETRY — KNOWN FAILURES
+  • <approach>: <exact failure reason>
+  • <approach>: <exact failure reason>
+
+NOT YET TRIED (candidates for this session)
+  • <item>
+  • <item>
+
+CURRENT FILE STATE
+  • <file> — <status/notes>
+  • <file> — <status/notes>
+
+KEY DECISIONS
+  • <decision> — <rationale>
+
+BLOCKERS
+  <blocker or "none">
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+EXACT NEXT STEP
+  > <precise first action>
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+The "DO NOT RETRY" section is **mandatory** — if there are failed approaches, they
+must be prominently listed. Never omit or summarize them. A developer skimming the
+briefing must see them immediately.
+
+---
+
+## Step 5 — Confirm intent and offer next step
+
+After the briefing, ask:
+
+```
+Ready to proceed with the next step above?
+
+  Y — Yes, start with: <exact next step>
+  N — No, I want to do something different first
+  K — Run /kickoff first to load full framework/repo context before proceeding
+
+(Or describe what you want to do instead)
+```
+
+If the developer says **Y**, acknowledge and proceed with the stated next step.
+
+If the developer says **K**, note: "Running /kickoff first is a good idea for a
+fresh session — it loads architecture, standards, and feature docs. After kickoff,
+come back to this next step."
+
+If the developer redirects, follow their instruction and update the working mental
+model accordingly.
+
+---
+
+## Notes
+
+- After loading a session, you are **primed** with its context. You do not need
+  `/kickoff` unless the developer explicitly wants full framework/repo docs loaded.
+  For short continuation sessions, the saved context may be sufficient.
+- If the session file is malformed or missing sections, load what is parseable and
+  note which sections were missing.
+- If the "Exact next step" section is blank or unclear, ask the developer what they
+  want to tackle before proceeding.
+- Recommend running `/session-save` again at the end of this session to update the
+  record with new progress.

package/skills/session-save/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: session-save
+description: Persists the current session's state to disk so it can be resumed in a future session. Captures what was built, what worked, what failed, what's pending, all decisions made with rationale, blockers, and the exact next step. Trigger when the user says "session-save", "save session", "save my session", "I'm done for today — save progress", "checkpoint my session", or names a session to save ("session-save auth-refactor").
+---
+
+# Session Save — persist session state for future resumption
+
+You are preserving the **exact mental model of this session** so that either you or
+a future Claude instance can resume from the same point without losing context.
+Be precise. Do not vague-ify failures. Do not omit blockers. A developer opening this
+file cold should be able to continue without asking questions.
+
+## Arguments
+
+```
+/session-save [name]
+```
+
+- `name` — a short slug for this session (e.g. `auth-refactor`, `worker-cron-fix`).
+  If omitted, derive a slug from what was worked on (kebab-case, max 4 words).
+- If the user provides a name, use it exactly. Do not clean it up.
+
+---
+
+## Step 1 — Collect session data from context
+
+Gather all of the following from the live session. For any item you cannot determine
+from context, mark it as `(unknown — developer to fill in)`.
+
+### 1a. Task summary (one sentence)
+What was being built or changed? Be specific: include the repo, the feature, and
+the goal. Example: "Refactoring cron-lock initialization in worker2 to eliminate
+double-acquire errors."
+
+### 1b. What WORKED (evidence required)
+List every approach, change, or fix that **succeeded**. For each:
+- The specific action taken (file modified, function changed, approach used)
+- Evidence of success (test output, observed behavior, error no longer occurring)
+- Do NOT include anything that succeeded then broke later.
+
+### 1c. What did NOT work (exact reason required)
+List every approach that **failed**. For each:
+- The approach tried
+- The EXACT reason it failed (error message, test failure output, conceptual problem)
+- Do NOT paraphrase. Do not write "it didn't work" — write the actual failure.
+- This list is what future-you must NOT retry.
+
+### 1d. What has NOT been tried yet
+Enumerate concrete approaches that were identified but not attempted. These are the
+candidates for the next session.
+
+### 1e. Current state of changed files
+List every file that was created, modified, or deleted this session, with a one-line
+description of the current state of the change.
+
+### 1f. Decisions made (with rationale)
+List architectural or design decisions made this session. For each: the decision, why
+it was chosen (the rationale), and what alternatives were rejected.
+
+### 1g. Blockers
+Any unresolved blockers preventing forward progress. If none, write "none."
+
+### 1h. Exact next step
+One specific action to take at the start of the next session. Be precise: name the
+file, function, test, or command. This is the first thing the developer should do
+when they resume — no thinking required.
+
+---
+
+## Step 2 — Determine save path and filename
+
+```
+File: ~/.claude/session-data/YYYY-MM-DD-<name>-session.md
+Also: <project-root>/.session-latest.md  (gitignored, for quick local reference)
+```
+
+Where:
+- `YYYY-MM-DD` = today's date (use the current date from the session)
+- `<name>` = the session name from Step 0
+- `<project-root>` = the root of the project being worked on (use the `team-repo-path`
+  memory or the current working directory; do not guess if unknown)
+
+Create `~/.claude/session-data/` if it does not exist.
+
+---
+
+## Step 3 — Write the session file
+
+Write the file at both paths using this exact template. Do not reformat, summarize,
+or condense — write the full content at both locations.
+
+```markdown
+# Session: <name>
+**Date:** YYYY-MM-DD
+**Project/Repo:** <repo> (<framework>)
+**Task:** <one-sentence summary from 1a>
+
+---
+
+## What WORKED
+<!-- Include specific file paths and evidence -->
+<items from 1b, one per bullet>
+
+## What did NOT work — DO NOT RETRY THESE
+<!-- Exact failure reasons — do not vague-ify -->
+<items from 1c, one per bullet with failure reason>
+
+## Not tried yet (candidates for next session)
+<items from 1d, one per bullet>
+
+## Current file state
+| File | Status | Notes |
+|------|--------|-------|
+<rows from 1e>
+
+## Decisions made
+<items from 1f: decision + rationale + rejected alternatives>
+
+## Blockers
+<items from 1g, or "none">
+
+## Exact next step
+> <single precise action from 1h>
+
+---
+_Saved by /session-save on YYYY-MM-DD_
+```
+
+---
+
+## Step 4 — Confirm to developer
+
+After writing both files, confirm:
+
+```
+✓ Session saved: ~/.claude/session-data/YYYY-MM-DD-<name>-session.md
+✓ Latest copy:   <project-root>/.session-latest.md
+
+To resume: /session-resume <name>   (or: /session-resume latest)
+
+Session captured:
+  • What worked: <N items>
+  • What to avoid: <N items>
+  • Next step: <exact next step summary>
+```
+
+If either write fails, report the error with the full path that failed and the reason.
+
+---
+
+## Notes
+
+- Both files must be written. If the project root cannot be determined, write
+  only to `~/.claude/session-data/` and note that the local copy was skipped.
+- The `.session-latest.md` file is gitignored (see `.gitignore`). It exists for
+  quick local reference when the developer returns to the project the next day.
+- Do NOT compress or summarize the "What did NOT work" section. Future sessions
+  depend on exact failure reasons to avoid repeating dead ends.

package/skills/sync-team-skills/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: sync-team-skills
+description: Pulls the latest shared team skills from the TOGATechnology/claude GitHub repo and installs them into the local .claude/skills folder so they're immediately usable in VS Code. Use this skill whenever the user says anything like "sync skills", "update skills", "pull latest skills", "get new skills", "install team skills", or "refresh skills". Trigger immediately — do not ask clarifying questions first.
+---
+
+# Sync Team Skills
+
+Pulls the latest skills from the shared `TOGATechnology/claude` GitHub repo and copies them into `.claude/skills/` so Claude Code picks them up immediately.
+
+## Steps to execute
+
+### Step 1 — Locate the claude repo
+
+The shared `claude` repo may be cloned **inside the project** (`./claude`) or as a
+**shared sibling repo** one level up (`../claude`), which several projects under the
+same parent folder can share (e.g. `C:\WWW\claude` shared by `C:\WWW\2.0`,
+`C:\WWW\1.0`, …). Check both, in order, and use the first that exists. Remember the
+path you find — call it `REPO` below.
+
+- **Windows (PowerShell)**:
+  ```powershell
+  $REPO = @('claude','..\claude') | Where-Object { Test-Path "$_\skills" } | Select-Object -First 1
+  if (-not $REPO) { "NOT_FOUND" } else { (Resolve-Path $REPO).Path }
+  ```
+- **Mac/Linux**:
+  ```bash
+  for d in claude ../claude; do [ -d "$d/skills" ] && REPO="$d" && break; done; echo "${REPO:-NOT_FOUND}"
+  ```
+
+If neither exists, stop and tell the user:
+> "I couldn't find a `claude/` repo next to this project (checked `./claude` and `../claude`). Clone https://github.com/TOGATechnology/claude — either into the project root, or as a shared sibling repo (e.g. `C:\WWW\claude`) — then try again."
+
+### Step 2 — Git pull
+
+From the located repo:
+
+```bash
+cd "$REPO" && git pull origin _main
+```
+
+Report what git says (e.g., "Already up to date." or the list of updated files).
+
+### Step 3 — Run the sync script
+
+The sync script resolves its **source** from its own location and its **destination**
+from the project you run it in, so the repo can live anywhere. Run it from the
+project root, pointing at the located repo:
+
+```bash
+node "$REPO/sync-skills.js"
+```
+
+This copies each skill from `<REPO>/skills/` into the project's `.claude/skills/`,
+creating the destination folder if it doesn't exist yet. If you run it from a
+subdirectory, pass the project root explicitly: `node "$REPO/sync-skills.js" <project-root>`.
+
+### Step 4 — Report results
+
+Tell the user:
+- Which skills were synced (from the script output)
+- That Claude Code picks up skills automatically — no restart needed
+- A one-liner: "To share a new skill with the team, add it to `claude/skills/` and push to GitHub."
+
+## Error handling
+
+- **git pull fails (auth/network)**: Tell the user to check their GitHub credentials or VPN and try again.
+- **Node.js not found**: Tell the user to install Node.js from https://nodejs.org (LTS version).
+- **No changes pulled**: Still run the sync script — local `.claude/skills/` may be out of sync even if the repo is current.
+
+## Self-updating anomaly log
+
+If you encounter any error, permission issue, or unexpected behavior not already documented above — even if you successfully work around it — you must record it. Append it to the **Known anomalies** section below using this format:
+
+```
+### [Short title of the issue]
+**Symptom**: What went wrong / what error appeared.
+**Fix**: The exact command(s) or steps used to resolve it.
+**Platform**: Windows / Mac / Both
+```
+
+Write the fix only to `.claude/skills/sync-team-skills/SKILL.md` (the locally installed copy). Do not touch the repo copy under `claude/skills/`. The anomaly log is per-machine — it captures quirks specific to this developer's environment so future runs on this machine are faster.
+
+Do this even for minor weirdness.
+
+## Known anomalies
+
+_(None recorded yet. Issues encountered during runs will be appended here automatically.)_

package/sync-skills.js

@@ -0,0 +1,71 @@
+#!/usr/bin/env node
+
+/**
+ * Syncs skills from this repo's skills/ folder into a project's .claude/skills/.
+ *
+ * Source  = <this script's dir>/skills    (resolved via __dirname, so it works no
+ *           matter where the claude repo is cloned — inside a project as `claude/`,
+ *           or as a shared sibling repo like C:\WWW\claude used by many projects).
+ * Dest    = the nearest ancestor of the current working directory that contains a
+ *           `.claude` folder; falls back to <cwd>/.claude when none is found.
+ *
+ * Run from the target project's root: node <path-to>/sync-skills.js
+ * Optionally pass an explicit destination project root as the first argument:
+ *   node C:\WWW\claude\sync-skills.js C:\WWW\2.0
+ */
+
+const fs = require('fs');
+const path = require('path');
+
+function findProjectRoot(start) {
+    let dir = start;
+    while (true) {
+        if (fs.existsSync(path.join(dir, '.claude'))) return dir;
+        const parent = path.dirname(dir);
+        if (parent === dir) return start; // no .claude ancestor — default to where we started
+        dir = parent;
+    }
+}
+
+function copyDir(src, dest) {
+    fs.mkdirSync(dest, { recursive: true });
+    for (const entry of fs.readdirSync(src, { withFileTypes: true })) {
+        const srcPath = path.join(src, entry.name);
+        const destPath = path.join(dest, entry.name);
+        if (entry.isDirectory()) {
+            copyDir(srcPath, destPath);
+        } else {
+            fs.copyFileSync(srcPath, destPath);
+        }
+    }
+}
+
+const src = path.join(__dirname, 'skills');
+if (!fs.existsSync(src)) {
+    console.error(`No skills/ folder found next to this script (${src}).`);
+    process.exit(1);
+}
+
+const projectRoot = process.argv[2]
+    ? path.resolve(process.argv[2])
+    : findProjectRoot(process.cwd());
+const dest = path.join(projectRoot, '.claude', 'skills');
+
+console.log(`source: ${src}`);
+console.log(`dest:   ${dest}\n`);
+
+const skills = fs.readdirSync(src, { withFileTypes: true })
+    .filter(e => e.isDirectory())
+    .map(e => e.name);
+
+if (skills.length === 0) {
+    console.log('No skills found in skills/.');
+    process.exit(0);
+}
+
+for (const skill of skills) {
+    copyDir(path.join(src, skill), path.join(dest, skill));
+    console.log(`  synced: ${skill}`);
+}
+
+console.log(`\n${skills.length} skill(s) synced to ${dest}`);