The Problem
Most agent skills are shipped on instinct.
You write a skill, install it, and hope the model triggers it at the right moment. When it fails, it usually fails silently. There is no obvious stack trace, no clear metric for trigger quality, and no easy way to tell whether the issue is wording, routing, or user phrasing.
That leaves both skill users and skill creators in the dark:
- Users keep repeating themselves when a skill should have helped.
- Creators cannot see which skills are under-triggering or misfiring.
- Improvements are based on hunches instead of evidence from real sessions.
The Thesis
I built selftune.dev around a simple idea: skills should have observability.
If skills are a real interface layer for agentic systems, then they need the same feedback loops we expect from the rest of software:
- instrumentation
- miss detection
- measurable quality
- safe iteration
- rollback when a change regresses
selftune turns skill behavior into something you can actually inspect and improve.
What I Built
selftune is an open-source system for skill-level observability and evolution.
It watches how skills behave in real sessions, identifies skills that should have triggered but did not, and generates evidence-backed improvement proposals so the skill layer evolves from actual usage instead of intuition.
The product is intentionally split across two operating modes:
- For users: install it and forget it. Skills get better quietly in the background.
- For creators: inspect trigger rates, confidence scores, misses, and comparison views to understand why a skill is working or failing.
Core Capabilities
- Session capture: records what users asked for and which skills fired.
- Miss detection: surfaces situations where a skill likely should have triggered but stayed silent.
- Evidence-backed evolution: rewrites skill descriptions and definitions from live usage data.
- Validation loop: evaluates proposed changes before rollout.
- Rollback protection: restores the previous version if a change degrades behavior.
- Crowdsourced improvement: allows skill creators to learn from anonymous opt-in usage across many users, not just their own vocabulary.
Product Direction
I positioned selftune to solve two adjacent but different jobs:
1. Consumers want less friction
They do not want another dashboard. They want skills that gradually adapt to how they naturally speak to their agent.
2. Creators want proof
They need to know which skills are healthy, which are missing, and whether a proposed rewrite improves trigger quality or makes things worse.
That dual framing shaped the site, product language, and roadmap: one product, two entry points, one shared data layer.
Why It Matters
The skill ecosystem is growing faster than the tooling around it.
People are building libraries of reusable skills for Claude Code, Codex, OpenCode, OpenClaw, Pi, and adjacent agent environments, but the operational layer is still immature. selftune treats skills as first-class software artifacts that deserve monitoring, grading, and continuous improvement.
That makes it useful as both a standalone product and as a broader point of view on where agent tooling is headed.
My Role
- Product strategy and positioning
- Problem framing and narrative design
- Information architecture for the public site
- Feature definition for observability, miss detection, and evolution loops
- End-to-end implementation across website, content, and product direction
- Open-source packaging and distribution strategy
Technical Direction
The public site and docs position selftune as:
- MIT licensed
- installable with one command
- compatible with existing agent setups
- designed to improve skills from real session data
The implementation direction emphasizes low-friction adoption:
- no extra API keys
- no separate subscription requirement just to get started
- compatibility with existing agent workflows
- progressive disclosure for users versus creators
Why This Project Belongs in the Portfolio
selftune is not just a marketing site. It is a concrete expression of how I think about productized AI infrastructure:
- identify a systems-level problem that others are working around manually
- define the missing operational model
- build the user-facing framing and the implementation around that model
- create the feedback loop that makes the product compound over time
That combination of product thinking, systems thinking, and developer experience work is exactly the kind of work I want the portfolio to surface.