Skip to content
Back to skills

Styled Markdown Reader

ASecurity

Read and query Styled Markdown (.smd) files token-efficiently, focusing only on meaningful content. Use this skill whenever you need information from a .smd file — answering questions about a spec/PRD/ADR/runbook/design doc, implementing what it describes, summarizing it, reviewing it, or checking its tasks, decisions, risks, APIs or open questions — even if the user just says "the spec", "the doc" or "the plan" and the file ends in .smd. Use it instead of reading .smd files with Read/cat, wh...

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 3, 2026
ai-agentsshellbashnodeapi

Works with

  • cli
  • api
  • mcp

Security analysis

A100/100

Scanned October 6, 2026

npx -y skills add bislink360/styled-markdown --skill styled-markdown-reader --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Styled Markdown Reader?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Styled Markdown Reader
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/bislink360-styled-markdown-reader/badge)](https://www.skillsdirectory.com/skills/bislink360-styled-markdown-reader)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: styled-markdown-reader
description: Read and query Styled Markdown (.smd) files token-efficiently, focusing only on meaningful content. Use this skill whenever you need information from a .smd file — answering questions about a spec/PRD/ADR/runbook/design doc, implementing what it describes, summarizing it, reviewing it, or checking its tasks, decisions, risks, APIs or open questions — even if the user just says "the spec", "the doc" or "the plan" and the file ends in .smd. Use it instead of reading .smd files with Read/cat, which wastes tokens on styling, layout and human-only content.
---

# Reading Styled Markdown (.smd) efficiently

`.smd` documents mix three kinds of content:

1. **Presentation:** colors, badges, layout.
2. **Human context:** background, research, history.
3. **What you need:** requirements, constraints, decisions, APIs, tasks.

The bundled CLI strips the first two and lets you pull only the sections you need.

```bash
node <this-skill-dir>/scripts/smd.cjs <command> …    # or `smd` if on PATH; Node 18+, no install
```

## Workflow

1. **`smd outline FILE`** (≈100–300 tokens) shows the title, status, summary, and every section with its line range and token cost. It also flags open tasks, decisions, risks, APIs and `AGENT INSTRUCTIONS`. The summary alone often answers the question.
2. **Read only what the task needs:**
   - Full agent view is small (≲ 2,000 tokens, shown on the outline's first line): run `smd agent FILE` once.
   - Specific question: run `smd agent FILE --section "Heading" [--section …]`. This matches heading text or id, includes subsections, and always appends `:::agent` instructions from elsewhere in the file.
   - Overview of a large doc: add `--brief`. It condenses diagrams, long code, `:::details` and completed tasks into pointers with line numbers.
   - Overview within a fixed budget: `smd agent FILE --max-tokens 2000`. It condenses as `--brief`, then leaves out the least important sections, never agent instructions or sections you asked for with `--section`.
3. **Related documents:** if the front matter lists `related:`, run `smd outline FILE --related`. It adds each related doc's title, status, summary and agent-view cost. Open a related doc (outline, then sections) only when the question needs it.
4. **Open raw lines only to edit.** Headings in the agent view carry `[L42]` line references. Read just that range with offset/limit, never the whole file. For writing or restructuring, use the `styled-markdown-writer` skill.

Across many documents:
- `smd index DIR` (or a committed catalog JSON) lists every document with title, summary, status, owners, tags, token costs (`tokens.agent`), sections (`id`, zero-based `line`/`endLine`, `tokens`) and counts of open tasks, decisions, risks, questions and APIs. Use it to pick which documents to read, then `smd outline` or `smd agent FILE --section "ID"` on those only.
- `smd tasks DIR` lists open tasks with priority, owner and due date, overdue first (`--mine @name` filters by owner).
- `smd risks DIR` is the risk register: every `:::risk` with its score (impact × likelihood, 1–16; `medium?` marks a level that was not set), owner, status, location and one-line mitigation, highest first, then an impact × likelihood matrix. Closed risks are left out unless `--all`; filter with `--status open,accepted` or `--owner @name`; `--json` for structured output.
- `smd query "SELECTOR" DIR` prints only the matching blocks in the agent view: `decision[status=accepted]`, `risk[impact>=high][status!=closed]`, `api[method=POST]`, `question`, `task[owner=@me][done=false]`, `heading[level=2]`. Commas combine selectors. Add `--titles` for one line per block, `--json` for structured output. Exit code 1 means no match.
- `smd decisions DIR --status accepted` lists the binding decisions across documents, one line each (date, title, owner, file:line, document › section), newest first; superseded and rejected ones are labelled. `--status open` lists decisions still to make, `--json` gives structured output.
- `smd meta FILE --no-diagnostics` gives JSON (outline, tasks, decisions, risks, agent blocks).

**MCP tools available?** If the `smd` MCP server is registered (tools `outline`, `section`, `agent`, `tasks`, `query`, `validate`), follow the same workflow with the tools instead of the shell: `outline` first, then `section` with the headings you need. Paths are relative to the server's root folder.

Catching up on a changed document:
- `smd diff FILE --since REF` (a commit, branch or tag such as `HEAD~3` or `main`) prints only what changed since then: front-matter changes, then each changed, renamed or added section in the agent view with `[L42]` refs into the current file, then removed headings. Use it instead of rereading a document you've already read. `smd diff DIR --since REF` covers every `.smd` file below, including new and deleted ones; `smd diff OLD.smd NEW.smd` compares two files.

## What the agent view means

| You see | Meaning |
|---|---|
| `<agent-instructions>` | Constraints written for you. Follow them for any work the document covers. |
| `<danger>` / `<warning>` | Hard constraint / important caveat |
| `<question>` | Unresolved. Don't pick an answer yourself; use the fallback in the agent instructions, or ask. |
| `<decision status="accepted">` | Binding. `proposed` isn't decided yet; `rejected`/`superseded` means don't do it. |
| `<risk impact=… likelihood=…>` | Design around it or test for it |
| `[risk matrix: …]` | A grid of the document's risks for people; the risks themselves are the `<risk>` blocks |
| `API POST /v1/x — …` | Endpoint definition; the following lines describe it |
| `<glossary>` … `</glossary>` | The document's defined terms and abbreviations, listed once; the text uses them as written (not expanded) |
| `<changelog>` with `## 1.2.0 (2026-03-01)` lines | Release history, newest first: each line is a version and its release date, followed by what changed in it |
| `<quote author="…" source="…" cite="…">` | A quotation: the words are the author's, not the document's own claims |
| `<figure id="fig-x"> Figure 2: caption`, `Figure 2 (fig-x)` | A numbered figure (or Table/Listing) and a reference to it; the id in parentheses names the `<figure>` meant |
| front matter `status:` | `approved` is authoritative, `draft`/`review` is tentative, `deprecated`/`archived` is history |
| front matter `lang:` | The language the document is written in. It only changes labels in rendered HTML; the agent view's labels stay English |
| `[P1]`, `@name`, `(due …, OVERDUE)` | Task priority, owner, due date |
| Values such as a version in the text | The source may write them as `{{version}}`, a front matter variable the view fills in. To change one everywhere, edit the front matter key, not the `[L…]` line. |
| `[^1]` … `[^1]: text` | A footnote reference and its definition, as written. In a `--section` excerpt, `Footnotes referenced above:` lists the definitions it needs. |
| `[code: path lines a-b …]` | Real source embedded by the doc. Read that file range if you need it (or rerun with `--embed`). |
| `<included file="shared/terms.smd" section="…">…</included>` | Text included from another document, part of this one. `[L…]` refs inside point into that file, so edit it there. |
| `[include: shared/terms.smd § Pricing — …]` | An include that wasn't expanded (`--no-includes`, or it can't be read). Run `smd agent shared/terms.smd --section "Pricing"` if you need it. |
| `[diagram: …]`, `[details: … omitted]` | Condensed by `--brief`. Read the given lines if you need them. |
| `[section omitted: ## X, L90-L128, ≈231 tokens — smd agent …]` | Left out by `--max-tokens`. Run the given command if the question needs that section. |

**No Node.js available?** Read the front matter and headings first (for example the first 20 lines, then search for `^## `), then read only the relevant line ranges. Skip `:::human` blocks and sections whose heading ends in `{agent=skip}`, and always read the `:::agent` block.

`:::human` blocks and `## … {agent=skip}` sections are left out on purpose. Use `--include-human` only when the task is specifically about that content (e.g. proofreading the background section).

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…