A codebase becomes an architecture diagram. How should you check Archify’s output?
A review of the Archify 3.2.0 repository, source-evidence rules and finalize command, explaining interactive HTML output, source checks, automated validation and version changes.
What to consider
Pin the diagram to a code commit, require source-file ranges for key nodes, then check readability with a handover task. Archify is an open-source skill for coding agents that turns descriptions or repository evidence into standalone interactive HTML. The reviewed package is version 3.2.0 under the MIT license. Source references and automated checks help find errors but do not prove business completeness. We reviewed the README, authoring rules and CLI source; we did not install or run Archify.
Distinguish description-based and source-backed diagrams
Archify accepts a system description or repository material read by a coding agent. A description-based diagram suits planning, with connections derived from the supplied explanation. A diagram of an existing implementation needs source support. The README’s interactive demo does not prove that any repository will automatically yield a complete architecture map; results still depend on the files the agent reads.
The current package includes architecture and sequence diagrams, among other types, as well as one-page HTML explainers. Choose the type around the task: an architecture map can help a new developer find a feature, while a sequence diagram can explain request calls. Standalone HTML is convenient to share, but keep the candidate JSON and the associated code revision too.
Check nodes and connections against a fixed commit
The repository authoring rules require a full commit hash and a credential-free repository address, with source paths and line ranges for key elements. Evidence is checked against committed files; uncommitted changes cannot be presented as that commit’s contents. Start at an entry point and follow each call in the diagram to the code that actually reads or writes data.
For an “API writes to database” edge, locate the actual write operation; a database name in configuration is insufficient. If the code delegates work through a queue to another process, retain that step. Record missing and incorrect connections rather than checking only that each node name appears somewhere in the repository.
| What to check | Expected evidence |
|---|---|
| Feature entry point and its next call | The entry point and call site at the pinned commit |
| A database or file write | The code performing the write and its conditions |
| A planned connection that is not implemented | An explicit planned label, separate from existing behavior |
Use the documented command to inspect automated checks
The repository package.json specifies Node.js 18 or later. The command below follows the documented finalize syntax with placeholder paths. An agent must first write candidate.json according to the schema, and the script path must point to the installed package. We checked the command and source only; we did not execute it or produce an architecture diagram.
finalize runs validation, delivery and browser checks, stopping on failure and producing receipts. An automated pass establishes only those checks; visualReview may still be not-requested. Inspect the HTML for overlapping text and traceable connections, then ask someone unfamiliar with the module to locate an actual code path using it.
node /path/to/archify/bin/archify.mjs finalize architecture candidate.json architecture.html --repo-root /path/to/repo --quality showcase --jsonKeep diagram versions when the code changes
Use a known small code change as an update sample, such as adding a cache read or changing an error branch, then ask the agent to regenerate. Compare candidates to see whether obsolete edges disappeared and new branches have source support. Record the code commit and generation conditions so that overwriting a filename does not erase the explanation for a change.
Archify itself uses the MIT license. Model and third-party service terms depend on the agent setup. For an internal repository, choose material according to how the agent accesses data. Adopt the diagram for regular handovers only after it helps new developers find the right entry points and remains aligned after updates. This documentation review did not measure those outcomes.
Checked sources
The following sources support the project descriptions and reported facts. The analysis is by the site editors; claims from these sources are not presented as results from our own tests.