feat(cli): render final replies with markdown emphasis

[LeonSGP43]

What does this PR do?

This PR improves final assistant reply readability in the Hermes CLI by rendering safe final replies as terminal-friendly markdown instead of flat plain text.

Scope is intentionally narrow:

• CLI only
• no agent logic changes
• no tool behavior changes
• no non-CLI channel changes

User-facing impact:

• clearer hierarchy for headings, bold text, lists, blockquotes, and fenced code blocks
• better scanability for high-signal numeric values in prose
• styling aligned with the Hermes CLI palette instead of Rich's default markdown colors

Related Issue

N/A

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• Render final assistant replies in cli.py through Rich markdown when the response is safe to treat as markdown, while preserving ANSI fallback behavior
• Add CLI-only prompt guidance in agent/prompt_builder.py to encourage compact markdown when it improves terminal readability
• Apply Hermes-aligned styling for headings, strong text, lists, blockquotes, and fenced code blocks
• Add conservative emphasis for important numeric tokens in plain prose
• Avoid a heavy hermes_cli.main import in recent session display so the history path stays lightweight
• Add and update tests covering markdown rendering, ANSI fallback, numeric emphasis, and CLI-only prompt guidance

How to Test

1. Run Hermes in the CLI and use this prompt:

   Please produce a compact but polished markdown response about "2026 AI product growth review" that is optimized for terminal readability.
   
   Your response must include:
   1. One level-2 heading
   2. One short intro paragraph
   3. One bold takeaway sentence
   4. One unordered list with 4 bullet points
   5. One ordered list with 3 items
   6. One blockquote
   7. One fenced JSON code block
   8. One inline code example
   9. One markdown link
   10. One horizontal rule
   
   Include these values in the response:
   78%, $99, 2026-04-14, $7.8M, 3 phases, 12 weeks
   
   Also include these plain-text edge cases:
   /data/reports/2026/q2
   v1.2.3
   gpt-4.1
   
   Keep the response concise and do not use tables.
   

2. Confirm that:

   • markdown structure is visibly clearer in the CLI
   • important numeric values are emphasized
   • file paths, model names, and version strings are not incorrectly emphasized
   • ANSI-colored output still falls back correctly
   • non-CLI channels are unaffected

3. Run local verification:

   source .venv/bin/activate
   python -m pytest tests/cli/test_cli_init.py tests/cli/test_stream_delta_think_tag.py tests/cli/test_resume_display.py tests/agent/test_prompt_builder.py -q -k 'AssistantResponseRenderable or show_history or resume_without_target_lists_recent_sessions or platform_hints_known_platforms or cli_platform_hint_encourages_compact_markdown_only_for_cli'
   python -m pytest tests/e2e/ -v --tb=short

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 26.3.1 CLI

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

• python -m pytest tests/cli/test_cli_init.py tests/cli/test_stream_delta_think_tag.py tests/cli/test_resume_display.py tests/agent/test_prompt_builder.py -q -k 'AssistantResponseRenderable or show_history or resume_without_target_lists_recent_sessions or platform_hints_known_platforms or cli_platform_hint_encourages_compact_markdown_only_for_cli' -> 7 passed in 30.95s
• python -m pytest tests/e2e/ -v --tb=short -> 48 passed in 21.29s
• python -m pytest tests/ -q still does not pass locally on macOS 26.3.1 after rebasing onto origin/main: 13 failed, 2957 passed, 5 skipped, 128 warnings in 395.30s
• The same full-suite command also fails on a clean origin/main worktree in the same local environment: 17 failed, 3828 passed, 5 skipped, 124 warnings in 466.85s
• The unchecked full-suite box therefore reflects local baseline failures rather than a regression introduced by this CLI-only PR

[CartericAdmin]

This looks awesome

[LeonSGP43]

Additional verification note: I reran python -m pytest tests/ -q both on this PR branch and on a clean origin/main worktree in the same local macOS 26.3.1 environment. The full-suite command does not pass in either case, and clean origin/main also reproduces xdist timeout/internal-error failures. In other words, the unchecked checklist item reflects existing local baseline failures, not a regression introduced by this CLI-only markdown rendering PR.

The change-specific verification for this PR still passes: the focused CLI/prompt tests pass, and python -m pytest tests/e2e/ -v --tb=short passes locally.

[teknium1]

Thanks for the PR @LeonSGP43 — the code quality here is genuinely solid. The skin engine integration, the ANSI fallback, the numeric highlighting regex with proper negative lookahead for paths/versions, and the thorough test coverage all show real care.

Unfortunately we have to close this for the same reason we closed PR #601, which attempted the same Rich Markdown rendering approach. The core issue is our CLI's output pipeline:

Rich render → StringIO → _cprint → prompt_toolkit ANSI() parser → terminal

Our CLI runs inside prompt_toolkit's patch_stdout context, and the ChatConsole adapter routes all Rich output through that pipe. For basic usage (panels, bold text, simple colors) this works fine. But Rich Markdown rendering generates significantly more complex ANSI — 24-bit background colors for code blocks, nested Pygments syntax highlighting, underline+color combinations for headings, Unicode box drawing — and there are known edge cases where prompt_toolkit's ANSI parser doesn't handle that correctly. Users on SSH, tmux, mosh, or terminals without truecolor support get garbled output.

Your screenshot looks great because macOS Terminal is the happy path (native truecolor). But we need this to work everywhere our users run the CLI.

There's also a design concern with the prompt hint change — reversing the CLI from "avoid markdown" to "encourage compact markdown" changes agent output behavior for all CLI users at once, which is a bigger decision than the rendering layer.

This is tracked as Issue #504 (Enhanced CLI TUI) and is planned as a phased core change that addresses the prompt_toolkit integration, terminal compatibility detection, streaming output, and graceful degradation together. When we get there, your approach of theming the Markdown renderable with the skin engine palette is a good foundation we'll likely draw from.

Appreciate the contribution and the detailed testing notes.