Agent skill

API Contract Detection

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

Apache-2.0Auto-check passedBackend & APIs

Install API Contract Detection

skills CLI
$ npx skills add prime-radiant-inc/greenfield --skill contract-detection -a claude-code

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

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

At a glance

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

  • Works in 7 steps: Contracts are PUBLIC -- machine-readable… → Exhaustive extraction -- extract EVERY… → Preserve precision -- contracts define… → …
  • Mining a repository's OpenAPI or Swagger files for what endpoints accept and return
  • SKILL.md covers When to Use This Mode, Why Contracts Are the…, OpenAPI / Swagger and GraphQL, plus 6 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

This skill is one stage of a larger reverse-engineering workflow: it locates machine-readable API contracts in a repository or documentation set and pulls behavioral facts out of them. It covers OpenAPI and Swagger files, GraphQL schemas, Protobuf and gRPC definitions and JSON Schema, and it turns what it finds into behavioral claims. Contracts are treated as the most reliable evidence because they are formal, published, machine-verifiable and versioned.

Detection starts with file searches for names such as openapi.* and swagger.*. For each OpenAPI document it extracts endpoints, HTTP methods, operation IDs, summaries and tags, then parameters with their types, required flags and enum, minimum and maximum limits, which act as behavioral constraints. All output is marked public and written to `workspace/public/contracts/`. The mode runs independently of other evidence sources and is meant to be loaded by an analyzer agent in the first layer of the plugin's pipeline.

When your agent uses it

  • Mining a repository's OpenAPI or Swagger files for what endpoints accept and return
  • Extracting behavioral claims from GraphQL, Protobuf or JSON Schema definitions
  • Building a spec of an existing API from its published contracts before a reimplementation

Example prompts

  • “Find every OpenAPI and Swagger file in this repo and list the endpoints with their parameters.”
  • “Read the .proto files under ./proto and write down what each gRPC method promises to do.”
  • “Turn the enum and min/max constraints in our openapi.yaml into behavioral claims.”

Workflow steps

7 steps, taken from the first numbered list in SKILL.md.

  1. Contracts are PUBLIC -- machine-readable contracts are published interface definitions. Output goes to workspace/public/, not…
  2. Exhaustive extraction -- extract EVERY endpoint, field, constraint, and error code. Contracts are finite and complete. Do not sample.
  3. Preserve precision -- contracts define exact types, constraints, and enums. Do not paraphrase "minLength: 1, maxLength: 100" as "limited…
  4. Note versions -- contracts have version fields. Always record the version. Behavioral claims from contracts are version-specific.
  5. Detect staleness -- a contract file may be outdated relative to the implementation. Flag contracts that appear unmaintained (old…
  6. Copy originals -- place copies of discovered contract files in workspace/public/contracts/raw/ for downstream reference.
  7. Cite as you go -- every behavioral claim gets an inline <!-- cite: --> comment immediately after the claim. Never defer citation to a…

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 markdown and bash).

    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

API Contract Detection loads about 4.2k tokens when it runs. Until then it costs about 59 tokens; SKILL.md has 1,149 words of instructions outside code blocks.

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

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). 1,149 words, ~4,183 tokens.

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

Contract Detection Methodology

Extract behavioral intelligence from machine-readable API contracts. These are formal, published definitions of system interfaces -- the strongest possible specification source. A contract file is an explicit promise about what the system accepts and returns.

When to Use This Mode

Contract detection activates when:

  • The target repository or documentation contains API specification files
  • The discovery inventory identifies machine-readable contract files
  • Other modes discover machine-readable contracts during analysis

This mode runs independently of all other intelligence sources. All output is PUBLIC -- machine-readable contracts are published definitions intended for external consumption. Output goes to workspace/public/contracts/.

Why Contracts Are the Strongest Source

Machine-readable contracts are unique among intelligence sources because they are:

  • Formal -- they use standardized schemas with unambiguous semantics
  • Published -- they are intended for external consumers to rely on
  • Machine-verifiable -- they can be validated against implementations automatically
  • Versioned -- they explicitly track breaking changes through version fields

A single OpenAPI specification can contain more behavioral intelligence than the entire official documentation site, because every endpoint, parameter, response schema, and error code is defined with machine precision.

OpenAPI / Swagger

Detection
bash
# Find OpenAPI/Swagger files
find . -maxdepth 5 -type f \( \
  -name "openapi.*" -o -name "swagger.*" -o \
  -name "api-spec.*" -o -name "api-docs.*" \
  \) \( -name "*.json" -o -name "*.yaml" -o -name "*.yml" \) 2>/dev/null

# Check for OpenAPI version markers in YAML/JSON files
grep -rl '"openapi":\|openapi:' --include="*.json" --include="*.yaml" --include="*.yml" . 2>/dev/null | head -20
grep -rl '"swagger":\|swagger:' --include="*.json" --include="*.yaml" --include="*.yml" . 2>/dev/null | head -20

# Check for hosted spec endpoints (common locations)
# /api-docs, /swagger.json, /openapi.json, /v2/api-docs, /v3/api-docs
Extraction

For each OpenAPI/Swagger specification, extract:

Endpoints
FieldWhat It Tells You
pathsEvery endpoint the API exposes
HTTP methodThe operation type (GET=read, POST=create, PUT=replace, PATCH=update, DELETE=remove)
operationIdThe canonical name for the operation
summary / descriptionBehavioral description of what the endpoint does
tagsLogical grouping of endpoints
Parameters
FieldWhat It Tells You
parameters (path, query, header, cookie)Required inputs and their types
requiredWhether the parameter is mandatory
schema with enumAllowed values (behavioral constraint)
schema with minimum / maximumValue range (behavioral constraint)
schema with patternValidation regex (behavioral constraint)
schema with defaultDefault value when omitted
Request/Response Schemas
FieldWhat It Tells You
requestBodyWhat the endpoint accepts (content type, schema)
responsesEvery possible response code and its schema
responses.4xxClient error conditions and their structure
responses.5xxServer error conditions
components/schemasShared data models with field types, constraints, and relationships
Authentication
FieldWhat It Tells You
securityDefinitions / components/securitySchemesAuth methods (API key, OAuth2, Bearer, Basic)
security (global or per-operation)Which endpoints require which auth
Output Format

Write to workspace/public/contracts/openapi-summary.md:

markdown
## API: {title} v{version}

### Endpoints

| Method | Path | Operation | Auth Required | Description |
|--------|------|-----------|---------------|-------------|
| GET | /users | listUsers | Bearer | List all users with pagination |
| POST | /users | createUser | Bearer | Create a new user |

### Data Models

#### User
| Field | Type | Required | Constraints | Description |
|-------|------|----------|-------------|-------------|
| id | string (uuid) | yes | read-only | Unique identifier |
| email | string | yes | format: email | User's email address |

### Error Responses
| Code | Meaning | Schema |
|------|---------|--------|
| 400 | Validation error | { message: string, errors: [{field, code}] } |
| 401 | Unauthorized | { message: string } |
| 404 | Not found | { message: string } |

GraphQL

Detection
bash
# Find GraphQL schema files
find . -maxdepth 5 -type f \( \
  -name "schema.graphql" -o -name "*.graphqls" -o -name "schema.gql" -o \
  -name "*.graphql" \
  \) 2>/dev/null

# Find GraphQL codegen config (indicates GraphQL usage)
find . -maxdepth 3 -type f \( \
  -name "codegen.*" -o -name ".graphqlrc*" -o -name "apollo.config.*" \
  \) 2>/dev/null

# Check for GraphQL in dependencies
grep -l "graphql\|apollo\|@graphql" package.json requirements.txt Gemfile go.mod 2>/dev/null

# Check for introspection endpoint (if running instance available)
# POST /graphql with { "query": "{ __schema { types { name } } }" }
Extraction

For each GraphQL schema, extract:

Queries (Read Operations)
ElementWhat It Tells You
Query type fieldsEvery read operation the API exposes
ArgumentsRequired and optional parameters with types
Return typesShape of the response data
Directives (@deprecated, @auth)Behavioral modifiers
Mutations (Write Operations)
ElementWhat It Tells You
Mutation type fieldsEvery write operation the API exposes
Input typesShape of the data the operation accepts
Return typesWhat the operation returns after modification
Error handling patternsUnion types for success/error returns
Subscriptions (Real-Time Operations)
ElementWhat It Tells You
Subscription type fieldsEvents the client can subscribe to
ArgumentsSubscription filters
Payload typesShape of the real-time data
Type System
ElementWhat It Tells You
Object typesData entities and their fields
Enum typesAllowed values for categorical fields
Interface typesShared behavioral contracts across types
Union typesPolymorphic response shapes
Input typesStructured input shapes for mutations
Custom scalarsDomain-specific value types (DateTime, JSON, URL)
Output Format

Write to workspace/public/contracts/graphql-summary.md:

markdown
## GraphQL Schema

### Queries
| Query | Arguments | Returns | Description |
|-------|-----------|---------|-------------|
| users | filter: UserFilter, page: Int | [User!]! | List users with filtering |
| user | id: ID! | User | Get user by ID |

### Mutations
| Mutation | Input | Returns | Description |
|----------|-------|---------|-------------|
| createUser | input: CreateUserInput! | User! | Create a new user |
| deleteUser | id: ID! | Boolean! | Delete user by ID |

### Subscriptions
| Subscription | Arguments | Payload | Description |
|-------------|-----------|---------|-------------|
| userCreated | — | User! | Fires when a new user is created |

### Types
#### User
| Field | Type | Nullable | Description |
|-------|------|----------|-------------|
| id | ID | no | Unique identifier |
| email | String | no | Email address |
| role | UserRole | no | Enum: ADMIN, USER, VIEWER |

Protobuf / gRPC

Detection
bash
# Find .proto files
find . -maxdepth 5 -type f -name "*.proto" 2>/dev/null

# Check for gRPC in dependencies
grep -l "grpc\|protobuf" package.json requirements.txt Gemfile go.mod Cargo.toml 2>/dev/null

# Find generated gRPC code
find . -maxdepth 5 -type f \( -name "*_grpc.pb.go" -o -name "*_pb2_grpc.py" -o -name "*_grpc.rb" \) 2>/dev/null
Extraction

For each .proto file, extract:

Services
ElementWhat It Tells You
service definitionsLogical groupings of RPC methods
rpc methodsEvery callable operation
Request/response typesInput and output shapes
Streaming modifiersstream on request, response, or both
Messages
ElementWhat It Tells You
message definitionsData structures used in requests and responses
Field types and numbersSchema with wire-format compatibility rules
repeated fieldsArray/list fields
oneof fieldsUnion types (exactly one field set)
optional / requiredField presence requirements
map fieldsKey-value pair fields
Enums
ElementWhat It Tells You
enum definitionsAllowed categorical values
option allow_aliasWhether multiple names map to the same value
Options
ElementWhat It Tells You
option java_packageTarget language packaging
option go_packageGo module path
Custom optionsDomain-specific metadata
Output Format

Write to workspace/public/contracts/protobuf-summary.md:

markdown
## Protobuf/gRPC Services

### Service: UserService
| RPC | Request | Response | Streaming | Description |
|-----|---------|----------|-----------|-------------|
| GetUser | GetUserRequest | User | none | Get user by ID |
| ListUsers | ListUsersRequest | ListUsersResponse | none | List users with pagination |
| WatchUsers | WatchUsersRequest | User | server-stream | Stream user updates |

### Messages
#### User
| Field | Number | Type | Label | Description |
|-------|--------|------|-------|-------------|
| id | 1 | string | — | Unique identifier |
| email | 2 | string | — | Email address |
| role | 3 | UserRole | — | User role |

### Enums
#### UserRole
| Name | Number |
|------|--------|
| USER_ROLE_UNSPECIFIED | 0 |
| USER_ROLE_ADMIN | 1 |
| USER_ROLE_USER | 2 |

JSON Schema

Detection
bash
# Find JSON Schema files
find . -maxdepth 5 -type f -name "*.schema.json" 2>/dev/null
find . -maxdepth 5 -type f -name "*.json" -exec grep -l '"$schema"' {} \; 2>/dev/null | head -20

# Check for JSON Schema in config files
grep -rl '"$schema":\|"\$ref"' --include="*.json" . 2>/dev/null | head -20

# Find JSON Schema in OpenAPI components (already covered above, but note cross-reference)
Extraction

For each JSON Schema, extract:

Type Definitions
ElementWhat It Tells You
typeThe data type (object, array, string, number, boolean, null)
propertiesNamed fields with their own schemas
requiredFields that must be present
additionalPropertiesWhether unknown fields are allowed
Show full SKILL.md (455 more words)Show less
Validation Rules
ElementWhat It Tells You
minLength / maxLengthString length constraints
minimum / maximumNumeric range constraints
patternRegex validation for strings
formatSemantic format (email, uri, date-time, uuid)
enumAllowed values
constFixed required value
minItems / maxItemsArray length constraints
uniqueItemsWhether array elements must be unique
Composition
ElementWhat It Tells You
$refReferences to shared schema definitions
allOfSchema intersection (all must match)
anyOfSchema union (at least one must match)
oneOfSchema exclusive union (exactly one must match)
notSchema negation
if / then / elseConditional validation
Defaults and Examples
ElementWhat It Tells You
defaultDefault value when field is omitted
examplesExample values (behavioral documentation)
descriptionHuman-readable behavioral description
Output Format

Write to workspace/public/contracts/json-schema-summary.md:

markdown
## JSON Schema: {title}

### Type: CreateUserRequest
| Property | Type | Required | Constraints | Default | Description |
|----------|------|----------|-------------|---------|-------------|
| email | string | yes | format: email | — | User email address |
| name | string | yes | minLength: 1, maxLength: 100 | — | Display name |
| role | string | no | enum: [admin, user, viewer] | "user" | User role |
| tags | array of string | no | maxItems: 10, uniqueItems: true | [] | User tags |

### Validation Rules
- `email` must match email format (RFC 5322)
- `name` must be 1-100 characters
- `role` defaults to "user" when omitted
- `tags` must contain unique strings, maximum 10

Cross-Contract Correlation

When multiple contract types are present (e.g., both OpenAPI and GraphQL, or OpenAPI with JSON Schema references), correlate them:

  • Do the endpoint definitions agree on field names and types?
  • Are the same data models defined consistently across contracts?
  • Do version numbers align?
  • Are there endpoints in one contract that are missing from another?

Document correlations and discrepancies in workspace/public/contracts/cross-contract-notes.md.

Provenance Rules

Source Type

All claims from contract detection use source=machine-readable-contract:

markdown
- The /users endpoint accepts a `role` query parameter with values: admin, user, viewer
  <!-- cite: source=machine-readable-contract, ref=openapi.yaml:/paths/~1users/get/parameters/0, confidence=confirmed, agent=contract-detector -->
Confidence Levels
  • confirmed -- the behavioral claim is explicitly defined in the contract schema (endpoint exists, field has this type, parameter has this constraint). Machine-readable contracts are formal specifications; their explicit definitions are confirmed by definition.
  • inferred -- the behavioral claim is derived from contract structure rather than explicit definition (e.g., "this API follows REST conventions" inferred from path patterns)
  • assumed -- the behavioral claim extrapolates beyond what the contract defines (e.g., "this endpoint probably supports pagination" because similar endpoints do)
Cite As You Go

Every behavioral claim gets an inline citation immediately after the claim. The ref field should be <file-path>:<json-path-or-line>.

Output Structure

workspace/public/contracts/
    openapi-summary.md             # OpenAPI/Swagger extraction
    graphql-summary.md             # GraphQL schema extraction
    protobuf-summary.md            # Protobuf/gRPC extraction
    json-schema-summary.md         # JSON Schema extraction
    cross-contract-notes.md        # Correlations and discrepancies across contract types
    raw/                           # Copies of discovered contract files for reference
        openapi.yaml
        schema.graphql
        service.proto
        config.schema.json

Note: Output goes to workspace/public/contracts/ -- not workspace/raw/. Machine-readable contracts are published definitions intended for external consumption. They contain no proprietary implementation details.

Rules

  1. Contracts are PUBLIC -- machine-readable contracts are published interface definitions. Output goes to workspace/public/, not workspace/raw/.
  2. Exhaustive extraction -- extract EVERY endpoint, field, constraint, and error code. Contracts are finite and complete. Do not sample.
  3. Preserve precision -- contracts define exact types, constraints, and enums. Do not paraphrase "minLength: 1, maxLength: 100" as "limited length." Preserve the exact constraints.
  4. Note versions -- contracts have version fields. Always record the version. Behavioral claims from contracts are version-specific.
  5. Detect staleness -- a contract file may be outdated relative to the implementation. Flag contracts that appear unmaintained (old modification dates, version mismatches with the codebase).
  6. Copy originals -- place copies of discovered contract files in workspace/public/contracts/raw/ for downstream reference.
  7. Cite as you go -- every behavioral claim gets an inline <!-- cite: --> comment immediately after the claim. Never defer citation to a later step.

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

Open the folder on GitHubat commit 6e6d4b4

Compare with similar skills

API Contract Detection 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.

API Contract Detection compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
API Contract Detection this skillprime-radiant-inc/greenfield292—~4.2kAutomated safety check: PassApache-2.0
API Designmajiayu000/spellbook287—~2.1kAutomated safety check: PassMIT
API ForgeEliasOulkadi/shokunin114—~2.9kAutomated safety check: PassMIT
API Architectcuriositech/some_claude_skills244—~1.4kAutomated safety check: PassMIT
System Design CommunicationHoangNguyen0403/agent-skills-standard572—~894Automated safety check: PassMIT
SpikardGoldziher/spikard124—~799Automated safety check: PassMIT

Similar skills

  • API Design

    majiayu000/spellbook

    REST/GraphQL/gRPC API design best practices. An agent skill from majiayu000/spellbook.

    287 GitHub stars~2.1k tokensUpdated yesterday
    Backend & APIsAuto-check passed
  • API Forge

    EliasOulkadi/shokunin

    Design REST/GraphQL APIs with OpenAPI 3.1, error handling, pagination, rate limiting, webhooks, and idempotency.

    114 GitHub stars~2.9k tokensUpdated 5 days ago
    Backend & APIsAuto-check passed
  • API Architect

    curiositech/some_claude_skills

    Expert API designer for REST, GraphQL, gRPC architectures. An agent skill from curiositech/some_claude_skills.

    244 GitHub stars~1.4k tokensUpdated 1 mo ago
    Backend & APIsAuto-check passed
  • System Design Communication

    HoangNguyen0403/agent-skills-standard

    Select how services talk: REST, gRPC, GraphQL, WebSocket, SSE, or webhook per hop, sync versus async per flow, service discovery mode, and DNS/edge routing.

    572 GitHub stars~894 tokensUpdated today
    Backend & APIsAuto-check passed
  • Spikard

    Goldziher/spikard

    Scaffold Spikard projects and generate code from OpenAPI, AsyncAPI, OpenRPC, GraphQL, and Protobuf schemas using the Spikard CLI or its MCP server.

    124 GitHub stars~799 tokensUpdated today
    Backend & APIsAuto-check passed
  • API Design

    yonatangross/orchestkit

    API contract design for REST and GraphQL, covering resource shape, URL and header versioning with deprecation windows, RFC 9457 Problem Details error handling, and OpenAPI specs.

    292 GitHub stars~2.9k tokensUpdated today
    Backend & APIsAuto-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
  • 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 API Contract Detection

What does API Contract Detection do?

Finds OpenAPI, GraphQL, Protobuf and JSON Schema files in a codebase and extracts behavioral claims from them as part of a reverse-engineering workflow. This skill is one stage of a larger reverse-engineering workflow: it locates machine-readable API contracts in a repository or documentation set and pulls behavioral facts out of them. It covers OpenAPI and Swagger files, GraphQL schemas, Protobuf and gRPC definitions and JSON Schema, and it turns what it finds into behavioral claims.

When should I use API Contract Detection?

API Contract Detection fits situations like: mining a repository's OpenAPI or Swagger files for what endpoints accept and return; extracting behavioral claims from GraphQL, Protobuf or JSON Schema definitions; building a spec of an existing API from its published contracts before a reimplementation.

How do I install API Contract Detection in Claude Code?

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

How do I install API Contract Detection in Codex?

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

Can I use API Contract Detection 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 contract-detection -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/contract-detection, .gemini/skills/contract-detection, .github/skills/contract-detection and .opencode/skills/contract-detection in your project.

What does API Contract Detection need to run?

SKILL.md names no scripts, command-line tools or credentials: API Contract Detection is instructions for the agent only.

Does API Contract Detection 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 API Contract Detection 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 API Contract Detection use?

API Contract Detection 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 API Contract Detection use?

About 4.2k tokens (SKILL.md is roughly 17k 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 API Contract Detection?

Skills that share tags, products or a category with API Contract Detection: API Design (majiayu000/spellbook, 287 stars), API Forge (EliasOulkadi/shokunin, 114 stars), API Architect (curiositech/some_claude_skills, 244 stars) and System Design Communication (HoangNguyen0403/agent-skills-standard, 572 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains API Contract Detection?

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.