Worked example: API and mobile deliveries
Use this to understand why one successful delivery does not complete a shared outcome. This is a synthetic learning fixture, not real approvals or native host acceptance.
Open in your agent: the installed workspace assets, read-only; use a disposable scratch copy for experiments.
Before you start
Locate the complete matching workspace assets. Never import the example identities, grants, timestamps or receipts into a real workspace. The fixed historical time belongs only to this frozen fixture.
Choose to show your host's invocation form.
Prompt
In your agent
Use workspace-status to inspect the synthetic two-repository fixture under <installed workspace assets>/fixtures/two-repository, read-only. Explain the shared outcome, API and mobile native methods, complete and incomplete deliveries, and interrupted attempts. Identify what is still missing before parent completion. Treat all fixture authority and evidence as examples, never as live permission.
How to invoke this skill
Claude Code: /workspace-status (or /docflow:workspace-status when exposed). pi / omp: /skill:workspace-status. Codex: $workspace-status or find it in /skills. OpenCode, Grok, Cursor and Copilot: select the discovered workspace-status skill. Add the task text above. These are agent inputs, not terminal commands.
Expected result
The API delivery is complete in the example, while mobile is incomplete. The shared work remains active and its agreement stays accepted. A successful API return neither satisfies mobile nor proves combined validation.
Check it
Inspect the named fixture records and validate at its frozen time using the fixture reference. The API and mobile instruction paths and methods differ; stopped attempts remain visible with predecessor links. Every required delivery and criterion needs checked evidence before parent completion.
Turn that model into real work
In your actual workspace, run workspace-status, then scope separate deliveries with workspace-scope. Start observations as unknown and evidence lists empty. Create each native task in its own member, under its own rules. Record only genuinely authorised acceptance and grants from a committed mandate.
Dispatch after current readiness checks. Execute in the assigned member context, return actual commands/exits/revisions, then use sync to verify the return and native completion. Keep prepared PRs and failed or revoked siblings open; do not dispatch a replacement just because the first worker is silent.
Try a rejected state in scratch
For a deliberate invalid-state exercise, use the adverse fixture recipe. It copies into scratch and expects a validator failure; it does not run member commands.