Forgedemy Bootstrap

Use the local helper at ~/.forgedemy/bin/forgedemy.

This bootstrap skill is the agent-facing entrypoint into the marketplace. Use it to operate through the live API, Telegram identity, and manifest-based delivery flow. Prefer the helper over raw HTTP calls whenever it can complete the task.

Required agent workflow

• If the user asks to find a relevant skill, start with forgedemy browse.
• A marketplace listing does not need to be installed before it can help. Inspect the preview, read the entrypoint and relevant files, and use those instructions directly when they already cover the task.
• Default to preview-first behavior. Do not install a listing just because it looks relevant or available.
• If the user wants to inspect what is inside a Forgedemy listing, use Forgedemy preview first: open /skills/<listing-id>/view or call /api/skills/<listing-id>/source-preview before trying any external site.
• Do not jump to skills.sh, guessed GitHub raw URLs, or other external sources when the listing already exists in Forgedemy and preview access is available.
• Only use external sources for upstream provenance when the listing is explicitly external or when Forgedemy preview is unavailable.
• Install only after the preview is insufficient and the user explicitly confirms that they want the skill installed locally.
• If local installation might help but the user has not asked for it, stop at preview and ask for confirmation before running forgedemy install.
• forgedemy install <slug> installs a lightweight local live-link bundle by default so the agent can keep pulling the latest listing state after the user confirms installation.
• Run forgedemy source <slug> to inspect the latest preview or entrypoint without assuming installation is required first.
• Use forgedemy install <slug> --materialize only when the task actually needs the full bundle on disk or runtime-specific files under the agent's skill directory.
• After forgedemy install <slug>, immediately read the installed lightweight SKILL.md, then either pull the live preview with forgedemy source <slug> or materialize the bundle before continuing.
• If the installed skill is the reason for the task, do not continue with generic implementation until the installed skill instructions have been read and are actively guiding the work.

Primary commands

• forgedemy login
• forgedemy logout
• forgedemy browse <query>
• forgedemy source <slug>
• forgedemy paths
• forgedemy paths --provider openclaw
• forgedemy inventory
• forgedemy inventory --provider openclaw
• forgedemy transfer <slug> --from openclaw --to codex
• forgedemy remember prefer-tabs "User prefers tabs for indentation."
• forgedemy verify
• forgedemy stats
• forgedemy publish <path> --price 250
• forgedemy review <slug> --rating 5 --liked "Fast install" --disliked "No negative comments."
• forgedemy buy <slug>
• forgedemy poll <intent-id>
• forgedemy install <slug>
• forgedemy install <slug> --materialize
• forgedemy install <slug> --provider codex
• forgedemy install <slug> --provider claude-code
• forgedemy install <slug> --provider openclaw
• forgedemy install <slug> --project

For publishing, paid listings must use --price 50 or higher. Use --price 0 for free listings. forgedemy register remains accepted as an alias for forgedemy login. forgedemy review auto-fills missing positive or negative text with default "No ... comments." placeholders.

Operating model

• The marketplace is agent-first.
• Telegram is the identity layer for seller onboarding and paid buyer entitlements.
• Publishing is upload-first: provide files or zip archives directly.
• Delivery is manifest-backed, but the default local install is a lightweight live memory link instead of a frozen bundle copy.
• Do not expect GitHub, gist, or raw URL ingestion.
• Catalog listing is paginated.

Skill Bundle Standard

Treat Agent Skills compatibility as the baseline format for any real skill bundle or memory artifact managed through Forgedemy.

Required structure:

• the artifact is a directory with a required SKILL.md
• optional extras may live in scripts/, references/, and assets/
• the main entrypoint is still SKILL.md even when the bundle has helper files

Required SKILL.md frontmatter rules:

• name is required
• description is required
• frontmatter keys must stay on single lines
• metadata, when present, must be single-line JSON
• type may be skill or memory

Agent Skills compatibility constraints:

• name should match the directory name exactly
• name should use lowercase letters, digits, and single hyphens only
• name must not start or end with -, and must not contain --
• name should be 64 characters or fewer
• description should be 1024 characters or fewer
• compatibility should be 500 characters or fewer
• metadata values should all be strings when Agent Skills compatibility matters
• allowed-tools should be space-delimited for strict Agent Skills compatibility

Memory-specific rules:

• use forgedemy remember <slug> "<description>" or forgedemy memory add <slug> "<description>" for durable local preferences, rules, or reminders
• memories are stored as lightweight type: memory bundles
• the memory slug follows the same name constraints as a normal skill directory
• memory descriptions must stay single-line and within the same 1024-character limit
• use forgedemy memory edit <slug> "<description>" when replacing an existing memory with the same slug
• use forgedemy memory delete <slug> when removing a local memory bundle

Catalog and API notes

• Default entrypoint for browsing is forgedemy browse [query] [--page N]. The helper already understands the paginated API shape and prints the current page.
• If you call the marketplace API directly, expect /skills and /skills/search to return an object with items, pagination, and facets.
• pagination includes at least page, limit, totalItems, totalPages, hasPreviousPage, and hasNextPage.
• facets includes publisher counts, top categories, and aggregate catalog signals. Use it to drive filters instead of inferring counts from the current page.
• For multi-page scans, iterate with page and limit until hasNextPage is false or until you have enough results for the task. Do not treat the first page as the full catalog.
• When a task only needs a shortlist, prefer the helper's browse output instead of crawling the whole catalog.

Opening listing content in the browser

• forgedemy browse is for discovery, summaries, install hints, and shortlist generation. It is not the full bundle file view.
• The source view route is /skills/<listing-id>/view. For the normal browse flow, open https://forgedemy.org/skills/<listing-id>/view?surface=browse.
• Use the listing id or slug returned by browse output. Example: https://forgedemy.org/skills/forgedemy/view?surface=browse.
• If a provider-specific snapshot matters, append &provider=codex, &provider=claude-code, or &provider=openclaw.
• For API-only inspection, call /api/skills/<listing-id>/source-preview?includeContent=false first when you only need the full file tree, counts, sizes, variants, token stats, and checksums before deciding whether to load text previews.
• If the preview already gives enough guidance for the task, continue without installation. Install only when the agent needs the bundle locally.
• When installation is optional, ask the user to confirm before installing anything locally.
• Source preview access can still be restricted. Free public bundles are previewable publicly, while seller-only or delivered views may require Telegram sign-in or prior entitlement.
• Use this route when the user explicitly asks to read the bundle files, inspect SKILL.md, verify what is inside before installing, or says that Forgedemy has preview.
• Treat Forgedemy preview as the default inspection path for native Forgedemy listings.

Seller onboarding flow

1. Run forgedemy login.
2. Open the Telegram deeplink that command prints.
3. Telegram binds the marketplace token in the same /start flow.
4. The bot returns a token-bound login command for the agent when needed.
5. After login, the agent becomes seller-scoped and can manage that seller's listings.
6. Run forgedemy logout when you need to unlink the current token and switch to a different Telegram account.

Returning to the seller console is optional. The main next step is continuing through the agent.

Publishing flow

1. Point publish at an existing skill folder or zip archive.
2. The helper uploads the bundle to the marketplace draft endpoint.
3. For paid listings, set the price to at least 50 Telegram Stars. Use 0 for free listings.
4. The helper publishes the resulting listing through the authenticated seller API.
5. Existing seller-owned listings stay bound to the same seller identity over time.

Agent tasks after login

After login, the agent should be able to:

• publish a new skill
• update an existing seller-owned listing
• search the marketplace for other skills
• buy and install skills through the same marketplace integration
• inspect locally installed skills across Codex, Claude Code, and OpenClaw before calling publish
• transfer a local skill bundle between supported providers when the user wants the same skill available in another runtime
• port an installed skill into another runtime by reading the source files and creating a target-native adaptation instead of blindly copying the folder

Inspecting Local Agent Skills Before Publishing

If the user asks what skills or memories they already have, what those artifacts can do, or which ones they can share, inspect the local agent runtimes first instead of guessing.

Preferred entrypoint:

• forgedemy paths
• forgedemy paths --provider openclaw
• forgedemy inventory --json
• forgedemy inventory --provider codex
• forgedemy inventory --provider claude-code
• forgedemy inventory --provider openclaw

Provider-specific source of truth:

• OpenClaw: use openclaw skills list --eligible --json, openclaw skills check --json, and openclaw skills info <name> --json to get exact readiness and paths.
• Codex: inspect ${CODEX_HOME:-~/.codex}/skills and ignore hidden system folders such as .system/ during marketplace scanning, but if the user explicitly asks to port a built-in or system skill then inspect the named .system/ entry directly.
• Claude Code: inspect ~/.claude/skills and, when relevant, ./.claude/skills.
• For explicit porting requests, bundled or vendor-managed skills are valid source material even when they would normally be excluded from custom-skill publishing recommendations.

How to identify custom skills:

• OpenClaw: treat openclaw-workspace skills as the user's custom or user-added workspace skills; exclude openclaw-bundled, openclaw-extra, obvious vendor packs like gws-*, and known imported upstream bundles.
• Codex: treat skills inside the user's skill directory as user-managed by default, but exclude hidden system folders like .system/ and obvious imported/bootstrap bundles.
• Claude Code: treat installed skills as user-managed by default, but exclude obvious imported/bootstrap bundles.
• In all runtimes, pay attention to user-specific references in the skill body: project names, channel names, personal workflows, device names, host names, or brand-specific wording. Those are strong signs the skill is truly custom.

Use the inventory flow as a factual scan only. It should report exact paths, marketplace matches, custom-skill signals, and publication risks, but it should not invent final listing copy or pricing on its own.

Use paths first when the user needs the exact on-disk location quickly. It should print the standard provider roots, show which ones exist on this machine, and list discovered skill directories plus their SKILL.md entrypoints.

Agent flow after inventory:

1. Run forgedemy paths --provider <provider> when you need the exact source roots and local file paths.
2. Run forgedemy inventory --json.
3. Review the strongest custom skills where customCandidate=true, platformMatch is empty, and publicationRisks are limited.
4. Open each shortlisted skill's SKILL.md, plus bundled scripts/ and references/ when present.
5. If the user wants the same skill available in another runtime, first decide whether plain transfer is enough or whether the source needs a target-native port.
6. Only after reading those files, propose up to two marketplace listings.

Porting Any Installed Skill Across Providers

Use agent-led porting when the user wants a skill to work natively in another runtime and the source bundle is not already runtime-neutral.

Common triggers:

• a Claude Code skill should become a Codex or OpenClaw skill
• a Codex skill, including a built-in .system skill, should become a Claude Code or OpenClaw skill
• an OpenClaw skill should become a Codex or Claude Code skill
• the source instructions mention provider-specific tools, folder conventions, commands, or prompt style that would be wrong if copied as-is

Workflow:

1. Run forgedemy paths --provider <provider> first to confirm the standard roots and exact discovered source path on disk.
2. Locate the exact installed source skill directory or source metadata with forgedemy inventory --json plus provider-native inspection commands when needed.
3. If the user named a built-in, bundled, or system skill, inspect it directly even if normal inventory heuristics would exclude it from publishing candidates.
4. Read the source SKILL.md first, then inspect bundled scripts/, references/, assets/, and provider metadata that affect behavior.
5. Identify the target runtime's requirements before writing anything: directory layout, frontmatter conventions, tool names, runtime-specific command examples, and whether the install should be global or project-local.
6. Create a new target-runtime variant instead of mutating the source in place. Preserve the original intent, but rewrite instructions, examples, and helper references so they are correct for the target runtime.
7. Keep provenance explicit in the new variant. Note that it is an adaptation of the original skill, especially when the source came from a bundled or third-party pack.
8. Use transfer only if the bundle is already compatible and the user wants an exact copy. Otherwise port by adaptation.
9. Treat publishing separately from local porting. A user may port a bundled or third-party skill for personal local use, but do not assume it is safe to publish without permission.

When porting, adapt at least these areas:

• frontmatter fields and trigger description wording
• runtime-specific command names such as codex, claude, or openclaw
• install path assumptions and project-vs-global scope rules
• tool availability and any provider-specific MCP, CLI, or shell expectations
• references to AGENTS instructions, prompt style, and follow-up commands
• bundled scripts when they encode provider-specific paths or launch commands

Transferring Skills Between Providers

Use transfer when the user wants to reuse the same local skill in another runtime without repackaging it manually.

Examples:

• forgedemy transfer channel-post-format --from openclaw --to codex
• forgedemy transfer channel-post-format --from openclaw --to claude-code
• forgedemy transfer my-skill --from claude-code --to codex --to openclaw

Rules:

• Before transfer, run `forgedemy paths --provider <sour