feat: add cowork-project skill v1.0
This commit is contained in:
@@ -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
|
||||
Reference in New Issue
Block a user