---
name: markdownto-timeline
description: Create or revise Markdown To timelines with accurate dated events and a clear narrative.
---
# Markdown To timeline
## Contract and workflow
Read `mdto spec timeline` (or the adjacent `SPEC.md` in a checkout) and the
[shared conventions](https://markdownto.ai/specs/conventions.md) before authoring or
repairing content. Outside a checkout, use the [published spec](https://markdownto.ai/specs/timeline.md).
This skill accompanies `[email protected]`. The spec and its fixtures govern conformance;
editorial advice below is non-normative and should adapt to the user's brief.
If the source declares another version, obtain its matching contract before changing it.
Use `markdownto: [email protected]`. Every level-2 heading begins with a real full date and
a title, as `## YYYY-MM-DD — Title`. Details follow the entry; empty details are legal.
An optional leading title is allowed; other heading levels and pre-entry detail are not.
Document order is preserved, so sorting an existing timeline is an editorial change.
## Content quality
Choose events that explain a change, not merely populate dates. State what happened in
the title and why it matters in the details, linking sources where appropriate. Preserve
intentional reverse chronology. Do not convert “sometime in 1998” into an invented full
date: resolve the date or explain the format limitation and keep the uncertainty in
source notes. Separate contemporaneous facts from later interpretation.
## Check and deliver
Validate the file with `mdto validate <path>` before editing existing content and again
after changes. Read diagnostics against the spec's rationale; preserve meaning when
repairing syntax. Prefer spec-owned verbs for edits they support, checking their current
`--help`; otherwise make a focused source edit, preserving unrelated content and IDs.
Render with `mdto render <path>` and inspect the result when available. Validation checks
structure, not editorial quality: review the content against the user's purpose as well.
Without the CLI, use the contract and examples and report that validation was not run.
Deliver the Markdown source and any requested artifacts, stating what was actually checked.
Give this guide to your agent, or read it as an author. It covers workflow and editorial judgment; the specification defines conformance.
Contract and workflow
Read mdto spec timeline (or the adjacent SPEC.md in a checkout) and the shared conventions before authoring or repairing content. Outside a checkout, use the published spec. This skill accompanies [email protected]. The spec and its fixtures govern conformance; editorial advice below is non-normative and should adapt to the user's brief. If the source declares another version, obtain its matching contract before changing it.
Use markdownto: [email protected]. Every level-2 heading begins with a real full date and a title, as ## YYYY-MM-DD — Title. Details follow the entry; empty details are legal. An optional leading title is allowed; other heading levels and pre-entry detail are not. Document order is preserved, so sorting an existing timeline is an editorial change.
Content quality
Choose events that explain a change, not merely populate dates. State what happened in the title and why it matters in the details, linking sources where appropriate. Preserve intentional reverse chronology. Do not convert “sometime in 1998” into an invented full date: resolve the date or explain the format limitation and keep the uncertainty in source notes. Separate contemporaneous facts from later interpretation.
Check and deliver
Validate the file with mdto validate <path> before editing existing content and again after changes. Read diagnostics against the spec's rationale; preserve meaning when repairing syntax. Prefer spec-owned verbs for edits they support, checking their current --help; otherwise make a focused source edit, preserving unrelated content and IDs. Render with mdto render <path> and inspect the result when available. Validation checks structure, not editorial quality: review the content against the user's purpose as well. Without the CLI, use the contract and examples and report that validation was not run. Deliver the Markdown source and any requested artifacts, stating what was actually checked.