Turn a project request into work an AI agent can deliver

Use My Architect to turn a requested outcome into work that an agent can understand, execute and hand over. Keep the product capability, the proposed change, its acceptance conditions and the delivery work connected throughout the task.

The expected outcome is a claimed, verifiable work record with linked requirements, source documents, evidence, and a concrete next action.

This guide applies to a new feature, a change to an existing feature, a defect or technical work. It assumes the project binding and connection have been checked using the agent quickstart.

Start with the outcome

Suppose the request is: “Help new users finish account setup.” First determine what users should be able to do and how the team will verify it. Find the existing onboarding capability and its current specification. A new work item need not create a new product feature.

Read the applicable requirements and decisions, then identify the change: a new capability, a revision to current behavior, a correction of an observed defect, or technical work. Preserve uncertainty instead of silently treating a proposal as agreed behavior.

Before choosing an approach, inspect existing project components and suitable external solutions. Reuse a working capability when it meets the constraints. The work record should explain the chosen approach only to the depth needed to implement and review it.

Write a brief the next agent can use

Record the requested result, affected feature IDs, source documents, acceptance conditions, constraints and open questions. Keep one canonical specification or decision document; link to it from the work rather than copying slightly different versions into every task.

For the onboarding example, useful acceptance conditions describe observable behavior: a user sees incomplete setup steps, completed steps persist after a reload, and an API failure leaves a clear recovery action. “Build frontend” alone does not describe an independently verifiable outcome.

Use requirements for obligations, issues for observed problems and documents for longer reasoning. If a question blocks the design, state the unresolved choice and its consequence. Resolve routine implementation details from the available evidence; ask the owner when goals, meaning or authority are genuinely unclear.

Choose a proportionate work structure

Create only the hierarchy needed to assign and verify the result. For a small task within an existing managed epic, reuse that epic and create or select one eligible leaf, then obtain its child claim. A standalone accepted outcome can use a proportionate epic; a larger change may need an epic with independent children. Enqueue applies to supported epic/initiative nodes, not arbitrary tasks. Confirmed unmanaged legacy work follows its supported task workflow; an unavailable flow reader does not prove that work is unmanaged.

Use WBS when decomposition helps, User Story Mapping when the user journey matters, and Event Storming when events and interactions need clarification. Available diagram types also include Box. Native C4, UML and sequence editors are not part of the documented released set.

For parallel work, define the interface between children before assigning them. If two changes require the same file or shared contract, agree how to integrate them and who writes the shared artifact. A task claim does not provide filesystem isolation.

Execute against the shared record

Read the live queue and capabilities. Enqueue accepted work and obtain the appropriate claim. Then implement with the required checks, recording meaningful changes in the work’s source document and progress.

Keep the next step concrete: “Verify the retry path against the staging API” is more useful than an unsupported percentage. Attach reports, decisions and demonstrations to the work where a human or the next agent can discover them. Preserve the original artifact and identify any derived preview.

When new information changes the specification, record what changed and why. Refresh the relevant context before continuing. Do not hide a new requirement in a chat that another worker cannot read.

Close the loop with evidence

Check the implementation against the applicable requirements and preserve evidence for the exact revision. Complete ordinary work and explicitly update requirements whose completion has been verified. Managed epics proceed through review and delivery confirmation under the project’s policy.

For a product change, confirmation of the specification slice and delivery of the managed epic are separate transitions. Complete the applicable transitions; neither a merged pull request nor a child marked done performs both.

The delivery guide explains the final checks. If work must continue elsewhere, use resume and handoff to preserve ownership, evidence and the next action.

Manage the onboarding improvement in My Architect. Find its existing
product capability and current specification, read the relevant sources,
and define observable acceptance conditions. Reuse or create proportionate
work, connect its requirements and documents, and claim the scope before
implementation. Keep decisions and progress current. Confirm delivery only
after checking the exact result against the project's accepted policy.

Verified against app/MCP 1.11.0 and workflow plugin 2.6.0 on October 13, 2026. Confirm the connected server’s capabilities before applying a procedure.