Mesteriis Architecture Map
Build a compact, verified architecture map from current files.
Workflow
- Read repo instructions and top-level dependency/build files.
- Identify entrypoints, layers, data flow, external integrations, and tests.
- Map dependency direction and boundary violations.
- Record uncertainty separately from verified facts.
- Keep the output short enough to guide implementation or review.
Graphify Route
When Graphify is exposed in the current environment and the task is about architecture, dependencies, call graphs, knowledge graphs, or repeated onboarding to a large codebase, use Graphify as the preferred Tier 2 knowledge-graph source.
Before building anything, check for existing state:
test -f graphify-out/graph.json && echo graph-ready
If graphify-out/graph.json exists, query it first for architecture,
dependency, and call-flow questions. Check whether relevant files changed after
the graph was built, or whether available Graphify metadata points at a
different root/scope. If freshness is uncertain, use the graph as a hypothesis
source and verify against files.
If no graph exists, initialize Graphify only when the map will benefit from a knowledge graph: broad architecture, dependency/call graph, repeated onboarding, large subsystem exploration, or multi-agent handoff. Prefer the narrowest useful scope:
graphify extract . --code-only
graphify extract <subdir> --code-only
Do not create graphify-out/ for tiny localized tasks. For read-only review,
security review, validation-critical work, or an explicit no-mutation request,
ask before creating Graphify state.
Treat Graphify output as an index, not as final proof. Verify important architecture claims against repository files, command output, or explicit user context before reporting them.
If Graphify is unavailable or not useful for the repository shape, fall back to
rg, git ls-files, targeted file reads, and top-level dependency/build files.
When Graphify state is created or reused, report whether it was existing, fresh, stale/uncertain, or newly generated.
Output
- repo shape
- main layers or bounded domains
- important entrypoints
- persistence/integration/config surfaces
- test and validation commands found
- risks and unknowns
- suggested next skill if applicable
Rule
Do not invent architecture. Every claim must come from files, commands, or explicit user-provided context.