Building to a professional standard

Cowork shapes, Code ships. Use Cowork to find the data, the people and the process, and even for the first build. Move to Code once the app has more than a few screens, logic that must be right, or more than one person changing it. I

Code builds, Cowork accepts. Code makes each change and runs the scripted checks; Cowork, in Edge, opens the live app as a real user with real data and walks the acceptance checklist; a person signs off. This closes the gap that Code's missing browser leaves. I

Studio for the agent, Code for the app. Agents and flows are designed and governed where they live, in Copilot Studio; the app binds to them and tests the contract. I

The CLI for the pipeline. When an app needs CI/CD, pinned tool versions, GitHub Actions deployment with a service principal or a third-party build tool, move that part to the ms CLI. D

Copy link

• The repository is the source of truth; chats are not. Before you switch tools, make sure the last session committed and pushed.
• Leave a handoff note in the repository: what changed, what was verified, what is next.
• Start every session the same way, with the session-start prompt below.
• Give each session one scope, and name it in the first message.
• Never let two sessions release at the same time.

Copy link

Copy link

Copy link

The template already contains an AGENTS.md written by the platform for any coding agent, and its own README says it is deliberately not the whole contract: the app service's own rules sit outside the repository. O Keep your project rules in your own files and tell every session to read them. Files are the only memory you fully control. I

Copy link

Copy link

• Write spec items a person can see or click. "Help has a Search box that filters topics as you type" is a spec item; "better Help" is not. O
• Make one change at a time and say what must not be touched. Microsoft's own guidance for Code is one focused change per request. D
• Settle the data contract before the screens: the list, the fields, their types, some sample rows, and what each screen does when the data is empty, slow or failing. Unless asked, agents skip empty, loading and error states. C
• Name every list and table exactly, with the site URL, list name or Dataverse logical name. Builders report apps that looked finished but saved nothing until the list was named in the prompt. C
• Point instead of describing: select the element on the Code canvas, or attach a screenshot of what you want. D
• State the navigation rules up front: every screen names itself, carries a labelled "Back to <origin>", sibling modes share one switch on both screens, and nothing redirects silently. O
• Ask for evidence, not adjectives: "show me the command and its output" or "show me the screenshot". A summary that claims something no tool output shows should fail the release. O
• Use models deliberately: the strongest reasoning model for planning, reviews and logic that must be right; a faster model for copy edits and small fixes. I
• Build in passes. Ask the agent to say what it added and what it deferred, test that, then say "Continue". C
• Keep the spec alive: change DESIGN.md first, then the code.
• Hand over a spec pack, not a paragraph. One builder attached the spec, an entity-relationship diagram and a screenshot of every existing screen, raised effort to High ("slower, but more thorough") and got a seven-table, five-screen app in under an hour; he noted a vague prompt would have cost more. C
• Read the plan like a solution design. Plan mode returned a full information architecture (13 lists, 3 libraries and a build order) in about two minutes for one builder, who moved a risky integration to phase two before approving. Edit the plan; it is the cheapest place to change your mind. C
• Demand live data in every build summary: "Confirm that every screen reads and writes the real source, and list anything still on sample or mock data." Agents have been seen quietly creating local mock data. C
• Paste errors back word for word, with what you were doing: "I'm getting the following error when I try to save: ..." The agent fixes faster from the exact text than from a description. C
• Check the bill as you go. Type /cost after a build in Cowork D; A /cost command is not documented for Code I; builders report that it works there C. Budget per app, not per task, because whole-app builds have cost about 670 to 5,400 credits. C
• Turn off Always allow when you're done. Once on, it stays on for existing and new Code sessions until you switch it off. D

Copy link

• One giant prompt for the whole app. Long, sprawling instructions degrade results; split the work into numbered items. C
• Letting the agent invent data, packages or field names. Check them against the source.
• Accepting "should work". No evidence means zero.
• Hand-editing generated/ or ms.config.json. Use the binding tools so the typed clients stay in step. D
• Releasing two features in one change, which makes both harder to verify and to roll back.
• Publishing from a stale clone.
• A third correction in the same thread. Start a fresh session with a better prompt instead. C
• Treating the builder's self-review as review. Use an independent reviewer that sees only the spec and the change. C

Copy link

Copy link

Copy link

The screen check in that app also reports controls without accessible names, screens without exactly one main heading, images without alt text, unlabeled inputs, slow first renders and console errors. It runs in a simulated page with no layout engine, so alignment, overlap, clipping and contrast still need eyes. O

Copy link

Any one of these blocks a release, whatever the score:

• A type, build, lint or test failure.
• A new error from the release scan.
• Any path that can send or save something outside the app (an email, a record) without passing its checks.
• Customer content, tokens or connector errors written to logs, URLs or analytics.
• A spec item missing without an agreed deferral, or a summary that claims something no tool output shows.
• After release, the live version does not hold the change.

Copy link

Copy link

• No evidence means zero. Evidence is a command that ran in this round, a test, a measurement or a screen someone looked at.
• Half points when an item was checked in a weaker way than it asks for, such as the screen check instead of the preview.
• Not applicable scores full points only with a one-line reason, and never for something the change touched.
• Record the score even when it fails, with the missing points and how to earn them.
• If the owner overrides the bar, log the override and the evidence still owed. That app did this twice in four days, and both releases are in the log as "preview owed". O

Copy link

Copy link

Unfinished work belongs in the live app behind a switch that is off by default. That app retired an old email composer in seven planned stages, and the first stage went live with every switch off, scoring 91 out of 100. Experimental screens live under a lab route that only development builds include, and the release scan fails if any lab link leaks into a production screen. O Switches can also be read per user from a small SharePoint list, which gives you pilot rings without a release. I

Decide this in the setup → Step 4: Screens and features

Copy link

The live app serves the deployed build until the next deploy, so rolling back means redeploying a known good commit: ms app deploy with a pinned commit, or asking Code to deploy that commit. Log the failed release and the rollback. Rolling back code does not roll back data, so keep schema and data changes backward compatible for at least one release. DI

Copy link

• Start every session with a fetch and a comparison against the remote main. If something seems to be missing, read the log before rebuilding it.
• Give each session one scope and allow one releaser at a time.
• Commit small, with messages that say what changed and why; release small chunks.
• Rebase onto main; never force-push, and never rewrite main's history.
• Leave every session clean: committed and pushed, or explicitly parked, with HANDOFF.md updated.
• Put anything half-built behind a feature switch.
• Record every release in the log, in the release commit itself.
• Watch repository size: the app studied was at about 1,600 Git objects when this guide was written. O

The table covers each collision and what to do, including a failed fetch.

That is the ceiling one builder hit; plan for it before a release.

Copy link

Conflicts concentrate in a few shared files: the app header and navigation, the route table, the feature-switch registry, the theme and the rubric itself. Give each one an owner, announce edits to them in the handoff note, and prefer adding a new file over growing a shared one.

Copy link

All four write to the same repository, and Microsoft documents no lock. Only the CLI documents the clone and pull routine explicitly; agents in Cowork and Copilot Studio push their own commits when you ask them for changes. Treat an edit made in Cowork or Studio exactly like a colleague's commit: before any release from Code, fetch, read what changed, and run the full checks against the combined result. DI

Copy link