I would caution anyone against using AsciiDoc. I really want to like AsciiDoc, but it has glaring issues for many years, that the developers seem to have no interest in fixing:
That looks like a minor issue in GitHub's stylesheet, not really an AsciiDoctor problem.
AsciiDoctor is adding p elements in places where it should not. GitHub could work around this error with CSS, but they have not done so, nor should they. It's a simple issue to fix, just emit the bare li elements.
The HTML alternate back-end fixes a lot of these issues and chooses semantic elements for a more modern age (while Asciidoctor is actively overhauling its output I believe).
The issue visually can be solved with CSS as-is (remove the padding or margin from li > p:only-child), but Microsoft GitHub treats its AsciiDoc rendering as a second-class citizen despite it objectively having more/better features for documentation than Markdown. The negligence becomes apparent when you look at the way GitHub syntax fork (“flavor”) handles admonitions; not only does it overload, overcomplicate, and ruin the semantics of the blockquote, but the CSS styling that makes them look nice was never ported to admonitions for reStructuredText and AsciiDoc despite these formats having the feature natively to the syntax (no fork required) since forever.
It's been 9 years. That is not actively by any definition of the word.
Been using it for years, and I haven’t run into any issue thy would make me want to use anything else.
There isn't much tooling. The community is small. The spec effort seems to have stagnated. AsciiDoctor and related projects seem to move at the speed of what Dan Allen decides is most worth his time.
That said, I've been wanting to do more long form writing, and AsciiDoc is lovely for that, so I may pick it up again for that.
The implementation lacks checking, so for example if you have some text between square brackets, it will often just get dropped even if the contents is not valid as an attribute list.
{asterisk}