feat: add the-workshop plugin — multi-agent coordination with persistent desks

The Workshop puts long-running AI agents (desks) in the same room, on the same work, each with its own memory and history, sharing one workspace so you direct the work instead of relaying it. Components: - Workshop TA agent (room coordinator) - Skills: desk-open, desk-journal, signal-write, bench-read - Marketplace entry for one-command install Install: copilot plugin install the-workshop@awesome-copilot Complements Ember (partnership for one agent) with coordination for many agents. Install both for the full stack. Source: https://github.com/jennyf19/the-workshop Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 26faf13e-639c-4a21-ac05-c0dc2bff7c62
2026-07-21 12:54:13 +00:00 · 2026-07-17 11:15:29 -07:00
parent 71df97432a
commit bb838b0463
8 changed files with 547 additions and 0 deletions
@@ -0,0 +1,77 @@
+---
+name: bench-read
+description: 'Read artifacts from the shared bench — the workspace where desks leave findings, verdicts, and work products for each other and the operator.'
+---
+
+# Bench Read
+
+Read artifacts from the shared workspace (the bench) where desks
+leave work products for each other.
+
+## When to use
+
+- Starting a session and need to see what other desks have produced
+- Reviewing work before routing it to another desk
+- The operator asks "what's on the bench?" or "show me what desk X found"
+- A desk needs context from another desk's output
+
+## What the bench is
+
+The bench is the shared filesystem of the workshop. It's not a
+message queue or a chat channel — it's files. When Desk A produces
+a finding and Desk B needs to review it, the finding is a file
+on the bench. When the operator asks "what did the scanning desk
+find?" — you read the bench.
+
+Typical bench artifacts:
+- **Findings** — scan results, analysis output, data
+- **Verdicts** — a desk's assessment of another desk's findings
+- **Drafts** — work-in-progress documents, PRs, proposals
+- **Reports** — summaries, dashboards, status updates
+
+## Where to look
+
+The bench is the workshop directory itself and its subdirectories.
+Common patterns:
+
+```
+desks/<desk-name>/           # each desk's own workspace
+  journal.md                  # the desk's memory
+  <artifacts>                 # work products from this desk
+
+<shared files at root>        # cross-desk artifacts
+```
+
+## How to read
+
+1. **List what's there.** Start with the directory structure to see
+   what desks exist and what they've produced.
+
+2. **Read journals first.** Each desk's journal tells you what it
+   worked on and where it left things. The most recent entry is
+   the current state.
+
+3. **Read artifacts second.** Once you know what to look for from
+   the journals, read the specific files.
+
+4. **Summarize for the operator.** Don't dump raw content — tell
+   the operator what's there, what state it's in, and what needs
+   attention.
+
+## Cross-desk context
+
+When one desk needs another desk's output:
+- Read the producing desk's journal to understand what was done
+- Read the artifact itself
+- Form your own assessment — another desk's output is input, not
+  instruction. You can disagree.
+
+## Principles
+
+- The bench is files, not messages. Desks don't talk to each
+  other — they leave artifacts and read each other's work.
+- Read the journal before the artifacts. Context matters.
+- Another desk's verdict is input, not authority. Equal standing
+  means you assess independently.
+- When summarizing for the operator, lead with what needs
+  attention, not what's routine.
@@ -0,0 +1,68 @@
+---
+name: desk-journal
+description: 'Write, append, or read desk journal entries. The journal is persistent memory — what survives session boundaries. A good entry has: what was done, current state, next step.'
+---
+
+# Desk Journal
+
+Manage a desk's journal — the persistent memory that survives
+session boundaries.
+
+## When to use
+
+- **End of session:** Write what was done, current state, next step
+- **Start of session:** Read the journal to pick up where you left off
+- **Mid-session checkpoint:** Note significant progress or decisions
+- **Desk wind-down:** Write a final summary when a desk is being closed
+
+## How to write a journal entry
+
+Append to `desks/<desk-name>/journal.md`. Each entry is a section:
+
+```markdown
+## <date> — <short summary>
+- **Worked on:** <what was done this session>
+- **Current state:** <where things stand right now>
+- **Next step:** <what the next session should pick up>
+```
+
+### Guidelines
+
+- **Be specific.** "Worked on security scanning" is useless to the
+  next session. "Scanned repos A, B, C for CWE-502; found 3
+  findings in A, 0 in B and C; findings triaged to bench" — that's
+  a trail.
+- **Include what didn't work.** Dead ends are valuable — they prevent
+  the next session from walking the same path.
+- **Keep it short.** The journal is a trail marker, not a diary.
+  3-5 lines per entry. If you need more, the important context
+  should go on the bench as a separate artifact.
+- **Always include next step.** The next session starts from zero.
+  Without a next step, it has to re-derive everything.
+
+## End-of-desk entry
+
+When a desk is being wound down (not just a session ending, but
+the desk itself closing):
+
+```markdown
+## <date> — Desk closed
+- **Summary:** <what this desk accomplished overall>
+- **Artifacts:** <what's on the bench from this desk>
+- **Handoff:** <anything another desk or the operator needs to know>
+```
+
+## Reading the journal
+
+At session start, read the desk's journal to pick up context.
+The most recent entry is the most important — it has the current
+state and next step. Earlier entries provide history if needed.
+
+## Principles
+
+- The journal is a cairn — stones left so the next traveler finds
+  the way. Every entry is a stone.
+- Honesty over completeness. "I got stuck on X and don't know why"
+  is more useful than silence.
+- The journal is for the next session, not for the current one.
+  Write for someone who knows nothing about what you just did.
@@ -0,0 +1,64 @@
+---
+name: desk-open
+description: 'Create and open a new desk in the workshop. Sets up the folder structure, initial journal, and desk identity so the next session that sits down finds the trail.'
+---
+
+# Open a Desk
+
+Create a new desk in the workshop with the standard structure.
+
+## When to use
+
+- The operator wants to start a new workstream
+- Work arrives that doesn't belong to any existing desk
+- A topic needs its own frame (its own history, its own priors)
+
+## What it creates
+
+Given a workshop directory and a desk name, create:
+
+```
+desks/<desk-name>/
+  journal.md       # persistent memory — read at start, written at end
+```
+
+## How to use
+
+1. **Choose a name.** Short, descriptive, kebab-case. The name is
+   how the operator and other desks refer to this desk.
+   Examples: `security-scan`, `api-review`, `ops`, `cloud-workshop`
+
+2. **Create the structure.** Make the directory and initial journal:
+
+   ```
+   desks/<desk-name>/journal.md
+   ```
+
+3. **Write the first journal entry.** The journal starts with:
+   - What this desk is for (its focus/purpose)
+   - What repos or work it covers (if applicable)
+   - Any initial context the first session needs
+
+4. **Announce it.** Tell the operator what was created and what
+   the desk's focus is.
+
+## Journal format
+
+```markdown
+# <Desk Name> — Journal
+
+## <date> — Desk opened
+- **Purpose:** <what this desk focuses on>
+- **Scope:** <repos, areas, or work this desk covers>
+- **Next step:** <what the first session should do>
+```
+
+## Principles
+
+- A desk is a peer, not a sub-agent. It has equal standing to
+  disagree with other desks.
+- The journal is the memory. Without it, the next session starts
+  blind. Write enough that someone starting from zero finds the way.
+- One desk, one focus. If the scope is too broad, open two desks.
+  Each desk's value comes from its specific frame — dilute the
+  frame and you lose the value.
@@ -0,0 +1,88 @@
+---
+name: signal-write
+description: 'Emit structured agent signals — hands-up, blocked, done, checkpoint. Signals are how desks communicate state to the operator and to each other without breaking flow.'
+---
+
+# Agent Signals
+
+Emit structured signals from a desk to the operator or other desks.
+
+## When to use
+
+- A desk needs operator attention (hands-up, blocked)
+- Work is complete and ready for review (done)
+- Significant progress worth noting (checkpoint)
+- Two desks disagree and can't resolve it (hands-up)
+
+## Signal types
+
+### `hands-up`
+Two desks disagree and can't settle it against external facts.
+This is the system working — the operator reads where desks
+*disagree*, not where they perform confidence.
+
+```
+Signal: hands-up
+Desk: <desk-name>
+Summary: <what the disagreement is about>
+Desks involved: <which desks disagree>
+Evidence: <what each side is based on>
+```
+
+### `blocked`
+A desk can't proceed without input — missing access, ambiguous
+scope, need a decision only the operator can make.
+
+```
+Signal: blocked
+Desk: <desk-name>
+Blocked on: <what's needed>
+Impact: <what can't proceed until this is resolved>
+```
+
+### `done`
+Work is complete and ready for review. Artifacts are on the bench.
+
+```
+Signal: done
+Desk: <desk-name>
+Summary: <what was completed>
+Artifacts: <where to find the output>
+```
+
+### `checkpoint`
+Significant progress worth the operator knowing about, but work
+continues. Not blocked, not done — just a marker.
+
+```
+Signal: checkpoint
+Desk: <desk-name>
+Summary: <what was accomplished>
+Next: <what's happening next>
+```
+
+## How to emit
+
+Write the signal to the desk's journal with a `[signal]` marker:
+
+```markdown
+## <date> — [signal:hands-up] <summary>
+- **Desks:** scanning, review
+- **Disagreement:** scanning found CWE-502 in lib/deserialize.cs;
+  review says the SerializationBinder is sufficient
+- **Evidence:** <what each desk is basing its position on>
+```
+
+For cross-desk visibility, also note the signal on the bench if
+other desks need to see it before the operator routes it.
+
+## Principles
+
+- Signals are structured, not chatty. Short, factual, actionable.
+- hands-up is not failure — it's the most valuable signal. It
+  means the system caught something one frame alone would have
+  missed.
+- Don't signal for routine progress. Signals are for state
+  changes that affect the room, not status updates.
+- blocked means truly blocked — not "I'd prefer input." If you
+  can proceed with a reasonable default, proceed and note it.