Basic Cohub abilities. Most agents already have these mounted; listed here for reference.
Platform Published by the Neta team.
Official Made by the Neta team.
Verified Reviewed by the Neta team.
Community Shared by a Cohub user. Not reviewed — read SKILL.md before you use it.
character-relationship-poster
Officialneta-search/character-relationship-poster
Use it in Cohub
Paste this into your agent's chat — it fetches the skill and follows it.
Use the skill: character-relationship-poster. Run `npx -y @neta-art/neta-search-cli@latest skills use neta-search/character-relationship-poster --via site` and follow what it prints. Read its complete output, redirecting it to a temporary file first if necessary, and resolve relative paths from the skill directory it prints.
npx -y @neta-art/neta-search-cli@latest skills use neta-search/character-relationship-poster
Summary
Turn your world's cast into one poster showing who is connected to whom, with colour-coded relationship lines.
Get a single image with portrait cards for up to 15 characters, linked by lines that carry short labels like rival or ally.
Line colours show the type of relationship, and a small legend on the poster explains each colour.
Put a chosen character in the middle, or let the most connected character take the centre.
Uses only the relationships your world actually states, and the faces come from your existing character images.
Works best with a world that has several characters with written bonds. If you have more than 15, the least connected are left out and you're told.
SKILL.md
# Character relationship poster
One generated **image** that shows who is connected to whom in this world: portrait cards for up to 15 characters, lines between them coloured by relationship type, and a small legend.
**Reply language — check before every line you write to the user:** every message in this conversation — the opening line, short progress notes between tool calls, the summary, the left-out list, follow-up turns ("is it ready?", a fix report) and the closing options — is written in the language the user wrote in. This file being in English, or the tool output being in English, never switches you to English. If the user writes in Chinese, every sentence is Chinese; only names and the poster's own labels are quoted as they appear.
## Requirements
This skill decides *what* the image is; the neta platform's `generate` skill does the generating.
- Read `/mods/neta/.agents/skills/generate/SKILL.md` and `/mods/neta/.agents/skills/generate/playbooks/image.md` first and follow their core loop (model declaration, character references, submit, reply). Everything below runs inside that loop.
- If `/mods/neta` does not exist in this world, tell the user image generation is not available here and stop.
## Steps
1. **Collect the cast and relationships.** Read the world through the neta CLI, run from the world root (`/workspace`): `world/WORLD.md` for the world itself, `node /mods/neta/neta atom list --type character` for the cast, then `atom get <id>` for each character (the body holds who they are and who they relate to) and the other atoms that link them (`atom list`, `atom list --query <name>`). Do not start from `manifest.json`: in current worlds its `atoms` list is empty. Only in an older world where `atom list` returns nothing and `manifest.json` still lists `atoms`, read the characters from there. Use only relationships the world actually states. If the user named a central character, put them in the middle; otherwise pick the most connected one.
2. **Keep it to 15 characters or fewer.** If the world has more, keep the ones with the most relationships and say which were left out.
3. **Find references** exactly as `generate` says. Use the images that already exist (character covers, existing reference images) — do not generate new reference sheets, portrait grids or profile cards first, even though the template mentions them as troubleshooting.
4. **Fill the template** at `/mods/neta/.agents/skills/generate/references/image/character-relationship-poster.md`. Follow its rules, especially the reference mapping: list `Reference image N = <Character>` in the same order as the `@` references, so faces do not get swapped. Keep the legend.
- **Word it so it renders.** Image providers reject prompts on wording, and a rejected poster never exists. Describe villains and conflicts in plain, non-graphic terms: line labels like "rival", "opposes", "serves"; looks as hair, clothing and colours only. No gore, killing, torture, fanatic or blood-oath wording, and no disfigurement or body-horror descriptors (missing features, mutilation, monstrous deformity), even where the world's lore uses them.
- Keep scratch files such as the prompt draft in `/tmp` (or pass the prompt inline). Never write them into the world or the run's output folder. The poster Work is the only thing this skill delivers.
5. **Submit** through the `new` branch (`--async`), work title `<World> relationships`. The poster is the only image this skill makes. Keep the Work id from the submit result JSON (`data.outputs[0].work.id`). Any retry or fix goes into that same Work with `--target-work <that id>` — never as a second new Work.
- **Every `--target-work` call passes the same `--work-title` again.** Leave it out and the platform renames the Work to the start of the prompt (e.g. `@Name, @Name, …`). Never re-render a poster that's already done just to fix its title.
- Follow `generate`'s timing: an `--async` submit is the end of the work. Don't sleep and poll, and allow at most one retry after a failure. Then go to step 6 whether the poster is ready, still rendering or failed.
- **Posters already in the world are not yours to touch.** If the world already holds a relationship poster (same title, same cast, an earlier session's render), still make this request's poster as a fresh `new` submit. Don't pass that older Work's id to `--target-work`, don't re-render it, don't hand it over in place of the new one. Leave it exactly as it is. The one exception is a user who explicitly asks to fix *that* existing poster.
- Change Works only through `neta generate`. Never hand-edit `works/*.json`, `manifest.json` or `artifacts/` files, for example to point a Work back at an earlier render. If your retry comes out worse than the first render, keep the retry and tell the user what's off.
6. **Reply and close** the way `generate` says. Hand the poster over with an `interaction-components` **Link** card on its own line, with target `{ "type": "work", "workId": "<id from step 5>" }`. Don't hand it over as a bare Markdown image link, a `world-file` path or a downloaded copy — the card is the handover. Send the card even if the render is still going or failed, with one line saying which (still rendering / failed, needs another pass). A turn that ends without the card has not delivered.
Visible text on the poster follows the user's language, or the language of the world's own documents; names stay exactly as the user or the world writes them. (The reply itself follows the reply-language rule at the top.)
## Not this skill
- An interactive, clickable relationship web page → the `relationship-network` skill (neta-skills).
- One character on their own → `character-design-sheet` or `character-profile-card`.
- Reworking, re-rendering or repointing a poster Work that existed before this request (see step 5). It stays as it was, even if it looks broken.
- Making extra pictures along the way, such as reference cards, portrait sheets, backgrounds or alternate posters saved as separate Works. If faces come out swapped, fix the same poster with `--target-work`: tighten the reference mapping, or use fewer references plus text identity notes. Then tell the user what's still off.