Work History
Overview
Work History lists publication runs as work states. Each row includes summary fields such as publication name, operation type, and status. Opening an entry shows a sheet with tabs for Details, Files, Messages, and reasoning.
Details
The Details tab shows descriptive statistics and a summary of Doc Holiday's reasoning for the run.
Work History can show clearer status labels while work remains in progress. A staged item now appears as In Progress. If Doc Holiday's latest bot comment asks for follow up, Work History shows Needs Attention instead, and the status options can show those items directly.
If an administrator cancels a running item, Work History shows Cancelled instead of leaving the run looking incomplete or failed.
Merged conversations
When a pull request or merge request has already merged, Work History shows who merged it and, when available, the merge time.
Open a pull request or merge request
After the run finishes, people with publication write access can open a pull request or merge request from a staged work item.
Open a Work History entry.
Select Open PR or Open MR.
Files
The Files tab lists the files modified during the run and shows file changes for each file.
Preview a Markdown file
Markdown files support a preview toggle that renders the full file content instead of only the file changes.
Download a file
Open a Work History entry.
Select Files.
Select the download icon for a file.
Note: Use Download All to download a single ZIP archive that contains every file listed in the Files view for the selected work item.
Upload a file
The Files tab uses a per-file upload action.
People without publication write access can still review files and comments, but only people with write access can upload files or edit file contents.
Open a Work History entry.
Select Files.
Select the upload icon for a file.
Select a local file.
Note: Upload is disabled while Doc Holiday is still making changes.
Exclude a file from a pull or merge request
The Files tab supports excluding specific files before opening a pull request (GitHub) or merge request (GitLab).
Open a Work History entry.
Select Files.
Discard the file that is unnecessary.
To restore an excluded file, select the restore action for the file.
Excluded files are tracked on the work state and are reflected in the Files tab.
Add a file
Files can be added directly from the Files tab on a draft work item by selecting a file and specifying a destination path.
Open a Work History entry.
Select Files.
Select the add file icon.
Enter the destination file path.
Select a local file.
Note: Only people with publication write access can add files.
Review file comments
The Files tab supports inline file comments during review. It lets teams add comments on specific lines or ranges, reply in anchored threads, and review quoted file context beside the affected content.
Work History keeps draft comments separate from comments already sent to Doc Holiday. Draft comments support multiline input, selected ranges can preview while drafting, and Ctrl+Enter or Cmd+Enter sends the comment.
Comment controls and visibility can vary with the conversation state, publication access, and comment authorship. Reviewers can continue reading and discussing content, but only people with write access can send requests to Doc Holiday from file comments.
Each comment also supports its own Send to Doc action from the comment menu, which makes it possible to forward a single comment without building a larger batch.
Work History shows comment ranges and quoted file context in clear, human readable labels. It also links file comment threads with related conversation context.
Comment filters can hide user comments, hide bot comments, hide outdated comments, or hide comments already sent to Doc Holiday.
Messages
The Messages view supports continued collaboration with Doc Holiday from the Work History entry. When a conversation has an open pull request or merge request, users can continue sending messages whenever the run status allows it.
Some file comment threads include navigation back to related Messages context after the comment has already been sent to Doc Holiday.
When the Work History entry is running, the Messages view instructs users to wait until Doc Holiday finishes before sending more messages.
Users can still review message history from this view.
When the Work History entry is ready for review and not running, users can open the send message form.
Background tasks
Background tasks can keep a work item in progress after the main conversation stays open. Background tasks generate simplified messages that hide the raw task payload. If someone stops the conversation, Doc Holiday also stops any background task that is still running. If a running background task becomes stale, Doc Holiday can restart it automatically up to a capped retry count. While the work item is running, the Messages view still requires publication write access for sending.
Notifications
When a publication has a notifier configured and the conversation reaches Ready for Review, Work History shows a Notify action. This action sends a completion update to the connected Slack channel.
Work History does not show Notify while a conversation is still running.
Last updated
Was this helpful?