/autonomous-discovery
Layer 1 intelligence source discovery - auto-detect available sources, search for public information, negotiate with user, produce inventory manifest
$ npx -y skills add prime-radiant-inc/greenfield --skill autonomous-discovery --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/autonomous-discovery
Context preview
The summary Claude sees to decide when to auto-load this skill.
Layer 1 intelligence source discovery - auto-detect available sources, search for public information, negotiate with user, produce inventory manifest
SKILL.md
autonomous-discovery.SKILL.mdname: 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 -201.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_PAT
Read more
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 -201.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_PAT
Showing the first part of this file.
Reverse engineer clean behavioral specs from any codebase. Greenfield reads source code, documentation, SDKs, runtime behavior, and binaries, then produces behavioral specifications, test vectors, acceptance criteria, and a full provenance trail.
Repo: prime-radiant-inc/greenfield
Other skills on greenfield.
- /analysis-pipeline
Reverse engineering - multi-source product intelligence analysis with provenance tracking. Master methodology for all analysis agents.
Open skill - /behavioral-spec-writing
Layer 3 deep documentation methodology. Per-module behavioral specifications, external and behavioral integration contracts, behavior documentation, end-to-end user journey analysis. Transforms Layer 2 synthesis into implementable behavioral specifications. Loaded by the
Open skill - /binary-analysis
Layer 1 methodology for extracting behavioral intelligence from compiled binaries, bytecode archives, managed assemblies, and bundled applications. Covers artifact identification, string extraction strategy, decompilation workflows, provenance requirements, and handoff to source
Open skill - /community-intelligence
Layer 1 skill for community intelligence gathering. Search channels, extraction methodology, consensus analysis, version-aware behavioral changes, structural contamination guard. Loaded by the analyzer agent for community intelligence gathering.
Open skill - /container-execution
Infrastructure skill for containerized target execution. Runtime detection, container lifecycle, security restrictions, interaction patterns.
Open skill - /contract-detection
Layer 1 skill for parsing machine-readable API contracts. OpenAPI/Swagger, GraphQL, Protobuf/gRPC, and JSON Schema detection, extraction, and behavioral claim generation. Loaded by the analyzer agent during Layer 1.
Open skill

