feat: version infra skills (1.0.0) + project-bootstrap manifest step

Six infra skills carry `version: 1.0.0` in frontmatter:
project-bootstrap, setup-context7, task-status-wiki, using-context7,
using-markitdown, wiki-maintainer. Bumped manually on SKILL.md edits;
semver — MAJOR breaks contract, MINOR adds, PATCH wording.

project-bootstrap gets a new Step 5.5 that writes
.wiki/concepts/bootstrap-manifest.md per project — skill + version + role
table read live from each delegated skill's frontmatter, not hardcoded.
The file is overwritten on re-bootstrap; for history, git log.

Why: when canonical layout for .wiki/ or .tasks/ changes, projects
bootstrapped under the old version drift silently. The per-project
manifest makes that drift debuggable instead of guesswork. Communication
and discovery skills (caveman family, find-skills, active-platform)
aren't versioned — their content is "good copy-paste" and snapshot
mismatch isn't a layout problem.

Wiki: .wiki/concepts/skill-versioning.md documents the convention;
index.md and log.md updated. .tasks/STATUS.md tracks (a/b/c) progress.

Setup/using split for wiki and tasks (commits b and c) follows.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.wiki/concepts/skill-versioning.md

@@ -0,0 +1,48 @@
+---
+title: Skill versioning + bootstrap manifest
+type: concept
+updated: 2026-04-28
+---
+
+# Skill versioning + bootstrap manifest
+
+## Why version skills
+
+When the canonical layout for `.wiki/` or `.tasks/` changes (as it has — see [wiki-realignment.md](wiki-realignment.md) and the upcoming task-tracking realignment), projects bootstrapped under the old version drift out of canon silently. Without a record of *which version* did the bootstrap, debugging that drift is guesswork.
+
+The fix is two-sided: skills carry a version, and `project-bootstrap` records which versions it used in a per-project manifest.
+
+## Frontmatter format
+
+The 6 infra skills (`project-bootstrap`, `setup-context7`, `setup-wiki`, `setup-tasks`, `using-wiki`, `using-tasks`, `using-context7`, `using-markitdown`) carry `version: <semver>` in their frontmatter:
+
+```yaml
+---
+name: project-bootstrap
+version: 1.0.0
+description: …
+---
+```
+
+Semver:
+- **MAJOR** — breaks the contract (renames, layout changes, trigger-phrase removals).
+- **MINOR** — adds capability (new triggers, new optional steps).
+- **PATCH** — wording / clarity tweaks; no behavioral change.
+
+Bumped manually when `SKILL.md` is edited. No CI gate — discipline-based.
+
+## What skills are versioned
+
+Currently only the **infrastructure** skills (the ones bootstrap touches and that govern project layout). Communication-mode skills (`caveman`, family) and discovery skills (`find-skills`, `active-platform`) aren't versioned — their content is "good copy-paste" and a snapshot mismatch isn't a layout problem.
+
+If we ever start packaging or marketplace-publishing the rest, we'll version them too.
+
+## The manifest
+
+`project-bootstrap` writes `.wiki/concepts/bootstrap-manifest.md` with a frontmatter block + a small table of skill + version + role. The file is **overwritten** on re-bootstrap (not appended) — for history, `git log` shows the changes over time.
+
+## Why this matters
+
+Concrete scenario: you discover that some old project's `.tasks/STATUS.md` doesn't follow the canon (no per-task files, no emoji status). Look at its `bootstrap-manifest.md` — if it shows `setup-tasks: 1.0.0` but the current canon is from `2.0.0`, you know exactly what happened and can re-run `setup-tasks` to migrate.
+
+Without the manifest: `git log` of the project's `.tasks/` folder, guess from filenames, hope.

.wiki/index.md

@@ -16,6 +16,7 @@ Catalog of all wiki pages. One line per page, organized by type. Updated on ever
 - [build-notes.md](concepts/build-notes.md) — why `build.ps1` exists alongside `build.sh`; PS 5.1 backslash-in-zip gotcha; how to extract a `.skill`
 - [context7-setup.md](concepts/context7-setup.md) — switched context7 from manual MCP entries to the official plugin; API key in `.mcp.json` as `--api-key`; now also captured as `setup-context7` skill (one-time install/migrate flow with key discovery)
 - [repo-layout.md](concepts/repo-layout.md) — flat `skills/`, committed `dist/`, bash + PowerShell scripts; install model
+- [skill-versioning.md](concepts/skill-versioning.md) — why infra skills carry `version: <semver>` in frontmatter and how `project-bootstrap` records them in a per-project manifest
 - [skill-vs-plugin.md](concepts/skill-vs-plugin.md) — when a bare SKILL.md is enough vs when you actually need a plugin (slash commands, hooks, sub-agents, MCP servers); concrete breakdown of `superpowers`
 - [wiki-realignment.md](concepts/wiki-realignment.md) — fixing `project-bootstrap` to create the Karpathy-canonical wiki layout
 

.wiki/log.md

@@ -22,3 +22,4 @@ Parseable: `grep "^## \[" .wiki/log.md | tail -20`.
 ## [2026-04-28] decision | setup-context7 skill — formalized the install/migrate algorithm; using-context7 gets a Prerequisites pointer; build.sh PS multi-arg bug fixed (loop instead of comma-joined -Names)
 ## [2026-04-28] verify | setup-context7 — Vitya ran using-context7 in a session that needed setup; Prerequisites pointer triggered setup-context7; full flow worked end-to-end. Pattern (policy + setup split) validated.
 ## [2026-04-28] decision | skill-vs-plugin — documented when a bare skill suffices vs when a plugin is required (slash commands, hooks, sub-agents, MCP via marketplace)
+## [2026-04-28] decision | skill-versioning — added `version: 1.0.0` to 6 infra skills' frontmatter; project-bootstrap now writes .wiki/concepts/bootstrap-manifest.md per project

.wiki/raw/setup-task-status-wiki.md

@@ -0,0 +1,204 @@
+# task-status-wiki
+
+> An idea file for LLM agents. Copy-paste this into your agent (Claude Code, Cursor, Windsurf, etc.)
+> and it will set up a task status tracking system in your monorepo.
+> The agent builds the specifics in collaboration with you.
+
+---
+
+## The Problem
+
+When working on multiple large tasks in parallel inside a monorepo, context is lost on every
+switch. You have to re-explain: what was being done, why, what the current blocker is,
+which files matter. This is expensive and error-prone.
+
+## The Pattern
+
+Maintain a small wiki inside the repo — a folder of plain markdown files — that an LLM agent
+actively reads and updates as you work. The files store *compressed working context*, not
+prose notes. When you switch tasks, you give the agent the relevant file and it is immediately
+oriented without re-explanation.
+
+This follows the same principle as Karpathy's llm-wiki: knowledge should *accumulate* across
+sessions, not be re-derived from scratch each time.
+
+---
+
+## Structure to Create
+
+```
+.tasks/
+  STATUS.md          ← the board: one block per task, sorted by priority
+  <task-slug>.md     ← deep context file per task
+```
+
+Place `.tasks/` at the monorepo root. Commit it to git — decision history is valuable,
+and diffs show how thinking evolved.
+
+### Solo vs. team
+
+**Solo:** local commits are enough. No need to push `.tasks/` — history is preserved locally,
+remote repo stays clean.
+
+**Team or multiple agents:** push `.tasks/` to remote. It becomes the shared source of truth.
+Without it, each agent or person works from their own stale snapshot and statuses diverge.
+Add a `**Owner:**` field to each STATUS.md block so it's clear who (or which agent) holds
+the task at any moment.
+
+---
+
+## STATUS.md — the board
+
+This is the first file you open when returning to work. One block per active task.
+The agent updates it at the end of every session, or when asked.
+
+### Format
+
+```markdown
+# Task Board
+_Updated: YYYY-MM-DD_
+
+## 🔴 [task-slug] — short description
+**Status:** active | paused | blocked | done
+**Owner:** person or agent name (team mode only — omit if solo)
+**Where I stopped:** one sentence — the exact thought or action interrupted
+**Next action:** one concrete step to resume immediately
+**Blocker:** (if any) what is stopping progress
+**Branch:** git branch name
+
+---
+
+## 🟡 [task-slug] — short description
+...
+```
+
+### Status emoji convention
+- 🔴 Active — currently being worked on (only one at a time)
+- 🟡 Paused — in progress, can be resumed
+- ⚪ Ready — not started, fully defined
+- 🟢 Done — completed, kept for reference until merged
+- 🔵 Blocked — waiting on external input
+
+---
+
+## Per-Task File — `<task-slug>.md`
+
+Created when a task starts. The agent maintains it throughout. This is the *compiled*
+context — not raw notes, but synthesized understanding that would take too long to
+re-derive from scratch.
+
+### Format
+
+```markdown
+# <task-slug>
+
+## Goal
+One paragraph. What this task achieves and why it matters in the monorepo context.
+
+## Key files
+List of files central to this task, with one-line notes on their role.
+- `path/to/file.ts` — what it does and why it matters here
+- `path/to/other.ts:42` — specific line if relevant
+
+## Decisions log
+Reverse-chronological. The agent appends here when a non-obvious decision is made.
+- YYYY-MM-DD: Why we chose X over Y
+- YYYY-MM-DD: Discovered constraint Z, adjusted approach
+
+## Open questions
+- [ ] unresolved questions that block or affect design
+- [ ] questions to discuss with teammates
+
+## Completed steps
+- [x] steps that are done (agent moves items here from open questions or session notes)
+
+## Notes
+Anything that doesn't fit above: temporary hypotheses, links to external context,
+names of people to ask.
+```
+
+---
+
+## Agent Operations
+
+These are the operations the agent performs. The agent should do them autonomously
+without being asked each time.
+
+### On session start
+1. If in team mode: `git pull` to sync `.tasks/` before reading anything
+2. Read `STATUS.md`
+3. If the user names a task, read its `<task-slug>.md`
+4. Confirm current state in one sentence: "We're in the middle of X, next step is Y"
+5. Ask if the plan is still correct before doing anything
+
+### On session end (or when user says "pause" / "switch")
+1. Update `STATUS.md`: set current task to 🟡, update "Where I stopped" and "Next action"
+2. Append to `<task-slug>.md` Decisions log any non-obvious choices made this session
+3. Move completed steps to "Completed steps"
+4. Commit: `git add .tasks/ && git commit -m "chore: update task status [<task-slug>]"`
+5. If in team mode: `git push`
+
+### On task switch
+1. Perform session-end operations for the current task
+2. Ask which task to switch to
+3. Read the target `<task-slug>.md`
+4. Set it to 🔴 in STATUS.md
+5. Confirm orientation before starting work
+
+### On task creation
+1. Ask: task name (becomes the slug), goal, known key files, branch name
+2. Create `<task-slug>.md` with populated Goal and Key files sections
+3. Add block to `STATUS.md` with status ⚪
+4. Create and checkout the branch if it doesn't exist
+
+### On task completion
+1. Move all open questions to resolved or drop them
+2. Set status to 🟢 in STATUS.md
+3. Add a "Completed" line in Decisions log with final summary
+4. Remind user to delete the branch after merge
+
+---
+
+## Initialization Prompt (run once per project)
+
+When the user pastes this file into the agent for the first time, the agent should:
+
+1. Confirm it understands the pattern in one sentence
+2. Ask: "What tasks are currently in flight? Give me their names and a one-line description."
+3. For each task mentioned: ask for branch name, current status, and where work stopped
+4. Create the `.tasks/` folder structure
+5. Create `STATUS.md` with all tasks filled in
+6. Create a `<task-slug>.md` for each active or paused task
+7. Make an initial commit: `git add .tasks/ && git commit -m "chore: init task status wiki"`
+8. Print the path to STATUS.md and say it's ready
+
+The agent must not invent task details — it asks for what it doesn't know.
+
+---
+
+## Rules for the Agent
+
+- **Never lose "Where I stopped"** — this is the most important field. If unclear, ask before ending session.
+- **One sentence per field** — STATUS.md fields are not prose. Compress.
+- **Key files must be specific** — not "auth module" but `packages/auth/src/useAuth.ts:87`.
+- **Decisions log is append-only** — never rewrite past entries, only add.
+- **Commit after every session end** — the git log is the history of thinking.
+- **Always confirm orientation** — at session start, state what you understand before acting.
+- **If STATUS.md is stale** (last update > 3 days ago), flag it and ask the user to confirm current state.
+- **Team mode:** always `git pull` before reading, always `git push` after committing. One 🔴 per owner — two people must not hold the same task active simultaneously. Use the `Owner:` field to make this visible.
+
+---
+
+## Why This Works
+
+The key insight from Karpathy's pattern: an LLM should not re-derive context on every session.
+It should read accumulated, compiled knowledge — the same way a compiler produces an artifact
+you don't recompute every time.
+
+The `.tasks/` wiki is that artifact for engineering work. Each task file is a *compiled*
+representation of: what was learned, what was decided, what remains. The agent's job is
+to keep it accurate and compressed — not verbose, not a log dump, but the minimum a future
+session needs to be immediately productive.
+
+The STATUS.md board adds fast navigation: glance at it, pick a task, load its file.
+Two reads and you're back in context.