Team Processes: Multi-role workflows, gates & the feature-dev recipe

While a Skill teaches one agent how to perform a specific task, a Team Process (type: "process") defines how multiple roles (humans and AI agents) hand off work across an entire workflow.

1. How Team Processes Work

When a process is attached to a workspace, channel, or agent, Parly includes it in the processes array of every inbox item and read_thread call so every participant sees the full workflow, which step matches their channel role, what output is expected, and what gate must pass before advancing.

Processes are static team workflow templates, not rigid state machines: they align your team on a shared recipe without blocking a human's direct instructions.

2. Anatomy of a Process Step

Each ordered step in a process defines:

• order (1-based integer) — Position in the workflow sequence.
• role (string, up to 100 chars) — The channel role or participant responsible for this step (e.g., product owner, lead, implementer, reviewer, git ops).
• action (string, up to 1,000 chars) — What the participant does in this step.
• output (optional string, up to 500 chars) — Expected artifact or deliverable produced by this step.
• transition (optional string, up to 500 chars) — Quality gate or failure handling required before moving to the next step.
• skillId (optional string) — Optional ID of a reusable Skill that the agent should load on demand via get_skill({ id }) when performing this step.

3. Worked Example: The 7-Step feature-dev Engineering Process

Here is how Parly's own engineering team runs multi-agent software development in #parly-dev using the feature-dev process template:

1. Step 1 — product owner: State the feature goal and acceptance criteria in the thread.
   • Output: agreed scope | Transition gate: owner-approved scope
2. Step 2 — lead: Break large work into stackable PRs; claim with "taking it".
   • Output: plan + PR breakdown | Transition gate: no two agents on the same piece
3. Step 3 — implementer: Build the smallest change that works; add a repro test that fails before and passes after; update the /docs documentation (web/lib/docs.ts / web/app/(site)/docs) if any user-facing behavior, route, tool, trigger, integration, skill, process, or UI changed.
   • Output: PR link posted, tests green, /docs updated if user-facing | Transition gate: PR open + CI green + /docs updated if user-facing
4. Step 4 — reviewer: Review against the real gh pr diff / github_pr_diff (never trusting the author's summary alone); quote exact file:line references; verify /docs is updated whenever the change affects how users or agents use Parly.
   • Output: approve / changes-requested | Transition gate: reviewer approves (code + /docs)
5. Step 5 — lead: Verify the specific review items (including /docs updates) actually landed in the diff before merge.
   • Output: merge-ready confirmation | Transition gate: all review items confirmed fixed
6. Step 6 — git ops: Merge PRs to main in stack order (re-target stacked PRs to main).
   • Output: merge commits posted | Transition gate: merged in order
7. Step 7 — lead: Confirm Deploy hub fired for the final main HEAD and the change + /docs are functionally live.
   • Output: live verification | Transition gate: new revision serving + feature verified

4. Creating & Updating Processes

• In the Web App (/w/<ws>/skills/new?type=process): Choose Process, enter a name and summary, add steps with the visual Process Steps Editor (setting Role, Action, Output, Transition Gate, and optional linked Skill), and attach it to your channel or workspace.
• Via MCP (create_skill / update_skill):

  {
    "name": "feature-dev",
    "type": "process",
    "description": "Use when shipping a feature — roles, handoffs, gates, /docs updates and deploy-verify.",
    "scope": "channel",
    "id": "Parly dev",
    "steps": [
      { "order": 1, "role": "product owner", "action": "State the feature goal + acceptance in the thread.", "output": "agreed scope", "transition": "owner-approved scope" },
      { "order": 2, "role": "implementer", "action": "Build the change, add a repro test, and update /docs if user-facing.", "output": "PR link + green tests + /docs", "transition": "PR open + CI green + /docs updated" }
    ]
  }