Capability discovery

Capability Discovery

Discovers available capabilities in the user's environment for dynamic workflow adaptation.

Iron Law

DISCOVER BEFORE ASSUMING. Never hardcode tool availability. Always scan the environment first.

Assuming a tool exists leads to runtime failures. Assuming it doesn't leads to missing capabilities.

Discovery Process

Steps 1-5 are independent — execute ALL simultaneously with parallel tool calls.

Step 1: Scan Agents

Use Glob to find agent files, then Grep to extract descriptions:

• Glob: ".claude/agents/*.md" — project agents
• Glob: "plugins/*/agents/*.md" — plugin agents

Parse: source, name (filename without .md), description (from frontmatter).

Step 2: Scan Skills

• Glob: ".claude/skills/*/SKILL.md" — project skills
• Glob: "plugins/*/skills/*/SKILL.md" — plugin skills

Parse: source, name (parent directory), description (from frontmatter).

Step 3: Scan Commands

• Glob: ".claude/commands/*.md" — project commands
• Glob: "plugins/*/commands/*.md" — plugin commands

Parse: source, name (filename without .md), description (from frontmatter).

Step 4: Parse CLAUDE.md for Quality Commands

CLAUDE_MD=""
[ -f ".claude/CLAUDE.md" ] && CLAUDE_MD=".claude/CLAUDE.md"
[ -z "$CLAUDE_MD" ] && [ -f "CLAUDE.md" ] && CLAUDE_MD="CLAUDE.md"
[ -n "$CLAUDE_MD" ] && grep -E "(npm|pnpm|yarn|bun|ruff|pytest|go |cargo |make )" "$CLAUDE_MD" 2>/dev/null

Step 5: Detect Tech Stack

[ -f "package.json" ] && echo "node"
[ -f "tsconfig.json" ] && echo "typescript"
[ -f "pyproject.toml" ] && echo "python"
[ -f "Gemfile" ] && echo "ruby"
[ -f "go.mod" ] && echo "go"
[ -f "Cargo.toml" ] && echo "rust"
[ -f "Makefile" ] && echo "makefile"

Early Exit: Markdown-Only

If no tech stack files found and no quality commands in CLAUDE.md, report:

• Quality Commands: "No code-related quality commands applicable"
• Tech Stack: "Markdown-only project"
• Skip Step 6

Step 6: Discover Verification Capabilities

ls verify.sh scripts/verify* playwright.config.* cypress.config.* 2>/dev/null

Step 7: Discover LSP Capabilities

Pre-check: Read lsp.enabled from settings (default true). If false, skip this step and report all LSP features as "Disabled" in the output table.

Probe for available LSP code intelligence features. Find a representative source file in the project (use the first file matching the detected tech stack — e.g., .ts, .py, .go, .rs, .rb), then test each LSP operation against it.

LSP feature probes (run each, catch failures individually):

Operation	Test	Capability
documentSymbol	List symbols in the file	Symbol navigation
hover	Hover on first symbol (line 1, char 1)	Type info / docs
goToDefinition	Definition lookup on an import or reference	Definition tracing
findReferences	Find references to a symbol	Impact analysis
goToImplementation	Find implementations	Interface resolution

Diagnostics inference: LSP diagnostics are not a discrete operation to probe — they are reported by the language server when it processes a file. If documentSymbol succeeds, the LSP server is active and diagnostics are available. Record diagnostics as "Available" when documentSymbol succeeds, "Unavailable" otherwise.

Process:

1. Find a representative source file using Glob (consistent with Steps 1-3):

   • Glob: "**/*.ts" or "**/*.py" or "**/*.go" or "**/*.rs" or "**/*.rb" (match detected tech stack)
   • Use the first result as the probe target

2. For each operation, attempt an LSP call against the file. Record success or failure:

   • Success → feature is available
   • Error "no LSP server" → LSP not configured for this file type
   • Error/timeout → feature not supported by this server

3. Read lsp.timeout from settings (default 5000ms). If an operation doesn't respond within this timeout, mark it as unavailable.

4. Report results in the LSP Capabilities output table.

Graceful degradation: If no source files exist (markdown-only project) or no LSP server is configured, report "No LSP server available — using CLI-only analysis" and skip. This is not an error.

Output Format

### Agents Available
| Agent | Source | Description |
|-------|--------|-------------|

### Skills Available
| Skill | Source | Description |
|-------|--------|-------------|

### Quality Commands
| Command | Purpose | Source |
|---------|---------|--------|

### Tech Stack
- {language} ({indicator file})

### Verification Capabilities
| Capability | Command | Source |
|-----------|---------|--------|

### LSP Capabilities
| Feature | Status | Use Case |
|---------|--------|----------|
| documentSymbol | {Available/Unavailable} | Symbol navigation in files |
| hover | {Available/Unavailable} | Type info and documentation during CODE phase |
| goToDefinition | {Available/Unavailable} | Trace code paths during EXPLORE phase |
| findReferences | {Available/Unavailable} | Impact analysis during EXPLORE, caller verification during REVIEW |
| goToImplementation | {Available/Unavailable} | Interface resolution |
| diagnostics | {Available/Unavailable} | Quality signal during VERIFY phase (errors→P1, warnings→P2) |

Graceful Degradation

Missing	Fallback
No agents	Use built-in review checklist
No CLAUDE.md commands	Detect from tech stack
No tech stack	Ask user for commands
No LSP server	CLI-only analysis (grep/glob for references, CLI tools for diagnostics)

Caching

This skill runs in a forked context. The calling command must store the output for use in later phases — do not re-invoke within the same command execution.