[Discussion] My take on the "Agentize" philosophy: GitHub Issues & Command/Skill abstraction

[Devil-SX]

Hi, I've been diving deep into the agentize philosophy over the last couple of days and found a lot of the concepts really resonate. I wanted to share my understanding and get some feedback/discussion going on a few points.

On using GitHub Issues

The core goal of AI programming is to boost automation and lower the cognitive load on developers. However, since current models aren't perfect yet, we always face a "latency vs. accuracy" trade-off. We can improve accuracy (and reduce the need for human fixes) by spending more "reasoning" time, letting the agent retry more often in the environment, adding more hook checks, or allocating more sub-agent ... but the downside is massive latency.

Because of this, a common strategy is to use concurrency to hide latency, similar to the philosophy behind GPUs. Since we have many parallel requirements with long lifecycles, we need a mechanism to track, record, and manage them. GitHub Issues seem to be the perfect, mature abstraction for this. Since models have seen millions of Issues during training, this "mental model" is incredibly stable for them to interact with.

On Commands vs. Skills

I view "Skills" as essentially dynamically loaded context. If the System Prompt is the compiled static binary, then a Skill is the dynamic library (DLL/so). Loading a library requires two things: (1) Implementation and (2) Invocation.

Originally, the skill standard seemed to be letting the model implicitly recognize which skill to call based on a description (e.g., User: "Update version" -> Model decides: "I need to call the PR skill"). However, the growing consensus—including in this repo—seems to favor explicit invocation by the user (e.g., User: "Update version, use the PR skill"). We see this "explicit" pattern a lot in the commands of this repository.

• The Good: Explicit calls massively improve interface stability.

• The Bad: It couples the implementation with the interface. When calling pre-defined commands, the flow and skill are locked in. It becomes hard to extend or inject useful skills from other domains because each implementation ends up with its own isolated, incompatible interface.

The "Flat Abstraction" Problem

When I try to implement this Command (invocation) / Skill (implementation) pattern myself, I run into issues where the abstraction layer feels too flat. In standard software, libraries call other libraries, forming a complex call graph. But here, the file structure often enforces a rigid two-layer hierarchy. If Skills need to reference or call other Skills, things get messy very fast.

Has you guys else ran into this structure problem? Would love to hear your thoughts.

[were]

My understanding is that:

• command is like a function. Invoking a command is something like you call a function from a xxx.so in Python, just like PyTorch does every day.
• skill is like a macro, or a leaf function, which cannot be recursive --- my guess is that because skill is a platform neutral standard, which means it cannot recursively call other aspects like commands or skills.