> ## Documentation Index
> Fetch the complete documentation index at: https://docs.comet.rpamis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Comet: More Than Skill

> Review Comet's evolution from the OpenSpec and Superpowers orchestration layer to Runtime, Eval, and Native workflow, as well as the design philosophy behind it.

This article is quite long. If you read it patiently, I believe you will gain something

## Preface

This article will explain exactly what Comet is doing and what our design philosophy is

Comet first became known to the public in May when it was just open-sourced

[https://linux.do/t/topic/2232510/52](https://linux.do/t/topic/2232510/52)

At the same time, a series of videos were also released. Due to the lack of time to promote the Native mode recently, the popularity of the old videos has been very high. Many people's understanding of Comet is that it is an Openspec+Superpowers orchestration layer, but in fact, we have already pointed out in the first video that Comet's combination of these two has never been the goal. With the rapid iteration of Comet, it is no longer merely a Skill. We just need a powerful enough Skill with a stable link to accumulate a Runtime/Harness that is suitable for real working and production environments. Here, I will take the positive time sequence as an example. What problems are the major version iterations of Comet aiming to solve

## The open source journey

1. May - Initial open source OpenSpec+Superpowers combination

At this point in May, there were no strong models like Fable5 or GPT5.6 with the superpowers thinking chain on the market yet. Under this premise, OpenSpec and Superpowers were still very effective methods on the models at that time. Before it was open-sourced, I had been deeply using this type of SDD for a long time (about several months). At that time, mattpocock/skills had not yet gone viral in China, and there was no official account to promote it everywhere
At that point in time, when I was using this type of SDD, I mainly faced several problems:

1. More than 90% of the time, I am clicking "yes". There are too many Skill names to remember, but many processes are relatively fixed and need to be called manually
2. Superpowers does not have the ability to natively manage requirements, while OpenSpec does, but the clarification dimension is insufficient

So, because I wanted to be lazy, I combined the two of them and encapsulated them in an SOP. At first, they were arranged in plain text in CLAUDE md

But soon I discovered a series of problems with such long-link nested Skill calls as follows:

1. After multiple context compressions, the Agent completely forgot what Skill to call next
2. The Agent did not actually trigger the Skill but did something similar to what the Skill required, and there was forgetting in the process
3. The Agent skipped the key Skill process and directly started writing code. For instance, it could only start writing code after the link required clarification was completed. The Agent started working without asking you any questions
4. There is no cross-device 0-context recovery that often requires context explanation, no reliable state reversal, no intent recognition, and no mandatory access control protection. It all depends on the Agent's self-awareness

Meanwhile, we also have \*\* other real job demands \*\* :

1. \*\* For individuals \*\* : \*\* Everyone has their own Skill preferences \*\*. For instance, one person might prefer Grilling me, while another might like brainstorming. Consistent with most of the friends in the comment section, we like to select useful skills to assemble by ourselves
2. \*\* For the team \*\* : In business, we often need to interface with skills from other teams. These skills were not written by us, but as the orchestration chain became long, how to stably execute them under the model construction at that time became a problem. That is to say, as mentioned above, it's very easy to fall into traps
3. \*\* For the industry \*\* : There are a great many ready-made and useful skills available. If we need Work or Excel capabilities, using the official ones is definitely much better than having the AI write them temporarily

With these questions in mind, I first connected the OpenSpec+Superpowers link of Comet, focusing on solving how to stabilize Skill triggering, cross-device context recovery, state machine, intent recognition, and phased access control protection on long-range nested skills, and then carried out open-source work. This is the initial version of Comet that everyone has seen. The question being considered is that if we can obtain a reusable Skill Harness practice based on this set of long-term task skills, then the problem of subsequently combining skills and stably executing them can be well solved

Second, in June and July, major companies began to promote the same practices. Comet started to work on Eval evaluation and Skill combination, and gained more best practices for progressive loading

In June and July, we observed that many major domestic and foreign companies and organizations, such as LangChain, Apache, Tencent, Alibaba, and ByteDance, began to promote Skill practices with similar ideas. At the time of our open source, there were no such articles

So later on, we wrote a special article to let everyone understand how Comet shares the same practical approach as major domestic and foreign companies

[https://docs.comet.rpamis.com/en/tech-blog/comet-vs-industry](https://docs.comet.rpamis.com/en/tech-blog/comet-vs-industry)

During those two months, we focused on refining Comet's progressive loading, more atomizable references, including user pause points (HITL), auto-advancing Skill protocol, context recovery protocol, workspace standards, and so on

The contents of these documents are not large, but the ideas are very clear. Everyone can learn something from the corresponding mechanisms

Meanwhile, with the rapid iteration of Comet Skill, we urgently need a mechanism that can evaluate Skill to measure whether each direction of Skill change has side effects and whether Skill has really improved.

As our user base grows, we can no longer rely on our sense of touch to do this. In the past, I have met many Skill authors who have iterated with AI very quickly, but their functions are unstable. Whether the effect is good or not depends entirely on our sense of touch. This is not a good iterative model.

At that time, we still hadn't seen many Eval works on social media platforms. A lot of them were running on papers, and some evaluations were too simple to be suitable for scenarios like Coding agents that frequently need to interact with users

We have done a lot of solid work on Eval, including how to evaluate any SKill using Claude Code and Codex, which are most frequently used by users, and how to make the entire evaluation process fully automated. How to evaluate Skill using Rubric, Pass\@K, and Pass^K scores? How to connect LangSmith and LangFuse

How to turn Skill iteration into a systematic project? We overcame a lot of difficulties, evaluated it with real Token consumption, and named this part Comet Eval and made the source code open source

In addition, I further developed the issue to be addressed in May, which was how to combine skills. \*\* I did not choose to create a Skill orchestration visualization system similar to Dify. I think that would not be AI-native enough and might soon face the risk of becoming outdated. \*\* So ultimately he became an AI Native Skill like/Comet-any, which can transform Comet's original five-stage workflow.

Or, based on the user's own Skill preferences, generate a set of skills similar to Comet processes, with built-in Runtime experience accumulated by Comet

Iii. July - August -Comet Native Workflow Born

With the release of Fable5 and GPT 5.6, I soon felt that the model's capabilities had reached a new stage. GPT 5.6 demonstrated a thought chain almost similar to that of Superpowers, which confirmed my previous viewpoints in multiple videos: "If the trajectory of a Skill is relatively fixed, it can definitely be evaluated. As long as we do a good job on the evaluation side and take the metrics as group truths, we can form a dataset." A model is one that can be trained.

After discovering this, thanks to the previously built Runtime, I open-sourced Comet Native Skill just a few days after the release of 5.6. My core thinking was:

1. When the model's capabilities become powerful enough, Skill is about to undergo a transformation similar to the past when the Agent Loop fully shifted from a Workflow-based core to a React-based core
2. The engineering iron laws of Superpowers conflict with the native thinking chain for strong models, but there are still many that we can consider leaving behind, such as TDD and Brainstorming
3. Skill should focus more on what to record, what to do, and how to verify. We no longer need to care about exactly how to do it. A few extremely lightweight documents are enough

The \*\*Native Skill produced in this way completed the core work with just over 100 lines of Skill content \*\*. Meanwhile, we natively adopted the Grain-ME style of high-intensity clarification, which is divided into two modes: linear clarification and batch clarification. It brings about a 75% reduction in Token consumption and 45% of time on the benchmark, while there is no decline in accuracy. The core adopts Loop Engineering drive and has the Supervisor Change mode, which is truly in line with the working environment. Usually, when we are working, we dispatch sub-requirements under a large demand. Native can detect this part of the dependency relationship through DAG, parallelize what can be parallelized, and wait for what has dependencies

The Native workflow has also ushered in some more free, React-style implementation mechanisms

When we use the Native workflow, we do not specify any implementation methods. However, when you install methodological skills like TDD and BDD locally, the Agent will automatically determine and initiate the TDD implementation during the implementation process

This brings us back to the essence of Skill. The model observes Skill name and desc to determine whether to call it or not, rather than forcing it in the process

When using Native Skill, we have a lot of free usage. You can use the documentation produced by grill me with docs without the clarification of Native, and simply use Native as an executor. Within its own Loop, it can complete the content of your documentation

## Design concept

Fourth, finally, it's about our design concept

Comet maintains a certain degree of restraint in the stacking of functions. Here are our thoughts

1. Self-evolving memory, self-evolving Skill, automatic document accumulation

These are all very hot directions. My research on the self-evolution topic began before the Agent Skill technology became an officially public standard, and the related PR was submitted to Spring AI Alibaba DeepResearch

[https://github.com/spring-ai-alibaba/deepresearch/pull/20](https://github.com/spring-ai-alibaba/deepresearch/pull/20)

The aim is to enable the Agent to better understand the user's characteristics in multiple rounds of conversations without the user's awareness and guide the Agent's responses in real time

At that time (early December 2025), this was still a very niche field, only focusing on academic papers. Occasionally, one could come across one or two articles on social media platforms, but they were all just superficial

The subsequent story is well known to all. In February 2022, the popularity of Hermes completely ignited these directions

However, in terms of design, we still don't want to incorporate these elements into the Skill, or rather, we don't want to go that deep

Because the content in the Memory and RAG directions is more about systematic engineering, involving a great deal of content, these two directions on the Skill side cannot truly move towards the production environment. This is because Memory needs to be evaluated and run in the background. Many companies specifically focus on vertical categories in this direction. In fact, it will be more of an independent system in the future. The Coding Agent only needs to be connected to it in a plug-in manner. RAG also needs to evaluate the recall rate, accuracy rate, the content of LLM as Judge, and at the same time, it needs to have embedding models and handle complex document slicing

We can see that each direction, when developed independently, is a vast amount of content. There is not much need for a complete implementation on Skill. Due to the fact that developers in this direction do not pay attention to Eval and lack benchmarks, many of their efforts are actually ineffective. Many top conference papers have pointed out that the products of self-evolving memory and self-evolving skills are mostly not user-friendly, and this remains a direction worthy of in-depth research

2. Cross-agent team Harness file injection

What can be done in this part is to complete the missing Rule mechanisms of various Coding agents. Hook can be used to selectively inject relevant documents. In the long run, this function is easy to implement for the Coding Agent team to inject rules. In fact, with linter, many things can be achieved. For instance, rules can be established as plugins, forcing files that do not meet the specifications to fail during code compilation. Once the Agent sees the error, it can naturally know how to fix it. This is also a form of post-specification.

3. About CLI

I believe many developers have a misunderstanding about CLI, thinking that CLI is created to facilitate installation on multiple platforms. However, in Comet, CLI is positioned as the entry point for Runtime/Harness. We place the parts that can be coded in CLI shortcut commands. And within the Skill, let the Agent itself identify whether it needs to call a certain CLI to perform complex but deterministic tasks, such as transforming the state of Comet. The advantage of doing so is that we can significantly reduce the content that needs to be described in the Skill, turning the areas that require stable execution into code The Agent doesn't need to know too much information; it only needs to understand the function. This is just like when we use electrical appliances in our daily life. We don't need to know the specific principles and internal structure of the appliances. We just need to know that pressing a certain point turns them on and pressing another point turns them off.

## Welcome to contribute

Five. The Last and the last

Comet warmly welcomes developers from all over to participate and contribute. Even the improvement of documentation is acceptable. \*\* We hope that everyone can truly learn the knowledge that can be used in work in Comet \*\*, rather than Just switching to a seemingly useful Skill. If you have any doubts about Comet, Just try it. Use /comet to initiate skills to do whatever you want