made.json

Why this exists

More people are publishing software as part of their work: tools, experiments, Claude and Codex skills, prototypes, prompts, workflows, tiny utilities, and apps that do one useful thing.

But there is no simple way to follow what someone makes as a set. These artifacts are scattered across GitHub repos, launch posts, personal sites, app stores, plugin directories, Discord links, and half-forgotten demos.

made.json gives that work a home on the open web. It is like RSS for software-shaped artifacts: publish one plain file, and any reader, crawler, launcher, directory, or agent can understand it.

How it works

Create a file at:

https://yourdomain.com/made.json

Start small:

{
  "version": "1.0",
  "items": [
    { "name": "My Cool Tool", "kind": "tool", "url": "https://example.com/cool" }
  ]
}

That is enough.

Add claims when they help

Software artifacts are different from posts. People want to know where something runs, whether it is current, whether the source is available, whether it was AI-assisted, and whether it can be forked.

made.json handles that with optional creator claims:

{
  "name": "My Cool App",
  "kind": "app",
  "url": "https://example.com/cool",
  "version": "1.2.0",
  "tags": ["writing", "utility"],
  "vibe_coded": true,
  "forkable": true,
  "source": "https://github.com/example/cool",
  "prompt_log": "https://example.com/cool/prompts",
  "targets": [
    { "kind": "web", "url": "https://example.com/cool", "label": "Open" }
  ]
}

These are not certifications from made.json. They are useful facts declared by the creator. Readers can show them, search over them, and build trust layers on top later.

Principles

• Publish to participate. A public made.json file is the opt-in.
• No central registry. Directories and readers can exist, but the standard is just the file.
• Tiny required surface. Only version, items, name, and url are required.
• Useful software context. Software artifacts need a little more metadata than posts: where to run them, what version they are, where the source lives, and whether they can be forked.
• Claims, not certification. Creator fields are creator claims. Readers can show them; trust layers can come later.
• For builders and audiences. Builders get a canonical list. Readers and subscribers get a way to follow, reuse, and publish from what people are making.

Tools

These are optional reference tools around the standard:

• Reader. Paste a feed URL into the reader to render and validate it.
• Badge. Use the badge generator to link your site or README back to your feed.
• Digest. Follow the example digest, JSON Feed, or RSS feed for seeded updates.
• Set up a feed from your repos. made-json-setup scans local repos, finds apps, Claude/Codex skills, CLIs, MCP servers, extensions, templates, and other creator-made software, then drafts entries and flags anything that needs confirmation.
• Keep a feed current. made-json-publisher adds or updates made items, preserves creator claims, and validates the feed.

They are examples and helper workflows, not required infrastructure. The standard is still just the made.json file.

Try it

Append your feed URL as a query string:

https://made-json.org/?feed=https://yourdomain.com/made.json

Loading seeded directory…