Seiso makes you assign a purpose to each document
Seiso asks you to decide whether a page is a how-to, a reference, an architecture decision, or another supported document kind. Its convention says a fact should have one home, with other pages linking there. That is useful when an agent repeats the same configuration advice across several files and later updates only one copy. Adopting it means accepting a documentation structure as well as a command.
Our checkout contained 433 files and about 29,003 source lines. GitHub identifies the implementation as Rust, while our lab exercised its Python packaging path. The distinction matters because the README also offers Cargo and npm distribution. A team should choose the route it will actually deploy and verify that route, rather than treat our package result as proof that every distribution behaves identically.
What happened when we ran it
Our run installed Seiso commit 5bae44f in 81 seconds, adding 36 packages and occupying 43 MB. The build step passed in 1 second. On 2026-10-15, the test step failed with exit 1 after 6 seconds: pytest reported 168 passed, 21 failed, and 1 collection/setup error out of 190. The container had 3 CPUs, 8 GB of RAM, Python 3.12 on Debian, no secrets, and no elevated privileges.
The log tail includes npm launcher cases raising TypeError because a value expected to be a path was None. Another launcher case raised UnboundLocalError for result. Installation-verification cases also failed assertions about diagnostics and parse output. The 168 passing tests are useful evidence, but those failures prevent a clean result. The excerpt does not establish the underlying reason for the missing path values, so blaming a particular system package would go beyond the evidence.
Pip-audit found 0 known vulnerabilities. Our scan found 5 CI workflow files and a tests directory, with no Dockerfile. These are useful maintenance signals, but they don't turn the failing command green. The 43 MB installed footprint makes a local trial a modest disk commitment. It says nothing about the accuracy of Seiso's judgment on your own documentation, which needs a separate review of its diagnostics.
Stable checks are narrower than the convention
Release v0.4.0 retains a small default rule set covering document kinds, links, and suppressions. Other checks require the preview option. The README warns that preview rules can produce false positives and says to keep them out of CI gates. You can follow the written convention without adopting every experimental check, which is a sensible way to evaluate whether the rules improve a real repository.
The 81-second install was the easy part of adoption. seiso init generates kind mappings and exclusions in seiso.toml, but the README tells you to review them. Someone still has to decide which page owns a duplicated fact and whether a design explanation belongs in an ADR. Seiso can identify a decision that needs attention. It cannot supply the architectural judgment merely because an agent can consume the diagnostic.
A Claude Code hook misses shell-written files
The integration guide connects Seiso to Claude Code's Write and Edit events. It checks a saved Markdown file and returns feedback to the agent. The guide explicitly says the hook runs after the edit and cannot undo it. Files created through shell commands or other processes fall outside that matcher. Run a broader check before accepting a change that crosses those boundaries.
Our 36-package Python installation doesn't remove the separate requirements of other integration paths. The documented pre-commit integration builds the CLI through maturin and requires Rust. Supported PyPI and npm platforms have prebuilt binaries, while other platforms need a source route. Seiso doesn't require a hosted model credential for its local checks, so the main ongoing configuration is document policy and the automation around it.
Inherited configuration can check the wrong paths
The v0.4.0 release notes list an unresolved configuration limitation: patterns inherited from a parent resolve from the child's directory. Issue 40 shows a root pattern targeting docs/reference/** effectively looking under docs/docs/reference/ from a nested configuration. A reference page can consequently lose its assigned kind. That is a direct reason to delay adoption across nested workspaces until you inspect the effective file selection.
Our 21 failed tests should be kept separate from these documented product defects. Issue 74 describes a valid Markdown thematic break followed by labeled prose being mistaken for unclosed YAML frontmatter. The release still lists that limitation, and a related pull request remained open. A team with that document style should expect to review a false positive rather than assume all reported frontmatter errors are author mistakes.
October changes support a trial, with policy review
The last push was 2026-10-13, the date v0.4.0 shipped, and GitHub listed 18 open issues and PRs. The release added an agents document kind for instruction files, alongside a separately versioned convention. Recent activity includes a packaging-cache change and a proposed frontmatter fix. Taken together, those dates and issue updates show an actively changing tool, with acknowledged gaps that affect everyday documentation layouts.
I'd start Seiso on a reviewed folder, keep preview checks local, and inspect each proposed policy change alongside the prose. Our 168 passing tests justify investigating further, while the failed complete run argues against making it an immediate mandatory gate. Choose markdownlint-cli2 for ordinary Markdown formatting checks or Vale for configurable prose style. Choose Seiso when your recurring problem is conflicting document responsibilities, and somebody is willing to own those decisions.