This document provides guidance for the writing style in the Velociraptor documentation. It specifies some informal standards and advice with the goal of ensuring as much consistency as possible in our prose content irrespective of author.
The guidance in this document is intended to:
The advice is intended to be helpful and should not be seen as a hurdle to contributions. If your contribution doesn’t subscribe to all the guidelines that’s perfectly OK - we can fix it up to be more compliant during future reviews.
This document is also a work-in-progress, and not set-in-stone “rules”.
Our docs website is compiled by Hugo which interprets markdown based on the Commonmark standard. Therefore it’s best to avoid using features from any other flavors of markdown such as GFM, as they may not be rendered correctly or at all by Hugo.
Hard wrap paragraph text at 70 or 80 characters. This makes it easier to review GitHub pull requests, which display changes side-by-side in two columns.
Your code editor may provide an auto-wrap option or an extension that makes this easy. For example, in VSCode you can use Rewrap.
Exceptions to hard-wrapping are:
Only use inline HTML when markdown cannot provide the same result, and even so try to avoid inline HTML except when it’s absolutely necessary. Having as much content as possible in markdown form simplifies website style changes, as well as automated style checking and content updates.
When writing content in HTML the same style rules apply as described in the Markdown flavor section.
Avoid overusing inline code or the prose starts to look like
patchwork.
Use inline code only for:
Do not use it for:
For the last 2 cases above it is recommended to use bold text for emphasis the first time a term is used. When doing so it is not necessary to use quotes around the term.
We currently support browser, python, yaml, sql, json,
bash, powershell, vql, text, shell syntax highlighting via
the highlight.js highlighter.
Prefer the vql syntax highlighting tag for VQL code blocks over sql,
although they are similar.
```vql
SELECT read_file(path="C:/Windows/notepad.exe", accessor="file")
FROM scope()
```
produces this syntax-highlighted code block
SELECT read_file(path="C:/Windows/notepad.exe", accessor="file")
FROM scope()
Try not to overuse admonition blocks. In particular, try to avoid having two or more of them adjacent, especially if they are the same admonition type.
Try to use them sparingly when the reader’s attention needs to be drawn to something specific. Often the content in an admonition block can be rewritten as part of the normal text content, and therefore doesn’t need to be wrapped in its own block.
Currently we support 4 admonition types: note, tip, info,
warning.
Admonition titles are optional but recommended.
Use - not *. Just for consistency.
The privilege indicator (e.g. # or $) depends on future styling
decisions and is TBD.
Use generic file names and omit version numbers and architecture where possible.
Use platform-appropriate command alternatives where applicable.
When providing command examples, use a consistent order for the command
components: [binary] [command] [subcommand] [flags] [args].
Use markdown links rather than Hugo ref or relref shortcodes.
Avoid splitting links across lines. Even though this is valid it makes future link maintenance more complicated. If a link is long:
Hugo will do internal link checking automatically. So always check your Hugo output for issues before submitting a PR.
When internal links are invalid, Hugo will fail to compile and refuse to start, but this only happens on dev server start, so do also remember to check the console output.
The same no-line-break rule applies to external links too: avoid splitting any link text or URL across lines.
Always try to add a meaningful summary field to the page metadata.
When using the children shortcode, it defaults to creating a summary
if one is not defined, and it does this by grabbing the first few
paragraphs/sentences from the page which is often not ideal. Usually
this “auto-summary” is not very helpful so it’s better to carefully
craft one rather than relying on “auto-summary” feature.
Tags are recommended on KB articles. These help users find related content.
Do not use meaningless tags such as “velociraptor” or “DFIR”.
Avoid using tags that are terms which already appear in the page content, because those can just be found with regular index-based searches. A tag should ideally be an association with some broader concept that is not explicitly mentioned in the content itself.
vql.yaml)Top level section headings should be level-3/H3 (###). The reason
for this is that when presented on the website, H1 is already used for
the page title, and H2 is used for the name of each
function/plugin/accessor. So headings within the section for each
function/plugin/accessor need to be H3 or lower.
Examples should always use Level-6 headings, regardless of their position in the heading hierarchy. This ensures a consistent style for all examples and allows Hugo to create a hyperlink for each example, which is important for sharing on community support on forums like Discord.
For example:
###### Example
L6 headings also won’t appear in TOCs, so this also prevents that from accidentally happening.
Don’t use a colon after the word Example unless there’s a subsequent example title such as “Example: Recursive use case”.
Bold all UI elements (buttons, tabs, menu names) to help users scan the page quickly.
Pages under docs/cli/commands/ document individual CLI commands
and command groups. They follow a consistent heading structure:
Each command or subcommand gets a Level-3 heading:
### [ artifacts list ]
### [ config show ]
### [ fuse container ]
The reason for using square brackets is that inline code notation overrides heading formatting and looks ugly. So this is just an alternative way to indicate that the commands are literals without using inline code notation.
After the ### command heading, include a text code block
showing the usage syntax (flags, arguments, defaults). This block
should be taken from the command’s -h output, but omit the flags
that the -h flag displays which are common to all commands.
artifacts list [<flags>] [<regex>]
Print all artifacts
-d, --[no-]details ... Show more details (Use -d -dd for even more)
Args:
[<regex>] Regex of names to match.
On pages documenting multiple subcommands, separate each
subcommand section with a horizontal rule (---).
Use #### (Level-4) headings for major topics within a
command’s documentation.
Use ##### (Level-5) headings for auxiliary content such as
notes and see-also sections.
Use ###### (Level-6) headings for examples (see the
examples section above).
The heading hierarchy for CLI command pages is:
### [ command.subcommand ] — command signature#### — major topic within the command##### — notes, see-also, usage notes###### — examplesWhen linking to another CLI command from within a command page,
use the [[ command ]] convention in the link text. This pairs
the bracket-notation style of the heading with a standard markdown
link:
- [[ fuse container ]](/docs/cli/commands/fuse/),
which allows you to mount collection containers instead of
extracting them.
- [[ decrypt ]](#-decrypt-), which removes the encryption from
collection containers.
This convention signals to the reader that the link refers to another CLI command (identifiable by the bracket style), even when skimming the page. This is again just an alternative to using inline code notation that makes things a bit more clear to the reader.