Treat each checkbox as a claim that needs evidence
Before copying a release checklist into an issue, verify that every checked item corresponds to work someone actually completed. A preview can show the marker in your draft; it cannot establish that a build passed, an owner accepted a task, or a release is ready.
For example, a coordinator might receive a draft where “Record build ID” is complete but two smoke checks are still pending. An indented list can make the relationship look obvious in the source while the preview drops the expected checkbox structure. The useful review question is whether each required check remains visible, has the right state, and has an owner who can supply evidence.
Keep an original copy in your normal document editor before using the browser. Use invented identifiers for a formatting rehearsal, and keep real credentials, private deployment links, and customer data out of it. Formatting the checklist does not require running any release commands.
Reproduce a small checklist and count its visible controls
Start with three top-level tasks and two indented tasks so that a missing checkbox is easy to notice. The following inputs form a fictional exercise, not a report of completed release work.
Open the Markdown Editor, select all the sample content in the Markdown field, and replace it with these lines. Each bullet below describes one line to enter; the surrounding explanatory bullets are not part of the input.
- Enter
## Release review, followed by an empty line. - Enter
- [ ] Confirm rollback owner. - On the next line enter
- [x] Record build ID. - After an empty line enter
- [ ] Smoke checks. - Enter two spaces followed by
- [ ] Open landing page. - On the next line enter two spaces followed by
- [ ] Check sign-in.
The current parser produces the heading and three disabled checkbox controls for the top-level tasks. Only “Record build ID” is checked. The two indented child tasks remain literal list text rather than becoming two additional checkbox controls. Do not count five task descriptions as five working controls.
This output was checked by executing the current component's conversion function with synthetic input on 2026-09-25. It was not a browser interaction test or an issue submitted to GitHub. The HTML Output panel gives readers a reproducible inspection step: search for type="checkbox" and confirm three occurrences for this input, with checked disabled on the build-ID item.
Now change the first line's task marker from [ ] to [x] in the Markdown field. Its preview should become checked, while the two child tasks remain literal. Restore the marker afterward: changing a symbol for a demonstration does not mean a rollback owner has been confirmed.
Keep the task relationships in the source when previews disagree
Use the destination editor to judge nested formatting; do not flatten the real checklist solely to satisfy this limited preview. If a portable flat list is acceptable, make each task name self-contained, such as “Smoke check: open landing page,” and give every item its own top-level marker.
For the exercise, remove the two leading spaces from both child lines. The component should now produce five checkbox controls, still with only the build-ID item checked. This is a second verification case: the task text is unchanged, but the hierarchy has changed. Decide whether that loss of nesting is acceptable before making the same edit to a real document.
GitHub's tasklist documentation describes the [ ] and [x] markers used in Markdown task items. Its interactive behavior belongs to GitHub; the ToolboxHub controls are disabled output. They are not connected to issues or release automation. This article concerns ordinary Markdown tasks, not the retired special tasklist-block feature.
When reviewing a real checklist, place evidence or a reviewer reference next to each completed claim in the source document. If evidence is missing, resolve that with the task owner. A formatting tool cannot make the underlying completion decision.
Check a fenced build identifier without mistaking it for execution
Use a short fenced sample to verify that an identifier stays inside its intended block. In this editor, a language label after the opening fence becomes part of the displayed code text rather than enabling language-aware highlighting.
For a reproducible example, append an empty line, then a line containing three backticks immediately followed by the word text. Put build-042 on the next line and three closing backticks on the line after that. The current conversion function produces a code block containing two lines: text and build-042. That exact output was included in the synthetic component check.
This differs from the language-identifier behavior described in GitHub's code-block documentation. Keep the intended source syntax and inspect it again in the destination preview. Neither preview executes the identifier or proves that the corresponding build exists.
If you see the language word in the local code block, it is a known parser limitation, not evidence that the source file was corrupted. If surrounding task lines unexpectedly join a code block, check that the opening and closing fences are both present before changing other formatting.
Copy the Markdown source and verify the handoff
For a Markdown issue body, select and copy the left-hand Markdown field. The Copy HTML button copies generated HTML from the output panel; it does not copy the original Markdown, save a file, or publish an issue.
Paste the source into the destination's draft editor and review it there before submission. Count the task descriptions again, confirm which ones are checked, inspect nesting, and verify that the build identifier is still separate from the task list. Actual issue creation and release execution are outside this exercise.
Keep the handoff copy in your normal saved document. If another person changes the checklist, Text Diff can compare two short pasted source versions. A change from [ ] to [x] deserves an evidence review even if no task wording changed. Text Diff does not understand approval state or inspect a repository.
Diagnose failures without losing the draft
When a checkbox will not toggle, edit its marker in the source: the preview's controls are intentionally disabled. When indented tasks look like plain text, inspect the destination renderer or choose an explicitly flat structure with meaningful task names.
If angle-bracket tags appear after pasting into a Markdown field, check whether you used Copy HTML. Return to the preserved Markdown source and paste that instead. If clipboard access fails, manually select the source and use your browser's normal copy action; verify the pasted text before proceeding.
Reloading the page is not a recovery method. This component does not save your draft, and its startup code loads sample content. Save the source elsewhere before refreshing, using Sample, or pressing Clear. Remote images in Markdown can also cause the browser to contact the image host, so leave private tracking URLs and unnecessary images out of this text-only rehearsal.
Frequently asked questions
The final acceptance check belongs in the destination draft and the team's evidence review. A matching local preview is only one part of the handoff.
Does a checked box mean the release task passed?
No. It means the supplied text contains a completed-task marker. The editor does not run tests, verify a build, contact reviewers, or authorize a release.
Why do nested tasks lose their checkboxes here?
The current parser recognizes the task marker at the start of a line. Indented task markers fall outside that rule. Preserve the intended hierarchy and check it in the destination rather than assuming the local output is full GitHub Markdown support.
Can I use Copy HTML to save a Markdown file?
No. It copies generated HTML to the clipboard. Save the original Markdown through your usual text editor; this tool does not write back to a local file or download a Markdown document.
Were these checks performed against a live GitHub issue?
No. The observed results come from running the local component's conversion function with fictional inputs. GitHub behavior was checked against its documentation; the final issue preview and any actual task completion remain for the responsible team to verify.