Menu
Use when writing, drafting, or publishing a blog article for metraton.github.io
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when constructing or interpreting the approval handoff envelope between subagent and orchestrator -- sealed_payload schema, approval_id format, APPROVAL_REQUEST contract shape, and reading a granted approval from the DB
Use when producing any agent response
Use when classifying any operation before executing it, or deciding whether user approval is required
Use when a mutative command was blocked by the hook and you need to request user approval, or when presenting a plan for a T3 operation before executing it
Use when the user wants to build, design, or extend a diagram — an architecture overview, a timeline, a planner board, a flow diagram, a presentation, a comparison, or a mind-map — as a portable, data-driven deck rendered from plain YAML. Triggers — "build a diagram", "architecture diagram", "diagram deck", "timeline", "flow diagram", "planner board", "add a page/section/component to the diagram".
Use when the user wants something to run routinely / on a schedule rather than once now -- "tarea programada", "rutinariamente", "cada mañana", "cada N horas", "todas las noches", "schedule", "cron". Covers mounting, structuring, and running an unattended headless task that reports back, plus consuming its reports. NOT for a live in-session agentic loop (that is agentic-loop).
| name | blog-writing |
| description | Use when writing, drafting, or publishing a blog article for metraton.github.io |
| metadata | {"user-invocable":true,"type":"technique"} |
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.
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.
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.
Write the first draft in Markdown at /home/jorge/ws/me/<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):
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.
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: /home/jorge/ws/me/metraton.github.io/_posts/YYYY-MM-DD-slug.html
Before publishing, pass through both language versions checking:
— ’ é etc.)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.
Commit and push to master in the blog repo. GitHub Pages deploys automatically.
Wait ~45s after push for GitHub Pages to build. Use Playwright to screenshot the live URL and compare against the localhost preview.
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.