presentify
Skill5 starsChanged 33 days agoMITView on GitHub
Create a self-contained HTML one-page briefing from supplied material.
In this repository18 other files it gives its agents.
- closeSkill
- cloudflare-private-static-siteSkill
- code-frictionSkill
- commitSkill
- debate-claudeSkill
- debateSkill
- delegateSkill
- eli5Skill
- email-triageSkill
- friction-triageSkill
- issuesSkill
- m5-delegateSkill
- magnus-security-reviewSkill
- mimir-searchSkill
- review-pr-codexSkill
- ship-itSkill
- ticket-fleetSkill
- user-test-memorySkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
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
- Very specific: line 17
Run a separate error-review pass before writing the final page.
- Distinctive: line 44
Keep the page concise. Prefer short noun phrases, numbers, and active verbs over source-style paragraphs.
- Distinctive: line 46
Do not mix estimates with final numbers without labeling them.
- Distinctive: line 47
Keep error findings visible but secondary to the executive readout.
- Distinctive: line 48
Use exact dates when the source contains relative timing or stale follow-up dates.
- Distinctive: line 49
Use brand-inspired styling without impersonating a live corporate site or implying official publication unless the user asks for that and …
- Distinctive: line 55
Keep the HTML self-contained unless the user requests a web app or hosted site.
≈ “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.
Files
Presentify
Core Workflow
- Locate and read the source material. If the user provides a folder, search for the named file from that folder first. If duplicates exist, compare hashes or timestamps and state which copy is used.
- Extract the presentation spine:
- title and audience
- executive message in one sentence
- key facts supported by the source
- sections appropriate to the audience and material
- risks, data gaps, and next actions when relevant
- Run a separate error-review pass before writing the final page. For detailed checks, read
references/review-checklist.md. - If the user gives a style-reference URL or brand page, inspect it before designing. Capture reusable signals: color palette, typography feel, spacing density, section patterns, card style, footer/header style, and CTA treatment. Do not copy restricted assets unless the user explicitly provides permission and the asset is appropriate to reuse.
- Build a self-contained HTML file. Prefer a single page that works from
file://with no build step. Useassets/onepager-template.htmlas a starting point when useful. - Validate the output:
- HTML parses without obvious errors.
- CSS is embedded or reliably local.
- The page is compact at desktop width and usable on mobile.
- Any material errors or gaps are visible and distinct from the executive summary.
- Visually inspect the rendered page at desktop and mobile widths before calling it complete.
- The final file is saved in the appropriate deliverables folder, usually
outputs/for projectless sessions.
- Open or hand off the file according to the user request. If they ask to see it in Safari, use the local file path with Safari.
Recommended One-Page Structure
Choose only the elements supported by the source and useful to the audience; this is an optional layout menu:
- Header with title, date/context, and optional brand cue.
- Hero summary with the core message.
- Top facts or metrics strip.
- Main content cards grouped by market, region, topic, or decision area.
- Executive takeaway with 2-4 concise bullets.
- Errors, gaps, and checks found.
- Next actions or items to fix in the next report.
- Small footer with source note and caveat if data is fictional, draft, or incomplete.
Writing Rules
- Keep the page concise. Prefer short noun phrases, numbers, and active verbs over source-style paragraphs.
- Preserve caveats instead of smoothing them away.
- Do not mix estimates with final numbers without labeling them.
- Keep error findings visible but secondary to the executive readout.
- Use exact dates when the source contains relative timing or stale follow-up dates.
- Use brand-inspired styling without impersonating a live corporate site or implying official publication unless the user asks for that and owns the context.
Output Rules
- For projectless sessions, write user-facing deliverables under
outputs/. - Name files clearly, for example
market-input-june-onepager.html. - Keep the HTML self-contained unless the user requests a web app or hosted site.
- Return the output path and any material errors or gaps actually found.
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
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.

