Run any Skill in Manus with one click

ingest-into-tome-app

Stars0

Forks0

UpdatedJuly 10, 2026 at 02:01

WHAT: the PromptWorld app-rung — a single flow that ingests an existing Claude-Code system directory (a dir of AIOSes / skills / rules / CLAUDE.mds), converts it into its own {name}-nomicon (the author's SkillTome — the framework-of-frameworks holder/search/router), and agentifies that tome into a standalone sidecar PromptWorld app (a CEO that carries the tome as its world-model, with the ingested AIOS dirs as its specialist agents). It WIRES the already-existing pieces (ingest = copy into the workspace; convert = the skill2framework→fold-into-tome pipeline; agentify = PromptWorld scoped to the tome) into one drop-dir→get-app flow. WHEN: when the user says 'ingest this claude-code dir', 'turn this system into an app / a webapp', 'make a {name}-nomicon from this', 'convert this dir into its own app', 'app-rung', or wants a Claude-Code directory packaged as a runnable sidecar PromptWorld with an AIOS (any of).

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

sancovp

sancovp/promptworld

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

More from this repository

same repository

compile-a-world

sancovp/promptworld

WHAT: PromptWorld's meta-compiler skill — the architecture patterns + worked examples for building a *World (a sim app = a team-leader + a specialist set + a domain + a driver) such as JobWorld, GameWorld, HealthWorld, or PromptWorld itself, plus how to reuse one pattern, combine them into a new World/app, and compose+publish it over the nomicon. WHEN: when the user (or the Archwizard) says 'compile/build/make a World', 'make a new jobworld/gameworld/healthworld', 'what World patterns are there / how is a World built', 'turn this into an app / a sim', 'meta-compiler', 'world compiler', or wants to scaffold a CAVE-fork sim app or fold one into the nomicon (any of).

2026-07-100

cave-teams

sancovp/promptworld

WHAT: Spin up a programmatic agent TEAM on the fly from a spec — mixed Claude-Code (claude -p, subscription) leaders + cheap MiniMax workers — with a LIVE WEB GALLERY that shows each agent in its own window as it works. cave-teams is a STANDALONE library (claude -p + MiniMax + files; no running CAVE required); it optionally streams its event seam to a gallery, a CAVE Channel, or Discord. WHEN: when you need to launch a sub-team to do parallel/heterogeneous work and watch it live — equip when spawning a team, unequip when done. Triggers: spawn a team, run a team, cave-teams, agent squadron, watch the agents, team gallery.

2026-07-100

wield-the-tome

sancovp/promptworld

WHAT: how a PromptWorld wizard WIELDS the SkillTome — consult the author's tome (which framework fits this task?), route through a framework's volume row, run the skill2framework chapter chain on something you built, and FOLD the finished framework into a tome (a code op, skilltree fold). WHEN: when a task smells like an existing framework might cover it; when a build is finished and should become a chapter; when the user mentions the tome, the nomicon, folding, a volume, or 'which of my frameworks fits this' (any of).

2026-07-100

install-promptworld

sancovp/promptworld

WHAT: the deploy WIZARD for PromptWorld — YOU (the agent) build the docker image and boot a container running the whole system (the Engineer-CEO that has every skill + a native subagent per component type, the 7 PromptGym specialist agents, the assistant-ui chat + Monaco file explorer + an embedded terminal), find the Claude credentials on THIS machine, copy them into the container at boot, and then just hand the user a URL. WHEN: when the user wants to install / run / launch / boot / spin up / deploy PromptWorld, or says 'set up promptworld', 'start promptworld', 'boot the promptworld container' (any of).

2026-06-080

name

ingest-into-tome-app

description

ingest-into-tome-app — drop a Claude-Code dir → get a sidecar PromptWorld app

("nomicon" is the legacy name; this skill was ingest-into-nomicon-app.)

This is the top rung of the tome ladder (info → prompt → skill → rules → AIOS → framework → fold-into-tome → APP). The produced artifacts keep the PROVEN {NAME}-nomicon naming conventions below (the dogfooded my-way pipeline) — the tome-vocabulary artifact names arrive when the DIY chain (skilltree fold) replaces the my-way fold in this flow. Everything below this rung already exists and is dogfooded E2E; this skill is the orchestration that composes them into one flow. You run THREE stages in order. Each stage's heavy lifting is a canonical piece you DISPATCH — you are the orchestrator, not the hands.

Inputs (filled at invocation)

SOURCE_DIR — the Claude-Code system directory to ingest (holds AIOSes: CLAUDE.md(s) + .claude/skills + .claude/rules, or a doc-mirror repo).
NAME — the new app/nomicon name (e.g. acme). Produces {NAME}-nomicon.
AUTHOR — the author token for the nomicon (the {user} in fold-into-nomicon).
WORKSPACE — the PromptWorld workspace root the app runs over (defaults to the new app's dir).

STAGE 1 — INGEST (copy the dir into the workspace; trivial)

Copy SOURCE_DIR into the app workspace as the new app's source tree. This is a plain filesystem copy into the path-jailed PromptWorld workspace (server/file_api.py jails every op to the workspace root) — never a mount of an outside path. The ingested dir's AIOS subdirectories (each a CLAUDE.md + .claude/) become the candidate specialist-agent dirs for STAGE 3. (Mechanism mirrors _ingest.md: "ingest = copy a dir into the bind-mounted workspace volume".)

STAGE 2 — CONVERT (the dir → a {NAME}-nomicon; run the existing UP pipeline)

Pinned names + paths (NON-NEGOTIABLE — these prevent a real name-collision + an atomize footgun; learned from the E2E)

Use EXACTLY these, do not improvise (the underlying prompts disagree on names; pin them here):

Holder (the app's nomicon) → {NAME}-nomicon at <app>/nomicon/{NAME}-nomicon/SKILL.md — its OWN dir, NOT inside the deploy skills/.
Framework skill (per AIOS) → {AUTHOR}-framework-{aios} (e.g. sancovp-framework-acme) — this is the PROVEN dogfood convention; do NOT use {aios}-nomicon (the generate-framework-skill prompt's default), because when the app has ONE AIOS named like the app it COLLIDES with the holder {NAME}-nomicon.
Atomize target (the deploy dir) → <app>/skills/ — a DISTINCT dir that does NOT contain the holder. NEVER atomize into the dir that contains the holder: nomicon-atomize will rmtree + self-symlink the holder and DELETE it (the bin's self-symlink guard only covers the inverse nesting — see the footgun note).

For EACH AIOS discovered in the ingested dir, run the already-dogfooded skill2framework pipeline by searching the prompt-store and dispatching each prompt-skill with its specifics: docmirror search "<step>" --corpus prompts → dispatch (the doc-mirror-prompts one-line form), in ORDER:

skill2framework/blog-organ/narrative-blog-from-aios — Blog1 (narrative) from the AIOS.
skill2framework/deep-dive/deepdive-blog-from-impl-docs — Blog2 (deep-dive) from its impl docs.
skill2framework/chapter/assemble-chapter — combine Blog1+Blog2 + CTAs + cross-links.
skill2framework/framework-skill/generate-framework-skill — the framework index/decision-tree/router skill. OVERRIDE its output name to {AUTHOR}-framework-{aios} (per the pinned names above), NOT {aios}-nomicon.
skill2framework/plugin/package-framework-plugin — the self-contained framework plugin (its skill dir = the framework skill's real frontmatter name {AUTHOR}-framework-{aios}, not the prompt's hardcoded default).
skill2framework/tome/fold-into-tome (the stage's current name/path; was nomicon/fold-into-nomicon) — fold the framework into the holder (create it if absent; idempotent one row per framework). Pass {user}=AUTHOR, {nomicon_dir}=<app>/nomicon/{NAME}-nomicon.

Then project the held frameworks flat so agents auto-discover them — into the DISTINCT deploy dir: nomicon-atomize <app>/nomicon/{NAME}-nomicon/SKILL.md <app>/skills (canon stays the source of truth; the deploy dir is relative symlinks to the holder + each framework skill — see the nomicon-atomize docstring).

Atomize footgun (verified): nomicon-atomize <holder> <target> self-symlinks the holder into <target>; if <target> is the dir CONTAINING the holder, author_dest == the holder dir and the bin rmtrees it → the holder is destroyed. ALWAYS atomize into a separate dir (the pinned <app>/skills/). (Bin guard gap tracked as a doc-mirror-system finding.)

VERIFY each hop's artifact yourself (the dispatched agent's report is a claim) — per prompt-skill discipline, these are GOLDEN/1.00 so a SANITY check of each produced file suffices; drop to FULL_E2E on any miss. After atomize, CONFIRM the holder SKILL.md still exists and the deploy symlinks resolve.

STAGE 3 — AGENTIFY (the {NAME}-nomicon → a runnable sidecar PromptWorld app)

Stand up a PromptWorld instance whose:

CEO carries {NAME}-nomicon as its world-model — make the holder discoverable in the CEO's config by atomizing it into the CEO's skills dir: nomicon-atomize <app>/nomicon/{NAME}-nomicon/SKILL.md <ceo_config>/skills (a DISTINCT dir from the holder — safe). The CEO then meshes with the framework set and routes tasks into the right framework (_nomicon.md v2: "the agent has the -nomicon which lets them mesh with the user way of thinking").
Specialist agents = the ingested AIOS dirs — each ingested AIOS subdir is already a scoped AIOS directory (the directory-codes-the-agent model, VERIFIED: p_main_agent.py config_dir→CLAUDE_CONFIG_DIR), registered with PromptGym so it runs scoped to its dir and streams to the gallery.
runs over WORKSPACE and serves the SPA + file-explorer + gallery (the existing PromptWorld server).

The container/packaging half (Dockerfile, docker-compose with neo4j, the install wizard, --strict-mcp-config, clean container ~/.claude) is the deployment boundary (packaging #1) — hand off to it; do not inline it here. This skill's terminal artifact = a runnable app DIRECTORY (nomicon + agent dirs + server config) that a local python -m server --dir <app> boots.

VERIFY (the whole flow, E2E — the only proof)

Run the flow on a SMALL real Claude-Code dir and confirm, by your own checks: (1) <app>/nomicon/{NAME}-nomicon/SKILL.md exists with a ## Frameworks table holding one row per ingested AIOS, each row's links resolving, and it SURVIVED atomize (was not self-clobbered); (2) the deploy <app>/skills/ dir's symlinks resolve (the holder + each {AUTHOR}-framework-{aios}) and auto-discover; (3) the PromptWorld app boots over the new dir and its CEO, asked "which of your frameworks fits ?", routes via the nomicon. Capture the literal output. Mark IS / UNKNOWN honestly.

Canonical references (resolve by design, not by accident)

The UP pipeline: doc-mirror-prompts → resources/prompts/skill2framework/* (provisioned with doc-mirror).
nomicon-atomize (doc-mirror plugin/bin/) — flat projection of a nomicon.
The PromptWorld app: application/promptworld/ (server, PromptGym, p_main_agent.py scoping, file_api jail).
Design: docs/vision/_ingest.md, _nomicon.md; doc-mirror-system docs/vision/_framework-to-nomicon.md.