Heads-up — No Theory Here, Just Autonomous Agents That Finish Tasks

A few months ago I kept replaying a scene in my head: I wake up in the morning, send a short message from my phone, and by the time I'm fully awake the code has been written and a PR is open. I don't open my laptop, I don't touch the IDE, I don't even leave the house — and yet the software keeps moving forward.

The moment I left the daydream and asked "how do I actually build this?", I realized the system needs an underlying layer first. You can't keep handing one agent endless context for every task — there has to be something that already teaches it the company.

In this post I'll walk through the system that turned that scene into reality. It's running today, I genuinely use it, and I'll show every layer in order. I'll get technical at points but I won't drown the post in it — the beauty is in how the parts connect.

One agreement up front: the post mentions a fictional company. Let's call it **Bugasoft**. From here on, when I say "Bugasoft" I mean this made-up company — no real-world tie. The system itself is company-agnostic: the same chain works at a 50-person startup or your own solo project.

Start with the pain: agents always begin from zero

When I started working with AI agents I noticed every new conversation was a fresh zero. Project architecture, my coding standards, my commit habits, naming conventions — I had to explain it all over again. A 5-minute job started with 15 minutes of context.

My first attempt was dropping config folders like `.claude/` or `.cursor/` into each project. It worked — but somewhere like Bugasoft with dozens of repos, keeping those in sync becomes a second job. Update one, the rest go stale. Every new joiner gets a "copy that folder over" instruction. Not sustainable.

The real reason: building infrastructure to support a daydream

This is exactly where agent-skills-mcp was born. I didn't build it for the GitHub agent system — I built it earlier, while imagining the scene above. Because for that scene to ever become real, this question had to be answered first:

The answer: don't carry skills as a separate file in every project — serve them from a single source, so every project reads from the same place.

To make that real, I built a server based on Anthropic's open-source SKILL.md format, speaking the Model Context Protocol (MCP): **agent-skills-mcp**. I moved my skills onto it — coding standards, commit conventions, UI/UX guides, repo-specific instructions, the whole catalog.

I open-sourced it instead of keeping it for myself. You can fork it and bring up your own MCP server quickly — it's a ready template for serving your own company's standards. You can take a look here:

So the order really was: I imagined the scene first → built agent-skills-mcp as the underlying layer → then built the rest of the daydream on top of it. Now let me walk through those layers.

Second layer: place it inside GitHub

Once the skill library was running, the next question was: can I run this not just on my own machine, but inside GitHub itself? Could opening a task trigger the agent to step in and do the work?

With Anthropic's official GitHub Action + the Claude GitHub App + agent-skills-mcp, this system was born:

• An @claude mention in a task triggers the workflow
• The agent shallow-clones the repo, connects to agent-skills-mcp, loads the relevant skills
• Reads the task, writes the code, opens its own branch and PR
• Explains in the PR description what it did and why, in Turkish

Where do tasks come from?

This part matters a lot to me, because I didn't want to be limited to a single entry point. Today I can hand work to the agent through three different channels:

**1. GitHub Projects** — GitHub has a Jira-like task management area built in. Board view, columns (Backlog, In Progress, Review, Done), drag & drop. At Bugasoft I track tasks here, and when I want to hand one to the agent I @claude on the same card.

**2. Repo Issues** — The classic route. I open an issue in a repository, the description contains an @claude mention, the workflow fires.

**3. Slack via the Claude app** — This is my favorite. While chatting with the Claude app in Slack I say "open a task in the ui-app repo and assign it to the agent," and it opens the task on GitHub and assigns it. Meaning I don't even have to open GitHub myself.

Tracking and pings via Slack

Coming back later to ask "what happened?" also goes through Slack. Ten minutes later I head to the Claude app on Slack and ask "what's the status of task X?" — it opens the PR on GitHub if needed and gives me a summary.

I can also wire the workflow so the agent pings me on Slack when it's done. So the scene becomes: I say "do this" on Slack → a few minutes later a Slack notification arrives → "PR is here, these are the changes, nothing pending." All of that is possible today — the technical side of the daydream is no longer in the way.

Third layer: organization policy

Here I made a critical choice: instead of redefining the agent's rules in every repository, I gathered them in a single CLAUDE.md inside Bugasoft's central `.github` repository.

Every workflow run pulls that central file and stamps it onto the agent's system prompt. Nothing is written into the caller repository's filesystem. One source, non-overridable, the same rules for everyone.

Some of what that file tells the agent:

• At the start of every task, list the skill catalog and explicitly state which skills are relevant
• Don't force a skill — if none match, plainly say "none"
• Never push directly to main; every change comes as a branch + PR
• All written communication in Turkish (the team language)
• End every task with a footer reporting which skills were used and an estimated token cost

These rules are non-overridable. Even if a repo's own CLAUDE.md tries to contradict the central rules, the central one wins. Repos can extend with project-specific guidance only — they can't loosen the core.

The invisible win: standardization

What I expected from this system was speed. Speed showed up — but the real win turned up somewhere else: standardization.

There's a detail I should mention here: I didn't only connect agent-skills-mcp to the GitHub agent. I'm also connected to the same MCP from my own Claude Code terminal. Meaning:

• When I write code myself (working with Claude Code in the terminal), it reads from the same skills
• When the GitHub agent writes code, it reads from the same skills
• Both sides write to the same standards

The result: regardless of who writes the code, it comes out at the same quality. There's no longer a stylistic gap between a junior's module and a senior's. Bugasoft's **corporate code culture** and **corporate UI/UX culture** are preserved on both sides.

When someone new joins, I don't have to tell them "follow these rules." Their agent will already write code that does. Onboarding shrinks; the code review burden gets lighter.

What's next

The system is currently at "write the code, open the PR" and runs cleanly. The next link in the chain:

• The agent will actually run the code it wrote inside the GitHub Action runner — bringing the project up end-to-end (lint + build + unit + smoke)
• If the build passes, it will auto-deploy to a non-prod environment (test or staging)
• Then ping me — "it's ready at this URL, can you take a look?" — via Slack or as a PR comment

Once that chain closes the flow looks like this: I hand off a task on Slack → the agent writes the code → runs it in the runner to verify → deploys to a test environment → tells me "it's ready" → I just look and say "okay, ship it to prod."

My role shifts from "the one writing code" to "the one deciding and overseeing." Decisions, taste, what the product becomes — that's me. The mechanics are the agent.

Conclusion

I didn't lean on Bugasoft's size or budget to build any of this — every piece I used is open source and well documented: Anthropic's official tooling, the MCP standard, GitHub Actions. I deliberately open-sourced agent-skills-mcp too. The same chain is buildable whether you're at a 200-person tech company or in a solo project of your own.

The real investment is thinking about what you'll teach the agent. Choosing which decisions to automate and which to keep in your hands. The more the system knows you, the more valuable it gets.

And what I've built so far is just the beginning. As the remaining links of the chain settle into place, "writing software" will gradually shift toward "managing software." More time for the decisions that actually matter, fewer hours spent on repetition. The scene the daydream put in front of me is slowly becoming real.