| name | set-up-shared-team-workflow |
| description | Turn one trusted individual workflow into a shared team method with clear ownership, approved context, privacy boundaries, a verified handoff, reusable guidance, and a concrete Routine. Use after a workflow has produced a useful accepted result and several teammates need to run, review, or rely on it consistently. |
Set Up a Shared Team Workflow
Turn a workflow that already works into a method the team can trust and repeat. Start from a real
accepted example. Do not use this skill to write generic process documentation or redesign a broad
operation before anyone has proved the underlying work.
1. Start from the working method
Identify the workflow, the result it produces, the people who use or depend on it, and the example
that proved useful. Reconstruct how the result was actually made across messages, files, tabs,
documents, project tools, connected apps, and human judgment.
If there is no accepted example yet, help the user complete or calibrate one focused workflow first.
A shared method should preserve what worked, not turn an untested idea into team policy.
2. Decide what the team needs to share
Separate the durable method from one person's private context and preferences. Agree on:
- the trigger and intended result;
- required inputs and their source of truth;
- the owner, contributors, reviewers, and handoff;
- the shared destination and useful source links;
- choices the companion may make versus choices a person must review;
- privacy, client, candidate, employee, or other context boundaries; and
- the exceptions that should stop or reroute the work.
Choose the smallest sharing layer that solves the problem. Share the approved artifact when the
team only needs this result. Create a team skill when they need the method. Share the full companion
only when teammates need its ongoing approved context, memory, and several workflows. These are
separate choices.
3. Build the reusable team method
Turn the accepted workflow into concise team guidance another companion or teammate can follow
without guessing. Preserve the judgment, source priority, output, review points, and escalation
logic that made the original work trustworthy. Do not copy personal notes, incidental steps, or
temporary workarounds into the shared version.
Use the team's real workspace. Strawberry can follow the workflow across visible tabs, logged-in
sites, shared files, communication tools, and approved apps while the user inspects or takes over.
Put the team skill and shared artifacts where the intended people can use them, and verify that its
links, permissions, fields, and destinations work for someone other than the original owner.
4. Pilot one real handoff
Run the method on a representative piece of work with the people who will own and review it. Check
whether they can find the inputs, understand the result, correct the companion's judgment, approve
the right actions, and pick up the next step.
Keep the pilot small enough to correct. Surface unclear ownership, unavailable context, permission
gaps, conflicting source meanings, and steps that depend on tribal knowledge. Update the team skill
from the accepted corrections, then rerun the handoff that failed before expanding.
5. Define the Routine precisely
Once the pilot works, define the concrete Routine that carries the method forward:
- Trigger: the event, state change, or cadence that starts it;
- Systems checked: the exact approved sources it reads;
- Actions: what it gathers, compares, drafts, creates, or proposes;
- Output: where the result appears and who reviews it;
- Approval behavior: which messages, record changes, permissions, or other writes wait for a
person; and
- Stop conditions: missing identity, conflicting sources, unavailable permissions, sensitive
context, or another exception that needs judgment.
Do not enable recurrence merely because a schedule is available. Keep the Routine as a reviewed
proposal when the trigger is weak, the method is still changing, or on-request use is enough.
6. Hand over and improve the workflow
Deliver the verified team skill, shared destination, ownership map, pilot result, and Routine plan
together. Make remaining gaps and temporary manual steps visible.
Use feedback from real runs to improve the method without allowing one exception to rewrite it.
Review ownership, permissions, source meanings, and approval behavior when the team or systems
change. Keep sharing the method, inviting teammates, enabling the Routine, and making external
changes as distinct approved actions.
