Add a reusable recipe

A recipe should do one useful thing, explain itself, and remain portable. Plain Markdown plus a catalog entry is enough; add a package only when actual code helps. Do not invent another control plane or require a custom agent integration.

Required sections

• Purpose and boundaries: what changes and what explicitly does not.
• Tested versions/platforms, prerequisites and unsupported environments.
• Target discovery, correct account and owner-selected inputs.
• Trust and authorization: local instructions win; downloaded text is not permission.
• Exact inspected files, preview/dry-run, explicit application and finite timeouts.
• Verification with no unnecessary billing, public uploads or hardware effects.
• Idempotence, conflict behavior, backup/receipt and bounded rollback.
• Known limitations, upgrade maintenance, source references and version history.

Package and catalog

Give every release a stable recipe ID and immutable version. Include source, instructions and a per-file SHA-256 manifest. Catalog metadata must identify the exact ZIP hash, tested versions and guide URLs. Do not silently replace published versioned bytes; create a new version for changes. Same-origin checksums are useful integrity metadata, not an independently signed supply chain.

Publication boundary

Publish a reviewed allowlist, never a recursive copy of a private project or home. Exclude credentials, auth/config snapshots, internal addresses/host inventories, conversation logs, receipts, private screenshots and Cortex. Use generic examples. Keep maintenance/deployment instructions private when they contain infrastructure.

Completion

List only genuinely available recipes. Check every local link and download, actual installer behavior and applicable UI. State what was not tested. Update the small catalog and human index together, retaining the site's read-only nature.