開発の暗黙知を集約するskillsを作ったA developer built a tool called "skills" that automatically harvests…

Tacit knowledge—the hard-to-verbalize instincts that experienced engineers accumulate over years—is one of the most valuable and most easily lost assets on any software team. A developer writing on the Japanese platform Zenn has described building a tool called "skills" that aims to capture this kind of knowledge automatically, rather than relying on engineers to write it down by hand. The effort is notable because it treats a long-standing organizational problem as something a system can help solve.

The post frames tacit knowledge through concrete examples familiar to most working programmers. It includes the vague sense during a code review that something "smells off," the premonition that "this design will cause pain later," the debugging instinct to "suspect this part first," unwritten team conventions along the lines of "this is how we do it here," implementation patterns that have failed in the past, and the domain-specific constraints or exceptions particular to a given business. These are the judgments that often separate a seasoned engineer from a newcomer, yet they rarely make it into formal documentation.

According to the author, three recurring problems make this knowledge difficult to preserve. First, tacit knowledge is highly abstract, so it is unclear what should even be written down. Second, and somewhat paradoxically, the more accomplished an engineer becomes, the harder articulation gets, because expert behavior is performed automatically and feels self-evident. Third, the act of documenting such insight is simply tedious, which means it frequently does not happen at all. Together these barriers explain why so much practical wisdom leaves an organization when a key contributor does.

The proposed answer is to harvest tacit knowledge automatically instead of asking people to author it from scratch. Rather than fighting the difficulty of articulation head-on, the tool appears designed to collect and aggregate signals that already exist in day-to-day work and turn them into reusable "skills." The full source excerpt is truncated, so the precise mechanics are not fully described here, but the stated goal is to shift the burden of capture away from the busy expert and onto the system.

This framing fits neatly into the surrounding ecosystem implied by the article's tags and category, which point toward Cursor, the AI-assisted code editor built on a fork of VS Code. Cursor and similar tools let developers supply project-specific guidance to a language model, for example through configuration such as rules files that describe conventions the AI should follow. A mechanism that continuously gathers a team's implicit norms and failure patterns could, in principle, feed exactly that kind of guidance, making an AI assistant behave more like an engineer who already knows the codebase and its history.

The concept of "skills" as discrete, reusable units of expertise has also gained traction more broadly in the AI-tooling space, where agent frameworks increasingly package specialized capabilities that a model can invoke. Whether this particular project connects to those wider conventions or is a self-contained utility is not spelled out, and readers should treat any such link as a reasonable inference rather than a confirmed detail.

It is worth placing the idea in the longer tradition of knowledge management. The distinction between explicit knowledge, which can be written and shared, and tacit knowledge, which resides in practice and intuition, has been discussed in management literature for decades. Past attempts to codify it—wikis, runbooks, architecture decision records, and onboarding guides—have all struggled with the same tedium and abstraction problems the author identifies. What is new here is the attempt to automate collection using the AI tooling now embedded directly in the coding workflow, which is where the relevant signals are generated in the first place.

Some caution is warranted. Automatically inferred conventions can encode bad habits as easily as good ones, and intuition captured out of context may mislead a newcomer who lacks the judgment to know when a rule does not apply. Privacy, review, and the risk of ossifying outdated practices are all open questions for any system of this type. Even so, the project is a concrete, developer-driven experiment in a persistent pain point, and it is likely to interest teams looking to reduce the knowledge lost when experienced engineers move on. As with many individual blog-published tools, its real-world value will depend on how well the automated harvesting holds up across different codebases and teams.