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.