Checklist: Writing Rules, Placement, and Examples

A checklist is a finite set of independent actions or verification gates that a reader can mark incomplete or complete. Its checkable state is part of the meaning: completing every required item should prove that a named task, review, or readiness condition is finished.

This rendered example has a bounded scope, four concise actions, visible unchecked states, and one completion condition. Converting the same words to decorative bullets would remove the promise that the set can be finished.

Why this element matters

Readers use a checklist to offload memory. Instead of holding every requirement in mind while switching between a draft, browser, design, and publishing interface, they can inspect one condition at a time and record progress. The finite boundary reduces uncertainty: the reader knows what remains, what “done” means, and when it is safe to move on.

That psychological contract is stronger than “here are some useful ideas.” A checkbox invites commitment, while the final unchecked item creates deliberate tension. The element must therefore be honest about scope. If the list omits a required gate or includes vague aspirations such as “make the page great,” the interface signals certainty that the content has not earned.

Machine extractability is the ability of search engines, AI answer systems, assistive technology, and publishing tools to isolate each item without losing its role or completion model. A typed checklist exposes a named collection, stable item boundaries, initial states, and a completion condition. A parser can distinguish required gates from examples or benefits, while an AI system can quote one self-contained action with the checklist’s subject intact.

Follow the element writing rules before choosing the component. Their precedence rule is semantic: when a block’s purpose is to be completed or verified, use the checklist element even if ordinary bullets could display the same words. Visual resemblance does not preserve state, validation, accessibility, or adapter mapping.

When to use it

Use a checklist when the set is finite, every item can independently pass or fail, and completing the required items establishes a meaningful condition. Appropriate subjects include pre-publish review, procurement requirements, migration readiness, incident handoff, document completeness, accessibility review, and a recurring maintenance inspection.

Apply three tests:

1. State test: Can each item be unambiguously marked incomplete or complete?
2. Boundary test: Does the list contain all required checks for its declared scope?
3. Completion test: Does finishing the required items prove a named outcome?

If any answer is no, another element is probably more accurate. The common near misses are:

• A bullet list groups facts, options, examples, or attributes. Its items are not tasks and the set does not become complete.
• A step list encodes dependent sequence. If moving item 4 before item 2 can cause failure, numbers and recovery guidance matter more than checkboxes.
• A feature list describes what a product has. “Supports CSV export” is not a check unless the reader is verifying a stated requirement.
• A wish list records preferences whose boundaries and priority may change. It should not promise completion.
• A scorecard evaluates dimensions on a scale. Binary check states would discard useful degrees of performance.
• A long procedure with a checkbox beside every click confuses execution with verification. Explain the procedure as steps, then add a short completion checklist.

Do not use a checklist as decoration at the end of every section. Repeated unchecked boxes impose work and imply the reader has not finished, even when the content merely offered optional advice.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Where to place it

Placement follows the moment at which the reader can act or verify. Introduce the task, scope, and required context first; then place the checklist immediately before the decision it controls or immediately after the material it summarizes.

• Put a readiness checklist after prerequisites and before an irreversible or expensive action.
• Put a quality-assurance checklist after the draft, configuration, or procedure it evaluates and before approval or publication.
• Put a buying-requirements checklist after needs and constraints are explained but before products are shortlisted.
• Put a recurring inspection checklist inside the maintenance section, next to its cadence and owner.
• Put the main checklist near the top of a dedicated checklist article, after a short scope statement, then explain difficult items below.

A checklist must not sit directly beside a second checklist with an overlapping scope; merge them or give each a distinct heading and completion condition. Do not place it beside a sequential step list without stating which block is the procedure and which is the verification. It must not split a warning from the consequence or required response, interrupt a comparison table, or sit inside a call to action. Never put a promotional button between the final item and the completion condition.

Anatomy

The labelled regions are:

1. Scope heading: names the exact object and decision, such as “Pre-publish link check.”
2. Instruction: says what completion permits or proves.
3. Checkbox control: exposes incomplete or complete state programmatically and visually.
4. Action label: starts with a concrete verb and remains understandable by itself.
5. Optional qualifier: supplies a threshold, location, owner, or evidence requirement.
6. Required indicator: distinguishes optional items only when the contract genuinely permits them.
7. Progress summary: reports completed and total required items in interactive variants.
8. Completion condition: states the outcome established when all required items pass.

The words remain authoritative. A tick icon, green row, or struck-through label may reinforce state, but none can replace the native or programmatic checked state.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Design examples

Static editorial checklist

Use visible unchecked controls for a printable or reference checklist. The reader may copy or print it, but the page does not claim to save progress.

Interactive progress checklist

Use when the reader benefits from marking progress during a session. Announce the count without moving focus and provide a clear reset action.

Required and optional checklist

Use only when optional tasks genuinely do not affect the completion condition. Label optional items in text; never rely on lighter color.

Grouped checklist

For more than ten total checks, divide the work into groups of four to ten with separate headings and completion conditions. Each group is independently understandable.

Print state

Print output must retain empty and completed marks in black and white, keep labels beside their controls, and avoid splitting a short group across pages.

Parameters

The initial checked value is for worked examples, saved templates, or server-owned task state. Editorial checklists start unchecked; authors must never pre-check an item merely to create a more attractive screenshot. If interactive=false, persist must be none.

Syntax and code examples

The canonical mapping follows the precedence, body, and nested-item rules in the base contract. The parent supplies collection behavior; each item supplies one label, optional detail, and state fields.

Portable Markdown directive

:::checklist{id="pre-publish-links" interactive=true persist=local}
## Pre-publish link check

Complete every required item before approving the page.

::item
### Open every internal link and confirm the destination exists
::

::item
### Confirm each anchor describes its destination out of context
::

::item{required=false}
### Check campaign parameters on optional promotional links
::

::item
### Verify keyboard focus is visible on every linked control
::

Complete when every required item passes and no exception remains.
:::

Hugo shortcode

{{< checklist id="pre-publish-links" title="Pre-publish link check" interactive="true" persist="local" completion="Complete when every required item passes and no exception remains." >}}
{{< checklist-item >}}Open every internal link and confirm the destination exists.{{< /checklist-item >}}
{{< checklist-item >}}Confirm each anchor describes its destination out of context.{{< /checklist-item >}}
{{< checklist-item required="false" >}}Check campaign parameters on optional promotional links.{{< /checklist-item >}}
{{< checklist-item >}}Verify keyboard focus is visible on every linked control.{{< /checklist-item >}}
{{< /checklist >}}

This is the required Hugo adapter shape, not a claim that the repository already provides the shortcode. Until a registered renderer exists, use semantic HTML for a live example rather than imitating the component with unrelated styles.

WordPress block

<!-- wp:amicited/checklist {"id":"pre-publish-links","title":"Pre-publish link check","interactive":true,"persist":"local","completion":"Complete when every required item passes and no exception remains."} -->
<!-- wp:amicited/checklist-item -->
<p>Open every internal link and confirm the destination exists.</p>
<!-- /wp:amicited/checklist-item -->
<!-- wp:amicited/checklist-item -->
<p>Confirm each anchor describes its destination out of context.</p>
<!-- /wp:amicited/checklist-item -->
<!-- wp:amicited/checklist-item {"required":false} -->
<p>Check campaign parameters on optional promotional links.</p>
<!-- /wp:amicited/checklist-item -->
<!-- wp:amicited/checklist-item -->
<p>Verify keyboard focus is visible on every linked control.</p>
<!-- /wp:amicited/checklist-item -->
<!-- /wp:amicited/checklist -->

All adapters must preserve source order, required state, visible labels, the completion condition, and the unchecked content when scripting is unavailable.

Examples

Good: a bounded release check

• Confirm the release version matches the approved change record.
• Run the documented smoke test and attach its result.
• Verify the rollback owner is available during the release window.
• Record the deployment time in the incident timeline.

Complete when: all four records are present and the named rollback owner has acknowledged the window.

This works because each item begins with an observable action, stays within one release decision, and has binary evidence. The completion line explains what the full set proves.

Bad: an aspirational content list

• Think about the audience.
• Make the article engaging.
• Improve SEO.
• Add anything else that helps.

This fails because none of the items defines a pass condition, “anything else” makes the set infinite, and completing the boxes would not prove the article is ready. Replace aspirations with verifiable gates such as “Name one primary audience in the brief” or move non-actionable guidance into prose.

Schema markup and accessibility

There is no general Schema.org Checklist type. Do not map independent checks to HowToStep unless the page genuinely describes an ordered procedure and the visible content contains those steps. A checklist can remain visible content inside Article, TechArticle, Product, or another justified page type, but its checkboxes do not create extra schema eligibility.

Use native <input type="checkbox"> controls for interactive state and associate every control with a <label> using wrapping or matching for and id values. A static display that cannot be changed must not masquerade as an enabled control. Use disabled checkboxes for an explicitly noninteractive example, or use a list with text equivalents such as “Not checked” in contexts where form controls would be misleading.

Keyboard users must reach every enabled checkbox in source order, toggle it with the Space key, and see a persistent focus indicator. Do not move focus after a check. If a progress message updates, announce a concise summary such as “Four of six required items complete” through a polite live region; do not announce the entire list again.

Checked and unchecked states require more than color. Preserve the label when checked rather than replacing it with “Done,” because the action must remain identifiable. If progress persists, explain the storage scope and provide Reset progress. The useful content, required indicators, and completion condition must remain in server-rendered HTML when JavaScript fails.

Writing rules

Checklist items are compact because the reader is executing or verifying, not learning the entire subject inside the control. Explain the reason in surrounding prose before stating the rule.

• Keep one checklist to four through ten items. Four establishes a useful finite set; more than ten becomes difficult to scan and signals multiple phases.
• Keep each action to about 80 characters and three to twelve words. A short label remains usable beside a control and extractable without adjacent prose.
• Start with a specific imperative verb: Confirm, Open, Compare, Record, Test, Attach, or Verify. Avoid weak verbs such as Consider, Remember, or Think about.
• Give each item one pass condition. “Check the title and links” can partially pass, so split it into two items.
• Keep items independent. If one action unlocks the next, convert the procedure to steps and use the checklist only for final verification.
• Keep grammar and altitude parallel. Do not mix “Confirm legal approval” with “Publish the campaign across all channels and monitor it for a week.”
• Name evidence when completion is not directly visible: attach the report, record the timestamp, or obtain the approver’s acknowledgement.
• Mark optional items explicitly and exclude them from required progress. Optional must mean the completion condition remains true without them.
• Use sentence case and terminal punctuation consistently. Full sentences are preferred when an item includes a qualifier.

Never put these inside a checklist item:

• Several ordered substeps, branching troubleshooting logic, or a second nested checklist.
• A safety warning, legal disclaimer, or irreversible consequence that must be seen before action.
• A paragraph of explanation, long quotation, testimonial, screenshot, video, form, or promotional call to action.
• A subjective score, open-ended aspiration, unsupported threshold, or requirement with no observable evidence.
• A link labelled only “here,” because the item must survive extraction without surrounding context.

Post types that use it

The joins below are driven by this page’s postTypes frontmatter. “Required” means the post type’s core task depends on a finite completion model; “recommended” and “optional” depend on the page’s subject.

QA checklist

Content and placement

• The heading names one bounded object, decision, or readiness state.
• The introduction explains what completing the required items proves.
• Use four to ten items, splitting larger work into named groups.
• Keep every item near 80 characters and begin with a concrete verb.
• Every item has one observable pass condition and can be checked independently.
• Confirm that reordering items does not break the task.
• The set is finite and includes every required gate for its stated scope.
• Optional items are visibly labelled and excluded from required progress.
• Remove nested procedures, warnings, long explanations, media, and promotion.

Complete when: the collection has one bounded purpose and every item is concise, independent, and verifiable.

Rendering and accessibility

• The completion condition appears directly after the final item.
• Enabled controls have associated labels, keyboard operation, and visible focus.
• State is not communicated by color, icons, strike-through, or position alone.
• Interactive progress works without moving focus and explains any persistence.
• Labels and completion criteria remain available without CSS or JavaScript.
• Keep structured data on the enclosing page; do not invent Checklist schema.
• Preserve the same fields and order in all three platform mappings.
• Keep screenshot comments as instructions; reference no missing image.

Complete when: state, labels, order, and completion meaning survive every supported rendering path.

FAQ

The academy template renders the five reviewed questions in this page’s [[faq]] frontmatter. They cover item count, the distinction from bullets and steps, saved state, and structured data.