Cesar / Gomez
←Back to insights
My AI Engineering Workflow: Skills, MCP Servers, and an LLM Wiki
October 31, 2026AI Engineering

My AI Engineering Workflow: Skills, MCP Servers, and an LLM Wiki

TL;DR: My AI workflow is a small system, not a chat window. Rules live in AGENTS.md, knowledge lives in an LLM wiki behind an MCP server, and repeatable jobs live in agent skills. In 16 weeks it helped cut a production Sentry backlog by 48%, from 202 to 105 unresolved issues.

A chat session forgets everything

Every new AI session starts cold. It does not know your architecture rules, last week's incident, or the mistake you corrected yesterday.

I needed three things the chat window does not give you:

  • Instructions that every tool reads the same way
  • Memory that survives between sessions and between people
  • Repeatable jobs that run the same way every week

The system has four parts

The loop closes at the wiki. Every investigation and plan the agent produces becomes a page the next session can search.

Part 1: AGENTS.md is the single source of rules

I keep one canonical AGENTS.md per repository. CLAUDE.md and GEMINI.md are thin pointers to it. Claude Code, opencode, and Antigravity all read the same rules.

For a large Rails monolith I did not write one giant file. I wrote a short AGENTS.md with a routing table, plus eight focused guides:

  • Architecture layers and the allowed calls between them
  • 17 named code patterns, each with a trigger such as "when you open a transaction"
  • Refactoring rules and a payments domain guide

The agent reads only the guide that matches the task. A small linter checks the structure of the docs, so they do not drift.

Part 2: The memory index stays small on purpose

Claude Code loads a MEMORY.md index at the start of every session. It rots fast. Old ticket facts pile up, and some entries contradict each other.

My rules:

  • Short facts go inline in the index, not in separate files
  • The agent asks for confirmation before it writes or edits a memory
  • I review the index every few weeks and delete what is stale

A wrong memory is worse than no memory. The agent trusts it.

Part 3: An LLM wiki behind an MCP server

The wiki is a plain Markdown repository. It holds incident investigations, plans, post-deploy verifications, decisions, and weekly triage snapshots.

I wrote a small MCP server, llm-wiki-mcp, with 21 tools. It enforces the schema in code instead of in a prompt:

  • Every page needs frontmatter or the write is rejected
  • Related pages link to each other in both directions
  • Decision records get sequential numbers

Before the agent investigates a bug, it searches the wiki. In five months the wiki grew to 85 incident investigations, 49 plans, and 33 post-deploy verifications.

Part 4: Agent skills run the repeatable jobs

A skill is a folder with instructions that an agent loads on demand. I keep mine in a plugin marketplace with 22 skills across 9 plugins:

  • Sentry triage and ticket drafting
  • Bug investigation and post-deploy verification
  • Planning and code review
  • Datadog dashboard reports

The marketplace installs into Claude Code and into opencode. My team uses these skills too.

Guardrails matter more than prompts

A clever prompt fails on a bad day. A guardrail does not. These are the ones I rely on:

  • Approval before side effects. The ticket skill drafts tickets and waits for my yes.
  • Dry run by default. Admin commands that change data show the plan first.
  • Read-only access where writing is not needed, such as the Sentry connection.
  • Schema checks in code. The wiki server rejects bad pages, whatever the agent intended.
  • Secrets stay in environment variables. They never enter a prompt or a chat.

Case study: Sentry triage that cut a backlog by 48%

Our payments Sentry project had a backlog nobody owned. I built a weekly triage skill and an epic to track the fixes.

Each weekly run does five things:

  1. Pulls unresolved issues for the team
  2. Classifies each one as active, re-opened, stale, noise, or background
  3. Groups issues by root cause
  4. Writes a report to the wiki
  5. Drafts Jira tickets for my approval

The results, from my weekly reports:

  • Unresolved issues fell from 202 to 105 between July 5 and October 26
  • Active issues fell from 128 to 86
  • The epic grew to 94 tickets, and 74 are done
  • Event volume fell about 42%, from roughly 250k to 144k, between August 10 and September 21

Read these numbers with care. Part of the drop comes from resolving stale and noisy issues, not from code fixes. New issues still arrive at 7 to 24 per week. The backlog is smaller, not gone.

What I learned

  • Short rules files beat long ones. A routing table keeps the agent focused.
  • Memory needs pruning. Treat the index like code and review it.
  • Make the agent show its work. Reports with sources in the wiki are easy to check.
  • Count what you can. I did not measure hours saved, so I do not claim any.

Tools I use

Claude Code is my daily driver. I also use opencode and Antigravity. Because the rules live in AGENTS.md and the skills live in a marketplace, I can switch tools without rewriting anything.

Start small

  1. Write an AGENTS.md with the 10 rules your agent keeps breaking.
  2. Add a CLAUDE.md that points to it.
  3. Turn your most repeated task into a skill with an approval step.
  4. Save the results as Markdown where the agent can search them.

Do these four steps in a week. Then decide what to build next, based on what the agent keeps getting wrong.