synaptiai/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.