• HomeHomePurpose, practised daily, in tools that show their work.
  • PageToolsA sentence, a table, a list of what you owe, an hour at an instrument. Each of those deserves a tool that shows its working, and none of them needs to be the same program.
  • PageSolutionsReadiness you can run, agents that stop for review, and every product in one reading: what Sylrohir solves, who it is for, and what it will not do.
  • PagePricingOne-time licences. Buy a version once, get every update to it, and upgrade to the next one only if you want it.
  • PageAboutWhy Sylrohir exists, what its tools are named for, how it is built, and what it does not claim.

Cookie settings

The site keeps only what it needs to remember your choices. Measuring how it is read is optional, and off until you turn it on.

  • Essential

    Your theme, colour, feel and pane arrangement, and this answer. Kept on this device for this site, and nothing in them identifies you.

  • Analytics

    Counts visits and how pages are read, to learn what is useful. Sent to Google Analytics.

Done should be a result, not a claim.

Conventions wear away, and faster when agents do the work. Agreements drift from the repositories they describe, evidence turns into anecdote, and done becomes something somebody says. Sylrohir writes intent, readiness, acceptance and evidence down as contracts that a person and a machine can both check.

What it solves

  • acceptance verify

    Readiness is a command, not an opinion.

    Every criterion a product declares is evaluated, each verdict cites what it checked, and the command fails until every criterion passes. Ready is something you run rather than something you are told.

  • loop

    Agents do the work. People keep the keys.

    An agent works inside a bounded loop with a cap on its cycles. The loop fails closed, stops at ready for human review, and never pushes or merges on its own.

  • status

    Every product, in one reading.

    One index lists every product you govern, with its readiness, acceptance and loop state. It fails while anything is failing or cannot be read, because an unknown is never counted as healthy.

  • readiness validate

    Conventions that hold.

    The documents a product's lane requires, their sections, and the identifiers they share are checked in the repository itself. When they part ways the check fails, instead of the drift turning up months later.

  • acceptance verify --record

    Review from evidence, not assurances.

    A verification can be kept as a receipt: the commit it observed, the versions it ran under, and every verdict with its citations. A reviewer reads what was checked rather than being told it was fine.

Who it is for

  • Developers and founders

    Directing AI-assisted work across one repository or many, and needing to know what is actually finished.

  • Teams

    Adopting the methodology through CI and automation, without taking on anyone else's branding along with it.

  • Reviewers

    Deciding whether work is ready from cited, reproducible verdicts rather than from a summary.

  • Coding agents

    Doing bounded work while the gates, the stopping conditions and the evidence are judged by something other than the agent.

What it will not do

It does not do the work itself. The body of a loop is run by an agent you choose; the engine judges the gates, the stopping conditions and the evidence.

It does not push or merge. Nothing leaves a loop without a person deciding that it should.

It is not an office suite. The tools that share its name are separate products with purposes of their own.

What it does promise is narrower, and checkable: when it says something is done, there is a command you can run that says so too.