Coordinate mixed members
Use this when repositories follow different methods, or when some members exist and others are still planned. Having Docflow conventions and having a real checkout are separate questions.
Open in your agent: The workspace home for shared planning; each member root for that member’s own setup and work.
Before you start
Create or resume the home. Read the existing members’ instructions and native work/claim sources. An issue/PR-led member does not need Docflow bootstrap to join.
Choose to show your host's invocation form.
Prompt
In your agent
Use workspace-scope to plan <outcome> across our existing Docflow API repository, issue-led mobile repository and future web repository. Preserve both existing methods. Propose each delivery and acceptance check; keep execution unauthorised. Keep web blocked until its independent checkout and native instructions exist. Show each member’s native completion rule and missing evidence.
How to invoke this skill
Claude Code: /workspace-scope (or /docflow:workspace-scope when exposed). pi / omp: /skill:workspace-scope. Codex: $workspace-scope or find it in /skills. OpenCode, Grok, Cursor and Copilot: select the discovered workspace-scope skill. Add the task text above. These are agent inputs, not terminal commands.
Expected result
One shared plan with distinct native deliveries: for example an API contract, mobile review and future web integration. Existing members retain their own tasks and rules. The unavailable web source remains blocked or unknown, with no invented local path or instruction file.
Check it
- Register real existing members with stable IDs, aliases, roles and actual paths.
- A remote-only
role: referenceentry needs a supplied remote and is not a substitute for a future delivery checkout. - Create future repositories separately under their owners’ Git rules. Run
bootstrapinside a new member only if Docflow governance is chosen; otherwise retain its native setup. - Once a checkout and instructions exist, register them from the workspace and validate at current UTC. Native tasks and claims remain member-owned.
- An accepted agreement does not assign an executor. Check current mandate, grant, claims, dependencies and resources before dispatch. Parent work remains open until every required delivery and criterion is verified.