diff --git a/skills/cowork-project/SKILL.md b/skills/cowork-project/SKILL.md
new file mode 100644
index 0000000..ad54f3c
--- /dev/null
+++ b/skills/cowork-project/SKILL.md
@@ -0,0 +1,184 @@
+---
+name: cowork-project
+description: >
+  Manages the full lifecycle of CoWork skill and plugin projects at MPM. Use this skill
+  whenever: starting a NEW skill, plugin, or tool concept that doesn't exist yet ("new skill idea",
+  "I want to build a plugin for X", "let's capture this concept", "add a new project to the registry");
+  OR when a skill or plugin has just been BUILT or UPDATED and needs its coordination artifacts
+  created or refreshed ("create the entry for this", "document this plugin", "update the wiki",
+  "add to the coordination folder", "set up the project folder", "package the plugin",
+  "we just finished building", "update the registry for"). This skill handles folder creation,
+  README writing, Git repo creation, .plugin packaging, Wiki V2 docs, and registry updates —
+  everything needed to keep the CoWork coordination system current. Always use this skill rather
+  than doing coordination steps manually.
+---
+
+# CoWork Project Coordination Skill
+
+You manage the CoWork project coordination system for MPM. Every skill, plugin, and tool gets
+tracked in the registry, documented in a wiki, and stored in the Coordination folder. This skill
+handles two modes depending on where the project is in its lifecycle.
+
+---
+
+## System Constants
+
+Keep these in context — you will need them for every operation.
+
+| Item | Value |
+|---|---|
+| User email | `bryan@messagepoint.media` |
+| Coordination folder (Drive ID) | `1W-FNW--P2R9jVvoowUXFmSe-sAZoY0GS` |
+| Project Registry (Sheet ID) | `1xN3l3CjhkpXQBo6hS85Qii86fC-yILg6qbxd33cChMA` |
+| Registry sheet name | `Project Registry` |
+| Wiki Template V2 (Doc ID) | `1QySFc6lycK9AOIaiuQFkv9pGiRlm7S9_wgFsrXM4Alo` |
+| Git org base URL | `https://git.alwisp.com/` |
+| Outputs working dir | `/sessions/vigilant-loving-faraday/mnt/outputs/` |
+
+**IMPORTANT — File Writes:** Never write files directly to the Google Drive FUSE mount path.
+The mounted path is unreliable and causes deadlock errors. Always use Drive API tools
+(`create_drive_file`, `create_doc`, `batch_update_doc`) to create files in Drive folders.
+
+---
+
+## Registry Column Map
+
+A=ID, B=Project Name, C=Type, D=Status, E=Priority, F=Version, G=Owner, H=Contributors,
+I=Description, J=Purpose, K=Repo (Git), L=Drive Folder, M=Chat Space, N=Wiki Doc,
+O=Odoo Module, P=Dependencies, Q=Last Updated, R=Notes
+
+---
+
+## CW-ID Assignment
+
+CW-IDs are sacred — never reused, never duplicated. Follow this process every time:
+
+**Step 1 — Ask the user first.** Before reading the registry, ask:
+*"Do you have a specific CW-ID to assign (e.g. for backfilling the registry), or should I
+auto-assign the next available number?"*
+
+**Step 2a — If the user provides a specific ID:**
+- Read the full registry column A to confirm that ID is not already in use.
+- If it IS in use, stop and tell the user — do not proceed with a duplicate.
+- If it is NOT in use, use that ID. Note it for correct-order insertion (see Registry Write below).
+
+**Step 2b — If auto-assigning:**
+- Read the full registry column A (all rows).
+- Parse every CW-XXX value as an integer (strip "CW-" prefix).
+- Find the maximum integer across all rows.
+- Assign max + 1 as the new ID.
+- Do not rely on row count — rows may be out of order or have gaps.
+
+**Correct-order registry insertion:**
+When writing a new registry row, read the current registry to find where the new CW-ID
+fits numerically. If it belongs in the middle (backfill case), shift all rows from that
+position downward by reading them, then writing each one row lower, and finally writing
+the new row at the correct position. If it belongs at the end (auto-assign case), append
+after the last data row.
+
+---
+
+## Mode Detection
+
+Determine the mode before doing anything else:
+
+- **Mode 1 — Concept**: No code or repo exists yet. User has an idea to capture and register.
+- **Mode 2 — Document**: A built or updated plugin/skill/tool needs its coordination artifacts.
+
+If the context makes it obvious, proceed. If ambiguous, ask:
+*"Is this a new concept to capture, or do you have a built plugin/skill you want to document?"*
+
+---
+
+## Mode 1 — Concept Interview
+
+Run a short interview, then generate the concept brief and registry entry.
+Collect ALL answers before doing any Drive or sheet operations.
+
+### Interview Questions
+
+Ask conversationally, grouping related items. Confirm all answers before proceeding.
+
+1. **CW-ID** — Do you have a specific CW-ID to use, or should I auto-assign the next one?
+2. **Name** — What is the name of this skill, plugin, or tool?
+3. **Type** — Plugin (MCP server + skills), Skill only (SKILL.md, no server),
+   Tool (standalone utility), or Feature (change to existing CoWork behavior)?
+4. **Concept** — What problem does it solve, and who uses it? (2–4 sentences)
+5. **Capabilities** — What skills or capabilities will it expose? List each with a one-liner.
+6. **Owner & Contributors** — Who owns it? Who else is involved?
+7. **Priority** — Critical / High / Medium / Low
+8. **Dependencies** — Other CW projects or external packages it relies on?
+9. **Repo** — Is there a Git repo URL already, or should I create one now?
+   If they want one created, use Gitea MCP to create it under the MPM org.
+
+### After the Interview — Outputs
+
+Execute these steps in order. Do not skip any.
+
+**Step 1 — Assign CW-ID** (follow CW-ID Assignment rules above)
+
+**Step 2 — Create Drive folder**
+Use `create_drive_folder` to create `CW-XXX — [Project Name]` inside the Coordination
+folder (ID: `1W-FNW--P2R9jVvoowUXFmSe-sAZoY0GS`). Record the new folder ID.
+
+**Step 3 — Create repo if requested**
+If the user asked to create a repo, use the Gitea MCP to create it now. Use the project
+name (lowercase, hyphenated) as the repo name under the appropriate owner/org.
+Record the repo URL.
+
+**Step 4 — Write Concept brief to Drive**
+Use `create_drive_file` with `mime_type: text/plain` and `folder_id` set to the new
+folder ID from Step 2. Name the file `CW-XXX_Concept.md`. Use the template below.
+Do NOT attempt to write to a local FUSE path.
+
+```markdown
+# [CW-XXX] [Project Name] — Concept Brief
+**Type:** [Plugin / Skill / Tool / Feature]
+**Status:** Proposed
+**Owner:** [name]
+**Contributors:** [names or TBD]
+**Priority:** [level]
+**Last Updated:** [YYYY-MM-DD]
+**Repo:** [URL or TBD]
+
+---
+
+## Concept
+[2–4 sentences: what problem it solves, who uses it]
+
+## Capabilities to Expose
+- **[Capability Name]** — [one-line description]
+- (repeat for each capability)
+
+## Dependencies
+[List of CW-IDs or external packages, or "None identified"]
+
+## Build Session Setup
+When starting a new session to build this project, read this file first.
+It contains the agreed scope and design intent. Any changes to scope should
+be noted in the Notes section below.
+
+## Notes
+[Any constraints, open questions, or decisions captured during the interview]
+```
+
+**Step 5 — Add registry row** (follow Correct-order insertion rules above)
+Status = Proposed. Populate all fields available from the interview.
+Drive Folder = URL of the folder created in Step 2.
+Leave Wiki Doc (N) blank — no wiki until Design status.
+
+**Step 6 — Confirm to user**
+Report: CW-ID assigned, folder link, Concept.md uploaded, registry row written.
+Tell them to load the Concept.md file at the start of the build session.
+
+---
+
+## Mode 2 — Document Existing Build
+
+Read `references/mode-document.md` for the full step-by-step process. That file covers:
+metadata extraction, version checking, repo creation, README generation, Git push,
+.plugin packaging, Wiki V2 creation, and registry write.
+
+Before reading that file, note:
+- If no registry row exists yet for this project: full new entry needed
+- If a registry row already exists: read it first, then only update what changed