Use when creating or updating README.md files for Oliver's public repositories. Apply this skill any time you are about to write or edit a README — even if the user just says "document this", "add a README", or you're creating a new public-facing project. Also triggers for "write a README", "update the README", "improve README", "make the README better", "brand the repo", "add docs to this repo", or "make this look professional on GitHub". Provides Oliver's personal brand identity, structure conventions, and quality bar for GitHub READMEs.
npx claudepluginhub oliverames/ames-claude --plugin ames-standalone-skillsThis skill uses the workspace's default tool permissions.
Oliver's public GitHub READMEs serve as marketing pages. They should feel
Provides Ktor server patterns for routing DSL, plugins (auth, CORS, serialization), Koin DI, WebSockets, services, and testApplication testing.
Conducts multi-source web research with firecrawl and exa MCPs: searches, scrapes pages, synthesizes cited reports. For deep dives, competitive analysis, tech evaluations, or due diligence.
Provides demand forecasting, safety stock optimization, replenishment planning, and promotional lift estimation for multi-location retailers managing 300-800 SKUs.
Oliver's public GitHub READMEs serve as marketing pages. They should feel professional, strategic, and branded — like they could be an official product page for the service they interface with, while clearly being Oliver's work.
Who: Oliver Ames — content strategist, software tinkerer, and video producer in Montpelier, Vermont.
Site: ames.consulting
Voice: Professional but approachable. Technically deep but accessible. Explain the "why" behind decisions, not just the "what." Show strategic thinking. Never generic or corporate-bland.
Visual brand (from ames.consulting):
#f5a542) — use for badges and highlightsSupport link: https://www.buymeacoffee.com/oliverames
Social links:
https://github.com/oliverameshttps://linkedin.com/in/oliverameshttps://bsky.app/profile/oliverames.bsky.socialhttps://ames.consultingEvery public repo README should follow this structure. Adapt section depth to the project — a 310-tool MCP server warrants more detail than a simple utility script.
<p align="center">
<!-- Icon or logo for the product/service this project integrates with -->
<img src="icon.png" width="80" height="80" alt="Project Name">
</p>
<h1 align="center">Project Name</h1>
<p align="center">
<strong>One-line value proposition — what it does and why it matters</strong>
</p>
<p align="center">
<code>key stat</code> •
<code>key stat</code> •
<code>key stat</code>
</p>
Use the official icon/logo of the product the project interfaces with (Meta, UniFi, YNAB, etc.) when available. For original projects, use the project's own icon.
Always include these badges in this order:
<p align="center">
<a href="https://www.npmjs.com/package/PACKAGE_NAME">
<img src="https://img.shields.io/npm/v/PACKAGE_NAME?style=flat-square&color=f5a542" alt="npm">
</a>
<a href="LICENSE">
<img src="https://img.shields.io/badge/license-MIT-f5a542?style=flat-square" alt="License">
</a>
<a href="https://www.buymeacoffee.com/oliverames">
<img src="https://img.shields.io/badge/Buy_Me_a_Coffee-support-f5a542?style=flat-square&logo=buy-me-a-coffee&logoColor=white" alt="Buy Me a Coffee">
</a>
</p>
Rules:
color=f5a542 (Oliver's brand amber) for all badge colorsstyle=flat-square for all badges---
Brief description (2-3 sentences). What the project does, who it's for, and
what makes it different from alternatives. Lead with value, not implementation.
Frame the project strategically. Not "I built this because I wanted to" but rather what problem it solves and the thinking behind the approach. Show the strategic reasoning — this is what separates Oliver's repos from generic open source projects.
For MCP servers: explain why an AI assistant needs deep access to this particular service, and what becomes possible.
For apps: explain the user problem and why existing solutions fail.
Immediately actionable. For MCP servers, this is the JSON config block. For apps, it's the install command. For libraries, it's the import + first call.
This varies by project type but should show depth and breadth:
For MCP servers:
For apps:
For libraries/utilities:
Tables for environment variables, config options, CLI flags. Use this format:
| Variable | Required | Default | Description |
|----------|----------|---------|-------------|
| `VAR` | Yes | — | What it does |
File tree with annotations. Show the design thinking.
How to build, test, and contribute.
---
<p align="center">
<a href="https://www.buymeacoffee.com/oliverames">
<img src="https://img.shields.io/badge/Buy_Me_a_Coffee-support-f5a542?style=for-the-badge&logo=buy-me-a-coffee&logoColor=white" alt="Buy Me a Coffee">
</a>
</p>
<p align="center">
<sub>
Built by <a href="https://ames.consulting">Oliver Ames</a> in Vermont
• <a href="https://github.com/oliverames">GitHub</a>
• <a href="https://linkedin.com/in/oliverames">LinkedIn</a>
• <a href="https://bsky.app/profile/oliverames.bsky.social">Bluesky</a>
</sub>
</p>
The footer Buy Me a Coffee badge uses style=for-the-badge (larger) vs
the header badges which use style=flat-square (compact).
Before shipping a README, verify:
When the project integrates with a specific product (Meta, UniFi, YNAB, Sprout Social, Image Relay), the README should feel native to that ecosystem: