agentleFS
robium-airobium-ai/robium/skills/app-publishing/SKILL.md

app-publishing

Skill93 starsChanged 3 months agoMITView on GitHub

Publish a tested Robium application as a coherent project page, article, and media set.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the app manifest, README, architecture record, case study, and run artifacts before changing copy or visuals.

    line 15
  2. Very specific:

    Keep runtime and capability facts in robium-app.yaml, article framing and media in docs/case-study.md, and current availability in the …

    line 17
  3. Distinctive:

    Read editorial-system.md for drafting or revising prose, and article-starter.md when creating a portable case study.

    line 32
  4. Distinctive:

    Read asset-workflow.md when preparing the hero, system diagram, social card, motion, or optional conceptual art.

    line 43
  5. Distinctive:

    Read visual-system.md when styling project surfaces.

    line 53
  6. Distinctive:

    Every public claim traces to repository-owned facts or a scoped real run.

    line 60

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

App publishing

Let the application and its real runs own the facts; publishing gives those facts one clear public identity.

Start from recorded reality

  • Publish only after the application's normal smoke passes. If the story presents a hosted path, its hosted smoke must pass too.
  • Read the app manifest, README, architecture record, case study, and run artifacts before changing copy or visuals.
  • Keep runtime and capability facts in robium-app.yaml, article framing and media in docs/case-study.md, and current availability in the website.
  • Read publication-contract.md when adding metadata, joining app and article records, or deciding which repository owns a field.

Tell one human story

  • Lead with the result, tension, or decision that makes this app worth reading. State run conditions next to the claims they qualify.
  • Explain the decisions a reader cannot infer from the README. Keep one tested path and leave exhaustive commands and troubleshooting in the app.
  • Cover the outcome, decision, important system boundaries, tested path, result, Robium's contribution, and limits without forcing identical public headings.
  • Read editorial-system.md for drafting or revising prose, and article-starter.md when creating a portable case study.

Use media honestly

  • Real-run media shows what happened. A diagram explains how the pieces connect. Generated art may illustrate a concept but must not resemble or replace application output.
  • Preserve the conditions and source record behind captures. Use literal alt text and captions that say whether a frame is simulated, recorded, or live.
  • Read asset-workflow.md when preparing the hero, system diagram, social card, motion, or optional conceptual art.

Keep the surfaces coherent

  • Overview, Live, Guide, cards, metadata, and source links share one app ID, project identity, navigation, status vocabulary, and visual language.
  • Reuse the project shell and lifecycle components. Keep a special robot viewer or result panel in a small adapter until a second consumer proves it belongs in shared code.
  • Read visual-system.md when styling project surfaces. Do not leak parent styles into embedded Gradio, Foxglove, Lichtblick, or other tools.
  • Route gateway, orchestrator, and cloud runtime mechanics to live-demo.

Done

  • Every public claim traces to repository-owned facts or a scoped real run.
  • The application, article, metadata, and media join on one stable identity.
  • Overview, Guide, and Live states work on desktop and mobile, including a readable unavailable state.
  • Deployment, paid capacity, production enablement, and external publication remain separately authorized actions.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.