An Open Source Project That Made Me Rethink

In April 2026, I stumbled upon an open-source project on GitHub called ‘Colleague.skill’.

This project doesn’t feature complex underlying algorithm innovations or flashy model fine-tuning. Instead, it distills the daily work methods, decision logic, and even some personality traits of a seasoned operations colleague into a callable API skill.

When you integrate this skill into an agent workflow, you are not just invoking a function named ‘generate copy’ or ‘data analysis’. You are invoking ’this person’.

The project went viral within days, leading to a surge of personal and team skill libraries. People began to enthusiastically encapsulate their efficient colleagues into interfaces, even packaging themselves as interfaces. This shift in perspective redefined our understanding of ‘human-machine collaboration’ over the past few years.

We are not using AI; we are being defined as ‘callable capabilities’.

This means we are no longer complete individuals being hired but rather functions waiting to be called. Our value is no longer solely determined by the depth of our thinking but by the clarity of our input-output interfaces.

Phenomenon: Why Has the World Suddenly Filled with Skills?

Three Transformations: Function → Chat → Skill

Looking back over the past few years, our interaction with machines has undergone three transformations. Initially, it was about functions—we had to click, select, and remember where buttons were. Then it became chat—we spoke, and the machine provided answers, but that was the limit. Now, with the arrival of skills, machines no longer wait for us to ask questions; they actively decompose tasks, adjust tools, and seek results. Functions are for humans, while skills are for AI. We have transitioned from users to resources within the system.

Skill = Callable, Composable, Task Chain Participating Capability Unit

As the agent architecture matures, systems are no longer satisfied with merely ‘answering questions’; they need to ‘solve problems’. To tackle complex issues, a new capability unit is required—this is the skill. It must be callable, composable, and able to participate in task chains.

A skill is a well-packaged capability black box. The main agent does not need to know how it operates internally; it only needs to know ‘what situation to encounter, what parameters to input, and what results to expect’. This highly decoupled design allows the system to quickly build solutions to complex scenarios like stacking blocks.

Why Is This Explosion Happening Now?

Why has this form exploded now? Because the model’s reasoning threshold has crossed a critical point, tool calling technology has matured, and the commercialization of agents demands high execution certainty.

Large models have finally gained the ability to decompose tasks and allocate resources like the human brain. The resources they allocate are the scattered skills. In simple terms, the system is smart enough; it just needs the right tools.

Skills are not a gimmick thought up by product managers; they are an inevitable byproduct of AI genuinely moving towards ’execution’.

Essence: How Skillization Restructures Product, AI, and Human Collaboration

Product: Function → Capability Network

When skills become the basic atoms of the system, the underlying logic of the entire digital world is undergoing a dramatic change. The first thing to be restructured is the product itself.

In the past, products were collections of functions, navigating between pages. Now, products are evolving into a capability network. The core barrier of a product is no longer how many functions it has but whether these capabilities can be clearly defined, accurately called, and stably coordinated in a task chain. Product managers are no longer just page designers and process arrangers; they are now the orchestrators and rule makers of this capability network: defining when a capability is triggered, what input it receives, what output it produces, and under what circumstances it should roll back, transfer, or terminate. What you design is no longer just an interface but a system of capabilities that the Agent can understand, call, and execute.

AI: Answering Questions → Completing Tasks

Next, the role of AI is being redefined. Early AI acted as a clever advisor; you asked, and it answered, providing information but not taking responsibility for outcomes.

Now, AI is transforming into a tireless project manager. It actively decomposes tasks, selects suitable tools from a vast skill library, orchestrates the order of calls, and ultimately executes the loop. It is no longer just a container of knowledge but an engine of action.

Humans: Positions → Callable Nodes

Finally, the most profound change occurs within us. In traditional corporate structures, humans are defined by specific ‘positions’. A position is a static container that holds your responsibilities and outputs.

However, in a skill-based network, the boundaries of positions are dissolving. You are no longer a fixed cog; you are a dynamic API.

Humans are no longer the center of processes but nodes within the system.

In this network, individual value depends on whether one can act as a highly reliable node, ready to be called upon by the system to complete specific tasks and then pass results to the next node. This may sound harsh, but it reflects the reality that is unfolding.

Skillization is not about replacing humans but redefining how humans are utilized.

Contrarian View: Not All Abilities Can Be Skillized

Boundaries of Skills

Since skillization is an irreversible trend, does it mean that all human abilities will eventually become APIs? Honestly, not necessarily.

The boundaries of skills are very clear: they heavily rely on ‘structurable capabilities’. As long as an action can be clearly defined in terms of input, output, and execution logic, it will definitely be skillized. However, there are two types of abilities that are extremely difficult to structure.

Two Types of Difficult-to-Skillize Abilities

The first type is cross-domain implicit judgment. For example, critical decisions about product direction or subtle trade-offs in business interests. These decisions often rely on vast amounts of ambiguous information, intuition, or insights into human nature. Systems cannot handle this chaotic state that lacks clear boundaries.

The second type is coordination ability based on long-term trust relationships. AI excels at handling ’explicit knowledge’, but when faced with ‘implicit sensations’, it quickly reveals its mechanical nature. For instance, in my independently developed Schnauzer vertical community application ‘Buk’, encapsulating a dog care encyclopedia skill and having a large model generate a feeding guide in one second is extremely cheap. However, when a user posts late at night, ‘My dog suddenly vomited yellow water,’ they do not need a sterile answer from Wikipedia but rather a real pet owner saying, ‘Don’t panic, my dog did that last month too; it was from hunger.’

The emotional resonance based on real pet ownership pain points and the trust accumulated between circles cannot be abstracted into input-output interfaces—systems can simulate response formats but can never truly ‘have raised a dog’.

What This Means for AI Product Managers

Function Design → Skill Design

This shift in perspective directly determines the restructuring of product managers’ daily work. In the past, the prototypes product managers created were for ‘humans’ to view, focusing on interaction experience; now, the schemas we design are for ‘main agents’ to call, focusing on capability boundaries and data structures. The outputs of product managers are transitioning from ‘page flow diagrams’ to ‘API definition documents’.

For example, in a project I previously managed, a tool focused on enhancing development process efficiency. In traditional product development tools, code review is often a complex page: developers submit merge requests, the system flows through, reviewers open the page, leave comments, and click approve or reject.

However, in the Agentic Workflow, the page is stripped away; I must abstract this step into a pure Code_Review.skill. As an AI PM, you no longer need to worry about whether buttons are on the left or right; you need to define highly structured input and output constraints. In the actual workflow, the triggering of Code_Review.skill is not passively waiting. The main agent continuously listens to the event stream of the code repository: when it detects a pull request pointing to the main branch marked as Ready for Review, and the associated CI pipeline has passed all checks, it will automatically invoke this skill. If the PR is still in draft status or the pipeline has failures, the main agent will skip it, avoiding introducing immature code changes into the review chain. This precise design of triggering conditions is the first threshold to ensure the entire automated workflow ‘does not go off track’. Once the triggering conditions are met, the boundaries of the skill itself need to be strictly defined. As an AI PM, you need to design a schema for this:

Your core work becomes delineating the ‘physical boundaries’ of this skill: what to do when the git_diff exceeds the context window limit of the large model? When the risk_score is on the edge value, how to block the AI’s automatic decision and hand it over to a human-machine collaboration node? This precise cutting of business boundaries is the true basic skill of product managers in the AI era.

User Flow → Task Chain Orchestration

Beyond the design of individual skills, a more complex challenge lies in orchestrating task chains. In early versions, we encountered a serious online incident. At that time, the main agent was processing a merge request containing a large amount of legacy code refactoring and directly fed thousands of lines of git_diff into Code_Review.skill.

The result was predictable; the context window of the large model was instantly overwhelmed, and token overload caused the entire review chain to crash. This experience made me deeply realize that in the Agentic Workflow, no single skill is absolutely reliable. We were forced to redesign the entire task chain orchestration logic, introducing extremely stringent fallback strategies.

When the size of git_diff exceeds the safety threshold, the main agent must trigger a downgrade mechanism: it no longer calls the large model for deep semantic review but instead calls a lightweight skill based on traditional static scanning tools, while forcibly marking the status as HUMAN_INTERVENTION_REQUIRED, directly passing the task to a senior architect for manual intervention.

What you design is not a process but an ’execution system’.

Product Manager → Capability Architect

When you no longer focus solely on the smooth execution of a single skill but begin to design system-level defense mechanisms for scenarios like token overload or manual takeover when risk scores are on edge values, the nature of your work undergoes a fundamental shift—you are no longer designing a process but a fault-tolerant execution system. This shift is the true watershed moment in the evolution of product managers into ‘capability architects’.

You need to inventory which capabilities can be distilled within the business line and which skills can be reused across businesses, ultimately weaving a highly efficient internal capability network. You are no longer just drawing diagrams; you are constructing the underlying logic.

As interactive interfaces gradually disappear, the moat of product managers will be built entirely on the deep deconstruction and reorganization of business logic.

Ultimate Question: We Won’t Be Replaced, But Must Be ‘Understood by the System’

Facing the wave of skillization, anxiety is a natural reaction. However, the real change is not about replacement but about how we connect. The system still needs humans; it just requires humans who can connect to the network in specific ways.

In the future collaborative network, high-value nodes typically possess three characteristics:

1. Ability to Express Structurally: Just as breaking down ‘code review’ from a vague consensus into a schema definition with precise input-output constraints—we must have the ability to abstract complex experiences into standard SOPs. When the system calls upon us, we can output results with a high signal-to-noise ratio rather than consuming processing resources with lengthy nonsense.
2. Reusability: Our capabilities should not be tied to a specific business line or team atmosphere. Just as a well-designed Code_Review.skill can be shared across different tech stacks, a truly high-value node should have modular capabilities that can be seamlessly plugged into different task chains while maintaining stable output quality.
3. Ability to Participate in Complex Decisions: When the system faces multiple constraints, rule conflicts, or data-deficient edge cases like ‘midnight user emotional breakdowns’, algorithms often become paralyzed. At this point, we need to act as the decisive arbitration node, using cross-domain implicit judgment to guide the system.

The most dangerous individuals are not those with lesser abilities but those who cannot ‘API-ize’ themselves and connect to the AI collaboration network.

Comparing humans to interfaces may sound harsh, even evoking a deep cognitive shock similar to that experienced with the ‘Colleague.skill’ project. However, this shock does not change the direction of system evolution. Business systems do not care about our emotions; they only care about whether our interfaces are standard.

If we cannot encapsulate our core experiences into inputs and outputs that the system can understand, we will be marginalized by the network or even disconnected. This is not an exaggeration but an inevitable logic of system evolution. A node that cannot be called is equivalent to non-existence in the network.

Returning to the ‘Colleague.skill’ project that made us rethink. Its impact lies in its early revelation of a reality. Instead of resisting this shock, we should proactively examine ourselves.

Stop asking whether AI will replace us. The real question is: when systems begin to call upon humans in the way they call APIs, is our interface documentation ready? In this era where everything can be called, refusing to think about how our abilities can be structured equates to relinquishing our initiative in participating in this system. Try to describe the input and output of your core ability in one sentence. If you cannot articulate it clearly, this may be the starting point we need to face.