Agent skill

Reverse Engineering Analysis Pipeline

by prime-radiant-inc in 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.

Apache-2.0Auto-check passedDevelopment

Install Reverse Engineering Analysis Pipeline

skills CLI
$ npx skills add prime-radiant-inc/greenfield --skill analysis-pipeline -a claude-code

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

GitHub CLI
$ gh skill install prime-radiant-inc/greenfield analysis-pipeline --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/analysis-pipeline .claude/skills/analysis-pipeline && 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
analysis-pipeline
GitHub stars
292
Token cost
~3.6k tokens
SKILL.md length
833 words
Files
1
Skills in repo
21
Repo updated
First seen
Licence
Apache-2.0

At a glance

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

  • Works in 7 steps: Complete Feature Inventory → External Contracts → Wire Protocols → …
  • Reverse-engineering a codebase into a clean behavioral specification
  • SKILL.md covers The Core Principle, Exhaustive Reading (CRITICAL), The 7-Layer Pipeline and Intelligence Sources, plus 10 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

The skill sets the core principle for a family of analysis agents: analyze deeply, output in behavioral language with no source identifiers, cite every behavioral claim to its evidence, and analyze completely rather than skipping sections marked lower priority. It insists on exhaustive reading: every function, method, class and module must actually be read and understood, not inferred from grep matches alone.

Work runs through a seven-layer pipeline (described as a dot graph) that starts by auto-discovering whichever intelligence sources are available and consuming all of them by default, unless specific ones are excluded. Those sources include raw sources such as source code, decompiled binaries, runtime observation, visual exploration, binary analysis and git history, and public sources such as documentation, SDK and ecosystem material, community discussion and machine-readable contracts, each handled by a named agent role and written to its own workspace folder.

The goal is a provenance-tracked set of behavioral specifications, test vectors and acceptance criteria that a fresh team could use to reimplement the target without inheriting its internal structure.

When your agent uses it

  • Reverse-engineering a codebase into a clean behavioral specification
  • Producing test vectors and acceptance criteria from an existing system
  • Analyzing a product across source, binaries, docs and runtime behavior with full provenance

Example prompts

  • “Reverse-engineer this payment service into a behavioral spec with provenance for every claim.”
  • “Analyze the decompiled binary and the public docs together to produce test vectors for a reimplementation.”
  • “Run the full analysis pipeline on this repo, excluding binary analysis since we only have source.”

Workflow steps

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

  1. Complete Feature Inventory
  2. External Contracts
  3. Wire Protocols
  4. Observable Behaviors
  5. Test Vectors + Acceptance Criteria
  6. User-Visible Text
  7. User Journeys

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

    No scripts in the folder and no shell commands in SKILL.md (its code samples are dot and markdown).

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

  • Network

    No URLs in SKILL.md.

    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

Reverse Engineering Analysis Pipeline loads about 3.6k tokens when it runs. Until then it costs about 38 tokens; SKILL.md has 833 words of instructions outside code blocks.

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

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 passed

The automated check found no risky patterns in SKILL.md.

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). 833 words, ~3,565 tokens.

Download SKILL.mdSave it as .claude/skills/analysis-pipeline/SKILL.md (or your agent's skills folder).
name
analysis-pipeline
description
Reverse engineering - multi-source product intelligence analysis with provenance tracking. Master methodology for all analysis agents.

Reverse Engineering

You analyze targets from multiple perspectives. You output behavioral specifications with provenance.

The Core Principle

Analyze deeply. Output behaviorally. Track provenance. Analyze COMPLETELY.

  • Analysis: Tear apart the source/binary/runtime. Trace every code path. Understand every decision tree.
  • Output: Write specs using behavioral language. No source identifiers in the output.
  • Provenance: Every behavioral claim cites its evidence source with <!-- cite: --> annotations.
  • Completeness: Analyze ALL modules (P0, P1, P2, P3 - everything). Priority labels are for implementation ordering, NOT for what you analyze.

Exhaustive Reading (CRITICAL)

You MUST read every single line of code. You MUST identify every single routine.

  • Do NOT skim code. Do NOT skip "unimportant" sections.
  • Do NOT rely on grep patterns alone - READ the actual source.
  • Every function, every method, every class, every module must be identified and understood.
  • If you haven't read a line, you don't know what it does.

The 7-Layer Pipeline

dot
digraph pipeline {
    rankdir=TB;

    "Start analysis" [shape=doublecircle];
    "Layer 1: Gather intelligence" [shape=box];
    "Layer 2: Synthesize and map modules" [shape=box];
    "Layer 3: Write deep behavioral specs" [shape=box];
    "Gate 1: Verification passed?" [shape=diamond];
    "Gate 1b: Source-to-spec completeness" [shape=diamond];
    "Layer 4: Generate test vectors and acceptance criteria" [shape=box];
    "Gate 2: Spec review passed?" [shape=diamond];
    "Layer 5: Sanitize raw specs to output/" [shape=box];
    "Layer 6: Second-pass review passed?" [shape=diamond];
    "Layer 7: Fidelity validation passed?" [shape=diamond];
    "Analysis complete" [shape=doublecircle];
    "Remediate Gate 1 findings" [shape=box];
    "Remediate Gate 2 findings" [shape=box];
    "Remediate Layer 6 findings" [shape=box];
    "Remediate Layer 7 findings" [shape=box];
    "STOP: Gate 1 failed after 3 attempts" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
    "STOP: Gate 2 failed after 3 attempts" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
    "STOP: Layer 6 failed after 3 attempts" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
    "STOP: Layer 7 failed after 3 attempts" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];

    "Start analysis" -> "Layer 1: Gather intelligence";
    "Layer 1: Gather intelligence" -> "Layer 2: Synthesize and map modules";
    "Layer 2: Synthesize and map modules" -> "Layer 3: Write deep behavioral specs";
    "Layer 3: Write deep behavioral specs" -> "Gate 1: Verification passed?";
    "Gate 1: Verification passed?" -> "Gate 1b: Source-to-spec completeness" [label="yes"];
    "Gate 1: Verification passed?" -> "Remediate Gate 1 findings" [label="no"];
    "Remediate Gate 1 findings" -> "Gate 1: Verification passed?" [label="attempt < 3"];
    "Remediate Gate 1 findings" -> "STOP: Gate 1 failed after 3 attempts" [label="attempt >= 3"];
    "Gate 1b: Source-to-spec completeness" -> "Layer 4: Generate test vectors and acceptance criteria" [label="pass"];
    "Gate 1b: Source-to-spec completeness" -> "Remediate Gate 1 findings" [label="gaps found"];
    "Layer 4: Generate test vectors and acceptance criteria" -> "Gate 2: Spec review passed?";
    "Gate 2: Spec review passed?" -> "Layer 5: Sanitize raw specs to output/" [label="yes"];
    "Gate 2: Spec review passed?" -> "Remediate Gate 2 findings" [label="no"];
    "Remediate Gate 2 findings" -> "Gate 2: Spec review passed?" [label="attempt < 3"];
    "Remediate Gate 2 findings" -> "STOP: Gate 2 failed after 3 attempts" [label="attempt >= 3"];
    "Layer 5: Sanitize raw specs to output/" -> "Layer 6: Second-pass review passed?";
    "Layer 6: Second-pass review passed?" -> "Layer 7: Fidelity validation passed?" [label="yes"];
    "Layer 6: Second-pass review passed?" -> "Remediate Layer 6 findings" [label="no"];
    "Remediate Layer 6 findings" -> "Layer 6: Second-pass review passed?" [label="attempt < 3"];
    "Remediate Layer 6 findings" -> "STOP: Layer 6 failed after 3 attempts" [label="attempt >= 3"];
    "Layer 7: Fidelity validation passed?" -> "Analysis complete" [label="yes"];
    "Layer 7: Fidelity validation passed?" -> "Remediate Layer 7 findings" [label="no"];
    "Remediate Layer 7 findings" -> "Layer 7: Fidelity validation passed?" [label="attempt < 3"];
    "Remediate Layer 7 findings" -> "STOP: Layer 7 failed after 3 attempts" [label="attempt >= 3"];
}

Intelligence Sources

Layer 1 auto-discovers available intelligence sources and consumes all of them by default:

Source TypeAgent RolesOutput LocationOrigin
Source Codebundle-splitter, chunk-analyzer, function-analyzerworkspace/raw/source/RAW
Decompiled Binariesdecompiler → chunk-analyzerworkspace/raw/source/decompiled/RAW
Public Docsdoc-researcherworkspace/public/docs/PUBLIC
SDK/Ecosystemsdk-analyzer, integration-test-minerworkspace/public/ecosystem/PUBLIC
Communitycommunity-analystworkspace/public/community/PUBLIC
Runtime Observationcli-explorer, web-ui-explorer, behavior-observer, ux-documenterworkspace/raw/runtime/RAW
Visual Explorationvisual-explorerworkspace/raw/runtime/visual/RAW
Binary Analysisbinary-surveyor, binary-deep-analyzerworkspace/raw/binary/RAW
Git Historygit-archaeologistworkspace/raw/project-history/RAW
Test Suitestest-reader, test-runnerworkspace/raw/test-evidence/RAW
Machine-Readable Contractscontract-parserworkspace/public/contracts/PUBLIC

Sources are auto-discovered. Use --exclude to skip specific source types.

Sources are excluded only by --exclude flag or user request during discovery negotiation.

Source Coverage

More independent source types covering the same behaviors = higher-confidence specs.

Minimum for high-confidence: 2+ independent source types covering the same behaviors. When a behavioral claim is supported by only one source, it gets confidence=inferred at best. When 2+ independent sources agree, it gets confidence=confirmed.

Provenance

Every behavioral claim MUST have a provenance citation:

markdown
Sessions expire after 30 minutes of inactivity.
<!-- cite: source=source-code, ref=workspace/raw/source/analysis/chunk-0046.md:23, confidence=confirmed, agent=deep-dive-analyzer, corroborated_by=runtime-observation -->

Confidence levels:

  • confirmed — 2+ independent sources agree
  • inferred — single source, direct evidence
  • assumed — reasoning from indirect evidence

Reference the provenance-methodology skill for complete format details.

Quality Gates

Gate 1 (after Layer 3 — behavioral specs)
  • No contradictions between specs — if two specs disagree, resolve before proceeding
  • Constants and crypto verified — exact values confirmed against source, not assumed
  • Claims have provenance — every behavioral claim cites its evidence source
  • Assumed claims are the minority — most claims should be confirmed or inferred from direct evidence. A module dominated by assumed claims needs more intelligence gathering
  • All modules have specs — completeness is forced, not optional
Gate 2 (after Layer 4 — test vectors and acceptance criteria)
  • No implementation leakage — specs describe behavior, not code structure
  • No P0 completeness gaps — critical behaviors are fully specified
  • ACs have valid IDs and link to specs — traceability is intact
  • P0 ACs have test vectors — critical acceptance criteria are testable
  • No contamination in validation artifacts — ACs and test vectors are clean

Mandatory Test Vectors

Layer 4 (test vector generation) is NOT optional. Test vectors are the bridge between "spec describes it" and "implementer actually builds it."

dot
digraph test_vectors {
    rankdir=TB;

    "Layer 3 specs complete" [shape=doublecircle];
    "Generate test vectors for P0 claims" [shape=box];
    "Generate edge case vectors" [shape=box];
    "Generate dependency contract vectors" [shape=box];
    "All P0 behaviors have vectors?" [shape=diamond];
    "Gate 1.5 PASS" [shape=doublecircle];
    "STOP: Add missing vectors" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];

    "Layer 3 specs complete" -> "Generate test vectors for P0 claims";
    "Generate test vectors for P0 claims" -> "Generate edge case vectors";
    "Generate edge case vectors" -> "Generate dependency contract vectors";
    "Generate dependency contract vectors" -> "All P0 behaviors have vectors?";
    "All P0 behaviors have vectors?" -> "Gate 1.5 PASS" [label="yes"];
    "All P0 behaviors have vectors?" -> "STOP: Add missing vectors" [label="no"];
}
Test Vector Format

Each vector follows Given/When/Then:

markdown
### TV-LOADER-001: TypeScript file execution
GIVEN: A file `test.ts` containing `interface Foo { x: number }; console.log("ok")`
WHEN: Run through tsx
THEN: Output is "ok", exit code 0

### TV-LOADER-002: JSON import without explicit attribute
GIVEN: A file importing `./data.json` without `with { type: 'json' }`
WHEN: Run through tsx on Node >= 18.19
THEN: Import succeeds (hook auto-adds the attribute)

### TV-LOADER-003: Invalid custom tsconfig
GIVEN: `--tsconfig nonexistent.json` flag specified
WHEN: Run through tsx
THEN: Error reported, non-zero exit code
Show full SKILL.md (334 more words)Show less
What Needs Vectors
  • Every P0 behavioral claim
  • Every documented edge case
  • Every dependency API contract failure mode
  • Every Node.js version-dependent behavior

Workspace Structure

workspace/
├── public/                    # Public origin
│   ├── docs/                  # doc-researcher output
│   ├── ecosystem/             # sdk-analyzer output
│   └── contracts/             # contract-parser output
├── raw/                   # RAW - requires sanitization
│   ├── source/                # Source code analysis
│   │   ├── chunks/
│   │   ├── analysis/
│   │   ├── functions/
│   │   ├── manifests/
│   │   └── exploration/
│   ├── runtime/               # Runtime observation
│   │   ├── cli/
│   │   ├── web/
│   │   ├── behaviors/
│   │   ├── ux-flows/
│   │   └── visual/            # visual-explorer output
│   ├── binary/                # Binary analysis
│   ├── project-history/       # git-archaeologist output
│   ├── test-evidence/         # test-reader, test-runner output
│   ├── synthesis/             # Layer 2 output
│   │   ├── features/
│   │   ├── architecture/
│   │   ├── api/
│   │   ├── behavioral-summaries/
│   │   └── module-map.md
│   └── specs/                 # Layer 3/4 output
│       ├── modules/
│       ├── journeys/
│       ├── contracts/
│       ├── test-vectors/
│       └── validation/
├── output/                     # Sanitized specs
│   └── specs/
├── provenance/                # Session logs
│   └── sessions/
└── workspace.json             # Metadata

What the Implementer Needs

0. Complete Feature Inventory
  • All CLI flags: Including hidden/debug ones
  • All interactive commands: Runtime commands with arguments
  • All keyboard shortcuts: Every shortcut and what it does
  • All env vars and config keys: Complete list
1. External Contracts
  • CLI interface, environment variables, configuration files
2. Wire Protocols
  • Request/response formats, wire format, error responses
3. Observable Behaviors
  • State machines, decision logic, workflows, error handling
4. Test Vectors + Acceptance Criteria
  • Input/output pairs, error conditions, state transitions
  • Formal Given/When/Then acceptance criteria per module
5. User-Visible Text
  • Error messages, prompts, status messages
6. User Journeys
  • End-to-end flows from input to output

What IS vs ISN'T Contamination

PRESERVE (Behavioral Interfaces)
TypeExamplesWhy
Environment variablesDATABASE_URL, DEBUGExternal API
CLI flags--format, --workersExternal API
Config keysupstreams, log_levelExternal API
API fieldsrequest_id, batch_sizeProtocol spec
User-facing paths~/.app/config.tomlBehavioral contract
Protocol namesSSE, gRPC, OAuthBehavioral contract
Error messagesExact textUX contract
REMOVE (Implementation Details)
TypeExamplesWhy
Function namesparseArgs(), handleRequest()Internal code
Variable namesrequestId, configMapInternal code
Minified identifierssp, r0, Ab2()Internal code
Line numbers"Line 1234"Internal code
Source file paths"in src/cli.ts"Internal code
Code structure"calls X then Y"Internal code

Running Analysis

/analyze [path]                              # Discover and consume everything
/analyze [path] --exclude source             # Black-box analysis
/analyze [path] --exclude git-history        # Skip commit mining

After analysis completes

  1. Gates must PASS
  2. Run /sanitize workspace/ to produce output specs
  3. END SESSION — analysis is complete

Handoff to Implementation

The output specs in workspace/output/ are the input for implementation. Greenfield stops here. The implementation team reads:

  • workspace/output/specs/ — per-domain behavioral specs
  • workspace/output/test-vectors/ — concrete input/output pairs to drive TDD
  • workspace/output/validation/acceptance-criteria/ — Given/When/Then acceptance criteria

The test vectors and acceptance criteria give the implementation pipeline a head start on proof obligations. How the implementation is carried out — walking skeletons, iteration planning, TDD cadence, review protocols — is outside Greenfield's scope.

Greenfield's job is to produce specs good enough to implement from. Implementation is a separate concern with its own methodology.

© 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/analysis-pipeline of prime-radiant-inc/greenfield.

Open the folder on GitHubat commit 6e6d4b4

Compare with similar skills

Reverse Engineering Analysis Pipeline 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.

Reverse Engineering Analysis Pipeline compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Reverse Engineering Analysis Pipeline this skillprime-radiant-inc/greenfield292—~3.6kAutomated safety check: PassApache-2.0
Dark Architecture Diagram BuilderCocoon-AI/architecture-diagram-generator7.4k1 repos~2.1kAutomated safety check: PassMIT
Deepwiki Rssopaco/deepwiki-rs3.1k—~748Automated safety check: PassMIT
Mermaid Diagramsjjmartres/opencode1336 repos~1.9kAutomated safety check: PassMIT
C4 Architecture Diagramslexler/skill-factory239—~2.3kAutomated safety check: PassApache-2.0
MVP Technical DesignKhazP/vibe-coding-prompt-template3.1k—~512Automated safety check: PassMIT

Similar skills

  • Dark Architecture Diagram Builder

    Cocoon-AI/architecture-diagram-generator

    Creates dark-themed system, cloud, security and network architecture diagrams as self-contained HTML files with inline SVG and CSS.

    7.4k GitHub starsUsed in 1 repo~2.1k tokens
    DevelopmentAuto-check passed
  • Deepwiki Rs

    sopaco/deepwiki-rs

    AI-powered Rust documentation generation engine for comprehensive codebase analysis, C4 architecture diagrams, and automated technical documentation.

    3.1k GitHub stars~748 tokensUpdated 26 days ago
    DevelopmentAuto-check passed
  • Mermaid Diagrams

    jjmartres/opencode

    Helps an agent pick the right Mermaid diagram type and write the syntax for class, sequence, flow, ER, C4, state and other software diagrams.

    133 GitHub starsUsed in 6 repos~1.9k tokens
    DevelopmentAuto-check passed
  • C4 Architecture Diagrams

    lexler/skill-factory

    Creates C4 model diagrams at every zoom level, from system landscape to code, in ASCII, Mermaid or Structurizr, for designing or documenting software architecture.

    239 GitHub stars~2.3k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • MVP Technical Design

    KhazP/vibe-coding-prompt-template

    Writes an MVP technical design from agreed requirements, covering architecture, data ownership, integration contracts, deployment and tradeoffs, then hands off to the next stage.

    3.1k GitHub stars~512 tokensUpdated 6 days ago
    DevelopmentAuto-check passed
  • Shift Subsystem Docs

    shift-editor/shift

    Updates or creates DOCS.md files for Shift subsystems, recording the architecture invariants and constraints that cannot be learned from reading the source.

    350 GitHub stars~1.9k tokensUpdated today
    DevelopmentAuto-check passed

More from prime-radiant-inc/greenfield

All 21 skills in this repo
  • 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
  • Fidelity Validation

    prime-radiant-inc/greenfield

    Cross-validates sanitized output specs against raw source specs to detect lost behavioral detail, dropped constants, missing features, or diluted precision.

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

Categories

Questions about Reverse Engineering Analysis Pipeline

What does Reverse Engineering Analysis Pipeline do?

Master methodology for reverse-engineering a codebase into behavioral specs with cited evidence, reading every line across source, binaries, docs, runtime and git history. The skill sets the core principle for a family of analysis agents: analyze deeply, output in behavioral language with no source identifiers, cite every behavioral claim to its evidence, and analyze completely rather than skipping sections marked lower priority. It insists on exhaustive reading: every function, method, class and module must actually be read and understood, not inferred from grep matches alone.

When should I use Reverse Engineering Analysis Pipeline?

Reverse Engineering Analysis Pipeline fits situations like: reverse-engineering a codebase into a clean behavioral specification; producing test vectors and acceptance criteria from an existing system; analyzing a product across source, binaries, docs and runtime behavior with full provenance.

How do I install Reverse Engineering Analysis Pipeline in Claude Code?

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

How do I install Reverse Engineering Analysis Pipeline in Codex?

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

Can I use Reverse Engineering Analysis Pipeline 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 analysis-pipeline -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/analysis-pipeline, .gemini/skills/analysis-pipeline, .github/skills/analysis-pipeline and .opencode/skills/analysis-pipeline in your project.

What does Reverse Engineering Analysis Pipeline need to run?

SKILL.md names no scripts, command-line tools or credentials: Reverse Engineering Analysis Pipeline is instructions for the agent only.

Does Reverse Engineering Analysis Pipeline access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Reverse Engineering Analysis Pipeline safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Reverse Engineering Analysis Pipeline use?

Reverse Engineering Analysis Pipeline 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 Reverse Engineering Analysis Pipeline use?

About 3.6k tokens (SKILL.md is roughly 14k 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 Reverse Engineering Analysis Pipeline?

Skills that share tags, products or a category with Reverse Engineering Analysis Pipeline: Dark Architecture Diagram Builder (Cocoon-AI/architecture-diagram-generator, 7.4k stars), Deepwiki Rs (sopaco/deepwiki-rs, 3.1k stars), Mermaid Diagrams (jjmartres/opencode, 133 stars) and C4 Architecture Diagrams (lexler/skill-factory, 239 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Reverse Engineering Analysis Pipeline?

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.