feat: split tasks — using-tasks (policy) + setup-tasks (one-time)

Mirror the wiki split. Rename `task-status-wiki` → `using-tasks` (preserves
file history via `git mv`). Strip the "Initialization" section out — that
content moves to the new `setup-tasks` skill, which owns greenfield
creation and migration.

`setup-tasks` has 6 phases (sanity → discovery → plan + confirm → backup →
greenfield/migrate → verify → report) and two modes:
- greenfield: write `.tasks/STATUS.md` with the canonical board template
  (emoji legend in a comment block; no per-task files at bootstrap — they
  get created on demand by using-tasks when actual tasks are added)
- migrate: detect old flat STATUS.md (no emoji, plain `## Done`/`## In
  Progress` sections), back it up, then walk the user *interactively*
  through each task to extract slug / status / branch / where-stopped /
  next-action. Never auto-parses the old format — too varied, real work
  at stake.

`using-tasks` Prerequisites section delegates to `setup-tasks` when the
board is missing or non-canonical (no emoji, no per-task files).

`project-bootstrap` Step 4 now delegates to `setup-tasks`.

The user's manual follow-up after this commit:
  rm -rf ~/.claude/skills/{wiki-maintainer,task-status-wiki}/
to clean up the stale installs of the old names. (install.sh creates the
new ones but doesn't remove the old.)

This completes the three-commit refactor (a/b/c) tracked in
.tasks/STATUS.md.

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

.tasks/STATUS.md

@@ -1,38 +1,31 @@
 # Task Board
 _Updated: 2026-04-28_
 
-## In Progress
-
-### Versioning + setup/using split for wiki & tasks
-**Goal:** version 6 infra skills (`1.0.0`), record them in a per-project bootstrap manifest, then split `wiki-maintainer`/`task-status-wiki` into `setup-X`/`using-X` pairs (mirroring context7) so bootstrap delegates to setup-skills and using-skills self-bootstrap on missing infra.
-
-**Three commits:**
-
-#### (a) Versioning + manifest
-- [x] Add `version: 1.0.0` to frontmatter of all 6 infra skills
-- [x] `project-bootstrap` Step 5.5 writes `.wiki/concepts/bootstrap-manifest.md` (table read live from each delegated skill's frontmatter)
-- [x] `concepts/skill-versioning.md` documents the convention; index + log updated
-- [x] Build + install affected skills (loop in build.sh handles 6-arg invocation cleanly)
-
-#### (b) Split wiki
-- [x] `git mv skills/wiki-maintainer/ skills/using-wiki/` (history preserved as rename)
-- [x] Updated `name:` to `using-wiki` and description to include `use project wiki` trigger; H1 + headline rewritten
-- [x] New `skills/setup-wiki/SKILL.md` — 6 phases (sanity → discovery → plan+confirm → backup → 4a greenfield / 4b migrate → verify → report), with full templates for each canon file
-- [x] `using-wiki` Prerequisites section delegates to `setup-wiki` when layout missing/non-canon
-- [x] `project-bootstrap` Step 3 now delegates to `setup-wiki`; inline templates kept as reference only
-- [x] Stale `dist/wiki-maintainer.skill` removed
-
-#### (c) Split tasks
-- [ ] Rename `skills/task-status-wiki/` → `skills/using-tasks/`; update `name:`
-- [ ] New `skills/setup-tasks/` derived from `.wiki/raw/setup-task-status-wiki.md` + existing SKILL.md
-- [ ] Prerequisites in `using-tasks` → invokes `setup-tasks`
-- [ ] `project-bootstrap` Step 4 delegates to `setup-tasks`
-
-**One-time, after all three:**
-- [ ] Manual `rm -rf ~/.claude/skills/{wiki-maintainer,task-status-wiki}/` (the old names) once the renamed installs are in place
-
 ## Done
 
+### Versioning + setup/using split for wiki & tasks (3 commits)
+
+#### (a) Versioning + manifest — `e1e5bd1`
+- [x] `version: 1.0.0` added to all 6 infra skills' frontmatter
+- [x] `project-bootstrap` Step 5.5 writes `.wiki/concepts/bootstrap-manifest.md`
+- [x] `concepts/skill-versioning.md` documents the convention
+
+#### (b) Split wiki — `36fe39e`
+- [x] `wiki-maintainer` → `using-wiki` (rename via `git mv`)
+- [x] New `setup-wiki` skill — 6 phases, two modes (greenfield / migrate), full canon templates
+- [x] `using-wiki` Prerequisites delegates to `setup-wiki`
+- [x] `project-bootstrap` Step 3 delegates
+
+#### (c) Split tasks — _this commit_
+- [x] `task-status-wiki` → `using-tasks` (rename via `git mv`)
+- [x] New `setup-tasks` skill — 6 phases, two modes (greenfield / migrate); migration is interactive, never auto-parses old flat STATUS.md
+- [x] `using-tasks` Prerequisites delegates to `setup-tasks`
+- [x] `project-bootstrap` Step 4 delegates
+- [x] Stale `dist/task-status-wiki.skill` removed
+
+### Manual follow-up for the user (one-time)
+- [ ] `rm -rf ~/.claude/skills/{wiki-maintainer,task-status-wiki}/` — the old folders linger on disk after rename. The new `using-wiki` / `using-tasks` are already installed alongside; once you remove the old ones, `available_skills` will list only the new names.
+
 ### Create `setup-context7` skill
 - [x] Drafted `skills/setup-context7/SKILL.md` — 8 phases (discovery → plan → backup → install → inject → clean → smoke-test → restart) + rollback + cross-platform notes
 - [x] API-key discovery in priority order: `settings.json` → `.claude.json` (top-level + project-scoped) → `settings.local.json` → env → ask

.wiki/log.md

@@ -24,3 +24,4 @@ Parseable: `grep "^## \[" .wiki/log.md | tail -20`.
 ## [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
 ## [2026-04-28] refactor | wiki split — `wiki-maintainer` renamed to `using-wiki` (policy); new `setup-wiki` skill owns greenfield creation and canon migration; `project-bootstrap` Step 3 delegates
+## [2026-04-28] refactor | tasks split — `task-status-wiki` renamed to `using-tasks` (policy); new `setup-tasks` skill owns greenfield + interactive migration (no auto-parsing of old flat STATUS.md); `project-bootstrap` Step 4 delegates

skills/project-bootstrap/SKILL.md

@@ -209,24 +209,11 @@ each get a `.gitkeep` so git tracks them.
 
 ## Step 4 — .tasks/
 
-If `.tasks/` already exists — skip it, notify the user.
+**Delegate to the `setup-tasks` skill.** It handles greenfield creation, migration from flat STATUS.md, and the no-op case uniformly, with its own confirmation gate. Don't recreate the layout inline.
 
-If it does not exist — create the structure:
+If `setup-tasks` is not installed, **stop** and tell the user — same rule as Step 3.
 
-```
+**Reference (for context only — `setup-tasks` is the source of truth):** the canonical layout is `.tasks/STATUS.md` (the board, with emoji status 🔴/🟡/⚪/🟢/🔵) plus `.tasks/<task-slug>.md` per active or paused task. The full pattern is documented in this repo at `.wiki/raw/setup-task-status-wiki.md`.
-.tasks/
-  STATUS.md     ← task board
-```
-
-Contents of `STATUS.md`:
-
-```markdown
-# Task Board
-_Updated: <today's date>_
-
-<!-- Tasks will appear here as work progresses.
-     Skill is activated by the phrase: use task management system -->
-```
 
 ---
 

skills/setup-tasks/SKILL.md

@@ -0,0 +1,202 @@
+---
+name: setup-tasks
+version: 1.0.0
+description: Creates or migrates a project's `.tasks/` board to the canonical layout — `STATUS.md` (the board, with emoji status legend) plus per-task `<task-slug>.md` files for each active or paused task. Use when the user says "set up tasks", "init tasks", "настрой таски", "инициализируй таски", "create task tracking", "migrate tasks to canon", "tasks broken", or whenever `using-tasks` detects a missing or non-canonical `.tasks/`. Two modes — greenfield (no `.tasks/`) and migrate (existing flat STATUS.md without per-task files). Confirmation gate before writing. Cross-platform.
+---
+
+# setup-tasks
+
+> Creates or migrates a `.tasks/` board to canon. The canonical layout is enforced by `using-tasks` and described in `.wiki/raw/setup-task-status-wiki.md` (the original idea file from which this skill is derived). This skill is the *only* place that creates the board structure.
+
+## When to use
+
+- User explicitly asks: set up / init / migrate / create tasks.
+- `using-tasks` runs and detects a missing or non-canonical `.tasks/` — its Prerequisites delegate here.
+- `project-bootstrap` Step 4 delegates here when initializing a new project.
+
+## Out of scope
+
+- Editing existing task content during normal work (that's `using-tasks`).
+- Anything outside `.tasks/`.
+
+## Hard rule: don't auto-mutate
+
+The procedure mutates `.tasks/`. **Pause for explicit confirmation between Phase 1 (discovery) and Phase 2 (plan).** A trigger phrase is permission to inspect, not to write.
+
+## Procedure
+
+### Phase 0 — Environment sanity
+
+- Confirm current working directory is a project root (preferably with `.git/`; otherwise it's still OK to bootstrap, just note it).
+- Tasks paths are POSIX-style (`.tasks/...`) on every OS.
+
+### Phase 1 — Discovery
+
+Inspect `.tasks/`:
+
+- **No `.tasks/`** → mode = `greenfield`.
+- **`.tasks/STATUS.md` exists with canonical signals** — has emoji status (🔴 / 🟡 / ⚪ / 🟢 / 🔵) AND at least one per-task `.tasks/<slug>.md` exists for any active/paused entry → mode = `noop`.
+- **`.tasks/STATUS.md` exists but flat** — no emoji legend, no per-task files, just plain `## Done` / `## In Progress` / `## Backlog` sections (or similar) → mode = `migrate`.
+
+Report findings:
+
+```
+Mode:        greenfield | noop | migrate
+STATUS.md:   exists | missing
+Per-task files: <count>
+Format:      canon | flat | mixed
+```
+
+### Phase 2 — Plan + confirm
+
+Show the plan in one block.
+
+**Greenfield:**
+```
+Will create .tasks/STATUS.md with the canonical board template.
+Per-task files will be created on demand by using-tasks when actual tasks are added.
+```
+
+**Migrate:**
+```
+Will:
+  • back up existing STATUS.md → STATUS.md.bak-<ts>
+  • for each task entry I can identify in the old STATUS.md, ask you for:
+      - task-slug (kebab-case, latin)
+      - current status (active / paused / ready / done / blocked)
+      - branch
+      - where you stopped (one sentence)
+      - next action (one sentence)
+    then write `.tasks/<slug>.md` and a canonical STATUS.md block.
+  • leave the .bak file as a fallback reference.
+```
+
+If existing `STATUS.md` is purely a placeholder (just the bootstrap-default comment block, no real tasks), treat as `greenfield` — no migration needed, just overwrite with the template.
+
+Wait for explicit confirmation ("ok", "go", "поехали"). Anything else → stop.
+
+### Phase 3 — Backup (migrate only)
+
+```bash
+TS=$(date +%Y%m%d-%H%M%S)
+cp .tasks/STATUS.md ".tasks/STATUS.md.bak-$TS"
+```
+
+### Phase 4a — Greenfield create
+
+Write `.tasks/STATUS.md`:
+
+```markdown
+# Task Board
+_Updated: <today>_
+
+<!--
+  Add one block per task, sorted by priority. Use the emoji status legend below.
+  Per-task deep context lives in .tasks/<task-slug>.md (created on demand by using-tasks).
+
+  Block format:
+
+    ## 🔴 [task-slug] — short description
+    **Status:** active
+    **Where I stopped:** one sentence — the exact thought or action interrupted
+    **Next action:** one concrete step to resume immediately
+    **Blocker:** (only if blocked) what is preventing progress
+    **Branch:** git branch name
+
+    ---
+
+  Status legend:
+    🔴 Active     — only one at a time
+    🟡 Paused     — in progress, resumable
+    ⚪ Ready      — defined, not started
+    🟢 Done       — kept until merged
+    🔵 Blocked    — waiting on external input
+-->
+```
+
+No per-task files at greenfield — they're created when actual tasks are added.
+
+### Phase 4b — Migrate
+
+In migrate mode, do *not* try to auto-parse the old flat STATUS.md. The old layout is too varied — agent-driven heuristics will mangle real work. Instead, drive the migration interactively:
+
+1. Show the user the old STATUS.md content (or a summary).
+2. Ask: "Which of these are real, in-flight tasks you want to keep?" Get a list.
+3. For each task, ask the four canonical fields (slug, status, branch, where-stopped, next-action). The skill never invents these.
+4. Build a fresh canonical `.tasks/STATUS.md` from those answers.
+5. Create `.tasks/<task-slug>.md` for each active or paused task using the per-task template (Goal, Key files, Decisions log, Open questions, Completed steps, Notes).
+6. Leave the `.bak-<ts>` file in place — historical record.
+
+Per-task template:
+
+```markdown
+# <task-slug>
+
+## Goal
+One paragraph. What this achieves and why it matters.
+
+## Key files
+- `path/to/file.ts` — role in this task
+
+## Decisions log
+- <today>: migrated from flat STATUS.md via setup-tasks@<version>
+
+## Open questions
+- [ ] (fill in)
+
+## Completed steps
+- [x] (fill in)
+
+## Notes
+```
+
+### Phase 5 — Verify
+
+After writes:
+
+- `.tasks/STATUS.md` exists and has the emoji status legend (or template comment block in greenfield).
+- For migrate: each task referenced in STATUS.md has its `<task-slug>.md` file (active and paused only).
+- No required content was lost (the `.bak` file is the safety net).
+
+If verification fails → restore from `.bak-<ts>` and report.
+
+### Phase 6 — Report
+
+Print final state:
+
+```
+✅ Tasks board ready at .tasks/.
+   Mode: greenfield | migrate
+   STATUS.md: <created | rewritten + .bak-<ts>>
+   Per-task files: <count>
+
+Next steps for the user:
+  • Add or edit task entries in .tasks/STATUS.md
+  • Read using-tasks SKILL.md if unfamiliar with the workflow
+```
+
+If invoked from `project-bootstrap`, return control silently.
+
+## Rollback
+
+1. `rm -rf .tasks/` (greenfield rollback)  
+   or  
+   `mv .tasks/STATUS.md.bak-<ts> .tasks/STATUS.md` (migrate rollback) and `rm .tasks/<task-slug>.md` for any newly created per-task files.
+2. `git reset HEAD .tasks/` if a git repo.
+3. Tell user what failed.
+
+## Common mistakes
+
+- **Auto-parsing existing flat STATUS.md.** Don't. The format varies, real work is at stake — drive migration through the user, one task at a time.
+- **Inventing task slugs / branches / "where you stopped" values.** Never. Ask the user. The whole point of `.tasks/` is *real* preserved context, not hallucinated context.
+- **Skipping confirmation on greenfield.** Yes, even greenfield needs the gate — the user might be running this in the wrong directory.
+- **Creating per-task files at bootstrap.** Don't pre-generate empty `<slug>.md` files in greenfield mode — wait until the user adds actual tasks.
+- **Editing the `.bak` file.** It's the rollback artifact; leave it alone.
+
+## Cross-platform notes
+
+The procedure is platform-agnostic. Wiki-style paths (`.tasks/...`) work the same on Windows / Linux / macOS. The only platform-conditional command is the timestamp generator (`date +%Y%m%d-%H%M%S` in bash; equivalent in PowerShell), and our scripts use bash via git-bash on Windows.
+
+## Source
+
+The canonical pattern (extended documentation, decisions log format, agent operations) lives in this repo at `.wiki/raw/setup-task-status-wiki.md`. Refer to it when designing project-specific extensions.

skills/using-tasks/SKILL.md

@@ -1,21 +1,32 @@
 ---
-name: task-status-wiki
+name: using-tasks
 version: 1.0.0
 description: >
-  Manage a persistent task status wiki inside a monorepo using the .tasks/ folder pattern.
+  Policy skill for working with an existing `.tasks/` board (per-task files + STATUS.md).
-  Use this skill whenever the user is switching between tasks, resuming a paused task,
+  Use whenever the user is switching between tasks, resuming a paused task, starting a new
-  starting a new task, asking "where were we", or wanting to track progress across multiple
+  task, asking "where were we", says "use task management system", "pause", "switch to X",
-  parallel workstreams. Also use when the user says "pause", "switch to X", "what's the status",
+  "what's the status", "update status", or wants to track progress across parallel workstreams.
-  "update status", or "initialize task tracking". Trigger even if the user doesn't explicitly
+  Trigger on any context-switching or multi-task coordination question in a code project.
-  mention the wiki — any context-switching or multi-task coordination question in a code project
+  If `.tasks/` is missing or non-canonical (no per-task `<task-slug>.md` files, no emoji
-  is a signal to use this skill.
+  status legend in STATUS.md), delegate to `setup-tasks` first — it has its own confirmation
+  gate. Renamed from `task-status-wiki` at v1.0.0.
 ---
 
-# Task Status Wiki
+# using-tasks
 
-A pattern for maintaining compressed working context across parallel tasks in a monorepo.
+> Policy for maintaining compressed working context across parallel tasks in a monorepo.
-The agent reads and updates a small wiki in `.tasks/` so that every session starts oriented
+> The agent reads and updates `.tasks/` so every session starts oriented and every switch
-and every switch costs seconds, not minutes.
+> costs seconds, not minutes. This skill governs *usage* of an existing `.tasks/` — initial
+> creation and migration to canon are owned by `setup-tasks`.
+
+## Prerequisites
+
+This skill assumes the project has a canonical `.tasks/` layout:
+
+- `.tasks/STATUS.md` — the board, with per-task blocks using emoji status (🔴 active / 🟡 paused / ⚪ ready / 🟢 done / 🔵 blocked).
+- `.tasks/<task-slug>.md` — one deep-context file per active or paused task.
+
+If `.tasks/` is **missing**, or `STATUS.md` exists but is non-canonical (e.g. flat sections like "## Done" / "## In Progress" without the emoji + per-task block format, or no per-task files exist alongside STATUS.md) — invoke `setup-tasks` first. It detects greenfield vs migrate, has its own confirmation gate, and creates / migrates the structure. Only after `setup-tasks` finishes should this skill operate on `.tasks/`.
 
 ## Structure
 
@@ -87,7 +98,7 @@ Temporary hypotheses, links, names of people to consult.
 ## Agent operations
 
 ### Session start
-1. Check if `.tasks/STATUS.md` exists. If not → run **Initialization** below.
+1. Check if `.tasks/STATUS.md` exists. If not → invoke `setup-tasks` and stop here until it returns.
 2. Read `STATUS.md`.
 3. If user names a task, read its `<task-slug>.md`.
 4. Confirm in one sentence: "We're in the middle of X, next step is Y."
@@ -120,22 +131,6 @@ Temporary hypotheses, links, names of people to consult.
 
 ---
 
-## Initialization (first time in a project)
-
-Run when `.tasks/` doesn't exist yet.
-
-1. Confirm understanding in one sentence.
-2. Ask: "What tasks are currently in flight? Give me each name and a one-line description."
-3. For each task: ask for branch, current status, and where work stopped last.
-4. Create `.tasks/STATUS.md` with all tasks filled in.
-5. Create `<task-slug>.md` for each active or paused task.
-6. Commit: `git add .tasks/ && git commit -m "chore: init task status wiki"`
-7. Print path to STATUS.md and confirm it's ready.
-
-**Do not invent task details — ask for what is unknown.**
-
----
-
 ## Rules
 
 - **Never lose "Where I stopped"** — most critical field. If unclear, ask before ending session.