// Verify that hl_lines attributes in markdown code blocks correctly highlight the intended lines. Use when reviewing documentation with code examples, especially Before/After comparisons, or when highlights seem incorrect.
| name | Check Code Block Highlights |
| description | Verify that hl_lines attributes in markdown code blocks correctly highlight the intended lines. Use when reviewing documentation with code examples, especially Before/After comparisons, or when highlights seem incorrect. |
Verify that hl_lines attributes in markdown code blocks are correctly set to highlight the intended lines.
See ../shared/repo-conventions.md for file conventions.
hl_lines is snippet-relative, NOT related to linenums:
linenums="21" sets the displayed starting line numberhl_lines="3" highlights the 3rd line of the snippet (which displays as line 23)Example:
`groovy linenums="21" hl_lines="3"
process FOO { <- displayed as line 21 (snippet line 1)
input: <- displayed as line 22 (snippet line 2)
val x <- displayed as line 23 (snippet line 3) - HIGHLIGHTED
}
`
For each code block with hl_lines:
Identify the code block - Find blocks with hl_lines="..." attribute
Count snippet lines - Number each line of the code block starting from 1:
1: #!/usr/bin/env nextflow
2: (blank line)
3: process FOO {
4: publishDir 'results' <- if this should be highlighted, hl_lines should include "4"
...
Verify intent - For Before/After blocks:
Check for common errors:
linenums with hl_lines (thinking hl_lines="21" highlights displayed line 21)input:, output:) instead of the actual valuesWhen you find incorrect highlights:
hl_lines to reference those snippet line numbersFor each file checked, report:
## [filename]
### Block at line [N]: [description]
- Current: hl_lines="X Y Z"
- Lines X, Y, Z contain: [what's on those lines]
- Issue: [description of problem, if any]
- Suggested fix: hl_lines="A B C" (highlighting [what those lines contain])
### Summary
- Blocks checked: N
- Issues found: M
- [List of fixes needed]
Given this code block:
`groovy title="example.nf" linenums="1" hl_lines="8 11 14"
#!/usr/bin/env nextflow <- snippet line 1
<- snippet line 2 (blank)
process SAY_HELLO { <- snippet line 3
<- snippet line 4 (blank)
publishDir 'results' <- snippet line 5
<- snippet line 6 (blank)
input: <- snippet line 7
val greeting <- snippet line 8 - HIGHLIGHTED
<- snippet line 9 (blank)
output: <- snippet line 10
path "*.txt" <- snippet line 11 - HIGHLIGHTED
<- snippet line 12 (blank)
script: <- snippet line 13
"""echo hi""" <- snippet line 14 - HIGHLIGHTED
}
`
Analysis: hl_lines="8 11 14" correctly highlights the input value (line 8), output value (line 11), and script content (line 14).
Run comprehensive validation and review checks including heading numbering, TODO/FIXME comments, Nextflow script conventions, orphaned files, admonition syntax, lesson structure, formatting, content accuracy, and teaching effectiveness. Use when validating, reviewing, or checking training materials quality, lesson quality, or before committing changes.
Walk through a training tutorial as a user would, progressively building examples exactly as instructed, running all commands, and verifying results against solutions. Use when testing tutorials end-to-end or validating that instructions are correct and complete.
Add an interactive exercise with solution to an existing lesson. Creates properly formatted exercise and solution admonition blocks. Use when a lesson needs hands-on practice.
Review inline code in markdown files for proper formatting and syntax highlighting. Check for missing backticks on CLI flags, filenames, and code elements. Verify that inline syntax highlighting (#!groovy) is used appropriately. Use when reviewing documentation or quiz questions.
Set up a Docker container for running Nextflow training examples. Handles basic setup, Docker-outside-of-Docker (DooD) for containerized processes, ARM Mac platform emulation, and troubleshooting. Use when you need to run Nextflow examples in a consistent environment.
Search markdown files, Nextflow scripts, and config files for TODO/FIXME comments, categorize by priority, and provide actionable recommendations. Use when you need to identify pending work or track technical debt.