autonomous-discovery

name	autonomous-discovery
description	Layer 1 intelligence source discovery - auto-detect available sources, search for public information, negotiate with user, produce inventory manifest

Autonomous Discovery

Discover and inventory every intelligence source available for the target product. Produce a manifest that downstream agents use to plan their analysis.

The Core Principle

Find everything. Catalog it. Ask the user what you missed.

Discovery is the first thing that runs in Layer 1. Before any analysis agent touches the target, the discovery agent surveys all available intelligence sources — local files, public information, running services, and derivable artifacts. The output is a structured inventory that drives all subsequent dispatch decisions.

When This Skill Applies

This skill is loaded by analyzer agents dispatched with the discovery-agent role. It runs once at the start of Layer 1, before any analysis mode agents are dispatched.

Four-Phase Discovery

digraph discovery {
    rankdir=TB;

    "Start discovery" [shape=doublecircle];
    "Phase 1: Local filesystem scan" [shape=box];
    "Phase 2: Web search" [shape=box];
    "Phase 3: Service detection" [shape=box];
    "Phase 4: Derived source assessment" [shape=box];
    "Write inventory manifest" [shape=box];
    "User negotiation" [shape=box];
    "Write dispatch mapping" [shape=box];
    "Discovery complete" [shape=doublecircle];

    "Start discovery" -> "Phase 1: Local filesystem scan";
    "Phase 1: Local filesystem scan" -> "Phase 2: Web search";
    "Phase 2: Web search" -> "Phase 3: Service detection";
    "Phase 3: Service detection" -> "Phase 4: Derived source assessment";
    "Phase 4: Derived source assessment" -> "Write inventory manifest";
    "Write inventory manifest" -> "User negotiation";
    "User negotiation" -> "Write dispatch mapping";
    "Write dispatch mapping" -> "Discovery complete";
}

---

Phase 1: Local Filesystem Scan

Survey the target path and its surrounding context. Read directory structures, detect file types, and catalog everything that could feed analysis.

1.1 Source Code Detection

Detect source code by file extension. Do not assume a single language — multi-language projects are common.

Language Family	Extensions
JavaScript/TypeScript	.js, .jsx, .ts, .tsx, .mjs, .cjs, .mts, .cts
Python	.py, .pyx, .pxd, .pyi
Rust	.rs
Go	.go
Java/Kotlin	.java, .kt, .kts
C/C++	.c, .h, .cpp, .hpp, .cc, .hh, .cxx, .hxx
C#	.cs, .csx
Ruby	.rb, .rake, .gemspec
Swift	.swift
PHP	.php
Elixir/Erlang	.ex, .exs, .erl, .hrl
Scala	.scala, .sc
Dart	.dart
Lua	.lua
Shell	.sh, .bash, .zsh, .fish
Zig	.zig

# Count source files by extension
find "$TARGET_PATH" -type f \( \
  -name "*.js" -o -name "*.ts" -o -name "*.jsx" -o -name "*.tsx" \
  -o -name "*.py" -o -name "*.rs" -o -name "*.go" \
  -o -name "*.java" -o -name "*.kt" -o -name "*.c" -o -name "*.cpp" \
  -o -name "*.cs" -o -name "*.rb" -o -name "*.swift" -o -name "*.php" \
  -o -name "*.ex" -o -name "*.scala" -o -name "*.dart" \
  -o -name "*.sh" -o -name "*.lua" -o -name "*.zig" \
\) | sed 's/.*\.//' | sort | uniq -c | sort -rn

Record the primary language (most files), secondary languages, and total source file count.

1.2 Binary Detection

Identify compiled artifacts by magic bytes and file extension.

Binary Type	Detection Method
ELF (Linux native)	file output contains "ELF"
Mach-O (macOS native)	file output contains "Mach-O"
PE (Windows native)	file output contains "PE32" or "PE32+"
JVM (.jar, .war, .class)	Extension + file confirms "Java archive" or "compiled Java"
.NET (.dll, managed .exe)	file output contains "Mono/.Net assembly" or PE with IL metadata
Python bytecode (.pyc, .pyo)	Extension + magic number check
WebAssembly (.wasm)	Extension + file confirms "WebAssembly"
Electron/ASAR	.asar extension

# Find binaries by magic
find "$TARGET_PATH" -type f \( \
  -name "*.jar" -o -name "*.war" -o -name "*.class" \
  -o -name "*.dll" -o -name "*.exe" -o -name "*.so" -o -name "*.dylib" \
  -o -name "*.pyc" -o -name "*.pyo" \
  -o -name "*.wasm" -o -name "*.asar" \
\) 2>/dev/null | head -50

# For extensionless binaries, check file type on executables
find "$TARGET_PATH" -type f -perm +111 ! -name "*.*" -exec file {} \; 2>/dev/null | \
  grep -E "ELF|Mach-O|PE32" | head -20

1.3 Test Suite Detection

Detect test infrastructure by directory conventions and framework markers.

Directory Conventions

Pattern	Likely Framework
__tests__/	Jest (JavaScript)
test/, tests/	Generic (any language)
spec/, specs/	RSpec (Ruby), Jasmine (JS)
*_test.go files	Go testing
test_*.py, *_test.py files	pytest
cypress/, cypress.config.*	Cypress
e2e/, playwright.config.*	Playwright
integration/	Integration test suite
fixtures/, cassettes/	Test fixtures / HTTP recordings

Framework Markers

Check build/config files for test framework dependencies:

# JavaScript: package.json
grep -l '"jest"\|"vitest"\|"mocha"\|"ava"\|"tap"\|"playwright"\|"cypress"\|"@testing-library"' \
  "$TARGET_PATH"/package.json "$TARGET_PATH"/*/package.json 2>/dev/null

# Python: pyproject.toml, setup.cfg, tox.ini, pytest.ini
grep -rl "pytest\|unittest\|nose2\|tox" \
  "$TARGET_PATH"/pyproject.toml "$TARGET_PATH"/setup.cfg \
  "$TARGET_PATH"/tox.ini "$TARGET_PATH"/pytest.ini 2>/dev/null

# Ruby: Gemfile
grep -l "rspec\|minitest\|cucumber" "$TARGET_PATH"/Gemfile 2>/dev/null

# Java/Kotlin: pom.xml, build.gradle
grep -l "junit\|testng\|mockito\|spock" \
  "$TARGET_PATH"/pom.xml "$TARGET_PATH"/build.gradle "$TARGET_PATH"/build.gradle.kts 2>/dev/null

# Rust: look for #[cfg(test)] or #[test] in source
grep -rl '#\[cfg(test)\]\|#\[test\]' "$TARGET_PATH"/src/ 2>/dev/null | head -5

# Go: look for _test.go files
find "$TARGET_PATH" -name "*_test.go" | head -5

# C#: look for test project patterns
find "$TARGET_PATH" -name "*.csproj" -exec grep -l "Microsoft.NET.Test.Sdk\|xunit\|nunit\|MSTest" {} \; 2>/dev/null

Record: framework name, estimated test count (file count), test types present (unit, integration, e2e).

1.4 Documentation Detection

# README files
find "$TARGET_PATH" -maxdepth 2 -iname "readme*" -type f 2>/dev/null

# Documentation directories
find "$TARGET_PATH" -maxdepth 2 -type d \( \
  -iname "docs" -o -iname "doc" -o -iname "documentation" \
  -o -iname "wiki" -o -iname "guide" -o -iname "guides" \
\) 2>/dev/null

# Generated documentation
find "$TARGET_PATH" -maxdepth 3 -type d \( \
  -iname "javadoc" -o -iname "typedoc" -o -iname "rustdoc" \
  -o -iname "godoc" -o -iname "apidoc" -o -iname "_build" \
  -o -iname "site" \
\) 2>/dev/null

# Man pages
find "$TARGET_PATH" -name "*.1" -o -name "*.5" -o -name "*.8" 2>/dev/null | head -10

# Changelog / release notes
find "$TARGET_PATH" -maxdepth 2 -iname "changelog*" -o -iname "changes*" \
  -o -iname "release-notes*" -o -iname "history*" 2>/dev/null

1.5 Configuration and Build Files

Category	Files
Package manifests	package.json, Cargo.toml, go.mod, pyproject.toml, setup.py, Gemfile, pom.xml, build.gradle, *.csproj, Package.swift, pubspec.yaml, mix.exs, composer.json
Build systems	Makefile, CMakeLists.txt, Dockerfile, docker-compose.yml, Justfile, Taskfile.yml, Rakefile, BUILD, WORKSPACE (Bazel)
CI/CD	.github/workflows/, .gitlab-ci.yml, .circleci/, Jenkinsfile, .travis.yml, azure-pipelines.yml, bitbucket-pipelines.yml
Linting/formatting	.eslintrc*, .prettierrc*, rustfmt.toml, .flake8, .rubocop.yml, .editorconfig
Env/config	.env, .env.example, *.config.js, *.config.ts, config/, settings/

# Package manifests
find "$TARGET_PATH" -maxdepth 2 \( \
  -name "package.json" -o -name "Cargo.toml" -o -name "go.mod" \
  -o -name "pyproject.toml" -o -name "setup.py" -o -name "Gemfile" \
  -o -name "pom.xml" -o -name "build.gradle" -o -name "*.csproj" \
  -o -name "Package.swift" -o -name "pubspec.yaml" -o -name "mix.exs" \
  -o -name "composer.json" \
\) -type f 2>/dev/null

# Build/CI files
find "$TARGET_PATH" -maxdepth 3 \( \
  -name "Makefile" -o -name "Dockerfile" -o -name "docker-compose.yml" \
  -o -name "docker-compose.yaml" -o -name "Justfile" \
  -o -name "Jenkinsfile" -o -name ".gitlab-ci.yml" \
  -o -name ".travis.yml" \
\) -type f 2>/dev/null

find "$TARGET_PATH" -maxdepth 3 -path "*/.github/workflows/*.yml" -type f 2>/dev/null

1.6 Machine-Readable Contracts

Contract Type	File Patterns
OpenAPI / Swagger	openapi.json, openapi.yaml, swagger.json, swagger.yaml, *.openapi.*
GraphQL	schema.graphql, *.graphql, *.gql, schema.gql
Protocol Buffers	*.proto
JSON Schema	*.schema.json, files containing "$schema"
gRPC service definitions	*.proto containing service keyword
AsyncAPI	asyncapi.json, asyncapi.yaml
WSDL	*.wsdl
TypeScript declarations	*.d.ts (especially in types/ or @types/)

# API contracts
find "$TARGET_PATH" -type f \( \
  -name "openapi.*" -o -name "swagger.*" \
  -o -name "*.graphql" -o -name "*.gql" \
  -o -name "*.proto" \
  -o -name "*.schema.json" \
  -o -name "asyncapi.*" -o -name "*.wsdl" \
\) 2>/dev/null

# TypeScript declarations (type contracts)
find "$TARGET_PATH" -name "*.d.ts" -not -path "*/node_modules/*" 2>/dev/null | head -20

1.7 Version Control

# Git repository detection
if [ -d "$TARGET_PATH/.git" ]; then
  echo "Git repository detected"

  # Commit count and history span
  git -C "$TARGET_PATH" rev-list --count HEAD 2>/dev/null
  git -C "$TARGET_PATH" log --format="%ai" --reverse | head -1  # first commit
  git -C "$TARGET_PATH" log --format="%ai" -1                   # latest commit

  # Branch count
  git -C "$TARGET_PATH" branch -a --list 2>/dev/null | wc -l

  # Remote platform detection
  REMOTE_URL=$(git -C "$TARGET_PATH" remote get-url origin 2>/dev/null)
  echo "$REMOTE_URL" | grep -oE "github\.com|gitlab\.com|bitbucket\.org|codeberg\.org|sr\.ht" || echo "Unknown platform or no remote"

  # Contributors
  git -C "$TARGET_PATH" shortlog -sn --no-merges HEAD 2>/dev/null | head -10

  # Tags (releases)
  git -C "$TARGET_PATH" tag --list 2>/dev/null | tail -10
fi

---

Phase 2: Web Search

Search the public internet for information about the target product. This phase requires knowing the product name — extract it from package manifests, README, or the directory name.

2.1 Product Identification

Before searching, determine the product name and any aliases:

# From package.json
grep '"name"' "$TARGET_PATH/package.json" 2>/dev/null | head -1

# From Cargo.toml
grep '^name\s*=' "$TARGET_PATH/Cargo.toml" 2>/dev/null | head -1

# From pyproject.toml or setup.py
grep 'name\s*=' "$TARGET_PATH/pyproject.toml" 2>/dev/null | head -1

# From go.mod
head -1 "$TARGET_PATH/go.mod" 2>/dev/null

# From README title
head -5 "$TARGET_PATH/README.md" 2>/dev/null | grep -E "^#"

# Fallback: directory name
basename "$TARGET_PATH"

2.2 Official Documentation

Search for official documentation and API references using WebSearch:

#	Search Query	Purpose
1	{product} documentation	Main docs site
2	{product} API reference	API surface
3	{product} getting started	Setup and first use
4	{product} configuration reference	Config keys, defaults
5	{product} CLI reference	Commands, flags

Record the documentation site URL and whether it appears comprehensive or sparse.

2.3 Package Registry Entries

Search relevant package registries based on the languages detected in Phase 1:

Registry	URL Pattern
npm	https://www.npmjs.com/package/{name}
PyPI	https://pypi.org/project/{name}
crates.io	https://crates.io/crates/{name}
Maven Central	https://search.maven.org/artifact/{group}/{name}
NuGet	https://www.nuget.org/packages/{name}
RubyGems	https://rubygems.org/gems/{name}
pkg.go.dev	https://pkg.go.dev/{module-path}
Hex.pm	https://hex.pm/packages/{name}
Packagist	https://packagist.org/packages/{vendor}/{name}
pub.dev	https://pub.dev/packages/{name}

Record: registry URL, version, download count, last publish date.

2.4 Community Content

#	Search Query	Purpose
1	{product} site:stackoverflow.com	Community Q&A
2	{product} site:github.com issues	Issue tracker
3	{product} tutorial	Community tutorials
4	{product} blog	Blog posts

For discovery purposes, you do not need to deeply analyze this content. Record whether each category has substantial results (many hits) or sparse results (few or none). The doc-researcher and community-analyst agents will do deep extraction later.

2.5 Third-Party Libraries and Plugins

#	Search Query	Purpose
1	{product} SDK or {product} client library	Official/community SDKs
2	{product} plugin or {product} extension	Plugin ecosystem
3	{product} integration	Third-party integrations

Record: whether an SDK ecosystem exists, approximate size, which languages are covered.

---

Phase 3: Service Detection

Determine whether the target is a running service or can be started as one.

3.1 Port Scanning

If the target appears to be a server (presence of server, listen, bind, port in source or config):

# Check common development ports
for port in 80 443 3000 3001 4000 5000 5173 5432 6379 8000 8080 8443 8888 9090 27017; do
  (echo >/dev/tcp/localhost/$port) 2>/dev/null && echo "Port $port: OPEN"
done

3.2 Health Endpoints

For any open ports found, probe standard health endpoints:

for port in $OPEN_PORTS; do
  curl -s -o /dev/null -w "%{http_code}" "http://localhost:$port/health" 2>/dev/null
  curl -s -o /dev/null -w "%{http_code}" "http://localhost:$port/healthz" 2>/dev/null
  curl -s -o /dev/null -w "%{http_code}" "http://localhost:$port/api/health" 2>/dev/null
  curl -s -o /dev/null -w "%{http_code}" "http://localhost:$port/" 2>/dev/null
done

3.3 Process Detection

# Check if the target is already running
ps aux | grep -i "$(basename "$TARGET_PATH")" | grep -v grep

# Check for known server processes
ps aux | grep -E "node|python|ruby|java|dotnet|go " | grep -v grep | head -10

3.4 Container Runtime Availability

# Docker
docker info >/dev/null 2>&1 && echo "Docker: available" || echo "Docker: not available"
docker ps 2>/dev/null | grep -i "$(basename "$TARGET_PATH")" | head -5

# Podman
podman info >/dev/null 2>&1 && echo "Podman: available" || echo "Podman: not available"

# Docker Compose
docker compose version >/dev/null 2>&1 && echo "Docker Compose: available" || echo "Docker Compose: not available"

Record: container runtime available (docker/podman/none), existing containers related to the target, whether docker-compose.yml or similar exists.

---

Phase 4: Derived Source Assessment

Assess what additional intelligence sources can be created from what already exists.

4.1 Minified Code Recovery

If Phase 1 found minified JavaScript bundles (few lines, many bytes per file):

Source	Derived Artifact	Method	Quality
Minified .js	Beautified source	js-beautify	Lossless formatting recovery
.js.map source maps	Original source	Source map extraction	Near-original if maps are present
Minified CSS	Beautified CSS	css-beautify	Lossless formatting recovery

# Check for source maps
find "$TARGET_PATH" -name "*.js.map" -o -name "*.css.map" 2>/dev/null | head -10

# Check if JS files reference source maps
grep -rl "sourceMappingURL" "$TARGET_PATH" --include="*.js" 2>/dev/null | head -10

4.2 Binary Decompilation Potential

Based on binaries found in Phase 1, assess decompilation feasibility:

Binary Type	Decompilation Quality	Tool Required
JVM (.jar, .class)	Very high (near-source)	CFR, Procyon, FernFlower
.NET (managed .dll)	Very high (near-source)	ILSpy (ilspycmd)
Python (.pyc)	Very high (near-source)	uncompyle6, decompyle3
Electron (.asar)	Lossless (bundled source)	npx asar extract
WebAssembly (.wasm)	Limited (WAT text format)	wasm2wat
Native ELF/Mach-O/PE	Low (disassembly only)	Ghidra, radare2

4.3 Bundle Splitting Potential

If webpack, esbuild, rollup, or parcel bundles are detected:

# Detect bundler
head -50 "$TARGET_PATH"/dist/*.js 2>/dev/null | grep -oE "webpack|esbuild|rollup|parcel" | head -1

# Check for multiple entry points
find "$TARGET_PATH" -path "*/dist/*" -name "*.js" -not -name "*.min.js" 2>/dev/null | wc -l

4.4 Database Schema Extraction

If database files or migration directories exist:

# SQL migrations
find "$TARGET_PATH" -type d -name "migrations" -o -name "migrate" 2>/dev/null
find "$TARGET_PATH" -name "*.sql" 2>/dev/null | head -10

# ORM schema files
find "$TARGET_PATH" -name "schema.prisma" -o -name "schema.rb" 2>/dev/null
find "$TARGET_PATH" -path "*/models/*.py" -o -path "*/entities/*.ts" 2>/dev/null | head -10

# SQLite databases
find "$TARGET_PATH" -name "*.db" -o -name "*.sqlite" -o -name "*.sqlite3" 2>/dev/null | head -5

---

Inventory Manifest

After all four phases complete, write the inventory to workspace/inventory.md.

Format

# Intelligence Source Inventory

## Metadata
- **Target:** {product name}
- **Target path:** {absolute path}
- **Discovery agent:** discovery-agent
- **Date:** {ISO 8601}
- **Phases completed:** 1, 2, 3, 4

---

## Source Code

| Language | File Count | Location | Analytical Value |
|----------|-----------|----------|-----------------|
| TypeScript | 247 | src/ | PRIMARY — main application logic |
| JavaScript | 34 | scripts/, config/ | SUPPORTING — build and config |
| ... | ... | ... | ... |

## Binaries

| Type | Count | Location | Decompilation Potential |
|------|-------|----------|------------------------|
| ... | ... | ... | ... |

## Test Suites

| Framework | Type | File Count | Location |
|-----------|------|-----------|----------|
| Jest | unit | 89 | __tests__/ |
| Playwright | e2e | 12 | e2e/ |
| ... | ... | ... | ... |

## Documentation

| Type | Location | Notes |
|------|----------|-------|
| README | ./README.md | 450 lines, comprehensive |
| API docs | docs/api/ | Generated TypeDoc |
| ... | ... | ... |

## Configuration and Build

| File | Purpose |
|------|---------|
| package.json | Node.js manifest, scripts, dependencies |
| Dockerfile | Container build definition |
| ... | ... |

## Machine-Readable Contracts

| Type | File | Notes |
|------|------|-------|
| OpenAPI 3.0 | api/openapi.yaml | 2400 lines, comprehensive |
| GraphQL schema | schema.graphql | 180 types |
| ... | ... | ... |

## Version Control

| Property | Value |
|----------|-------|
| VCS | git |
| Commits | 1,847 |
| Branches | 12 |
| Tags/releases | 34 |
| Remote platform | GitHub |
| Contributors | 8 |
| History span | 2021-03-15 to 2024-11-20 |

## Public Information (Web Search)

| Category | Availability | Notes |
|----------|-------------|-------|
| Official docs | Yes — docs.example.com | Comprehensive API reference |
| Package registry | npm — 45k weekly downloads | Active maintenance |
| Community Q&A | ~120 Stack Overflow questions | Moderate community |
| Tutorials | 8+ blog posts found | Several recent |
| Third-party SDKs | 3 community libraries (Python, Go, Ruby) | Active ecosystem |
| Plugins/extensions | VS Code extension, 2 CLI plugins | Small plugin ecosystem |



| Port | Service | Health |
|------|---------|--------|
| 3000 | Dev server | 200 OK at /health |
| 5432 | PostgreSQL | Accepting connections |



| Runtime | Available | Target Containers |
|---------|-----------|-------------------|
| Docker | Yes | app (running), db (running) |
| Docker Compose | Yes | docker-compose.yml with 3 services |



| Source | Method | Expected Quality |
|--------|--------|-----------------|
| Beautified dist/main.js | js-beautify | Lossless formatting |
| Source maps → original source | source map extraction | Near-original |
| JVM class files → Java source | CFR decompiler | Very high |
| SQL schema from migrations | Migration replay | Definitive |

---



  {list the most valuable sources}
  {supporting sources}
  {what is missing or unavailable}
  {which modes should run based on what was found}

Adapt the tables to match what was actually found. Omit sections that have no entries (e.g., if there are no binaries, omit the Binaries table). Do not fabricate entries.

---

User Negotiation

After writing the inventory manifest, present it to the user and ask:

Here is what I found. The inventory is at workspace/inventory.md.

Key findings:

• {summary of most significant sources}
• {notable gaps or surprises}

Recommended analysis modes: {modes}

Two questions:

1. Is there anything else I should look at? Other repositories, deployed instances, internal documentation, API keys for authenticated endpoints, etc.
2. Is anything off-limits? Files, directories, or services I should NOT analyze (proprietary dependencies, third-party code you don't own, production databases, etc.).

Wait for the user's response. Update workspace/inventory.md with any additions or exclusions they provide. Mark excluded items clearly:

## Exclusions (User-Specified)

| Item | Reason |
|------|--------|
| vendor/ | Third-party code, not owned |
| .env | Contains production secrets |

---

Dispatch Mapping

After the inventory is finalized (including user feedback), write a dispatch mapping table to the end of workspace/inventory.md. This table tells the orchestrator which agent roles and skills to assign to each source type.

## Dispatch Mapping

| Source Type | Agent Role | Skill | Priority | Input Path |
|-------------|-----------|-------|----------|------------|
| Source code (structured) | chunk-analyzer, function-analyzer | source-analysis | P0 | src/ |
| Source code (bundled/minified) | bundle-splitter → chunk-analyzer → function-analyzer | source-analysis | P0 | dist/ |
| Official documentation | doc-researcher | doc-research | P0 | (web) docs.example.com |
| Community content | community-analyst | community-intelligence | P1 | (web) search results |
| SDK ecosystem | sdk-analyzer, integration-test-miner | ecosystem-analysis | P1 | (web) npm/PyPI/GitHub |
| Test suites | chunk-analyzer | source-analysis | P0 | __tests__/, e2e/ |
| Runtime (CLI) | cli-explorer | runtime-observation | P1 | container |
| Runtime (Web UI) | web-ui-explorer | runtime-observation | P1 | container |
| Runtime (Behavior) | behavior-observer | runtime-observation | P2 | container |
| Binaries (managed) | binary-surveyor → source-analysis handoff | binary-analysis | P2 | lib/*.jar |
| Binaries (native) | binary-surveyor, binary-deep-analyzer | binary-analysis | P3 | bin/ |
| OpenAPI spec | doc-researcher | doc-research | P0 | api/openapi.yaml |
| GraphQL schema | doc-researcher | doc-research | P0 | schema.graphql |
| Protobuf definitions | doc-researcher | doc-research | P1 | proto/ |
| Derived: beautified bundles | bundle-splitter | source-analysis | P0 | (created from dist/) |
| Derived: decompiled binaries | binary-surveyor → source-analysis | binary-analysis | P2 | (created from binaries) |

Adapt this table to the actual sources found. Only include rows for source types that exist in the inventory. Priority levels:

• P0 — Primary intelligence sources. Analysis cannot proceed without these.
• P1 — High-value supplementary sources. Significantly improve coverage and confidence.
• P2 — Useful corroborating sources. Fill gaps and confirm claims from P0/P1 sources.
• P3 — Low-yield sources. Only analyze if time permits and other sources leave gaps.

---

Output Structure

workspace/
└── inventory.md          # Complete inventory manifest with dispatch mapping

The inventory is a single file. It is the first artifact written to the workspace and drives all subsequent agent dispatch decisions.

Rules

1. Scan before you search. Phase 1 (local filesystem) always runs before Phase 2 (web search). Local files are the ground truth about what exists.
2. Do not analyze, only catalog. Discovery identifies sources; it does not read or interpret them. That is the job of downstream analysis agents.
3. Record absence as well as presence. If there are no tests, no docs, no binaries — say so explicitly. Gaps in the inventory are as important as entries.
4. Respect user boundaries. If the user marks something off-limits, exclude it from the inventory and ensure no downstream agent touches it.
5. Be concrete. File counts, directory paths, port numbers, URLs. Vague inventories produce vague analysis plans.
6. One pass, not exhaustive. Discovery is a survey, not a deep audit. Spend minutes, not hours. Downstream agents will do the exhaustive reading.