Create

Skill anubhavmohandas/Hermes/skills/create

HERMES deliverable-creation orchestrator. Apollo routes here whenever the user wants something MADE — a presentation, report, spreadsheet, PDF, website, web app, mobile app, tool, or research brief. Runs the intake interview from prompts/<type>.md, confirms the brief, routes to the executing skill, verifies the output exists, logs it, and delivers. One flow, every deliverable.From its SKILL.md

Install

npx -y skills add anubhavmohandas/Hermes --skill create

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.4 KB, as published. Nobody here has run it

skills/create — intake-first deliverable flow

Called by Apollo, not directly by the user. This is the "one person uses HERMES and gets a working result" layer: interview → brief → build → verify → deliver. Never skip to building.

1. Detect the deliverable type

User asks for…	Load
presentation / deck / slides / pptx	`prompts/presentation.md`
report / memo / paper / write-up / docx	`prompts/report.md`
spreadsheet / excel / budget / tracker / xlsx	`prompts/spreadsheet.md`
pdf / fill form / merge / split	`prompts/pdf.md`
website / landing page / web app / dashboard / frontend	`prompts/website.md`
mobile app / android / ios / react native	`prompts/mobile.md`
tool / script / CLI / utility / automation	`prompts/tool.md`
research / investigate / deep dive / find out	`prompts/research.md`
plan / brainstorm / design review / roadmap	`prompts/plan.md`
blog / post / marketing copy / resume / cover letter	`prompts/content.md`

Ambiguous ("make me something for my client meeting")? Ask which, with the options — don't guess.

Type not in the table? Say there's no intake file yet, offer the closest one, and note that adding prompts/<newtype>.md + an Apollo routing row is the extension path (see prompts/README.md).

2. Intake interview

Read the type's prompts/<type>.md.
Strike every intake question the user's request already answered.
Ask ALL remaining questions in ONE grouped message — required first, optional after, numbered, answerable in one reply. Tell the user "your call" is a valid answer for optionals.
No drip-feed interrogation. One round; at most one follow-up round if a required answer is missing or contradictory.

3. Confirm the brief

Echo back a compact brief — "Building: [what] for [audience], goal [goal], [length/stack/format], style [style]" — and get a yes or an adjustment BEFORE building. This is the cheap moment to be wrong.

3b. Scaffold `hermes/` (website / mobile / tool types only)

Only for deliverable types that produce a standalone code project — website, mobile, tool. Skip for presentation/report/spreadsheet/pdf/ research/plan/content — those aren't codebases with an execution flow to track.

Check first, idempotent: if hermes/decisions.md already exists at the project root, do nothing — this runs once per project, ever. Never overwrite, never create a second dated copy.
Otherwise, create hermes/decisions.md and hermes/flow.md from skills/create/templates/decisions.md.template and flow.md.template, substituting {{PROJECT_NAME}}.
Mention it once to the user in the delivery summary (§5) — don't make a separate announcement.

Ongoing discipline once these exist (this session and every future one — hooks/apollo_gate.sh reminds every turn when the files are present):

Append a decision to hermes/decisions.md for any non-obvious call (library choice, architecture, rejected alternative) — never a new dated file.
Update hermes/flow.md when the entry point or call order actually changes — not on every edit.
Before presenting a major change (new dependency, architecture shift, breaking change) for the user to accept, quiz yourself on it first: can you state what it does, why this approach over the alternatives, and what it risks? If not, you're not ready to ask for acceptance yet.

4. Execute

Follow the file's Execution section step by step. Non-negotiables:

The route targets in the file are real: installed skills live in ~/.claude/skills/ (docx, pptx, xlsx, pdf, ui-ux-pro-max, slides, design, frontend-design, theme-factory, web-artifacts-builder, webapp-testing, canvas-design, brand, banner-design, ui-styling, design-system). If one is missing, SAY SO and degrade honestly (markdown outline instead of a fake .pptx) — Invariant #5.
Outline/structure checkpoints in the Execution steps are real user checkpoints, not rhetorical.
Tier discipline still applies: Apollo already ran brain.py check; sensitive content stays Tier 1/2 (that includes slide content and report data, not just queries).

5. Verify, log, deliver

Verify: the promised artifact exists (file check / build runs / tests pass — whatever the type's Execution section names). Never report success on a skill's word alone.
Log: Mnemos write ("created <type>: <path> — <one-liner>") and the ReasoningBank entry per Apollo §2 — honest reward.
Deliver: path + short summary + one offered revision round.

Ground rule

This skill owns the FLOW, not the craft. Content quality comes from the templates in prompts/, design intelligence from the installed design skills, file generation from the document skills. If a step produces something weak, fix it through the type's own polish/clarity pass (most files have one) — don't freelance a new pipeline mid-task.