Archify for DeepSeek Harness
A repository can be understandable to the people who built it and still be opaque to the next engineer. The archify DeepSeek Harness plugin is a community integration that makes the Archify filesystem skill available inside DSH. It can guide an architecture or data-flow diagram workflow from codebase evidence or a plain-language system description. Rendering, validation, preview, and export depend on the Archify toolchain available in the environment, and the generated topology still needs to be checked against the system it represents.
From Repo to Diagram: What Archify Generates
Plugin quick facts
| Item | Detail |
|---|---|
| Adapter | @tt-a1i/archify-dsh@0.1.0 |
| Publisher | tt-a1i / Archify |
| DSH form | Filesystem skill provider, not a native render service |
| Runtime | Node.js ^22.19.0 or 24+ for the verified adapter release |
| First artifact | A narrow repository or system diagram with editable source |
| Documentation reviewed | September 16, 2026 |
Setup and first check
Add the pinned adapter to the profile that will analyze the repository:
dsh plugin --profile web add @tt-a1i/archify-dsh@0.1.0
dsh --profile web --dump-configUse a disposable checkout for the first run. Request one diagram with a small component count and one named data path, then confirm that the Archify skill is present and that the installed toolchain can validate and export the chosen format. The adapter supplies skill instructions; rendering still depends on the Archify components available in the same environment.
The adapter supplies instructions as a filesystem skill; it does not add host-native render, validate, or delivery tools to DeepSeek Harness. The result therefore depends on which Archify components are installed and callable in the same environment. Confirm the available commands and output formats before choosing a delivery workflow.
For a repository map, ask for a small number of core components, one primary path, external dependencies, and trust boundaries. For a process view, define the participants, handoffs, exceptions, and approval points that matter to the decision. A crowded diagram is not more accurate. It usually makes the key path harder to inspect.
Treat every generated diagram as a review artifact. It can make a proposed structure easier to discuss, but it does not inspect live traffic, prove ownership, or establish that a deployment is safe.
Installing Archify as a DeepSeek Harness Skill
The DSH adapter is a community package, not an official DeepSeek product. Node.js ^22.19.0 or >=24.0.0 is required. Adapter version 0.1.0 pairs with developer-preview @deepseek-ai/dsh@0.1.0-rc.6 and carries Archify Skill 2.14.0. That compatibility statement is experimental rather than a promise across later DSH releases.
Install version 0.1.0 into the profile you intend to use:
dsh plugin --profile web add @tt-a1i/archify-dsh@0.1.0Do not substitute the repository root for the package name. The root is not a DSH bundle. After installation, use the skill by asking it to map the current repository or create a specific diagram type. The adapter adds a filesystem skill provider. It does not add native render tools, a custom web client, background services, telemetry, credential handling, or install hooks.
Before bringing it into a production repository, test the same command in a disposable checkout and confirm that the installed DSH version matches the adapter's supported range. Pinning the package keeps a later repository change from silently altering an existing profile.
Feeding It a Repo vs a Plain-Text System Description
Repository-driven generation starts with files that can support an authored topology. Ask the agent to identify entry points, main modules, stores, external systems, and a representative execution route. This mode is appropriate when the diagram will support a code review, onboarding session, or architecture change.
Description-driven generation does not require a repository. A concise prompt such as “Browser to API to Redis cache to PostgreSQL fallback” can guide a diagram for a proposed system, workshop note, or design alternative that does not yet exist in code.
The distinction should stay visible in the review:
- A repository map claims to represent inspected source at a particular revision.
- A description map represents the architecture the author supplied.
- Neither proves live traffic, deployment state, ownership, performance, or security.
For change review, compare a baseline with a candidate. Keep additions, removals, moved nodes, changed labels, and rerouted relationships explicit instead of asking the diagram to predict whether the change is safe.
How Validation and Export Actually Work
The available validation and export steps come from the installed Archify toolchain, not from native DSH tools registered by the adapter. Check the toolchain version, supported formats, and local prerequisites before relying on a preview or export path.
A disciplined export loop looks like this:
- Generate a narrow diagram from a repository or description.
- Run the validation available in the installed toolchain.
- Inspect whether components and relationships match the intended system.
- Export only to a format the current toolchain supports.
- Keep the editable source beside the artifact when the workflow provides one.
Toolchain validation may establish structural consistency. It cannot establish that the architecture description is complete or that a proposed deployment will work. A maintainer who knows the system should approve the topology before it becomes durable project documentation.
Frequently Asked Questions
Is Archify an official DeepSeek Harness feature?
No. The DSH adapter is a community integration that installs the Archify skill into a DeepSeek Harness profile. It does not imply endorsement or native ownership by DeepSeek.
Does Archify need a repository to create a diagram?
No. It can work from a plain-text system description. A repository is useful when the output must be grounded in current source files rather than a proposed or manually described design.
Does a validated diagram prove the system is correct?
No. Any available validation is a toolchain-specific structural check. A human still needs to confirm that the diagram matches the real or intended system.
Add a Visual Checkpoint to Your Harness Evaluation
Choose one architecture decision that is currently hard to explain, then generate both a source-backed map and a description-backed map. Compare their differences before treating either as project documentation. Review Verdent integrations to evaluate where a diagram skill belongs beside permissions, plugins, and repository safety.