analysis-pipeline
Reverse engineering - multi-source product intelligence analysis with provenance tracking. Master methodology for all analysis agents.
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.
/autonomous-discoveryContext 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
name: autonomous-discovery description: Layer 1 intelligence source discovery - auto-detect available sources, search for public information, negotiate with user, produce inventory manifest
Discover and inventory every intelligence source available for the target product. Produce a manifest that downstream agents use to plan their analysis.
**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.
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.
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";
}---
Survey the target path and its surrounding context. Read directory structures, detect file types, and catalog everything that could feed analysis.
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.
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 -20Detect test infrastructure by directory conventions and framework markers.
| 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 |
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
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
Reverse engineering - multi-source product intelligence analysis with provenance tracking. Master methodology for all analysis agents.
Layer 3 deep documentation methodology. Per-module behavioral specifications, external and behavioral integration contracts, behavior documentation, end-to-end…
Layer 1 methodology for extracting behavioral intelligence from compiled binaries, bytecode archives, managed assemblies, and bundled applications. Covers…
Layer 1 skill for community intelligence gathering. Search channels, extraction methodology, consensus analysis, version-aware behavioral changes, structural…
Infrastructure skill for containerized target execution. Runtime detection, container lifecycle, security restrictions, interaction patterns.
Layer 1 skill for parsing machine-readable API contracts. OpenAPI/Swagger, GraphQL, Protobuf/gRPC, and JSON Schema detection, extraction, and behavioral claim…