teamshare-bridge 0.22.16 → 0.22.18

package/skills/teamshare-cdd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: teamshare-cdd
-description: Documents-driven development for TeamShare. Before any code, find and read the project's documents in the Documents tab (virtual folders: docs/, agents/<you>/tasks/<taskId>/). Write plan.md BEFORE starting, keep progress.md/notes updated while working (update_document_note), and close with summary.md. Uploads and markdown notes live in Cloudinary-backed virtual folders, never loose files.
+description: Documents-driven development for TeamShare. Before any code, find and read the project's documents in the Documents tab (virtual folders: docs/, agents/<you>/tasks/<taskId>/). Write the task-titled plan note BEFORE starting, keep progress.md/notes updated while working (update_document_note), and close with summary.md. Uploads and markdown notes live in Cloudinary-backed virtual folders, never loose files.
 ---
 
 # TeamShare Documents-Driven Development (CDD)
@@ -26,7 +26,10 @@ agents/
 └── <agent-slug>/                  <- ONE folder per agent (short, stable slug)
     └── tasks/
         └── <taskId>/              <- per-task workspace
-            ├── plan.md            <- written BEFORE starting the work
+            ├── <task-slug>-plan.md  <- written BEFORE starting the work
+            │                           (named from the task title, NEVER a bare
+            │                           `plan.md` — six tasks must not produce six
+            │                           identical filenames)
             ├── progress.md        <- updated while working (or rely on subtasks)
             └── summary.md         <- written on completion
 reports/                           <- milestone reports (optional)
@@ -38,8 +41,10 @@ Rules that are not optional:
 - **Lowercase** folder paths; no spaces, no leading/trailing slashes.
 - **One folder per agent, one subfolder per task.** Never write outside your
   own folder except into `docs/**` when you add shared knowledge.
-- Document names are unique enough to be obvious (`plan.md`, `progress.md`,
-  `summary.md`, `adr-001-auth-rbac.md`).
+- Document names are unique enough to be obvious (`<task-slug>-plan.md`,
+  `progress.md`, `summary.md`, `adr-001-auth-rbac.md`). A plan note named
+  exactly `plan.md` is forbidden: with N tasks the Documents tab shows N
+  identical rows and nobody can tell which plan belongs to which task.
 
 ## The workflow — three gates
 
@@ -57,13 +62,17 @@ Rules that are not optional:
    your implementation (same way `docs/api-contract.md` and
    `docs/ui-style-guide.md` govern TeamShare's repos).
 4. Read your own task folder if this is a `--continue`/resumed session.
-5. **Write `plan.md` FIRST** via `create_document`: goal, decisions, files to
-   touch, step list. No code until the plan note exists.
+5. **Write the plan note FIRST** via `create_document`: goal, decisions, files to
+   touch, step list. Name it `<task-slug>-plan.md` from the task title
+   (lowercase, words joined with `-`, e.g. `fix-login-redirect-plan.md`) —
+   never a bare `plan.md`. On a re-plan, list the folder first and reuse the
+   existing `*-plan.md` name so it versions in place. No code until the plan
+   note exists.
 6. **Move the task to `in_progress`** via `update_task` — you are now working it.
 
 ### DO (while working)
 7. Check off subtasks (`update_subtask done: true`) and update
-   `progress.md`/`plan.md` via `update_document_note` as you go — the human
+   `progress.md`/the plan note via `update_document_note` as you go — the human
    watches the app.
 8. **Checklist items — ALWAYS list first.** Before creating checklist items,
    call `list_checklist_items` (pass `taskId` or `subtaskId`) to see what
@@ -82,7 +91,7 @@ Rules that are not optional:
 12. Write `summary.md`: what you built, why, how it maps to the plan, links to
     related docs, follow-ups.
 13. Post the closing comment referencing the summary doc.
-14. Never leave a task without `plan.md` + `summary.md` notes.
+14. Never leave a task without a plan note + `summary.md` notes.
 15. **Git is the runner's job.** After your session the bridge automatically
     commits everything in the working tree on branch
     `teamshare/<taskId8>`, pushes it and opens a pull request — so do NOT
@@ -160,8 +169,8 @@ run, the following rules apply ON TOP of everything above:
   `readyForDev=true AND status=open` tasks (plus blocked in-progress ones).
 - **Strict order, full completion.** Work the queue in exact order — never
   pick a later task while an earlier one is open. Do not move on until the
-  current task is genuinely complete: build passes, `plan.md` written first,
-  subtasks checked off, `summary.md` written, status moved to `in_review`.
+   current task is genuinely complete: build passes, plan note written first,
+   subtasks checked off, `summary.md` written, status moved to `in_review`.
 - **Failure protocol (never block the queue).** If a task cannot be finished,
   the BUILD LOOP (not you) handles it: it leaves a `[question]` comment on the
   task (marked with the literal prefix `[question]`) and a message in the
@@ -172,8 +181,9 @@ run, the following rules apply ON TOP of everything above:
   - `readyForDev: true` so they enter the queue,
   - increasing `sortOrder` (1, 2, 3, ...) so they are worked strictly in order,
   - dependencies first (a task that unblocks others comes before them),
-  - write the plan into `agents/<your-slug>/tasks/<taskId>/plan.md` per task,
-    and a shared `docs/guides/build-plan.md` note summarizing the order.
+   - write the plan into `agents/<your-slug>/tasks/<taskId>/<task-slug>-plan.md`
+     per task (named from the task title, never bare `plan.md`),
+     and a shared `docs/guides/build-plan.md` note summarizing the order.
 - **Progress signals.** Push the task to `in_progress` when you start it and
   `in_review` when done — the build loop watches status to decide
   done vs. failed, so a task left in `in_progress` at the end of a session is