Start small enough to review.
- Describe the outcome.Define the deliverable, useful sources, constraints and what “done” means. A launch brief is easier to review than “do our marketing.”
- Choose the team and tasks.Give the researcher, writer and reviewer distinct responsibilities. Task dependencies define where work passes between them.
- Set tools and a budget.Configure the model route and only the connections the job requires. Access to a server or account is a separate, explicit decision.
- Let the team work, and steer when needed.Follow task progress and handoffs. A question saves the task state; your answer can continue the workflow within its limits.
- Review the result and its evidence.Check sources, assumptions and open questions. Request a revision, accept the result, or stop the work.
Approve a process only after it is useful.
A team can propose a reusable skill after finishing work. Review the proposed steps, inputs and exact version. Approving the skill is separate from accepting its result, authorizing an external action or sharing its source history.
The owner can approve reuse within the allowed scope or import a skill manually. Future runs can use an approved procedure while still checking their own permissions and budget.
What happens when something changes?
You can add guidance, answer a saved question, pause or cancel. If an external operation has an unknown outcome, the workflow should ask for reconciliation rather than blindly repeat it. Not every action can be undone; review tool access before the first real run.
Try the launch-brief starter, or read what is currently verified and what needs setup.