Questo documento è mantenuto solo in inglese. La versione inglese è quella che fa fede.
Structure
The forge block is a single top-level key added to your existing manifest. It has five sub-objects, four of which are implemented in v0.1 and one that is planned.
forge.versionrequiredSpec version — must be "0.1"forge.publisherlivePublisher identity — set on claimforge.securityliveSecurity scan results — set by Forgeforge.credentialsliveWhat a user must supply — names, never valuesforge.evalsliveEval suites you invite people to runforge.composeplannedRuntime composability hintsforge.versionrequired
The version of this spec the block conforms to. Must be "0.1" for this version.
forge.publisherlive — v0.1
Publisher identity, populated automatically by Forge when you claim your listing. You can include it manually — Forge compares it against its verification records.
| Field | Type | Description |
|---|---|---|
verified | boolean | true if Forge has verified this publisher |
verification_method | string | "github-owner" · "github-collaborator-api" · "manual" |
github_login | string | GitHub username of the verified publisher |
verified_at | datetime | ISO 8601 — when verification occurred |
forge.securitylive — v0.1
Security scan results written by Forge — not self-reported. Forge queries the OSV vulnerability database for known CVEs against the exact published version, and runs static analysis on npm lifecycle scripts for suspicious patterns.
| Field | Type | Description |
|---|---|---|
scanned | boolean | Whether a scan has run |
scan_level | string | "base" or "verified" |
last_scan | datetime | ISO 8601 of last scan |
scanner_version | string | Forge scanner version |
vulnerabilities | integer | Total CVEs (all severities) |
critical / high / moderate / low | integer | CVEs by severity |
suspicious_scripts | boolean | Flagged lifecycle script patterns |
status | string | "clean" · "warnings" · "critical" · "failed" |
forge.evalslive
The eval suites you invite people to run against your package — id, version, a SHA-256 digest of the suite's own bytes, and where to fetch it. This block carries no results. Anyone can write "accuracy": 0.99 into their own manifest, so a number here would cost nothing to write and be worth nothing to read. What it carries instead is the commitment that makes a result checkable: exactly which cases to run.
The digest covers the suite's id, version, kind and cases, canonicalised and hashed — not its description or URL, so a mirror of the same suite still corroborates the original. Run forge eval <suite> <target> to compute it.
Eval resultslive
Results are not part of the manifest. They are submitted as individual runs to POST /api/v1/entries/:id/evals by forge eval --publish, and the registry stamps each one with the GitHub identity it authenticated. A run names the suite digest it ran, the exact version of your package it ran against, passed/total, latency, and a digest of its per-case outcomes.
Forge then derives how much it can stand behind. Nobody submits this — there is no request that sets it:
- Reproduced — two or more independent accounts ran the same suite digest against the same version and agreed within two points.
- Contested — they ran it and did not agree. Shown as a range, prominently. A disputed number tells you more than an unexamined one.
- Unverified claim — one account has reported it, including when that account is the publisher. Displayed, and labelled as a claim.
One identity gets one vote, so re-running your own suite is not a reproduction. A run whose case count differs from the suite's is rejected outright — otherwise the cheapest route to a perfect score would be to run only the cases you pass. And eval results never affect the trust score: that score is a security rubric, and folding a metric authored by the party being measured into it would compromise the one number the registry's credibility rests on. Quality is a parallel signal, with its own badge and its own --min-accuracy filter — which only reproduced results satisfy.
forge.composeplanned — v0.2
Composability hints that let Forge build a dependency graph and run supply chain security checks across agent pipelines.
Usage by format
MCP server
Add forge as a top-level key in package.json:
A2A Agent Card
Add forge as an extension key in agent.json:
Skill (SKILL.md)
Add a forge key in the YAML frontmatter:
Claiming your listing
You don't need to write the forge.publisher block yourself — Forge writes it automatically when you claim your listing.
- Find your package in the registry
- Click “Claim this listing” on the package profile
- Sign in with GitHub — Forge checks repo access automatically
- Submit the claim — most are verified instantly via the GitHub collaborator API
After verification, Forge writes the forge.publisher block and displays your GitHub identity on the listing. Security scanning runs automatically on every claimed package.
Versioning
This spec follows semantic versioning:
| Bump | When |
|---|---|
| Patch (0.1.x) | Clarifications, no schema changes |
| Minor (0.x.0) | New optional fields — backwards-compatible |
| Major (x.0.0) | Breaking changes to required fields or removed fields |
The forge.version field in the block records which version of this spec the block conforms to. Clients should treat unrecognised fields as unknown and ignore them.
RFC process
This spec evolves through an open RFC process on GitHub.
- Open an issue describing the problem you're solving with concrete JSON examples
- Discussion period: 7 days for minor changes, 14 days for significant, 30 days for breaking
- Open a PR updating SPEC.md and forge.schema.json, referencing the issue
- Merge after discussion period with no unresolved objections
JSON Schema
A machine-readable JSON Schema is available for validation:
Use it with any JSON Schema validator. Example with ajv: