# Work On Pull Request > Implement changes for a OneDev pull request. Use when the user asks to address feedback, fix, improve, or continue PR work. Use when this capability is needed. - Skill: `tomevault-io/work-on-pull-request` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/work-on-pull-request` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/work-on-pull-request/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/work-on-pull-request --- # Work on a OneDev pull request Check out the PR source branch, read the relevant context, and implement the work. The work may also require replies or resolutions on OneDev. **Push before publish:** any reply or resolve that implies a code change is complete must wait until the commits are on the server, so reviewers are not notified of a change they cannot see yet. ## Prerequisites - `tod` is installed and configured. - The current repository is the PR's source project. ## Stop on error Run the workflow sequentially. On any command failure, missing required output, or failed precondition, stop immediately, report the command and error, and wait for the user. Do not continue, repair state beyond the current step, or retry silently. ## Workflow Given a `` (e.g. `42`, `#42`, `myproject#42`, or `PROJ-42`): 1. **Confirm the source project.** Read the PR metadata and the project inferred from the working directory: ```bash tod pr get tod project current ``` From `tod pr get`, note ``. The output of `tod project current` must equal ``. If it does not, stop and tell the user. 2. **Check out the pull request.** `tod pr checkout` requires a clean working directory: ```bash git status --porcelain ``` Any output means there are uncommitted changes; stop and ask the user to commit or stash them before re-running the skill. Then check out the PR head onto the source branch (when the PR is open and the cwd is the source project): ```bash tod pr checkout ``` Verify you are on ``: ```bash git symbolic-ref --short HEAD ``` 3. **Determine the work specification.** The work may come from the user's prompt directly or from feedback on OneDev: | Work instruction source | Primary specification | OneDev context | |-------------------------|-----------------------|----------------| | User prompt specifies the work | The prompt (concrete task, scope, approach, or constraints beyond naming the PR) | Always use PR metadata and description; inspect the feedback sources identified by the prompt and any directly related discussion as supplementary context | | Prompt only names the PR | PR title and description | Comments, code comments | | Prompt generally asks to address feedback | Applicable PR comments and code comments | PR metadata, description | Even when the prompt is the primary specification, do not proceed from the prompt alone. The PR metadata and description fetched in step 1 are required context, and any feedback source the prompt points to must be fetched in full, including its replies. First determine the current login name: ```bash tod get-login-name ``` Save the login name and match it against the author of each PR comment, code comment and reply. Treat matching comments as your own prior context rather than independent collaborator feedback. | Context source | How to inspect | |----------------|----------------| | PR comments | `tod pr get-comments ` | | Line-anchored code comments | `tod pr get-code-comments ` — note `id`, file, line range, resolution state, and replies. | Read the current patch to understand what the PR already changes relative to its target: ```bash tod pr get-patch ``` When the patch alone is insufficient, inspect the corresponding files in the checked-out working copy. **Inspect embedded resources.** Download every linked image or file from the PR description and discussion: - Find image and file links (`![alt](url)` and `[label](url)`) in every text source you read above. - For each URL, save it with the URL **exactly** as written: ```bash tod download ``` - Open images and read other files as needed. 4. **Assess, plan, and execute.** Check the requested work against the current code and behavior before deciding that a code change is needed. - If the request is reasonable and not already implemented, summarize what you will do, outline your approach, and then implement the change. - If the request is already implemented, verify that conclusion and do not make a redundant code change. Draft a response explaining the existing implementation and the evidence you found. - If the request is unreasonable, technically incorrect, contradictory, or unsafe, do not force a code change merely to satisfy it. Draft a response that clearly explains the issue and, when useful, proposes an alternative. In either no-code-change case, responding in the relevant PR or code-comment is the work product. Before running any `tod` command that changes OneDev state (such as adding a comment or reply, resolving a code comment, or changing PR state), show the exact planned action and obtain explicit user consent. **Push before publishing code-dependent updates.** If a reply or resolve relies on code being submitted — for example, "Fixed", "addressed your feedback", or an explanation of a code change — draft it and obtain consent now, but do not post it yet. Record the deferred action so it can be applied only after the code has been pushed. Replies that do not depend on submitted code, such as clarifications, questions, or disagreement, may be posted immediately after obtaining consent. Match the discussion channel when posting immediately or deferring an update: - General PR feedback → `tod pr add-comment ""` - Line-anchored thread → `tod code-comment add-reply ""` - Concern addressed in code → `tod code-comment resolve --note ""` when appropriate When code was changed, leave the working copy on the PR source branch with the implementation and any deferred OneDev actions ready for a separate submission request. No submission is needed when the outcome is only a discussion response. --- > Source: [theonedev/tod](https://github.com/theonedev/tod) — distributed by [TomeVault](https://tomevault.io).