Skip to content

Implement#

Implement is the delivery stage of the canonical Workflow. It takes one ready, unblocked Task or Bug and produces working software in a review-ready pull request. The stage owns branching, coding, committing, opening the pull request, tracking progress, running the automated review loop, responding to feedback, and finalizing the release note. Implement builds delivery leaves; it does not implement an Epic or PBI aggregate, plan from scratch, or supply the independent review.

Enter this stage when#

Implement a Task, fix a Bug, create a branch, open a pull request, respond to review feedback, or finalize a pull request. Given an Initiative, Epic, or PBI, follow native containment and blocked-by relationships to a ready delivery leaf; do not treat list order as execution order.

Input#

A ready repository-delivery Task or Bug number or URL. An operational Task follows its canonical operational delivery path instead of this pull-request flow.

Flow#

1. Orient#

  1. Read the delivery issue fully, including its type-specific body, native parent, and dependency edges.
  2. Read the repository README first per README-Driven Context.
  3. Identify the stack and load the relevant Coding Standards. Repo-local linter config wins where it disagrees with a published standard.

2. Branch and draft pull request#

Use git worktrees for every repository-delivery Task or Bug.

  1. Create a worktree from the default branch per Branching and Merging.
  2. Push an initial commit and immediately open a draft pull request so CI attaches from the first push.
  3. Close exactly that Task or Bug in the pull request. Reference a parent PBI or Epic only as non-closing context, then assign the pull request.

3. Build#

For each step in the delivery plan:

  1. Implement the change and self-review the staged diff.
  2. Commit per Commit Conventions — one logical change per commit.
  3. Update the issue as each plan step completes — do not batch.
  4. Push regularly so CI runs against current work.

When the plan is wrong, stop and document the conflict in a comment, then update the plan before resuming. Out-of-scope problems go to Define.

4. Self-review and respond#

  1. Run the Copilot review loop until it reports a clean round.
  2. Triage each thread and CI failure per Review Etiquette: fix in scope and propagate the same fix elsewhere; file a follow-up for out-of-scope; reply, then resolve.

5. Standards and framework alignment pass#

Run this once per implementation session, when the change is otherwise complete and before the pull request is marked ready — not on every commit. Re-read the applicable guidance in precedence order and reconcile the whole diff against it:

  1. Process — the Ways of Working pages that govern this stage, including Commit Conventions, PR Format, and Branching and Merging.
  2. Standards — the Coding Standards chapters that apply to the languages and file types actually changed.
  3. Framework and domain documentation — the documentation the repository's framework or product owns, published under Capabilities or in the repository itself; for example the module-pipeline documentation for a module repository, or the action contract for an action repository.

Process defines the method; standards and framework documentation define correctness details. Where the layers overlap, the narrower layer supplies the detail and the broader layer supplies the method — a framework page never overrides a process rule it does not own. Read the canonical pages instead of recalling them; that is what keeps guidance written once and referenced everywhere.

Record the outcome as one row per changed surface:

Changed surface Standards checked Framework docs checked Result
src/functions/** (PowerShell) Naming, Functions, Error Handling Module source layout Aligned
.github/workflows/** GitHub Actions Reusable workflow contract Exception — Owner/Repo#123

A result is Aligned, Fixed in this PR, or Exception with a link that justifies it. Where a changed surface has no framework or domain documentation of its own, write None (no framework-specific docs) rather than inventing a pseudo-link. Carry the table into the pull request's Technical details block per PR Format, so Review can verify the pass instead of guessing whether it happened.

Stop rule. Fix what is in scope for the closing Task or Bug and small enough to keep the pull request reviewable. When a finding is out of scope, systemic across the repository, or would change the shape of the pull request, file a follow-up issue through Define, link it in the table as an exception, and leave the change as it is. The pass improves alignment; it does not turn into a second delivery.

6. Issue convergence sweep#

Run this once per implementation session, at the same timing as the standards/framework pass: when the change is otherwise complete and before the pull request is marked ready.

  1. Search for already-open issues whose asks are already satisfied by the finished diff, not only the issue originally linked when the branch was opened.
  2. Scope the sweep deliberately so it scales: prioritize the delivery leaf's parent and siblings in the Issue Hierarchy, then narrow by affected component, labels, keywords, or code paths. Do not read every open issue serially in large repositories.
  3. Treat convergence as outcome-based:
  4. Fully satisfied — the diff already delivers the issue's ask. Add it to the pull request's Relevant issues block with a closing keyword (Fixes, Closes, or Resolves) so merge closes it.
  5. Partially satisfied — the diff helps but does not fully deliver the ask. Link it as non-closing context and keep or create a follow-up delivery leaf for the remaining gap.
  6. Keep this pass focused on convergence and linkage. It does not rewrite, reformat, or otherwise "fix up" issue bodies to match issue templates; issue quality edits are separate work routed through Define.

7. Finalize and hand off#

When the change meets the Definition of Ready for Review:

  1. Finalize the title, release-note description, and label per PR Format.
  2. Mark the pull request ready and enable auto-merge per Branching and Merging.

Operating rules#

  1. Micro-commits, one logical change each, with descriptive messages.
  2. Progress is visible — the delivery issue is updated as plan steps complete, not in bulk.
  3. Draft pull request from the start; stay in the issue's scope.
  4. Mark ready only when the change meets the Definition of Ready for Review — never with open plan steps.
  5. Run the standards and framework alignment pass once at session end, before marking the pull request ready, and record its result in the pull request.
  6. Run the issue convergence sweep once at session end, before marking the pull request ready, and link every fully convergent issue in the pull request with closing keywords.
  7. Return unplanned work to Define and hand review-ready work to Review.

Where this connects#