Ontoly Software Graph
Use this skill when a coding agent needs graph-backed understanding of a TypeScript repository. Ontoly is the source of truth; the skill only teaches the workflow.
When to Use
- Explain repository architecture or package/module topology
- Trace a route, controller, service, function, or dependency path
- Find services, controllers, providers, modules, routes, configuration, or environment variables
- Estimate impact before refactoring or deleting code
- Audit unresolved imports, circular dependencies, dead code, semantic coverage, or graph quality
- Produce onboarding, documentation, or architecture-review notes with deterministic evidence
Workflow
Check whether an Ontoly graph already exists: .ontoly/, SoftwareGraph.json, diagnostics.json, validation reports, graph hash, or MCP setup.
If the graph is missing and local analysis is allowed, run:
ontoly build .
Inspect graph health before answering: diagnostics, graph hash, semantic coverage, trust or quality score, framework detection, and build timestamp.
Prefer Ontoly CLI or MCP capabilities over repository search for graph-answerable questions.
Search source files only when Ontoly cannot answer, the graph is stale or incomplete, or the user explicitly asks for file-level verification.
Always cite graph evidence: node IDs, edge types, file paths, source locations, diagnostics, framework analyzer output, and confidence.
Capability Map
- Architecture review:
ExplainArchitecture
- Dependency analysis:
FindDependencies
- Impact analysis:
ImpactAnalysis
- Request tracing:
TraceExecution
- Configuration analysis:
FindConfigurationUsage
- Framework analysis:
FrameworkReport
- Dead-code review:
FindDeadCode
Response Pattern
Return the direct answer first, then evidence:
AuthController handles authentication.
Evidence:
- node: class:src/auth/auth.controller.ts:AuthController
- route edges: HANDLES POST /login and POST /logout
- dependency edges: USES AuthService and JwtService
Confidence: high, because the graph has controller, route, and dependency edges with source locations.
Fallbacks
- If the graph is missing, build it first when allowed.
- If validation fails, report the graph issue and verify only the affected area with source search.
- If several nodes match, show candidates with package/module context.
- If nothing matches, return
NOT_FOUND with the closest graph evidence instead of inventing an answer.
1---2name: ontoly-software-graph3description: Use Ontoly's deterministic Software Graph and MCP capabilities for repository architecture, request tracing, dependency analysis, configuration lookup, and impact analysis before falling back to source search.4---5
6# Ontoly Software Graph
7
8Use this skill when a coding agent needs graph-backed understanding of a TypeScript repository. Ontoly is the source of truth; the skill only teaches the workflow.
9
10## When to Use
11
12- Explain repository architecture or package/module topology
13- Trace a route, controller, service, function, or dependency path
14- Find services, controllers, providers, modules, routes, configuration, or environment variables
15- Estimate impact before refactoring or deleting code
16- Audit unresolved imports, circular dependencies, dead code, semantic coverage, or graph quality
17- Produce onboarding, documentation, or architecture-review notes with deterministic evidence
18
19## Workflow
20
211. Check whether an Ontoly graph already exists: `.ontoly/`, `SoftwareGraph.json`, `diagnostics.json`, validation reports, graph hash, or MCP setup.
222. If the graph is missing and local analysis is allowed, run:
23
24 ```bash
25 ontoly build .
26 ```
27
283. Inspect graph health before answering: diagnostics, graph hash, semantic coverage, trust or quality score, framework detection, and build timestamp.
294. Prefer Ontoly CLI or MCP capabilities over repository search for graph-answerable questions.
305. Search source files only when Ontoly cannot answer, the graph is stale or incomplete, or the user explicitly asks for file-level verification.
316. Always cite graph evidence: node IDs, edge types, file paths, source locations, diagnostics, framework analyzer output, and confidence.
32
33## Capability Map
34
35- Architecture review: `ExplainArchitecture`
36- Dependency analysis: `FindDependencies`
37- Impact analysis: `ImpactAnalysis`
38- Request tracing: `TraceExecution`
39- Configuration analysis: `FindConfigurationUsage`
40- Framework analysis: `FrameworkReport`
41- Dead-code review: `FindDeadCode`
42
43## Response Pattern
44
45Return the direct answer first, then evidence:
46
47```text
48AuthController handles authentication.
49
50Evidence:
51- node: class:src/auth/auth.controller.ts:AuthController
52- route edges: HANDLES POST /login and POST /logout
53- dependency edges: USES AuthService and JwtService
54
55Confidence: high, because the graph has controller, route, and dependency edges with source locations.
56```
57
58## Fallbacks
59
60- If the graph is missing, build it first when allowed.
61- If validation fails, report the graph issue and verify only the affected area with source search.
62- If several nodes match, show candidates with package/module context.
63- If nothing matches, return `NOT_FOUND` with the closest graph evidence instead of inventing an answer.
64
majiayu000