agentleFS
metratonmetraton/gaia/skills/blog-writing/SKILL.md

blog-writing

Skill4 starsChanged 5 months agoMITView on GitHub

Use when writing, drafting, or publishing a blog article for metraton.github.io -- "escribe un post para el blog", "publica un artículo", "write a blog post", "draft an article for the blog".

7 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 8 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every article starts with something that actually happened -- a deployment that went sideways, a late-night refactor, a conversation that …

    line 14
  2. Distinctive:

    Ask Jorge: "What happened recently that surprised you or changed how you think about something?" The best topics come from moments where …

    line 16
  3. Distinctive:

    Before writing a single paragraph, define: title, audience, core thesis (one sentence), and format.

    line 20
  4. Very specific:

    Write the first draft in Markdown at <workspace>/<slug>.md.

    line 26
  5. Distinctive:

    Each section adds something new: Do not repeat the same example or insight across sections.

    line 41
  6. Distinctive:

    Before publishing, pass through both language versions checking:

    line 57
  7. Distinctive:

    No broken anglicisms ("marcar" not "flagear")

    line 62
  8. Very specific:

    Ensure Jekyll is running locally (see reference.md for environment details).

    line 67
  9. Distinctive:

    Commit and push to master in the blog repo.

    line 71
  10. Distinctive:

    Wait ~45s after push for GitHub Pages to build.

    line 75

≈ “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

Blog Writing

Jorge's blog (metraton.github.io) is where he thinks out loud about agentic systems, context engineering, and the intersection of architecture and AI. The articles are bilingual (English and Spanish), grounded in real experience, and written in first person. They are not corporate content -- they are reflections from someone building these systems daily. The register is human-register's; this skill owns the article's process and voice.

The Writing Process

1. Find the story first

Every article starts with something that actually happened -- a deployment that went sideways, a late-night refactor, a conversation that shifted your thinking. The story is the anchor. Without it, you are writing a tutorial, not an article.

Ask Jorge: "What happened recently that surprised you or changed how you think about something?" The best topics come from moments where the outcome was different from the expectation.

2. Build the brief

Before writing a single paragraph, define: title, audience, core thesis (one sentence), and format. Jorge's natural format is Strategic Insight -- personal experience analyzed through a technical lens, ending with a transferable lesson.

The audience is engineers, solution architects, AI practitioners, and tech leaders. They do not need hand-holding but they appreciate honesty about what did not work.

3. Draft in Markdown, iterate with Jorge

Write the first draft in Markdown at <workspace>/<slug>.md. Work section by section -- do not dump an entire draft and ask "what do you think?" Each section should be reviewed before moving to the next.

Article structure (not rigid, but this is Jorge's natural flow):

  • Opening story -- what happened, told personally
  • The problem -- what was broken or surprising
  • Investigation -- what you looked into and found
  • The shift -- the insight or reframe
  • In practice -- what changed, concretely
  • Results -- evidence it worked
  • Closing thought -- punchy, memorable, one line

4. Principles that matter

Examples must be real. Not "imagine a team that..." but "I was deploying to Cloud Run when..." If you cannot point to something that actually happened, the example does not belong.

Each section adds something new. Do not repeat the same example or insight across sections. If the investigation section already showed the problem, the "in practice" section should show the solution -- not restate the problem.

Quotes add weight when grounded. Citing Anthropic, Hinton, or other thought leaders works when the quote connects directly to the experience. A quote floating without context is decoration.

Technical terms stay in English in both languages. LLM, skills, agent, Cloud Run, Terraform -- these do not get translated.

Closing lines are signatures. "Built with context.", "Built with reasoning." -- short, confident, tied to the article's thesis.

5. Convert to bilingual HTML

Once the Markdown draft is approved, convert to the bilingual HTML format. The Spanish version is not a mechanical translation -- it is natural Latin American Spanish, with the same voice and directness. Read reference.md for the HTML template and front matter structure.

Final HTML goes in: <workspace>/metraton.github.io/_posts/YYYY-MM-DD-slug.html

6. Editorial review

Before publishing, pass through both language versions checking:

  • Spelling, grammar, flow, and consistency
  • HTML entities are correct (&mdash; &rsquo; &eacute; etc.)
  • Technical terms stay in English in the Spanish version
  • Gender consistency for borrowed terms ("los skills" not "las skills")
  • No broken anglicisms ("marcar" not "flagear")
  • Citations link to real, accessible URLs

7. Visual verification

Ensure Jekyll is running locally (see reference.md for environment details). Preview at localhost:4000. Use Playwright to take screenshots at desktop (1280x900) and mobile (375x812). Check that all visual components render, no horizontal overflow, responsive breakpoints work.

8. Publish

Commit and push to master in the blog repo. GitHub Pages deploys automatically.

9. Live verification

Wait ~45s after push for GitHub Pages to build. Use Playwright to screenshot the live URL and compare against the localhost preview.

10. LinkedIn post

Draft a sharing post: 1-3 sentence personal hook connecting to the article's insight, the link, and a bilingual P.D. See reference.md for the template. Conversational but technical tone, no aggressive hashtags -- the article preview image does the heavy lifting.

Jorge's Voice

  • First person, always. "I was deploying..." not "The team deployed..."
  • Honest about failures and iterations -- does not pretend things worked the first time
  • Confident but not preachy. States what he found, not what everyone should do
  • Direct. Short sentences when making a point. Longer when telling a story
  • Latin American perspective -- references to the region's tech community are natural, not forced

Anti-Patterns

  • Writing generic content that could appear on any corporate blog
  • Translating English to Spanish mechanically instead of rewriting naturally
  • Dumping an entire draft without iterating section by section
  • Using hypothetical examples when real ones exist
  • Repeating the same insight across multiple sections

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.