# Deliver Ocb Change

> Deliver OCB Backend or web Frontend Developer work from Jira verification through approved planning, implementation, domain-specific verification, LinearB-visible Git delivery, and developer-performed GitLab merge. Use for explicit `$deliver-ocb-change` requests, OCB backend, frontend, or mixed Jira implementation or plan execution, OCB-traceable GitLab MR preparation, and verified merge. Do not use for generic coding advice, Mobile delivery, unrelated Jira administration, deployment, release, self-approval, or generic LinearB reporting.

- Skill: `tuanloc1105/deliver-ocb-change` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add tuanloc1105/deliver-ocb-change`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tuanloc1105/deliver-ocb-change/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: tuanloc1105 (https://skillmd.com/u/tuanloc1105)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/tuanloc1105/deliver-ocb-change

---


# Deliver OCB Change

Guide an OCB Backend or Frontend Developer through an evidence-backed `MERGED` outcome. The Developer may proactively merge after required checks, GitLab mergeability, explicit merge authorization, and platform-enforced controls pass. End before deployment, release, or post-merge measurement.

## Load the Contract

Whenever this skill is loaded, also load the complete `$interact-with-jira` and `$interact-with-git-platform` skills before any OCB workflow work. Their current routing, identity, authorization, mutation, verification, and reporting rules govern all Jira and Git-platform operations; loading them grants no mutation authority.

Before changing source or Git state, read:

- [Core policy](references/core-policy.md): shared Jira, Git, authorization, evidence, and ownership rules.
- [Repository profile](references/repository-profile.md): optional local overrides, mode routing, precedence, and drift handling.
- [Workflow contract](references/workflow-contract.md): required plan section, gates, states, authorization, and handoff format.

After resolving the delivery mode, read the complete applicable domain policy:

- `backend`: [Backend policy](references/backend-policy.md).
- `frontend`: [Frontend policy](references/frontend-policy.md).
- `mixed`: both policies; apply each rule to its affected scope and satisfy the union of applicable gates.

Apply precedence, warning-first gates, and override rules from the core and applicable domain policies exactly.

Before combining this skill with discuss, plan, or execute, handing off its record, or resuming after a new session or compaction, read [Composition and resume](references/composition-and-resume.md) completely. Persist its OCB policy binding in the existing record so the receiving workflow restores this skill and its applicable policies before dependent work. Reviewing this skill is not an instruction to activate OCB delivery.

## User-Response Contract

Every question that requires a user response must use `request_user_input`. This includes clarification, selection, confirmation, approval, authorization, risk acceptance, override, retry authorization, and requests for a free-form value. Do not ask a user-facing question in prose, commentary, or the final response, and do not duplicate the tool's question or options outside the tool.

- Follow the tool schema exactly. Provide 1-3 independent questions per call, each with 2-3 practical and mutually exclusive options. Put the recommended option first and suffix its label with `(Recommended)`. Prefer one question when an earlier answer may change later choices.
- Do not add an `Other` option when the client supplies it automatically. Use that client-provided path for an exact value not covered by the listed options, and ask any necessary follow-up through `request_user_input`.
- Keep headers, prompts, labels, and descriptions concise. Present detailed evidence or an exact mutation proposal before the tool call, then use short options such as `Approve exact proposal (Recommended)`, `Request changes`, and `Pause` so the returned selection is the authorization decision.
- Preserve the displayed option order and returned selection in the workflow record. Existing exact user authorization that is still valid for the current repository, state, target, scope, and action does not need to be requested again.
- If `request_user_input` is unavailable, do not fall back to a prose question. Record the unresolved decision and resume checkpoint, pause only the dependent action, and report that the required question tool is unavailable.

## Resolve Delivery Mode

Resolve exactly one mode before `$plan`, source mutation, or Git mutation: `backend`, `frontend`, or `mixed`.

Use evidence in this order:

1. Explicit value in the current user request.
2. Approved or current plan.
3. Valid `.ocb/deliver-change.yaml` profile.
4. Authoritative repository instructions.
5. Unambiguous target paths and requested implementation scope.

Do not silently classify from a repository name, framework guess, a single ambiguous file, or unrelated paths in a monorepo. Use `mixed` when the authorized implementation crosses backend and frontend boundaries. If evidence remains missing, ambiguous, or conflicting, pause dependent work, report the conflict, and recommend a mode and exact path scope. Continue when the user explicitly selects or accepts that exact classification under a recorded override.

Record the resolved mode, evidence source, affected roots, and per-path classification in the workflow contract. Re-resolve it when scope or diff boundaries drift. A missing or ambiguous mode is a **Hard** gate before `$plan` or mutation. Pause, warn, and recommend a mode; continue only when the user explicitly accepts the stated classification risk and authorizes that exact mode and scope.

## Run the Workflow

1. Begin at `MODE_UNRESOLVED`. Record the repository, initial Git status, staged and unstaged diff boundaries, Jira key if supplied, requested outcome, acceptance source when applicable, and all existing user changes.
2. Resolve delivery mode, then resolve `.ocb/deliver-change.yaml` as specified in the repository profile. Warn on configuration drift before dependent mutation.
3. Enter `MODE_RESOLVED`. Resolve the working Jira key from the request, approved or current plan, current branch, and repository evidence, in that order. If missing or ambiguous, pause, warn, and recommend an exact Jira context rather than silently guessing. With a unique key, use `$interact-with-jira` for minimal identity, issue, type, parent, relationship, Epic, current-assignee, work-status, date-field metadata, and applicable sprint verification, plus acceptance-criteria verification when required by the applicable domain policy. Apply the core policy's automatic Jira work-start procedure before implementation: obtain today with exactly `date "+%Y-%m-%d"`; transition to `In Progress` only when needed; fill only an empty Start Date with today and an empty Due Date with tomorrow; then re-read status and dates. Also verify that the authenticated Developer is the current assignee and, when sprint delivery applies, verify the exact intended sprint and its dates. These work-start and sprint-alignment gates are warning-first and user-overridable: on failure, pause only dependent implementation, explain the missing or conflicting evidence and recommended Jira correction, and continue without claiming compliance when the user explicitly accepts the stated risk and authorizes the exact issue, scope, and action. The explicit delivery request authorizes only the bounded start and completion mutations defined in the core policy; every other assignment, sprint, transition, or issue edit still requires exact authorization through `$interact-with-jira` and a verifying re-read. Story, Task, and Bug are peer issue types that should belong directly to an Epic. A Subtask may have a Story, Task, or Bug as its direct parent, and that parent should belong to the same delivery Epic. Never treat prose mentioning a key as verified relationship evidence. For every authorized new Jira work item, apply the Vietnamese ticket contract in the core policy: concise Vietnamese title and body, the exact four required sections, an agent-produced estimate no greater than 3 hours, and assignment to the verified currently authenticated Jira account. For a correction found after Story, Task, or Bug completion, default to creating and re-reading exactly one authorized bug-fix Subtask under that completed issue. If any Jira gate remains unmet or the user requests reuse of an old delivery path, warn and continue only under an explicit scoped override that identifies the exact issue and Git path.
4. Resolve and verify the exact existing remote Epic base branch; never silently infer or substitute an integration branch. Separately resolve the development base: use the Epic base for an independent ticket, or, when the user explicitly chooses to start a dependent ticket before its predecessor is merged, use the exact remote working branch of the immediately preceding ticket in the same Epic. Verify the complete Epic-to-predecessor ancestry, branch SHA, Jira dependency, and intended review/merge order; never infer a stacked dependency from branch names alone. If evidence is missing or conflicts, pause, warn, and recommend the exact verification or branch fix. Continue only after the user explicitly accepts the risk and identifies or authorizes the exact fallback base and affected action. Read-only repository or design-source inspection may continue while unresolved.
5. After mode, Jira, and Epic-base gates pass or receive valid scoped overrides, assess every intended single-PR slice against the pre-code PR-size gate in the workflow contract. Prefer `$plan` with a complete `OCB Delivery Workflow Contract`. Use 155 changed lines as the bundled default maximum unless a valid repository profile is stricter. Treat every line authored or materially edited by the implementing agent as handwritten/non-generated code. The handwritten/non-generated portion of every intended PR must stay at or below the effective maximum; this is a non-overridable hard gate. For every estimate above the effective maximum, recommend the smallest independently buildable, testable, and reviewable Jira Subtasks organized by behavior, contract, or functional slice; never split mechanically by file, function, or line count. Independently estimate each proposed Jira slice in hours and refine any slice above 3 hours until it is at or below 3 hours or its Jira estimate exception is explicitly resolved; the company's 6-hour ceiling is context, not permission to choose more than 3 hours under this workflow. Do not approve the plan or mutate source while the estimate or split assessment is unresolved. Deterministic generated artifacts such as OpenAPI Generator output may make the total PR exceed the effective maximum only through the generated-artifact exception in the core policy; agent-authored implementation, tests, configuration, migrations, specifications, or documentation never qualify merely because the agent produced them. Record the split recommendation or generated-artifact evidence in the plan, and obtain explicit authorization before creating or editing Jira work items through `$interact-with-jira`. If the user explicitly directs execution without a plan after warning, record the scoped override for skipping the plan only; PR-size evidence, handwritten/non-generated compliance, and any required generated-artifact exception remain mandatory. Do not create a separate lifecycle tracker.
6. Resolve branch username from the current request, approved/current plan, or authoritative repository evidence, in that order; never infer it from `git config user.name`. Before the first source mutation, obtain exact current-session authorization for working-branch creation, the mandatory LinearB init commit, and publishing that branch and init commit to the exact remote in every affected repository. Create or verify the working branch from the resolved development base using `{jira_id}_{username}_{task-slug}`. The working branch is always the MR source and the Epic base is always the MR target, including for a stacked ticket; never retarget the MR to the predecessor branch. Implementation commits, later pushes, and MR creation remain unauthorized until the post-implementation delivery checkpoint.
7. Immediately after creating the working branch and before editing source, create the required LinearB init commit as the first ticket-owned commit in every affected repository. When verifying an existing working branch, confirm that this init commit already occupies that position; never create it retroactively after implementation commits and claim a valid start marker. Prefer an empty commit so no artificial file change enters the delivery diff, and use the required `{jira_id}_{username}_{task_name}` prefix followed by `chore: initialize LinearB work tracking`. First verify that the index contains no staged changes; never include, unstage, or rewrite pre-existing or unrelated work to create this commit. If the index is not clean or an existing branch has ticket-owned implementation commits without the init commit, pause before implementation, report the exact boundary, and use `request_user_input` under `User-Response Contract` to obtain the user's resolution. Record the init commit SHA and timestamp as evidence. Publish the exact working branch and push the init commit to the verified remote, then verify that the remote branch resolves to the init commit SHA. Do not create a draft MR merely for observability. Do not enter `IMPLEMENTING` until the branch and init commit are remotely observable; local-only state and risk acceptance cannot satisfy or override this gate.
8. Implement only the approved scope on the working branch without committing implementation changes yet. Follow repository instructions and applicable domain policies, preserve unrelated changes, keep the eventual commit set reviewable, and record verification evidence. Re-estimate after material scope drift and stop before agent-authored handwritten/non-generated work is expected to exceed the effective maximum; amend the execution record and recommend the next functional Jira slice. Generated artifacts may take the total diff above the maximum only while the generated-artifact exception remains valid, and revalidate it after affected source input, generator, configuration, base-ref, target, or diff-boundary changes. For `mixed`, maintain a per-domain path boundary and run the union of applicable checks. When the complete intended diff and required checks are ready, enter `CODE_READY` with the implementation still uncommitted and pause for the user's delivery confirmation.
9. At the post-implementation delivery checkpoint, present the exact repositories, working branches, reviewed diff boundary, check results, proposed implementation commit messages, remote, MR target, and MR title/body. The proposed and initially created MR body is exactly the canonical Jira ticket URL and nothing else; ignore content an external AI reviewer appends later. The already-published init commit authorizes no further Git mutation. Do not create an implementation commit, push later commits, or create an MR until the user explicitly authorizes those exact actions. Authorization may cover the reviewed implementation commits, required pre-MR empty commits, later pushes, MR creation, and the required Jira MR-link comment together only when every action and target is enumerated. After authorization, create only the reviewed implementation commits, then follow the core policy’s required pre-MR empty-commit sequence: verify no matching MR exists and the index is clean, create the marker, record and verify it, push its SHA, create the MR with the Jira-only body, and re-read it; reuse verified state on retries. Once the MR URL is certain, use only a Jira comment to record it: never create or update a Jira Web Link, remote link, development link, issue link, or Jira field for this backlink. Add exactly one comment rendered as one clickable hyperlink with no other visible content; the displayed text and destination must both be the canonical MR URL, and the agent must not rely on Jira auto-linking plain text. Unless an existing comment has that exact text and destination, create it with an explicit link representation supported by the route, then re-read the comment by ID and verify both values. An existing plain-text URL or non-comment link does not satisfy this requirement. Reuse the verified username for the required `{jira_id}_{username}_{task_name}` commit prefix unless the user explicitly overrides that naming gate after warning. Before `glab`, verify its version, leaf-command help, authentication, repository target, and identity. Always provide explicit source and the exact Epic MR target; never use interactive defaults or auto-merge. For a stacked ticket, record the predecessor branch/MR, review order, incremental ticket diff, and temporary cumulative Epic-target diff in workflow evidence rather than adding them to the Jira-only MR body. Before `CODE_READY`, audit the issue key across Jira, branch, intended ticket-owned commits, and proposed MR; re-read assignee, work status, work-start dates, and applicable sprint membership; and record any days or work types whose activity is not remotely observable. Missing or conflicting traceability is a warning-first, user-overridable gate: pause dependent delivery, recommend the exact correction, and continue under a scoped override when the user accepts the reporting risk. Never fabricate activity, prolong `In Progress`, delay an otherwise reviewable MR, or defer truthful completion to match an estimate or increase FTE. After the MR exists with the expected repository, source, and target, execute the core policy's automatic Jira completion procedure: pre-read status, raw `timeoriginalestimate`, `timetracking.originalEstimate`, Time Spent, the complete worklog list, and expanded `Done` transition metadata. When not already `Done` and no worklog exists, require a canonical duration matching the positive raw estimate; immediately before the transition tool call run exactly `date '+%Y-%m-%dT%H:%M:%S.000%z'`, validate its stdout against `^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}[+-]\d{4}$`, and include exactly one atomic worklog `add` using `timeSpent` plus that `started` value in the first `Done` request. On a mismatch, stop before mutation and regenerate with the same command. Never use a colonized offset, missing milliseconds, or a timestamp supplied or inferred from context. Never send both duration forms, write aggregate `timespent`, use a standalone worklog endpoint, or try a worklog-free transition first. After rejection or uncertainty, re-read before anything else and never automatically retry or switch payloads. Finally verify `Done`, a worklog-count increase of exactly one, the new worklog duration equal to Original Estimate seconds, and Time Spent reflecting it. When the user instead explicitly requests a Bug handoff to `Ready to test`, execute the core policy's Bug handoff procedure: select an exact metadata-supported Resolution and reassign to the verified Reporter, then re-read status, Resolution, Reporter, and assignee. Do not treat Jira status as evidence of pipeline results, mergeability, predecessor merge, or merge.
10. After `MR_READY`, verify that the MR still has the exact expected source and target, required checks and GitLab mergeability pass, all platform-enforced approval and protected-branch controls are satisfied, and no relevant evidence has gone stale. Do not add a separate approver-role or branch-owner confirmation gate. For a stacked ticket, also verify that every predecessor has merged into the Epic branch in order, update or rebase the working branch when required by repository policy, remeasure the now-independent Epic-target diff, and rerun affected checks before merging. The Developer may then proactively perform the merge under explicit merge authorization. Never merge a stacked ticket ahead of an unmerged predecessor, self-approve, or bypass GitLab approval, protected-branch, pipeline, or mergeability controls.
11. Assign `CODE_READY`, `MR_PREPARED`, `MR_READY`, `MERGED`, or `WAITING_EXTERNAL` only from evidence and criteria in the workflow contract.

## Enforce Waiting and Ownership

- Treat every skill-defined gate as warning-first and user-overridable only under its applicable policy, except gates explicitly marked non-overridable. The PR-size hard gate is non-overridable for all agent-authored handwritten/non-generated lines. Deterministic generated artifacts may make the total PR exceed the maximum only through the narrowly verified generated-artifact exception in the core policy; the exception never covers agent-authored lines. On a gate failure, pause only the dependent action; state missing evidence, affected action, risk, and recommended fix. If the applicable policy permits an override and the user explicitly accepts the risk and authorizes the exact action, record the scoped override and continue. Revalidate it after state drift.
- An override never supplies missing operational details or mutation authorization: require an exact repository, target, scope, and action before acting. Never use an override to violate higher-priority instructions, guess among ambiguous targets, expose secrets, perform destructive recovery outside authorization, or claim missing evidence was verified.
- Use `WAITING_EXTERNAL` when credentials, permission, platform-enforced approval or protected-branch controls, tooling, required design evidence, or another external system prevents the next step after safe recovery is exhausted. A failed check or visual discrepancy is work to diagnose, not automatically an external wait.
- Never self-approve, bypass or change GitLab approval/protected-branch/merge settings, deploy, call LinearB deployment APIs, tag releases, perform Mobile delivery, or claim post-merge DORA results.
- At `MR_READY`, the Developer owns the explicitly authorized merge after required checks, mergeability, and platform-enforced controls pass. Distinguish verified evidence, accepted assumptions, overrides, and residual risks explicitly.

## Compose with Other Skills

Apply [Composition and resume](references/composition-and-resume.md) throughout the combined task. Generic workflow defaults do not relax OCB requirements. In particular, retain the pre-source LinearB init commit and the post-implementation confirmation boundary even when another workflow normally uses incremental commits.

- With `$discuss`, honor its mutation overlay and update its sole tracker.
- With `$plan`, place the complete `OCB Delivery Workflow Contract` in the plan.
- With `$execute`, keep the approved plan as execution truth, revalidate gates before mutation, obtain OCB branch, init-commit, and initial-push authorization before source mutation, publish the branch and init commit, override generic incremental-commit cadence by retaining the verified implementation diff until the post-implementation confirmation checkpoint, and continue through `MERGED` after required checks, mergeability, explicit merge authorization, and platform-enforced controls pass unless the workflow truthfully ends at `CODE_READY`, `MR_PREPARED`, `MR_READY`, or documented `WAITING_EXTERNAL`.
- With `$interact-with-jira`, delegate all real Jira behavior and safety rules to that skill.
- With `$interact-with-git-platform`, delegate all GitLab identity, repository, MR, pipeline, approval, and merge behavior and safety rules to that skill; use ordinary Git only for local repository operations.
- With a UI design or design-to-code skill, use it only for approved frontend scope; this workflow remains authoritative for Jira, Git, evidence, and ownership.

## Report the Handoff

Use the format in [workflow-contract.md](references/workflow-contract.md). State the final workflow state, mode and path classification, evidence, checks, domain verification, exceptions, preserved unrelated changes, and next owner. Never describe `MR_PREPARED` as `MR_READY`.