I Rebuilt My GitHub Profile Around the Tools I Am Actually Shipping

I updated my GitHub profile because the old version no longer described the work I am doing.

That sounds like a small thing, but profile READMEs become a kind of public index. If someone lands on your GitHub, they should understand what you build, what you care about, and which projects are active now. In my case, the answer changed a lot during the last months.

I am still a backend-first full-stack developer. I still work heavily with PHP, Laravel, TypeScript, JavaScript, Python, NestJS, FastAPI, Docker, APIs, queues, and integrations. But the center of gravity moved toward AI tooling that is practical enough to use in real projects.

The new profile is here:

https://github.com/tecnomanu

The theme: agents need boring infrastructure

The most important shift for me is that I stopped thinking about AI agents as magic chat boxes.

Useful agents need boring infrastructure:

• project context they can reuse
• rules they can read before touching code
• tools they can call safely
• routines they can run without asking every time
• notifications when a human should return
• repeatable workflows instead of improvised prompts

That is why a lot of my recent work lives around APC, APX, MCP servers, ChatGPT Apps, and video automation.

APC: one shared place for project context

APC means Agent Project Context.

The idea is simple: a project should have one shared context layer instead of scattering durable instructions across every agent-specific folder.

Today a team can easily end up with:

.claude/
.cursor/
.codex/
.opencode/
AGENTS.md
README.md
docs/

Each tool has its own conventions. That is fine. The problem starts when the same project facts get copied into five places and slowly drift apart.

APC gives the project a portable context home:

AGENTS.md
.apc/
  project.json
  agents/
  skills/
  mcps.json

APC does not replace MCP. That distinction matters.

MCP connects tools. APC organizes project context. If MCP is the way an agent reaches external capabilities, APC is the way a project explains itself to any capable agent.

Project:

https://github.com/agentprojectcontext/agentprojectcontext

Website:

https://agentprojectcontext.com/

APX: the runtime layer I use around APC

APC is intentionally small and portable. APX is the practical layer around it.

APX is where I am experimenting with the daily mechanics of agent work: project registration, routines, tasks, MCP configuration, Telegram bridges, and reusable agent templates.

The split is important:

• APC should stay a durable project convention.
• APX can be opinionated runtime tooling.

That means a repository can keep its context in APC without being locked into one runtime. Then APX can make that context useful when I want automation, background workflows, or coordination across tools.

MCP servers as focused tools

I have also been building MCP servers that solve small, concrete problems.

The pattern I like is:

1. Keep the server narrow.
2. Make setup simple.
3. Prefer local execution when possible.
4. Give agents an obvious workflow, not just raw primitives.

Examples from my current profile:

• MCP Telegram Agent, for notifications and reply-based control loops.
• Puppeteer Server, for safer browser automation.
• Bootstrap Project MCP, for guided project creation.
• Agent Rules Kit MCP, for making project rules easier to run from agents.
• PAMPA, for semantic code memory and MCP-compatible repository search.

None of these should be huge platforms. They are small pieces that make agent workflows less fragile.

Video automation became a serious thread

Another area I am investing in is video generation for docs and social publishing.

I do not mean generic AI video. I mean practical, deterministic videos that explain real software.

Two projects came out of that:

• Video Docs Builder
• FrameVOX

Video Docs Builder focuses on documentation videos for web app flows. It combines Playwright, TTS, and FFmpeg so an agent can analyze an app, write a flow, record browser actions, generate narration, and assemble an MP4.

FrameVOX is more focused on short publish-ready videos: script, voice, visuals, templates, and rendering through HyperFrames.

This is the same theme again: make agents useful by giving them a repeatable workflow.

ChatGPT Apps and real product work

I also worked on the Bytetravel ChatGPT App, published in the ChatGPT Apps directory:

https://chatgpt.com/apps/bytetravel/asdk_app_69cbfe8a08cc819189985005d12166e1

That project reinforced a lesson I keep seeing: the hard part is rarely the single API call. The hard part is product shape.

What should the app expose?
What should stay behind the scenes?
What should be a widget?
What should be a tool?
How much should the model decide?
Where does the user need control?

Those questions apply to MCP servers, ChatGPT Apps, and agent workflows in general.

What I want the profile to say now

The new profile is less about listing every old repository and more about showing the current direction:

• shared context for AI-assisted teams
• agent workflows that stay practical and controllable
• MCP servers and ChatGPT Apps
• backend systems that still need to be reliable
• video automation for docs and social publishing
• local-first AI utilities

I kept some older backend and infrastructure work there because it still matters. AI tools do not remove the need for queues, APIs, Docker images, auth, migrations, observability, and boring production constraints.

If anything, agents make those basics more important. A tool that can move faster also needs better boundaries.

The current stack

The stack I keep reaching for:

Backend:       PHP, Laravel, Node, NestJS, FastAPI
Automation:    TypeScript, JavaScript, Python, Bash
AI tooling:    MCP, APC, APX, ChatGPT Apps, agents
Video:         Playwright, TTS, FFmpeg, HyperFrames
Infra:         Docker, Nginx, queues, APIs, workers

The interesting part is not any individual technology. It is how they connect.

A useful agent workflow may need:

• repository context from APC
• a local MCP server for browser automation
• a Telegram checkpoint when human approval is needed
• a video generator to document the feature
• a publishing tool to turn the result into a post

That is the direction I am building toward.

Links

GitHub profile:

https://github.com/tecnomanu

APC:

https://github.com/agentprojectcontext/agentprojectcontext

FrameVOX:

https://github.com/tecnomanu/framevox

Video Docs Builder:

https://github.com/tecnomanu/video-docs-builder

MCP Telegram Agent:

https://github.com/tecnomanu/mcp-telegram-agent

I will keep using the profile as a map of what is active, not a museum of everything I ever touched. Right now, that map points clearly at practical agent tooling, shared context, MCP, and automation that turns real work into reusable workflows.