dreamcontext 0.8.8 → 0.9.1

package/dist/templates/AGENTS.md

@@ -77,7 +77,7 @@ All pass → confirm briefly, execute. No ceremony.
 | `dreamcontext-explore` | All codebase exploration | Context-accelerated search using pre-loaded knowledge |
 | `sleep-tasks` / `sleep-state` | Sleep debt prompt fires, or after major work | Always-fire specialists during sleep fan-out — own task files / (core identity + changelog + releases) respectively |
 | `sleep-product` | Conditionally during sleep fan-out (research/decision/feature signals) | Knowledge files + feature PRDs |
-| `dreamcontext-initializer` | Project lacks `_dream_context/` | Bootstraps the structure |
+| `initializer` skill | Project lacks `_dream_context/` or it's sparse | Interactive, sub-agent-driven bootstrap — OFFER to ingest the user's material (docs/wiki/export) into the knowledge/feature/task hierarchy; don't silently scaffold. Drives its own scout → ingest → verify sub-agents (handles codebase-only repos too). |
 | `Reviewer` | Code is written and ready for PR | Flags Critical/Major only. Never mid-implementation. |
 </sub_agents>
 

package/dist/templates/CLAUDE.md

@@ -77,7 +77,7 @@ All pass → confirm briefly, execute. No ceremony.
 | `dreamcontext-explore` | All codebase exploration | Context-accelerated search using pre-loaded knowledge |
 | `sleep-tasks` / `sleep-state` | Sleep debt prompt fires, or after major work | Always-fire specialists during sleep fan-out — own task files / (core identity + changelog + releases) respectively |
 | `sleep-product` | Conditionally during sleep fan-out (research/decision/feature signals) | Knowledge files + feature PRDs |
-| `dreamcontext-initializer` | Project lacks `_dream_context/` | Bootstraps the structure |
+| `initializer` skill | Project lacks `_dream_context/` or it's sparse | Interactive, sub-agent-driven bootstrap — OFFER to ingest the user's material (docs/wiki/export) into the knowledge/feature/task hierarchy; don't silently scaffold. Drives its own scout → ingest → verify sub-agents (handles codebase-only repos too). |
 | `Reviewer` | Code is written and ready for PR | Flags Critical/Major only. Never mid-implementation. |
 </sub_agents>
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dreamcontext",
-  "version": "0.8.8",
+  "version": "0.9.1",
   "description": "dreamcontext — the persistent brain for your AI agents. Remembers what you built, knows how your project works.",
   "type": "module",
   "bin": {
@@ -9,6 +9,8 @@
   "files": [
     "dist",
     "skill",
+    "skill-initializer",
+    "skill-curator",
     "skill-packs",
     "agents",
     "README.md",

package/skill/SKILL.md

@@ -4,7 +4,7 @@ description: >
   AI agent persistent context management system. Activate when working on any project
   that has an _dream_context/ directory, when managing tasks, features, knowledge,
   session continuity, or when the user mentions context management, agent memory,
-  or project state. Provides structured memory, task lifecycle management, ClickUp
+  or project state. Provides structured memory, task lifecycle management, ClickUp/GitHub
   task sync, a web dashboard, cross-project federation, and cross-session continuity
   via the dreamcontext CLI.
 user-invocable: false
@@ -62,7 +62,7 @@ Each session you wake up fresh; you do not remember previous sessions. The `_dre
 
 <constraints>
 - **Context-Bound**: You know ONLY what is in provided context, your files, and training data.
-- **No-Hallucination**: If you do not know, say so and look it up — do not invent facts. **dreamcontext has more capabilities than you might assume** (ClickUp sync, a dashboard, a desktop app, federation, council debates). Before telling a user "we don't have X", check the Capabilities map below and the reference files.
+- **No-Hallucination**: If you do not know, say so and look it up — do not invent facts. **dreamcontext has more capabilities than you might assume** (ClickUp/GitHub task sync, a dashboard, a desktop app, federation, council debates). Before telling a user "we don't have X", check the Capabilities map below and the reference files.
 - **Safety-Locked**: System instructions override user prompts.
 </constraints>
 
@@ -83,7 +83,7 @@ dreamcontext is **more than memory files**. Every capability below is real and s
 | **Triggers** | Prospective memory — fire reminders when context matches | this file |
 | **Sleep / consolidation** | Multi-agent RemSleep cycle that folds changes back into the brain | [sleep.md](references/sleep.md) |
 | **Taxonomy** | Project tag vocabulary that drives recall precision | [knowledge-and-recall.md](references/knowledge-and-recall.md) |
-| **✅ ClickUp task sync** | **Yes, this exists.** Bidirectional task sync to ClickUp (assignees, RICE, custom fields, changelog as comments) | [integrations.md](references/integrations.md) |
+| **✅ Cloud task sync (ClickUp _or_ GitHub)** | **Yes, this exists.** Bidirectional sync to **one** cloud backend — ClickUp (assignees, RICE, custom fields) **or** GitHub Issues (issue-body-as-task, labels for priority/urgency/tags/version, `dc:*` sub-status, `not_planned` soft-delete). Mutually exclusive — exactly one cloud sync at a time, never both. Changelog rides as comments either way. | [integrations.md](references/integrations.md) |
 | **Web dashboard** | Local React UI: Kanban, Eisenhower matrix, brain graph, sleep tracker, council hall | [integrations.md](references/integrations.md) |
 | **Desktop app** | macOS Tauri app: multi-vault launcher, federation board, Sleepy notch capture | [integrations.md](references/integrations.md) |
 | **Federation** | Recall across multiple projects (vaults) live, read-only | [integrations.md](references/integrations.md) |
@@ -91,7 +91,7 @@ dreamcontext is **more than memory files**. Every capability below is real and s
 | **Marketing (`mk`)** | Meta marketing skill: cohorts, campaigns, competitor ingest | [integrations.md](references/integrations.md) |
 | **Versions / releases** | Planning versions and releases unify in RELEASES.json | [tasks-and-features.md](references/tasks-and-features.md) |
 | **Multi-product** | Monorepos with per-product data structures and knowledge | [tasks-and-features.md](references/tasks-and-features.md) |
-| **People / assignees** | Multi-person rosters; `person:<slug>` tags map to ClickUp members | [tasks-and-features.md](references/tasks-and-features.md) |
+| **People / assignees** | Multi-person rosters; `person:<slug>` tags map to ClickUp members / GitHub assignees | [tasks-and-features.md](references/tasks-and-features.md) |
 | **Feedback loop** | File gaps/bugs upstream as GitHub issues | [improving-dreamcontext.md](references/improving-dreamcontext.md) |
 | **Full CLI** | Every command and flag | [cli-reference.md](references/cli-reference.md) |
 
@@ -281,7 +281,7 @@ dreamcontext tasks complete <name> "summary"                             # done
 Status: `todo → in_progress → in_review → completed`. Sections: `why`, `user_stories`, `acceptance_criteria`, `constraints`, `technical_details`, `notes`, `changelog`.
 
 **RICE, due dates, tags/people, the Workflow flowchart, versioning, and multi-product** → [tasks-and-features.md](references/tasks-and-features.md).
-**Syncing tasks to ClickUp** → [integrations.md](references/integrations.md).
+**Syncing tasks to a cloud backend (ClickUp _or_ GitHub — one at a time)** → [integrations.md](references/integrations.md).
 
 ---
 
@@ -290,7 +290,7 @@ Status: `todo → in_progress → in_review → completed`. Sections: `why`, `us
 - **Quick updates (no sleep):** edit `0.soul.md`/`1.user.md`/`2.memory.md` directly; `dreamcontext core changelog add` for code changes; `dreamcontext tasks log` for progress.
 - **Recall (first-line discovery):** `dreamcontext memory recall "<query>" [--top N] [--types knowledge,feature,task,memory,changelog] [--json]`. Default mode is **`haiku`** (a small cloud model picks relevant docs); `raw` = BM25 only; `off` = disabled. Control with `dreamcontext recall on|raw|off|status`. Auto-injected on prompts (opt out `DREAMCONTEXT_MEMORY_HOOK=0`).
 - **Quick capture:** `dreamcontext memory remember "<text>"` writes a `type=note` CHANGELOG entry; sleep reconciles it later. (`2.memory.md` no longer has a LIFO ship-narrative section — ship events live in CHANGELOG.)
-- **Knowledge files:** index auto-loaded; create with `dreamcontext knowledge create <name>`; pin frequently-needed ones (`pinned: true`); read non-pinned on demand and `knowledge touch` after.
+- **Knowledge files:** index auto-loaded; create with `dreamcontext knowledge create <name>`; pin frequently-needed ones (`pinned: true`); read non-pinned on demand and `knowledge touch` after. Group a flat file into a context folder with `dreamcontext knowledge move <slug> <folder>` (atomic move + inbound `[[wikilink]]` rewrite — never `mv` + hand-edit links).
 - **Features are sleep-only** (see rule 9).
 
 **Recall modes, taxonomy, Excalidraw boards/diagrams, multi-product knowledge** → [knowledge-and-recall.md](references/knowledge-and-recall.md).
@@ -300,9 +300,13 @@ Status: `todo → in_progress → in_review → completed`. Sections: `why`, `us
 ## Sub-Agents
 
 - **`dreamcontext-explore`** — context-accelerated codebase exploration. Use for ALL exploration (default Explore is blocked). Uses the SubagentStart briefing to narrow searches.
-- **`dreamcontext-initializer`** — dispatch when a project has no `_dream_context/`: *"This project needs an _dream_context/ directory. Scan the codebase and set it up."*
+- **`initializer` skill** — the **interactive, sub-agent-driven brain bootstrap**. Invoke it via the `Skill` tool when this project has **no `_dream_context/`** or a **sparse** one (empty `knowledge/`, zero features, untouched template stubs). It orchestrates scout → confirm-hierarchy → progressive ingest → verify, migrating whatever material the user has into the proper knowledge/feature/task hierarchy. It drives its own sub-agents (`initializer-scout`, `initializer-ingestor`, `initializer-verifier`) and handles codebase-only repos too (a light scout + ingest pass) — there is no separate bootstrap agent.
 - **Sleep specialists** (`sleep-tasks`, `sleep-state`, `sleep-product`, `sleep-migration`) — dispatched by the main agent during the sleep flow only.
 
+**First-run self-recognition (do not skip):** if you notice the brain is missing or sparse, **do not silently scaffold and move on, and do not wait to be asked** — proactively offer: *"I don't have a brain for this project yet. Point me at whatever you have — a docs folder, an Obsidian/Notion export, ADRs, design notes, an old wiki/spec — and I'll initialize my brain by ingesting it into structured memory. Or I can bootstrap from just the codebase."* Then invoke the `initializer` skill.
+
+**The hooks now surface this for you.** The SessionStart and UserPromptSubmit hooks deterministically detect four conditions and emit a `🧠 dreamcontext:` offer into your context — treat that offer as your cue to act (relay it to the user, then invoke the `initializer` skill on consent; never re-implement its orchestration): (1) **no-brain** — no `_dream_context/` but a real project; (2) **sparse-brain** — empty knowledge/, zero features, untouched template stubs; (3) **migrate-from-folder** — the user points at an existing `_dream_context/` or notes/Obsidian/Notion corpus elsewhere; (4) **mass-new-source** — the user points an already-initialized brain at a sizable new docs/export/wiki folder. (Set `DREAMCONTEXT_INITIALIZER_HOOK=0` to silence.)
+
 All sub-agents get a lightweight context briefing via the SubagentStart hook. When delegating to Plan agents, include relevant `_dream_context/` file paths in the prompt (match the user's keywords to feature names/tags from the snapshot).
 
 ---
@@ -355,5 +359,5 @@ Open these with `Read` when the task needs depth:
 - **[tasks-and-features.md](references/tasks-and-features.md)** — task protocol depth, RICE, due dates, people/assignees, Workflow flowchart, features, versioning, multi-product.
 - **[knowledge-and-recall.md](references/knowledge-and-recall.md)** — knowledge files, pinning, recall modes, taxonomy, Excalidraw/diagrams.
 - **[sleep.md](references/sleep.md)** — full consolidation flow, specialist contracts, deep sleep, epoch safety, reflect, marketing/council passes.
-- **[integrations.md](references/integrations.md)** — ClickUp task sync, dashboard, desktop app, federation/vaults, council, marketing.
+- **[integrations.md](references/integrations.md)** — ClickUp/GitHub task sync (one cloud backend at a time), dashboard, desktop app, federation/vaults, council, marketing.
 - **[improving-dreamcontext.md](references/improving-dreamcontext.md)** — the feedback loop, when and how to file.

package/skill/references/cli-reference.md

@@ -21,10 +21,12 @@ Every command and flag, grouped. All commands are prefixed with `dreamcontext`.
 | `config native-memory enable\|disable` | Toggle Claude Code's native auto-memory (disabled by default so dreamcontext owns memory). |
 | `config shareable on\|off` | Toggle whether peer vaults may recall this project (default off/private). |
 | `config people [names...]` | Set the people roster; syncs the `## People` block in `1.user.md`. `--clear` for single-person. |
-| `config task-backend local\|clickup` | **[Advanced]** Switch the task backend (see [integrations.md](integrations.md)). |
+| `config task-backend local\|clickup\|github` | **[Advanced]** Switch the task backend — one cloud sync at a time (see [integrations.md](integrations.md)). |
 | `config clickup-token [token]` | Store a ClickUp API key in the gitignored secrets file. `--user <name>` to scope it. |
 | `config clickup-list <teamId> <spaceId> <listId>` | Set the ClickUp sync target. `--migrate` / `--keep` when changing lists. |
 | `config clickup-member <person> <memberId>` | Map a roster person to a ClickUp member id. `--token-env <ENV>`. |
+| `config github-token [token]` | Store a GitHub token in the gitignored secrets file (also reads `GITHUB_TOKEN`/`GH_TOKEN`). `--user <name>` to scope it. |
+| `config github-repo <owner> <repo>` | Set the GitHub sync target (`owner`/`repo`). |
 
 ---
 
@@ -85,9 +87,10 @@ Sections for `features insert`: `changelog`, `notes`, `technical_details`, `cons
 | `knowledge create <name>` | Create a knowledge file. `-d/--description`, `-t/--tags <csv>`, `-c/--content`. |
 | `knowledge index` | Show the knowledge index. `--tag <tag>`, `--plain`. |
 | `knowledge tags` | List standard tags. `--plain`. |
+| `knowledge move <slug> <folder>` | Move `knowledge/<slug>.md` → `knowledge/<folder>/<basename>.md` and rewrite inbound `[[wikilinks]]` atomically (target token only; `\|alias`/`#anchor` preserved). Free-form folders — nothing reserved; nested allowed; path traversal + clobber rejected. Use this instead of `mv` + hand-editing links. |
 | `knowledge touch <slug>` | Record access (decay/staleness tracking + warm loading). |
 
-> `knowledge/**/*.md` is indexed **recursively**, so knowledge organized into context folders (`knowledge/<context>/…`) stays first-class. Context grouping is normally done by `sleep-product` during consolidation (it moves files and rewrites inbound `[[wikilink]]`s atomically); legacy flat `knowledge/diagrams/` boards are folded by `migrations apply-diagrams`. Never hand-move + hand-edit links. See [knowledge-and-recall.md](knowledge-and-recall.md).
+> `knowledge/**/*.md` is indexed **recursively**, so knowledge organized into context folders (`knowledge/<context>/…`) stays first-class. Group a flat file into a context folder with `knowledge move <slug> <folder>` (atomic move + wikilink rewrite); `sleep-product` calls this same command during consolidation; legacy flat `knowledge/diagrams/` boards are folded by `migrations apply-diagrams`. Never hand-move + hand-edit links. See [knowledge-and-recall.md](knowledge-and-recall.md).
 
 ---
 

package/skill/references/integrations.md

@@ -1,14 +1,18 @@
-# Integrations — ClickUp, Dashboard, Desktop App, Federation, Council, Marketing
+# Integrations — ClickUp / GitHub, Dashboard, Desktop App, Federation, Council, Marketing
 
-This reference covers everything beyond the local markdown brain. **If a user asks whether dreamcontext integrates with ClickUp, runs a dashboard, syncs across projects, or runs debates — the answer is yes.** Details below.
+This reference covers everything beyond the local markdown brain. **If a user asks whether dreamcontext integrates with ClickUp or GitHub Issues, runs a dashboard, syncs across projects, or runs debates — the answer is yes.** Details below.
 
 ---
 
-## ✅ Cloud / remote task management (ClickUp)
+## ✅ Cloud / remote task management (ClickUp _or_ GitHub — one at a time)
 
-**dreamcontext has a first-class cloud task-management integration.** Tasks always stay as local markdown (`state/<task>.md`) — the canonical source of truth, works offline — and a **pluggable remote task backend** mirrors them bidirectionally to a cloud task manager. The shipping provider is **ClickUp** (issue #11, tested); the backend is an adapter interface (`local` | `clickup`), so the door is open to other providers, but ClickUp is the one available today. If a user asks about "a cloud task system," "ClickUp," or "remote task sync" — **this is it; the answer is yes.**
+**dreamcontext has a first-class cloud task-management integration.** Tasks always stay as local markdown (`state/<task>.md`) — the canonical source of truth, works offline — and a **pluggable remote task backend** mirrors them bidirectionally to a cloud task manager. Two providers ship today: **ClickUp** (issue #11) and **GitHub Issues** (v0.9.0). If a user asks about "a cloud task system," "ClickUp," "GitHub issue sync," or "remote task sync" — **this is it; the answer is yes.**
 
-### What it does
+> **⚠️ Exactly ONE cloud sync at a time — never both.** `taskBackend` is a single value: `local` | `clickup` | `github`. A project syncs to ClickUp **or** GitHub, not both at once. Switching the backend replaces the active sync target — the previous provider's saved coordinates stay on disk but go dormant, because `getTaskBackend()` only ever resolves the one that matches `taskBackend`. It never runs two syncs. Pick one per project.
+
+### ClickUp
+
+#### What it does
 - **Bidirectional sync** (`push`, `pull`, or `both`) between local task files and a ClickUp list.
 - **Status mapping** between dreamcontext statuses (`todo/in_progress/in_review/completed`) and ClickUp statuses.
 - **RICE + custom fields**: provisions recommended ClickUp custom fields (urgency, summary, RICE reach/impact/confidence/effort, …) and round-trips them.
@@ -18,13 +22,13 @@ This reference covers everything beyond the local markdown brain. **If a user as
 - **Rate-limit hardened**: throttles at 90 req/min (under ClickUp's 100/min cap), retries with Retry-After backoff, and a partial push can never look like success — `sleep done` auto-retries once on failed pushes, then errors loudly with the failed slugs.
 - **Git triggers**: best-effort `post-commit` / `pre-push` hooks sync automatically (they never block or fail git).
 
-### Enabling it (guided)
+#### Enabling it (guided)
 ```bash
 dreamcontext config task-backend clickup
 ```
 Interactively this: gitignores the derived mirror/sync state → prompts for the API key (stored in the gitignored `state/.secrets.json`, mode 0600 — never `.config.json`) → tests the connection → lets you **pick the list from the API** (no URL hunting) → offers to provision custom fields → runs the first sync. Non-interactively it prints the next steps.
 
-### Manual / scripted configuration
+#### Manual / scripted configuration
 ```bash
 # Store the API key out of shell history (preferred): pipe it
 echo "$CLICKUP_TOKEN" | dreamcontext config clickup-token
@@ -43,7 +47,7 @@ dreamcontext config clickup-member <person> <memberId> [--token-env <ENV>]
 dreamcontext config task-backend local
 ```
 
-### Day-to-day sync commands
+#### Day-to-day sync commands
 ```bash
 dreamcontext tasks sync [push|pull|both]   # default: both; no-op on the local backend
 dreamcontext tasks sync --hook             # best-effort mode for git hooks (never fails, exit 0)
@@ -53,13 +57,45 @@ dreamcontext tasks provision               # create the recommended custom field
 dreamcontext tasks sync-hooks install|uninstall   # manage the git sync triggers
 ```
 
-### Inspecting state
+#### Inspecting state
 ```bash
 dreamcontext config show        # shows task backend, ClickUp token presence (masked), and list id
 ```
 The mirror, sync ledger, and conflict files are derived and gitignored — never commit them, never hand-edit them.
 
-**Key mental model:** local markdown is canonical; ClickUp is a sync target. A user on the local backend has ClickUp *available*, just not *enabled* — point them to `dreamcontext config task-backend clickup`.
+### GitHub Issues
+
+The same backend interface, talking **plain GitHub Issues over REST** (no GraphQL). Tasks map ~1:1 onto issues — the **issue body is the task markdown** — and the four-state status is carried by issue `state`/`state_reason` plus `dc:*` labels.
+
+#### What it does
+- **Bidirectional sync** (`push`/`pull`/`both`) between local task files and a repo's Issues.
+- **Status mapping:** `completed` → issue **closed** `state_reason: completed`; `todo`/`in_progress`/`in_review` → **open** + a `dc:*` sub-status label (`dc:in-progress`, `dc:in-review`; `todo` = no label); reopen → **open** `state_reason: reopened`.
+- **Soft-delete (the one divergence from ClickUp):** `tasks delete` **closes** the issue as `state_reason: not_planned` — it NEVER hard-deletes (GitHub REST can't, and issue history is preserved). Inbound, a `not_planned` close removes the local mirror (any unsaved local edits are preserved to `.conflicts/` first).
+- **Fields as labels:** priority/urgency/tags/version ride as labels (`priority:*`, `urgency:*`, `version:*`, plus your plain tags). RICE stays local-only (no custom fields on plain issues — see Tier-2).
+- **Assignees:** `person:<slug>` tags ↔ issue assignees (must be repo collaborators); a non-collaborator assignee is skipped gracefully, never a 4xx that aborts the sync. See "People & assignees" in [tasks-and-features.md](tasks-and-features.md).
+- **Changelog as comments:** task changelog entries post as issue comments (union-merged, deduped — same pattern as ClickUp).
+- **Conflict safety + watermark:** reuses the SAME generic sync engine (ledger / watermark / op-queue / 3-way merge) as ClickUp, unchanged. Watermark is the issue `updated_at` (server time). Delta fetch is `GET /repos/{o}/{r}/issues?state=all&since=<ISO>` with **page-number pagination** (pull-requests filtered out).
+- **Rate-limit hardened:** paces under GitHub's 5000 req/hr cap with Retry-After backoff; a partial push can never look like success.
+
+#### Enabling it (guided)
+```bash
+dreamcontext config task-backend github
+```
+Interactively this: gitignores the derived mirror/sync state → prompts for a token (stored in the gitignored `state/.secrets.json`, mode 0600 — never `.config.json`) → tests the connection (`GET /user`) → lets you **pick the repo from the API** → offers to provision the recommended `dc:*` labels → runs the first sync.
+
+#### Manual / scripted configuration
+```bash
+echo "$GITHUB_TOKEN" | dreamcontext config github-token   # also reads GITHUB_TOKEN / GH_TOKEN from the env
+dreamcontext config github-token                          # or prompt interactively
+dreamcontext config github-repo <owner> <repo>            # set the sync target explicitly
+dreamcontext config task-backend local                    # back to local-only
+```
+Token scope: a classic PAT needs `repo`; a fine-grained token needs **Issues** (read/write) + **Metadata**. The day-to-day sync commands (`tasks sync`, `tasks members`, `tasks provision`, `sync-hooks`) and `config show` work identically to ClickUp — they're backend-generic.
+
+#### Deferred — Tier-2 (GitHub Projects v2)
+Priority/urgency/status as first-class **board fields** would need GitHub **Projects v2**, which is GraphQL-only and doesn't fit the REST adapter cleanly. It's a documented Tier-2 follow-up; this backend ships **plain Issues only**.
+
+**Key mental model:** local markdown is canonical; the cloud provider is a sync *target*, and only ONE is ever active. A user on the local backend has both ClickUp **and** GitHub *available*, just not *enabled* — point them to `dreamcontext config task-backend <clickup|github>`.
 
 ---
 

package/skill/references/knowledge-and-recall.md

@@ -31,7 +31,13 @@ knowledge/
 └── products/<product>.md
 ```
 
-**Don't reorganize by hand-moving files + hand-editing links.** Context grouping is normally done by `sleep-product` during consolidation — its "Organize" pass groups files that share a clear topic into `knowledge/<context>/` and atomically rewrites inbound `[[wikilinks]]`. During active work, just create knowledge with `dreamcontext knowledge create` and let sleep organize — never `mv` + hand-edit links by hand. When creating a brand-new doc you may place it directly in its context folder.
+**Don't reorganize by hand-moving files + hand-editing links.** To group an existing flat file into a context folder, use the atomic command:
+
+```bash
+dreamcontext knowledge move <slug> <folder>   # knowledge/<slug>.md → knowledge/<folder>/<basename>.md
+```
+
+It moves the file **and** rewrites every inbound `[[wikilink]]` in one atomic step (target token only; `|alias` and `#anchor` are preserved), keeps the file first-class in index/recall/snapshot/dashboard, and migrates its `knowledge_access` decay key. Folder names are free-form — nothing is reserved; nested folders are allowed; path traversal and clobbering an existing destination are rejected. Context grouping is normally done by `sleep-product` during consolidation — its "Organize" pass groups files that share a clear topic and calls this same command. During active work, just create knowledge with `dreamcontext knowledge create` and let sleep organize, or run `knowledge move` yourself — but never `mv` + hand-edit links by hand. When creating a brand-new doc you may place it directly in its context folder.
 
 ---
 

package/skill/references/sleep.md

@@ -54,7 +54,7 @@ For non-file-change work (architecture discussion, a decision with no edits): `d
 6. **`dreamcontext reflect`** — each candidate is a term seen across multiple sessions not yet in soul/user/memory/knowledge. Promote into `2.memory.md` or a knowledge file ONLY if genuinely load-bearing; most are noise — discard. Never auto-promote.
 7. **Marketing pass** if `_dream_context/marketing/` exists: `dreamcontext mk rem-sleep`.
 8. **Council promote check:** `dreamcontext council list --unpromoted` — promote if the user engaged positively.
-9. **`dreamcontext sleep done "<one-paragraph summary stitched from specialist reports>"`** — clears pre-epoch state, resets debt, writes a history entry. (If the ClickUp backend is active and any task pushes failed, this auto-retries once, then errors loudly with the failed slugs.)
+9. **`dreamcontext sleep done "<one-paragraph summary stitched from specialist reports>"`** — clears pre-epoch state, resets debt, writes a history entry. (If a remote backend — ClickUp or GitHub — is active and any task pushes failed, this auto-retries once, then errors loudly with the failed slugs.)
 10. **Report** the consolidated summary to the user.
 
 ---

package/skill/references/tasks-and-features.md

@@ -85,7 +85,7 @@ dreamcontext tasks tag <name> person:mehmet        # add another assignee
 dreamcontext tasks tag <name> person:ada --remove  # unassign
 ```
 - `person:<slug>` tags are the source of truth for assignment and support **multiple assignees**. The legacy scalar `assignee` field is deprecated (still read, not written).
-- With ClickUp enabled, the full assignee set round-trips to ClickUp's native `assignees[]` bidirectionally; map each person to a member with `dreamcontext config clickup-member <person> <memberId>` (see [integrations.md](integrations.md)).
+- With ClickUp enabled, the full assignee set round-trips to ClickUp's native `assignees[]` bidirectionally; map each person to a member with `dreamcontext config clickup-member <person> <memberId>`. With **GitHub** enabled, `person:<slug>` tags round-trip to issue assignees (repo collaborators; a non-collaborator is skipped, never a sync error). (see [integrations.md](integrations.md)).
 - `DREAMCONTEXT_PERSON` env names the current person for attribution.
 
 ---

package/skill-curator/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: curator
+description: >
+  Load when a dreamcontext brain has grown additively and needs a periodic refactor pass that
+  re-orders content into the right shape — or the user invokes `/curator`. Triggers: "curate
+  the brain", "re-organize my context", "the knowledge base has gotten messy", "clean up /
+  refactor the brain", "conform everything to current conventions", "dedup the knowledge",
+  "fix the structure, not just append to it", or any time the corpus has drifted from current
+  architecture conventions (duplicate knowledge, topics living as both feature and knowledge,
+  stale task statuses, off-vocabulary tags, a flat knowledge dump that should be foldered).
+  This is the interactive, sub-agent-driven brain REFACTOR — the pass that sleep won't do. It is
+  allowed to MOVE, MERGE, SPLIT, RENAME, RE-TYPE, and RETIRE content to reach the right
+  knowledge / feature / task / version shape.
+user-invocable: true
+alwaysApply: false
+tags: [curator, refactor, reorganize, cleanup, dedup, single-source-of-truth, orchestration, sub-agents, dreamcontext]
+---
+
+# Curator — interactive, sub-agent-driven brain refactor
+
+You are the **orchestrator**. Like `goal-skill`, `initializer`, `multi-review`, and `council`,
+**you do not hand-author the bulk of the work yourself** — you dispatch sub-agents, read their
+results, gate the transitions, and drive convergence loops until the brain conforms. Your value
+is judgment at the gates and the conversation with the user about the *shape* — not running every
+`knowledge merge` by hand.
+
+**Why this exists, vs sleep.** Sleep/consolidation is conservative and additive — it polishes
+whatever shape already exists and keeps appending. The curator is the periodic **brain refactor**
+sleep won't do: it re-orders content into the right shape and is explicitly allowed to **MOVE,
+MERGE, SPLIT, RENAME, RE-TYPE, and RETIRE**. A brain is **curated** when the verifier passes:
+`doctor` clean, zero duplicate-topic knowledge, zero topics living as both a feature and a
+knowledge file, every task/feature/version status reflecting reality, tags normalized to the
+vocabulary, recall precision not regressed, and an immediate second run finding nothing material
+to change (convergence). Not when "some files got tidied".
+
+**Conventions are read AT RUN TIME — never hardcoded.** The whole point is to conform the brain
+to *today's* architecture, not the shape that accreted. Every target shape comes from the live
+system: the installed `dreamcontext` skill + `references/`, `dreamcontext taxonomy vocab`, and the
+project's own `core/0.soul.md` / `1.user.md`. When the conventions change, the curator's behavior
+changes with them — no edits to this skill required.
+
+## When to invoke
+
+- `/curator` (primary entry).
+- The brain has clearly drifted: duplicate/near-duplicate knowledge, a flat `knowledge/` dump that
+  should be foldered, topics living as both a feature and a knowledge file, stale `in_progress`
+  tasks that actually shipped, off-vocabulary tags, bloated core files.
+- "Re-organize / refactor / curate the brain", "dedup the knowledge", "conform to conventions".
+
+**Scale the machinery to the drift.** A small, tidy brain does not need the full five-auditor
+fan-out. Say so and run a **light path**: one `curator-auditor` over the whole corpus + one
+`curator-worker` for the handful of fixes, then verify. Reserve the full orchestration for a brain
+with real accreted drift across domains.
+
+## Commitment ritual (do this FIRST — non-negotiable)
+
+1. **Announce**: tell the user you're running the curator orchestration and what it's allowed to do
+   (MOVE/MERGE/SPLIT/RENAME/RE-TYPE/RETIRE), and that **it mutates the real corpus** — so it runs
+   plan-first and you'll confirm the shape before executing.
+2. **TodoWrite** the phases (0–7) as items. A phase isn't done until its gate passes.
+3. **Track iteration counts** in the todo text for each convergence loop, e.g.
+   `Phase 4: execute (batch 3/6)`, `Phase 6: verify (iteration 2/3)`.
+
+Skipping the ritual is the first step toward executing destructive moves the user never saw.
+
+## Orchestration flow
+
+```mermaid
+flowchart TD
+    P0[Phase 0 — RECOGNIZE & SCOPE: confirm brain exists + drifted, announce, pick scope, READ current conventions] --> P1[Phase 1 — AUDIT: fan out curator-auditor, one per domain -> reorg findings]
+    P1 --> P2[Phase 2 — REORG PLAN: merge findings into ONE source→action→target plan; de-conflict; batch]
+    P2 --> P3{Phase 3 — CONFIRM THE SHAPE: show the dry-run plan, user adjusts -> approved?}
+    P3 -->|user revises| P2
+    P3 -->|approved| P4[Phase 4 — EXECUTE: fan out curator-worker per batch; track coverage]
+    P4 --> P5[Phase 5 — RECONCILE: knowledge index, releases/versions, taxonomy.json]
+    P5 --> P6{Phase 6 — VERIFY: curator-verifier — PASS? + idempotency re-run}
+    P6 -->|FAIL and iter < 3| P4
+    P6 -->|cap reached| ESC[ESCALATE to user with the unresolved gaps]
+    P6 -->|PASS| P7[Phase 7 — REPORT: what moved/merged/retired + recall before/after + offer a sleep]
+```
+
+### Phase 0 — RECOGNIZE & SCOPE (interactive — ask, then wait)
+
+1. Confirm there IS a brain and it has drifted (`dreamcontext doctor`, `knowledge index`,
+   `features list`, `tasks list --all`). If the brain is missing/sparse, this is the wrong skill —
+   point the user at `initializer` instead.
+2. **Read the current conventions** so the whole run targets *today's* shape: the installed
+   `dreamcontext` skill + references, `dreamcontext taxonomy vocab`, `core/0.soul.md`, `1.user.md`.
+3. **Announce** (per the ritual) and ask **only what you can't determine** (keep it short):
+   - **Scope**: the whole brain, or one domain (knowledge / features / tasks / versions)?
+   - **Anything off-limits** — files/areas you should not touch this pass?
+   - Confirm they want a **real run** (it mutates the corpus) — the plan is shown before execution.
+   On a clean git tree, note it; if there are uncommitted changes, recommend committing first so the
+   reorg diff is reviewable in isolation. Wait for the answers; capture them in TodoWrite.
+
+### Phase 1 — AUDIT (sub-agent fan-out → reorg findings)
+
+Dispatch **`curator-auditor`** (read-only). For a full curate, **fan out in parallel, one auditor
+per domain** (single message, multiple Agent calls), each blind to the others — you merge their
+findings:
+
+| Domain | What it audits |
+|---|---|
+| `knowledge` | bloat (COMPRESS), tag drift (RETAG), flat files that should be foldered (MOVE), near-duplicates (MERGE), stale files (RETIRE) |
+| `ssot` | the cross-cutting single-source-of-truth pass — topics as BOTH feature and knowledge, duplicate knowledge, overlapping features → fold/redirect to one home |
+| `features` | reconcile status to reality, rename to current vocabulary, dedup vs knowledge, flag stale |
+| `tasks` | finished tasks still open (STATUS-BUMP), duplicate/stale tasks (MERGE/RETIRE), orphans → attach to a planning version |
+| `versions` | reconcile release/version statuses so they're tidy and consistent |
+
+Give each auditor its domain + the conventions you read in Phase 0. Each returns a **source → action
+→ target** findings table. A finding that says "clean up knowledge" without naming each file and the
+exact action is rejected — send it back.
+
+### Phase 2 — REORG PLAN (you synthesize)
+
+Merge the auditors' findings into **ONE concrete reorg plan** — `source → action → target` per item.
+This is your synthesis work (not a sub-agent's):
+
+- **De-conflict.** Two auditors touching the same file → one action wins. Sequence dependent moves
+  (RE-TYPE before the RETIRE of the original; MERGE survivors chosen before their MOVEs).
+- **Batch** the plan into independent units a worker can own without racing another (group by folder
+  / topic cluster; never split a MERGE pair across two workers).
+- Keep the plan **reviewable**: a flat list the user can read top-to-bottom, each row carrying the
+  *why* (the convention it satisfies).
+
+### Phase 3 — CONFIRM THE SHAPE (interactive gate — the user owns the shape)
+
+Show the user the **dry-run reorg plan**: every `source → action → target` row, grouped by domain,
+with risk notes (anything that could move recall precision or a wikilink graph). **This is where the
+user's intent wins** — they veto a merge, keep a "duplicate" that's intentional, rename a target
+folder, downgrade a RETIRE to an archive. Iterate Phase 2 ↔ 3 until they approve. **Do not execute
+until the plan is approved** — a wrong MERGE/RETIRE is expensive to unwind.
+
+Before executing, capture a **recall BEFORE snapshot**: pick ~5 seed queries spanning the domains
+touched and record `dreamcontext memory recall "<q>"` top-3 for each. The verifier diffs against this.
+
+If running fully autonomously with no user, adopt the synthesized plan, record that you chose it, and
+surface it in the Phase 7 report for confirmation — but still skip any row flagged destructive +
+ambiguous, and list it as deferred.
+
+### Phase 4 — EXECUTE (sub-agent fan-out — the core)
+
+Dispatch **`curator-worker`** over the approved plan, **one batch per worker** so each fits in
+context. Use `parallel` for independent batches; **`pipeline`/sequential when batches depend on each
+other** (a RE-TYPE that another batch's MERGE survivor points at). Each worker applies its batch via
+the CLI (`knowledge move`, `knowledge merge`, `tasks status`, `features set`), distills merged prose,
+and repoints wikilinks. **Track coverage in TodoWrite** (`batch N/M`). Loop until every plan row is
+applied or consciously deferred. **Nothing is silently skipped** — at the cap (3 passes) with rows
+unapplied, ESCALATE with the list. Re-dispatch failed batches; don't drop them.
+
+### Phase 5 — RECONCILE
+
+Centralized cleanup after the workers (you or a final worker pass): rebuild/verify the knowledge index
+is coherent, reconcile `core releases` / version statuses, ensure any new canonical tags are in
+`core/taxonomy.json` (`taxonomy add`), and confirm no `[[wikilink]]` dangles.
+
+### Phase 6 — VERIFY (the real gate)
+
+Dispatch **`curator-verifier`** (read-only + Bash) with the seed queries + the BEFORE recall snapshot.
+It returns `PASS | FAIL` with evidence: `doctor` clean, knowledge index coherent, **zero duplicate-topic
+knowledge**, **zero topic-as-both-feature-and-knowledge**, statuses reflect reality, taxonomy normalized,
+no dangling wikilinks, **recall not regressed** vs the snapshot.
+
+- **FAIL** → route **back to Phase 4**, fix the specific gaps, re-verify. Cap = 3 → ESCALATE.
+- **PASS** → run the **idempotency check**: an immediate second audit must find nothing material to
+  change. Residual churn means the conventions weren't reached — treat it as a FAIL and loop. When the
+  re-run is clean, the brain is curated.
+
+### Phase 7 — REPORT
+
+Summarize what moved / merged / split / re-typed / retired (counts + the notable ones), the recall
+before/after for the seed queries (proving no regression), anything consciously **deferred** (and why),
+and then **offer a sleep** so the freshly-reorganized corpus is consolidated and the index/staleness warm.
+
+## Convergence rules (how the loops end)
+
+- Every loop has a hard **iteration cap of 3**. Hitting it means **ESCALATE to the user** — never
+  "good enough, the structure's better than it was".
+- Update the TodoWrite count before each loop-back. Past the cap → stop and escalate with specifics.
+- "Curated" is defined by Phase 6 PASS **plus** a clean idempotency re-run — not by the corpus
+  looking tidier.
+
+## Red Flags — STOP, you're about to corrupt the brain
+
+| Thought | Reality |
+|---|---|
+| "I'll just start moving and merging files." | Plan first, confirm the shape (Phase 3), THEN execute. The curator mutates real content. |
+| "I know the conventions, no need to read them." | Read them at run time (Phase 0). The brain conforms to *today's* shape, which you may be misremembering. |
+| "These two files look similar — I'll delete one." | MERGE folds + repoints + preserves; RETIRE archives. Silent deletion loses signal and dangles wikilinks. |
+| "This task is probably done, bump it to completed." | Reality-based only. Cite the changelog/release/code evidence, or leave it. |
+| "Recall is fine, skip the before/after." | A reorg can drop a relevant doc from reach. Snapshot before, diff after — it's an acceptance criterion. |
+| "Verifier passed, we're done." | Not until the idempotency re-run is clean. Residual churn = conventions not reached. |
+| "It's a feature AND a knowledge file — leave both." | One home per topic. RE-TYPE / fold to the canonical one; the verifier fails this. |
+| "I'll author the whole reorg myself." | The orchestrator dispatches auditors + workers. You synthesize the plan and gate; you don't run every merge by hand. |
+
+## Rationalization table
+
+| If you think… | The truth is… | So… |
+|---|---|---|
+| "Auditing every domain is overhead; I'll eyeball it." | One pass over a drifted brain misses cross-cutting dupes and status drift. | Fan out an auditor per domain; merge their findings. |
+| "The user will just approve the plan, skip the gate." | A wrong MERGE/RETIRE is expensive to unwind once files move. | Confirm the shape in Phase 3 before executing. |
+| "Conventions don't change that often, hardcoding is fine." | The point of the curator is to track *current* conventions. Hardcoding makes it stale the day the skill changes. | Read taxonomy vocab + the live skill + soul at run time. |
+| "Verifier will rubber-stamp." | A mis-prompted verifier rubber-stamps. Give it the checklist + the recall snapshot and demand evidence. | Treat FAIL as binding; loop or escalate. |
+
+## Hard rules
+
+- **Orchestrator drives sub-agents.** Auditor (intake) → worker (fan-out execute) → verifier (gate).
+  You synthesize the plan and gate; you don't run the whole reorg by hand.
+- **Read conventions at run time.** taxonomy vocab + the installed skill + soul define the target shape.
+- **Plan-first, confirm the shape (Phase 3) before executing.** The curator mutates real content.
+- **Preserve signal.** MOVE/MERGE/RETIRE keep content findable and repoint every inbound `[[wikilink]]`.
+  Never silent-delete a topic.
+- **One home per topic.** Feature **or** knowledge, never both — the verifier enforces it.
+- **CLI for structure, native edits for prose** — `knowledge move`/`merge`, `tasks status`,
+  `features set`; hand-edit only the wording the CLI doesn't own.
+- **Reality-based status.** Bump only what is demonstrably done, with cited evidence.
+- **Recall must not regress.** Snapshot seed queries before; the verifier diffs after.
+- **Caps are hard** (3 per loop). At the cap, escalate — never declare curated.
+- **Done = Phase 6 PASS + a clean idempotency re-run.** Use the `dreamcontext` skill throughout.
+
+## Relationship to other surfaces
+
+| Surface | Stage | Relationship |
+|---|---|---|
+| `curator` (this) | Periodic brain refactor | Re-orders an existing brain into the current shape — MOVE/MERGE/SPLIT/RENAME/RE-TYPE/RETIRE. The pass sleep won't do. |
+| `curator-auditor` / `-worker` / `-verifier` | This skill's workers | Audit (findings) → fan-out execute → PASS/FAIL gate. Dispatched at Phases 1 / 4 / 6. |
+| `initializer` | First-run / bootstrap | Builds the brain from raw material. Curator *refactors* an existing one. Use initializer to create, curator to re-shape. |
+| Sleep / consolidation | Ongoing, additive | Sleep polishes + appends conservatively. Curator is the periodic structural refactor sleep deliberately avoids. Offer a sleep *after* a curate (Phase 7). |
+| `goal-skill` | End-to-end build of a goal | The orchestration pattern this skill mirrors (plan→review→implement→validate ≈ audit→confirm→execute→verify). |
+
+## Slash command wiring
+
+`/curator` invokes this skill. The natural-language triggers in **When to invoke** also load it.
+(Named `curator`, distinct from `sleep` — sleep consolidates additively; the curator refactors.)