菜单
Investigate services and assess change impact with ctx-cli — one-call service investigation (deps, owners, runbooks), blast radius, incident response, dependency/package safety checks, package migration, and business-flow understanding.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | ctx-investigate |
| description | Investigate services and assess change impact with ctx-cli — one-call service investigation (deps, owners, runbooks), blast radius, incident response, dependency/package safety checks, package migration, and business-flow understanding. |
| allowed-tools | Bash(ctx-cli:*), Bash(curl:*) |
Prerequisites: requires
ctx-cliinstalled and authenticated. If it isn't, or you haven't run the once-per-session version check, see thectxskill first.
These are the tier-1 composites — each bundles several primitive calls into one
answer. Prefer them when one matches your intent; drop to the primitives in
ctx-search only when no composite covers the question or you
need a specific narrow slice.
| Intent | Tool | Notes |
|---|---|---|
| "How does service X work / what does it depend on / who owns it?" | investigate_service -p serviceName=<name> | Returns service, deps, dependents, ownership (team/oncall/slack/pagerduty), ADRs, runbooks, flows, incidents, Jira/GitLab issues in one call. Supports partial name match. |
| "What breaks if I change X?" | blast_radius -p target=<name> | Param is target (not serviceName). Returns risk score (LOW/MEDIUM/HIGH), transitive dependents, affected flows, teams-to-notify, recommendations. |
| "We're seeing errors in X — runbook + escalation" | incident_response -p service=<name> | Param is service (not serviceName). Optional symptom=<text> finds similar past incidents. |
| "Is package X safe / should I use it?" | dependency_check -p packageName=<name> | Vulnerabilities + upgrade history + migration examples. Returns [] on tenants where package data isn't indexed. |
| "How do I migrate from X to Y?" | code_migration -p fromPackage=<pkg> -p toPackage=<pkg> | Params are fromPackage / toPackage. Migration status, examples from teams who've done it. |
| "How does the business flow work?" | understand_flow -p flowName=<name> | Flow steps, services involved, related ADRs and incidents. Returns [] on tenants without indexed flows. |
| "What's the context for this file?" | get_file_context -p filepath=<path> | Param is filepath (one word, lowercase). Returns ADRs, incidents, security patterns, experts, blast radius for the file's service. Requires git-insights-analyzer to have run on the repo — returns [] on tenants where it hasn't. |
# One-call investigation of a service (deps, owners, runbooks, incidents…)
ctx-cli mcp call investigate_service -p serviceName="CTX API Server" -o json
# What breaks if I change this service?
ctx-cli mcp call blast_radius -p target="CTX API Server" -o json
# Runbook + escalation for an active issue, with similar past incidents
ctx-cli mcp call incident_response -p service="CTX API Server" -p symptom="elevated 5xx" -o json
# Is this package safe to adopt?
ctx-cli mcp call dependency_check -p packageName="lodash" -o json
# How do teams migrate off package X?
ctx-cli mcp call code_migration -p fromPackage="moment" -p toPackage="date-fns" -o json
The composites are inconsistent about their primary parameter name — confirm with
ctx-cli mcp describe <tool> whenever a call errors:
investigate_service takes serviceName.blast_radius takes target (not serviceName).incident_response takes service (not serviceName).code_migration takes fromPackage / toPackage (not from / to).get_file_context takes filepath (one word, lowercase — not filePath).[]Several composites depend on tenant-specific indexers having run:
understand_flow / flow data → returns [] on tenants without indexed flows.dependency_check → returns [] where package data isn't indexed.get_file_context → requires git-insights-analyzer; returns [] otherwise.When a composite comes back empty, fall back to the graph primitives in
ctx-search (find_entities → traverse_edges) — graph
adjacency still captures the underlying relationships even when the composite's
enriched view isn't available.
Onboard a Context Engine tenant: confirm a model + embedder are configured, connect data sources (GitHub/GitLab/Jira/… repos + credentials) and ingest, then immediately show what CTX understood about each repo (what it is, stack, what it does, what it talks to) with a live semantic-search demo and an invitation to ask questions — and kick off the slower enrichment agents that build the service/dependency graph as a follow-on. Use for "set up / onboard / get started with CTX", "connect repos", or "what does CTX know about my system".
Set up and route Context Engine CLI (ctx-cli) work — install, authenticate, check version, discover tools, and pick the right tool by intent. Start here for anything involving ctx-cli or the Context Engine; it routes to the ctx-onboarding, ctx-search, ctx-security, ctx-guidelines, and ctx-investigate skills.
Apply and audit a team's coding standards with ctx-cli — fetch managed coaching guidelines to write or review code to spec, and inspect discovered AI-guideline files (CLAUDE.md, .cursorrules, AGENTS.md) for coverage and cross-repo drift.
Search a team's codebase and knowledge graph with ctx-cli — find where code is implemented (code_search), find entities by natural-language query, and traverse graph relationships between services, libraries, and code. Use to locate source or explore what an entity connects to.
Triage and resolve security findings with ctx-cli — the CVE and SAST resolution inboxes, each row carrying a ready-to-apply fix diff or advisory. Use for any security search or CVE/SAST remediation work.
Set up and route Context Engine CLI (ctx-cli) work — install, authenticate, check version, discover tools, and pick the right tool by intent. Start here for anything involving ctx-cli or the Context Engine; it routes to the ctx-search, ctx-security, ctx-guidelines, and ctx-investigate skills.