Skip to content
Chelis docs

The Kiro dialect

c-earchin can ingest Kiro-style requirements.md files in addition to plain .ears sources. Kiro, the AWS spec-driven IDE, authors acceptance criteria in markdown with the EARS structural keywords bolded. c-earchin normalizes those lines into canonical EARS and lowers them through the same Deep pipeline used for .ears input, so a Kiro requirement becomes a chelis prove-able property with provenance back to the markdown line.

A runnable demo lives at references/kiro_example/.

Selecting the dialect

Section titled “Selecting the dialect”
InvocationParsed as
c-earchin translate spec.mdKiro (auto-detected from .md)
c-earchin translate spec.earsEARS (default)
c-earchin translate <any> --dialect kiroKiro (flag wins)
c-earchin translate <any> --dialect earsEARS (flag wins)
stdin (-)EARS unless --dialect kiro

The explicit --dialect flag always overrides the filename. EARS remains the default, so every existing .ears workflow is unchanged. --dialect is also accepted by c-earchin check. A .md source maps to a module the same way .ears does (requirements.md becomes CEarchin.Generated.Requirements).

Accepted subset

Section titled “Accepted subset”

A line is treated as a requirement when it carries an EARS shall predicate. For each such line, c-earchin:

  • strips markdown bold markers (**...**);
  • skips # headings, blank lines, and list bullets that do not themselves contain shall;
  • synthesizes a positional id REQ-001, REQ-002, and so on in document order;
  • recognizes the EARS patterns: ubiquitous (the <actor> shall ...), event-driven (WHEN ...), state-driven (WHILE ...), optional (WHERE ...), and unwanted (IF ... THEN ...);
  • rewrites each into the canonical, comma-delimited EARS form the classifier expects. For instance **WHEN** a tick arrives **the system shall** update becomes WHEN a tick arrives, the system shall update.

A short Kiro source looks like this:

## Requirement 1: Non-negative prices


**The Option Pricer** shall produce non-negative call prices.


## Requirement 2: Implied-volatility tolerance


**WHEN** market data arrives, **the system shall** keep the implied-volatility surface within tolerance.


## Requirement 3: Portfolio delta limit


**WHILE** the exchange is open, **the system shall** keep the portfolio delta at most the limit.


## Requirement 4: Order rejection


**IF** an order breaches the position limit, **THEN the order gateway shall** reject the order.

The headings are skipped. The four requirement lines become REQ-001 through REQ-004 in order.

Actors

Section titled “Actors”

The actor may be any the <actor> shall ..., not just the literal the system. Only the leading article is lowercased to the; the rest of the actor's source case is preserved, so **The Pricing Engine** shall ... becomes the Pricing Engine shall .... Arbitrary actors classify and resolve against the vocabulary exactly like .ears actors do.

Spans

Section titled “Spans”

Each requirement's span points at the visible text of its source line. Columns exclude leading whitespace and the leading bold marker, so explain and the spans manifest report the column of the first real character. A line beginning ** reports column 3, not the raw line length. In the demo, REQ-001 resolves to requirements.md:11:3.

Limitations

Section titled “Limitations”

These are deliberate and named rather than silently handled:

  • Positional ids only. REQ-00N is synthesized in encounter order. Any requirement ids Kiro itself emits, such as user-story numbering or 1.1, are not read or preserved.
  • Per-line scan. Surrounding Kiro document structure, such as user stories, nested acceptance-criteria sub-lists, and numbered or lettered lists, is not modeled. Only the individual EARS shall line is extracted, and a requirement must fit on one line. Unlike .ears, there are no continuation lines.
  • A line whose shall clause has no recognizable the <actor> is passed through unchanged and surfaces as a normal classifier error rather than being silently dropped.