ambleloftTurn a discussion into a plan
Describe the host change once in a shared discussion and let specialist partners contribute. Review the host’s proposed nodes and dependencies, then explicitly start the plan for project-by-project delivery.
Outcome: Clarify a goal and its sources, then prepare tasks with clear owners, projects, dependencies and acceptance criteria.
Before you begin: Use a desktop source build with the collaboration workbench. Prepare the model, experts and practice projects described below; check release notes for installer coverage.
On this page
01Describe the goal and shared sources
Open Discussion in a space with projects and members, ensure no expert is pinned, and use the practice prompt below. Attach the actual change brief as a reference and replace the project names with linked ones. Do not invent versions, paths or service addresses to fill gaps.
I maintain the host, SDK, samples, connected extension service, website and guides myself. The referenced change brief and interface contract describe this host update.
Help these projects align without repeating the same background in each project.
First check the shared goal, scope and interface agreement. Ask me about missing decisions, then propose reviewable work nodes.
Dependencies: implement and accept the host first. Then the SDK, SSH connected service and website may proceed independently. Start the sample only after both SDK and service are accepted; write the guide after the sample is accepted; finish with integration and delivery review.
For each node, specify the expert, main execution project, source references, output location, verification method and prerequisites. Verify SSH connectivity and environment without disturbing existing services.
Prepare the plan for my review. Do not implement before I explicitly start it.02Check the coordination
The host uses actual members’ responsibilities, skills and project assignments to coordinate analysis and propose tasks. Specialists needing earlier conclusions should receive existing results; independent analysis can run in parallel. Check that “align after host acceptance” is encoded as a dependency, not merely mentioned in prose. Parallel discussion and implementation startup are separate: several expert replies do not prove synchronized code.
03Answer questions and address an expert
The host may request key decisions in a supplemental form; natural-language replies also work. Read the missing fields and answer them. Sending only “continue” does not supply those facts. @ addresses only the selected experts for this message; the next unaddressed message returns to the host. Choose Continue with this expert to pin a recipient, then return to the host when finished.
04Review the proposal and its sources
Review the current proposal in the discussion context. Distinguish user decisions, expert suggestions, unanswered questions and unverified facts. Open sources to inspect original messages or expert results. Port availability and installed server tools require execution evidence; mentioning them in a discussion does not verify them. Historical sources are queried within existing authorization.
05Prepare tasks in the same conversation
Choose the host reply’s task-check action or Shape into tasks, and clarify details in the same conversation. Preparation pins the discussion and referenced material. Model output is an editable proposal. Check every node and edge. Formal documents are optional, but this exercise benefits from a saved interface contract shared at one revision. Later discussion does not silently rewrite a saved plan.
| Review | Required detail |
|---|---|
| Delivery and acceptance | Specific output, verification method and passing result. |
| Owner and project | An actual expert, the execution directory and appropriate authorization. |
| Dependencies | Upstream results this task needs; list order is not a dependency. |
| Scope and constraints | Permitted changes, deployment target and systems to preserve. |
06Check every dependency before starting
Use this baseline, splitting nodes when real responsibilities require it. Encode prerequisites as dependencies, not only in titles. Each node needs one main execution project. For tests spanning environments, specify their relationships, access method and blocker handling. Website copy can follow host acceptance; final delivery must also check the demonstrated sample and guide.
| Node | Delivery | Required accepted predecessors |
|---|---|---|
| A Shared goal and contract | Scope, interfaces, inputs, outputs and acceptance criteria | None; review the shared basis first. |
| B Host implementation | Host code, contract and test evidence | A |
| C SDK alignment | SDK changes, consumable artifacts and checks | B |
| D SSH connected service | Service adaptation, independent tests and deployment record | B |
| E Website alignment | Accurate capability descriptions and entry points | B |
| F Minimal sample | Runnable example using the pinned SDK and test service | C + D |
| G Guide | Complete steps based on the verified sample | F |
| H Integration and delivery review | Versions, entry points, outcomes and remaining gaps | E + F + G |
07Confirm saving and the handoff boundary
After review, choose Confirm and save plan and Start plan later from Tasks, or explicitly confirm immediate startup. Downstream dispatch includes summaries and acceptance records from direct predecessors, plus the node’s pinned references. Long outputs can be truncated. This does not synchronize all repository knowledge, copy artifacts, publish an SDK or relocate a service. State exact locations, versions and access methods; missing access should be reported as a blocker.
08Stop, recover and continue
Stop generation when needed, then inspect retained responses and drafts before continuing. If a plan was saved but startup failed, reopen that plan and retry rather than creating a duplicate. Describing a goal centrally does not eliminate future clarification. Pause and revise affected plans when interfaces or sources change, then recheck the basis and downstream work. A finished run, a model success claim and user acceptance are distinct states.
Follow execution and review deliverablesCheck the result and troubleshoot
Clarify a goal and its sources, then prepare tasks with clear owners, projects, dependencies and acceptance criteria.
Check actual results using this page’s verification steps. For business integrations, inspect UI submission, tool receipts and server records separately.
Check states and recovery steps →