Agent skill

Autonomous Discovery

by prime-radiant-inc in prime-radiant-inc/greenfield

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

Apache-2.0Auto-check: notes

Install Autonomous Discovery

skills CLI
$ npx skills add prime-radiant-inc/greenfield --skill autonomous-discovery -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install prime-radiant-inc/greenfield autonomous-discovery --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/prime-radiant-inc/greenfield.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/autonomous-discovery .claude/skills/autonomous-discovery && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
autonomous-discovery
GitHub stars
292
Token cost
~6.5k tokens
SKILL.md length
1,409 words
Files
1
Skills in repo
21
Repo updated
First seen
Licence
Apache-2.0

At a glance

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

  • Works in 4 steps: Local Filesystem Scan → Web Search → Service Detection → …
  • SKILL.md covers The Core Principle, When This Skill Applies, Four-Phase Discovery and Phase 1: Local Filesystem Scan, plus 4 more sections
  • Calls git, curl and docker; reaches npmjs.com and pypi.org

What it does

Autonomous Discovery is an agent skill from prime-radiant-inc/greenfield. Layer 1 intelligence source discovery - auto-detect available sources, search for public information, negotiate with user, produce inventory manifest

Its SKILL.md is about 6.5k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

The repository describes itself as: A Claude Code plugin that reverse-engineers clean behavioral specs, test vectors, and acceptance criteria from any codebase, producing a provenance trail so a fresh team can… The licence is Apache-2.0.

Example prompts

  • “/autonomous-discovery”

Requirements

  • Python 3
  • Docker

Workflow steps

4 steps, taken from the step headings in SKILL.md.

  1. Local Filesystem Scan
  2. Web Search
  3. Service Detection
  4. Derived Source Assessment

What it can do on your machine

Read from SKILL.md and the folder at commit 6e6d4b4. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • curl
    • docker
    • python
    • ruby
    • java
    • dotnet
    • go
    • podman
    • npx

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • npmjs.com
    • pypi.org
    • crates.io
    • search.maven.org
    • nuget.org
    • rubygems.org
    • pkg.go.dev
    • hex.pm
    • packagist.org
    • pub.dev

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Autonomous Discovery loads about 6.5k tokens when it runs. Until then it costs about 43 tokens; SKILL.md has 1,409 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~43
When it runs · the whole SKILL.md, loaded when a task matches
~6.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteMentions a .env fileSKILL.md:205
    | Env/config | `.env`, `.env.example`, `*.config.js`, `*.config.ts`, `config/`, `settings/` |
  • NoteMentions a .env fileSKILL.md:638
    | .env | Contains production secrets |

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from prime-radiant-inc/greenfield at commit 6e6d4b4, republished under its Apache-2.0 licence (© prime-radiant-inc). 1,409 words, ~6,502 tokens.

Download SKILL.mdSave it as .claude/skills/autonomous-discovery/SKILL.md (or your agent's skills folder).
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

dot
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 FamilyExtensions
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
bash
# 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 TypeDetection 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
bash
# 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
PatternLikely Framework
__tests__/Jest (JavaScript)
test/, tests/Generic (any language)
spec/, specs/RSpec (Ruby), Jasmine (JS)
*_test.go filesGo testing
test_*.py, *_test.py filespytest
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:

bash
# 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
bash
# 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
CategoryFiles
Package manifestspackage.json, Cargo.toml, go.mod, pyproject.toml, setup.py, Gemfile, pom.xml, build.gradle, *.csproj, Package.swift, pubspec.yaml, mix.exs, composer.json
Build systemsMakefile, 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/
bash
# 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 TypeFile Patterns
OpenAPI / Swaggeropenapi.json, openapi.yaml, swagger.json, swagger.yaml, *.openapi.*
GraphQLschema.graphql, *.graphql, *.gql, schema.gql
Protocol Buffers*.proto
JSON Schema*.schema.json, files containing "$schema"
gRPC service definitions*.proto containing service keyword
AsyncAPIasyncapi.json, asyncapi.yaml
WSDL*.wsdl
TypeScript declarations*.d.ts (especially in types/ or @types/)
bash
# 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
bash
# 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

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:

bash
# 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 QueryPurpose
1{product} documentationMain docs site
2{product} API referenceAPI surface
3{product} getting startedSetup and first use
4{product} configuration referenceConfig keys, defaults
5{product} CLI referenceCommands, 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:

RegistryURL Pattern
npmhttps://www.npmjs.com/package/{name}
PyPIhttps://pypi.org/project/{name}
crates.iohttps://crates.io/crates/{name}
Maven Centralhttps://search.maven.org/artifact/{group}/{name}
NuGethttps://www.nuget.org/packages/{name}
RubyGemshttps://rubygems.org/gems/{name}
pkg.go.devhttps://pkg.go.dev/{module-path}
Hex.pmhttps://hex.pm/packages/{name}
Packagisthttps://packagist.org/packages/{vendor}/{name}
pub.devhttps://pub.dev/packages/{name}

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

2.4 Community Content
#Search QueryPurpose
1{product} site:stackoverflow.comCommunity Q&A
2{product} site:github.com issuesIssue tracker
3{product} tutorialCommunity tutorials
4{product} blogBlog 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 QueryPurpose
1{product} SDK or {product} client libraryOfficial/community SDKs
2{product} plugin or {product} extensionPlugin ecosystem
3{product} integrationThird-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):

bash
# 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:

bash
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
bash
# 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
bash
# 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.


Show full SKILL.md (566 more words)Show less

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):

SourceDerived ArtifactMethodQuality
Minified .jsBeautified sourcejs-beautifyLossless formatting recovery
.js.map source mapsOriginal sourceSource map extractionNear-original if maps are present
Minified CSSBeautified CSScss-beautifyLossless formatting recovery
bash
# 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 TypeDecompilation QualityTool 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/PELow (disassembly only)Ghidra, radare2
4.3 Bundle Splitting Potential

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

bash
# 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:

bash
# 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
markdown
# 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 |

## Running Services

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

## Container Runtime

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

## Derived Sources (Can Be Created)

| 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 |

---

## Summary

- **Primary intelligence sources:** {list the most valuable sources}
- **Secondary sources:** {supporting sources}
- **Gaps:** {what is missing or unavailable}
- **Recommended analysis modes:** {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:

markdown
## 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.

markdown
## 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.

© prime-radiant-inc, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/autonomous-discovery of prime-radiant-inc/greenfield.

Open the folder on GitHubat commit 6e6d4b4

Compare with similar skills

Autonomous Discovery next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Autonomous Discovery compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Autonomous Discovery this skillprime-radiant-inc/greenfield292—~6.5kAutomated safety check: NotesApache-2.0
Resemble Detectgithub/awesome-copilot40k3 repos~4.1kAutomated safety check: PassApache-2.0
Threat Detectionalirezarezvani/claude-skills28k—~3.5kAutomated safety check: PassMIT
Pii Detectruvnet/ruflo74k—~350Automated safety check: NotesMIT
Detecting Dnp3 Protocol Anomaliesmukul975/Anthropic-Cybersecurity-Skills34k—~3.6kAutomated safety check: PassApache-2.0
Detecting Attacks On Scada Systemsmukul975/Anthropic-Cybersecurity-Skills34k—~6.9kAutomated safety check: PassApache-2.0

Similar skills

  • Resemble Detect

    github/awesome-copilot

    Official

    Deepfake detection and media safety — detect AI-generated audio, images, video, and text, trace synthesis sources, apply watermarks, verify speaker identity, and analyze media intelligence using…

    40k GitHub starsUsed in 3 repos~4.1k tokens
    Media & CreativeAuto-check passed
  • Threat Detection

    alirezarezvani/claude-skills

    A skill your agent uses when hunting for threats in an environment, analyzing IOCs, or detecting behavioral anomalies in telemetry.

    28k GitHub stars~3.5k tokensUpdated 1 mo ago
    SecurityAuto-check passed
  • Pii Detect

    ruvnet/ruflo

    Detect and flag personally identifiable information (PII) in text, code, and configurations.

    74k GitHub stars~350 tokensUpdated yesterday
    Auto-check: notes
  • Detecting Dnp3 Protocol Anomalies

    mukul975/Anthropic-Cybersecurity-Skills

    Detect anomalies in DNP3 communications used in SCADA/ICS systems by monitoring unauthorized control commands, firmware update attempts, protocol violations, and deviations from baseline traffic…

    34k GitHub stars~3.6k tokensUpdated 1 mo ago
    Data & AnalyticsAuto-check passed
  • Detecting Attacks On Scada Systems

    mukul975/Anthropic-Cybersecurity-Skills

    This skill covers detecting cyber attacks targeting Supervisory Control and Data Acquisition (SCADA) systems including man-in-the-middle attacks on industrial protocols, unauthorized command…

    34k GitHub stars~6.9k tokensUpdated 1 mo ago
    Data & AnalyticsAuto-check passed
  • Detecting AWS Cloudtrail Anomalies

    mukul975/Anthropic-Cybersecurity-Skills

    Detect unusual API call patterns in AWS CloudTrail logs using boto3, statistical baselining, and behavioral analysis to identify credential compromise, privilege escalation, and unauthorized…

    34k GitHub stars~751 tokensUpdated 1 mo ago
    SecurityAuto-check passed

More from prime-radiant-inc/greenfield

All 21 skills in this repo
  • Reverse Engineering Analysis Pipeline

    prime-radiant-inc/greenfield

    Master methodology for reverse-engineering a codebase into behavioral specs with cited evidence, reading every line across source, binaries, docs, runtime and git history.

    292 GitHub stars~3.6k tokensUpdated 2 mo ago
    Auto-check passed
  • Community Intelligence Research

    prime-radiant-inc/greenfield

    Mines tutorials, forums, reviews, issues and changelogs for observed product behavior, using six search channels and consensus analysis.

    292 GitHub stars~4.5k tokensUpdated 2 mo ago
    Auto-check passed
  • Containerized Target Execution

    prime-radiant-inc/greenfield

    Runs untrusted analysis targets inside Docker or Podman containers with memory, CPU and process limits, covering image builds, lifecycle, command execution and cleanup.

    292 GitHub stars~2.1k tokensUpdated 2 mo ago
    Auto-check passed
  • API Contract Detection

    prime-radiant-inc/greenfield

    Finds OpenAPI, GraphQL, Protobuf and JSON Schema files in a codebase and extracts behavioral claims from them as part of a reverse-engineering workflow.

    292 GitHub stars~4.2k tokensUpdated 2 mo ago
    Auto-check passed
  • Documentation Research Methodology

    prime-radiant-inc/greenfield

    Method for extracting behavioral specifications from a product's public documentation: tiered search order, claim extraction rules, output structure, stop criteria and gap analysis.

    292 GitHub stars~4.6k tokensUpdated 2 mo ago
    Auto-check passed
  • Ecosystem Analysis

    prime-radiant-inc/greenfield

    Layer 1 skill for SDK and ecosystem analysis. An agent skill from prime-radiant-inc/greenfield.

    292 GitHub stars~2.9k tokensUpdated 2 mo ago
    Auto-check passed

Questions about Autonomous Discovery

What does Autonomous Discovery do?

Layer 1 intelligence source discovery - auto-detect available sources, search for public information, negotiate with user, produce inventory manifest. Autonomous Discovery is an agent skill from prime-radiant-inc/greenfield.

How do I install Autonomous Discovery in Claude Code?

Run `npx skills add prime-radiant-inc/greenfield --skill autonomous-discovery -a claude-code`. Or copy the skill folder (skills/autonomous-discovery in prime-radiant-inc/greenfield) into .claude/skills/autonomous-discovery in your project. Claude Code loads it when a task matches its description.

How do I install Autonomous Discovery in Codex?

Run `npx skills add prime-radiant-inc/greenfield --skill autonomous-discovery -a codex`. Or copy the skill folder (skills/autonomous-discovery in prime-radiant-inc/greenfield) into .agents/skills/autonomous-discovery in your project. Codex loads it when a task matches its description.

Can I use Autonomous Discovery in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add prime-radiant-inc/greenfield --skill autonomous-discovery -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/autonomous-discovery, .gemini/skills/autonomous-discovery, .github/skills/autonomous-discovery and .opencode/skills/autonomous-discovery in your project.

What does Autonomous Discovery need to run?

Going by SKILL.md and its folder, Autonomous Discovery needs the command-line tools its instructions call (git, curl, docker, python, ruby and java). Our summary lists: Python 3; Docker.

Does Autonomous Discovery access the network?

SKILL.md names 10 domains. In commands or code: npmjs.com, pypi.org, crates.io, search.maven.org, nuget.org, rubygems.org, pkg.go.dev, hex.pm, packagist.org and pub.dev; the agent is likely to contact these when it follows the instructions. This is read from the text; nothing was executed.

Is Autonomous Discovery safe to install?

Our automated static check of SKILL.md found notes only (mentions a .env file), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Autonomous Discovery use?

Autonomous Discovery is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Autonomous Discovery use?

About 6.5k tokens (SKILL.md is roughly 26k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Autonomous Discovery?

Skills that share tags, products or a category with Autonomous Discovery: Resemble Detect (github/awesome-copilot, 40k stars), Threat Detection (alirezarezvani/claude-skills, 28k stars), Pii Detect (ruvnet/ruflo, 74k stars) and Detecting Dnp3 Protocol Anomalies (mukul975/Anthropic-Cybersecurity-Skills, 34k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Autonomous Discovery?

prime-radiant-inc (a GitHub organization) maintains it in prime-radiant-inc/greenfield, which has 292 GitHub stars. The repository holds 21 skills in this directory. The repository was last updated on August 6, 2026.

Source: prime-radiant-inc/greenfield on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.