Registry and Live Monitoring of the Studio's AI Capability Stack

Context

Teams that work seriously with LLM agents quickly arrive at the same point: the core value accumulates not in individual prompts but in a skills library — formalized procedures from which agents take proven techniques instead of deriving them anew in every session. A skill is a unit of engineering knowledge: how to assemble a music video from a track and artwork, how to build a dashboard, how to run a cold-email campaign. The more such units, the higher the return on every agent.

But this asset has a systemic problem: it lives in the file system. Dozens of folders with SKILL.md files, some in English from the built-in distribution, some authored in Russian, with no single place to see what actually exists. It is the classic pain of any capability registry — the knowledge exists but is not observable. An engineer spends time searching for what is already written, duplicates existing work, and when handing the toolkit to someone else delivers not a system but an archive of folders with no map.

The difficulty is compounded by the catalogue being alive: skills are added, renamed, and updated constantly, so any catalogue maintained by hand drifts out of sync with the disk within days. In parallel, the studio's fleet of working agents for specific projects keeps growing — from the Planify product platform to an agricultural holding and a padel-club network — and their state was likewise consolidated nowhere. Which agent works on what and in which status lived in the operator's head, not in an interface. For a one-person operation that is tolerable; for an operation meant to be handed over and scaled, it is not.

The Task

Build a unified registry of the studio's AI capabilities: a tool that scans the skills catalogue by itself, with no manual upkeep, displays it in Russian with categories, and keeps a live list of working agents with their tasks and statuses alongside.

The key requirements were stated firmly. First — zero cost of ownership: the panel must launch with one command and require no dependency installation, so anyone can bring it up on any machine with no environment setup. Second — fidelity: the registry must reflect the actual state of the file system in real time, not the state as of the last manual sync.

The third requirement goes beyond monitoring: the toolkit must be transferable. The skills library is an asset the studio wants to hand to clients and partners, which means a reproducible mechanism for assembling a hand-off kit: an archive of skills, a catalogue with descriptions, and an installation guide.

Approach

The technology choice follows from the zero-cost-of-ownership requirement: the entire platform is written on the Python standard library. HTTP server, file reading, page serving — all on stdlib, without a single external package. This makes launch trivial: the start.sh script brings up the server, the interface opens on a local address, and there is fundamentally nothing in the system to break when third-party libraries update — because there are no third-party libraries.

The frontend is deliberately not split into a separate build: HTML, styles, and scripts are embedded directly in server.py. For an internal tool this is a conscious engineering trade — one file that is simultaneously the backend and the page is easier to hold in your head, edit, and move around than a frontend-backend-build-pipeline triad. The interface style is clean white and professional, per the owner's documented requirements.

The governing principle is declarativity over manual upkeep. The skills registry is not maintained by hand: the server scans the ~/.claude/skills folder in real time and refreshes the list every few seconds, so a skill added to disk appears in the panel by itself, with no restart and no operator action. The agent panel works the same way: it reads the roster from a simple JSON file where each agent has a name, task, and status. The source of truth is always the file system and the config; the interface is only their reflection.

Architecture

The core of the system is server.py: simultaneously a stdlib web server and an embedded page. It aggregates two independent data sources. The first is a live scan of the skills catalogue refreshed every 5 seconds: the list in the interface always reflects what actually sits on disk, and drift between registry and file system is ruled out by architecture, not by operator discipline. The second source is the agents.json file in name/task/status format, which populates the agent monitoring panel.

The skills catalogue is heterogeneous, and the architecture accounts for that at the data level. Skills came from different sources: authored ones are written in Russian, built-in ones in English, some with no explicit category. The normalization layer is split into two components: Russian descriptions of built-in skills live in a dedicated ru_desc.py dictionary — the registry shows the Russian description when available and falls back to English when not — and categories are computed on the fly via the CAT_MAP mapping in server.py. Of ~80 skills, 56 are categorized automatically; the system degrades gracefully: a skill without a category is still visible in the registry, just without a label.

The service is embedded in the studio's broader operations loop: it is registered in the shared launch.json as its own launch configuration and stands alongside the other local services, brought up the same standard way. Port 8770 is kept clear of other projects' ports so panels do not conflict when running simultaneously — routine hygiene for an environment where a dozen local services live in parallel.

The agent monitoring panel is populated with the studio's real working projects: the Planify product platform, an agricultural holding, a padel-club network platform, a B2B team-management platform, a Telegram agent. One page thus covers both cuts of observability: what the studio can do — the capability registry — and where those capabilities are being applied right now — agent statuses by project.

Skill Engineering and Hand-off

The registry is the storefront; the substance is 24 authored skills written as genuine SKILL.md files in Russian. These are not notes or documentation but full executable capabilities that Claude picks up and uses in its work. Their generation is factored into a dedicated _gen_skills.py script: the set is rebuilt reproducibly, in a single pass, rather than by editing files manually — the standard infrastructure-as-code approach applied to a knowledge base.

A distinct architectural decision is pointer skills. Five skills are built not as duplicates but as thin references to already-existing built-in implementations: deep-research, web-artifacts, pdf, pptx, image. They do not copy the logic; they redirect to the base version. This resolves the conflict between completeness and maintainability: the catalogue is complete by name, but no code is duplicated, and when the built-in skills update, no drift arises.

The transferability requirement is closed by a dedicated packaging loop: the generate_share.py script assembles a hand-off bundle — an archive of all skills, a Russian catalogue SKILLS_RU.md, and an installation guide INSTALL.md. The update cycle is reduced to one action: update the skills, run the script, get a fresh kit. The toolkit went from a local folder to an artifact that can be versioned and delivered.

Outcome

The platform is running and solves the original observability problem: the entire set of ~80 skills is visible in one place, in Russian and with categories, and the agent fleet no longer lives in anyone's head — it is in the interface and drawn from configuration. The live scan eliminated manual registry upkeep entirely: a skill added to disk appears in the panel by itself within seconds, and the "catalogue lags the disk" class of drift is ruled out altogether.

The tool's economic effect is in the speed of access to accumulated knowledge: finding the right skill before a task takes seconds of scanning one categorized page instead of digging through dozens of folders. The registry has already changed working practice: before a new task the operator checks the panel rather than writing the procedure from scratch, and the seven-agent monitoring panel answers "what is running where" from the same single page.

The second outcome is transferability. The capability library is packaged into a hand-off-ready bundle: archive, Russian catalogue, installation guide, reproducible rebuild with one script. This moves the studio's toolkit from the "sits in my folder" category into an asset that can be installed at a client's or partner's — and that is precisely what distinguishes a capability registry from a list of files.

The next stage of development is exposing a Claude agent to the internet through the studio's existing server project, with a dedicated Telegram bot as the access channel. An honest engineering blocker is on record here: publication requires access to an Anthropic API key, and until that is resolved, taking the agent online is deferred. Architecturally the dependency is isolated: the local registry and monitoring do not depend on it and continue to operate in full.

What we built

• Stdlib server with an embedded page

  server.py is simultaneously the HTTP server and the embedded HTML/CSS/JS, with no external dependencies; launched via start.sh on a local address, port 8770.

• Live scan of the skills catalogue

  The server scans ~/.claude/skills in real time and refreshes the list every 5 seconds — a new skill on disk appears in the panel without a restart.

• Agent monitoring panel from JSON

  The agent roster is read from agents.json in name/task/status format and populated with the studio's real projects: Planify, an agricultural holding, a padel-club network platform, a B2B team-management platform, a Telegram agent.

• Normalization layer: descriptions and categories

  ru_desc.py stores Russian descriptions of built-in skills (Russian shown when available, English otherwise), while CAT_MAP in server.py automatically categorizes 56 of ~80 skills.

• 24 authored skills as code

  A set of 24 skills written as genuine SKILL.md files in Russian; generation is factored into the reproducible _gen_skills.py script — the knowledge base is rebuilt, not hand-edited.

• Pointer skills without duplication

  Five skills are thin pointers to built-in implementations (deep-research, web-artifacts, pdf, pptx, image): the catalogue is complete by name, logic is not duplicated, and updates cause no drift.

• Hand-off bundle for the toolkit

  The generate_share.py script assembles a sharing kit: an archive of all skills, the Russian catalogue SKILLS_RU.md, and the INSTALL.md guide; rebuilt in a single pass.

• Integration into the operations loop

  The service is registered in the studio's shared launch.json as its own launch configuration; its port is kept clear of the other local services so they can run simultaneously.

Engineering challenges