Universal guardrails loaded by every agent. Defines Verify Before Reporting (VBR), Write-Ahead Log (WAL), and the security baseline. Always-on, role-independent.
The English summary is being prepared. Showing the original description.
Use when: analysing a project's architecture, structure, and infrastructure health from the System perspective.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Evaluates the structural and architectural health of a codebase. Assigns a score from 0.0 to 1.0 across three dimensions.
Complexity — Are individual files understandable, and how much surrounding context does a change pull in?
Cohesion — Are responsibilities well-grouped, and is the module graph actually acyclic?
Infrastructure — Is the project properly configured?
A pure JS/Node module (pipelines/deploy/lib/dep-graph.js, no TypeScript compiler API, no tree-sitter, no native/compiled dependency) parses a project's .ts/.tsx/.js/.jsx files with regex-based specifier extraction (import/export ... from, dynamic import(), and require()), resolves relative specifiers to files inside the project, and builds a module-level import graph. Bare/package specifiers (e.g. react, node:fs) are external and excluded from the graph — only project-internal edges count toward cycles and coupling. The engine reports two real metrics per scan: dependency cycles (with the modules involved) and fan-in/fan-out coupling per module. Python and other non-JS/TS languages are not yet covered.
This is a separate implementation from the ticket-dependency-cycle check the task-tracking CLI uses internally — that one walks ticket ids, not code imports, and the two are never conflated.
On tiers where Graphify is available, scan-sys checks for an already-generated .graphify/<project>/graphify-out/graph.json before running its own source scan. Graphify produces a richer, real call/import graph than dep-graph.js's own regex-based extraction; when the file is present and parses as a valid Graphify graph, its imports_from edges (file-to-file import relations — distinct from Graphify's symbol-level imports/contains/calls edges) are used to build the same module-level import graph shape, and cycles/coupling are computed from that instead.
Graphify is optional and derived, never canonical — running it is a separate, explicit step (npm run graph:generate), and its absence is never an error. When no graph.json exists for a project — whether Graphify was never run, or the tier doesn't ship Graphify at all — scan-sys falls back to dep-graph.js's own source scan unconditionally, on every tier. This preference check happens fresh on every scan; a stale graph.json (regenerated less recently than the source it describes) is still preferred over a fresh source scan, since npm run graph:refresh <project> is how a project keeps its graph current, not scan-sys.
sys_score = (complexity + cohesion + infrastructure) / 3
Score interpretation:
| Finding | Priority |
|---|---|
| Source files > 300 lines (>3 files) | high |
| Source files > 300 lines (≤3 files) | medium |
| Modules with fan-out > 10 internal dependencies | medium |
| Directories > 20 source files | medium |
| Import cycles found (>3 cycles) | high |
| Import cycles found (≤3 cycles) | medium |
| tsconfig.json missing (TS project) | high |
When performing a manual SYS analysis:
strict: true is set; mark TypeScript N/A if no .ts files foundOutput: a ranked list of structural issues, each with the file or directory, the dimension it violates, and a recommended remediation.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Universal guardrails loaded by every agent. Defines Verify Before Reporting (VBR), Write-Ahead Log (WAL), and the security baseline. Always-on, role-independent.
The English summary is being prepared. Showing the original description.
Use when: architecture mode, architect this, ADR, C4, PlantUML, system boundary, design decision, PRD gap, high ambiguity, multiple technical approaches, security architecture, data architecture, integration risk, implementability gap, story ticket, or epic ticket.
The English summary is being prepared. Showing the original description.
Use when: assumptions audit, audit assumptions, check for hidden assumptions, plan/ticket has ambiguous scope edges, pre-flight before finalizing a ticket, unstated assumptions, or 'what am I assuming'. Surfaces unstated assumptions, ambiguous scope edges, and untested preconditions in a finished plan/ticket/ADR before it is handed to Builder. Optional pass — Architect judges when to apply it; not a mandatory gate on every ticket.
The English summary is being prepared. Showing the original description.
Use when: Tester needs UI state evidence for VBR, or Builder needs to verify an integration wire is observable end-to-end. Powered by agent-browser MCP — token-efficient browser automation (200–400 tokens/page).
The English summary is being prepared. Showing the original description.
Use when drafting a bug or defect ticket, reviewing one someone else wrote, or deciding whether a reported problem is ready to file. Keeps what the reporter actually saw separate from what the agent later found out, so a reader can tell which lines are testimony and which are collected proof. Trigger phrases: 'file a bug', 'write up this defect', 'triage this report', 'is this ticket ready to file', 'what did the reporter actually see'.
The English summary is being prepared. Showing the original description.
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
The English summary is being prepared. Showing the original description.