vibe-coding: a Chinese-language record of building with Claude Code

A process diary, not a piece of software

The repository at LingyiChen-AI/vibe-coding holds documentation and images rather than an application. Its stated purpose is to record the author's AI programming process, and the tool used throughout is Claude Code. The subject of the recorded build is an AI comic-drama generation platform, and the resulting code lives in a separate repository, twwch/AIComicBuilder, which the notes link to.

The top level of the repository makes the shape clear. There is a README, a folder of images that are mostly screenshots of the agent in action, a claude-code-ai-orchestration directory, an embedding directory and a wechat-article.md file. There is no source tree, no build script and no test suite.

That makes the correct way to read it clear too. Anyone evaluating it should treat it as a tutorial and a set of configuration notes rather than as software to install. The repository has no GitHub releases, the primary language and the licence are both unlisted on the repository, and the last push was on 2026-05-16, so nothing here carries the maintenance guarantees of a released tool.

Where vibe coding comes from and what it claims

The notes introduce the idea of Vibe Coding as a concept raised by Andrej Karpathy in February 2025, described in the text as a former Tesla AI director and OpenAI co-founder. The core idea is that you no longer really write code, you describe what you want in natural language and let the AI generate it, and your job becomes judging whether the result looks right and adjusting it in plain language when it does not. A quoted passage from Karpathy is included, describing giving in to the vibe, embracing exponentials and forgetting that the code even exists.

The characteristics listed are natural language driven development, iterative development in a loop of look, feedback and adjust, a focus on what to do rather than how to do it with the developer acting more like a product manager, and a claim that documentation is king: a good requirements description and technical document matter more than the code itself.

That last point is the load-bearing idea in the whole repository. Everything that follows, the specification format, the plan review, the skill installs, is a mechanism for making the documentation good enough that the agent can work from it. The notes are also candid about the method's boundary, in a sentence that reads as an instruction to the reader: in the AI era, documentation is the king.

SPEC documents as the contract with the agent

The middle concept the notes develop is the SPEC specification, described as a structured standard language for telling a machine or an AI what a feature looks like, how it is called, what goes in and what comes out.

Three properties are given. A SPEC is non-executable code, usually a YAML or JSON file describing system behaviour. It uses a standardised format, with OpenAPI Specification named as the most common one. And it is machine understandable, which is the point, since the notes argue that a specification is what lets an AI read your interface and call it without a human in the loop.

The workflow is described in four steps under a slogan about writing the rules before writing the implementation. Drafting is writing a YAML document that conforms to the OpenAPI specification. Validation is checking the syntax with a tool such as Swagger Editor. Binding is importing that SPEC into your skill platform. Implementation is writing the backend logic so that the returned data matches the SPEC description exactly.

The fourth step is the one that exposes the weakness. If the returned data has to match the specification exactly, then the specification is a contract that the code must satisfy, and an agent working from a loose description will produce something that satisfies a looser contract. The SPEC approach only pays off if the description is precise enough to test against, which is why the recorded workflow puts so much effort into the documents before any code is written.

The four phases of the recorded build

The notes describe their own practice in four phases, and this sequence is the most reusable part of the repository.

In the technology selection phase, the requirements are described in natural language and the AI produces a technical proposal document, which the author then reviews. In the development phase, Skills and Subagent drive the work, and the AI writes the code and makes the Git commits. In the iteration phase, a screenshot plus natural language feedback is enough for the AI to understand the context and fix things itself. In the UI phase, a single sentence triggers a redesign of the interface and interaction logic.

The example project is an AI comic-drama generation platform, and the first prompt the author used shows the shape of a good request. It states the intended stack, that the project should be built full stack with nextjs and that the database should be sqlite so integration is quick, and asks the AI to complete the technology selection and produce a document to check. The author notes that the selection is refined through interaction, with changes requested directly in the terminal, and the outcome is a linked design document in the docs/superpowers/specs directory of the project repository.

Development then starts by referencing that generated file, and the AI produces an execution plan that it reviews on its own, modifying it where it finds problems. The finished plan, which includes code, is filed under docs/superpowers/plans.

Nine skills, several of them third party

The largest part of the documentation is a catalogue of Claude Code skills, each with a source, a description and an installation command. The first is superpowers, a complete software development workflow framework for AI coding agents with 14 composable skills including brainstorming, test-driven-development, systematic-debugging, subagent-driven-development and code-review, and it enforces a red-green-refactor cycle, a four stage debugging method and Socratic brainstorming. It is installed through the official plugin marketplace:

  /plugin install superpowers@claude-plugins-official

The rest are installed with the skills CLI. The Anthropic frontend-design skill, described as guidance for building distinctive production interfaces and particularly suited to React with Tailwind:

  npx skills add https://github.com/anthropics/skills --skill frontend-design

planning-with-files implements a Manus style persistent Markdown planning workflow, using task_plan.md to track phases and progress, findings.md for research and progress.md for session logs and test results, and it is aimed at complex multi-step tasks needing more than five tool calls:

  npx skills add https://github.com/OthmanAdi/planning-with-files --skill planning-with-files

The Anthropic skill-creator is a meta skill with Create, Eval, Improve and Benchmark modes covering the full lifecycle of a Claude Code skill. The notebooklm skill lets Claude Code talk to Google NotebookLM notebooks for source based answers with citations, and it is the one entry that cannot be installed with the skills CLI, because it is cloned into the local skills directory and it supports only a local Claude Code installation, not the web interface:

  mkdir -p ~/.claude/skills
  cd ~/.claude/skills
  git clone https://github.com/PleasePrompto/notebooklm-skill notebooklm

The remaining entries are best-minds, which reframes a question by asking who knows most about it, find-skills from Vercel for discovering and installing skills, ui-ux-pro-max with 67 or more UI styles, 161 colour schemes, 57 font pairings and 161 industry specific design rules across 13 stacks, and the built-in simplify skill, which reviews recently changed code for reuse, quality and efficiency and is invoked with /simplify.

Commits per feature and a first run that broke

Two operational details from the recorded build are worth separating from the marketing of the method.

The first is that using the superpowers skill has a side effect the author describes as a benefit: the agent commits after each feature it finishes, so if the AI breaks the code you can conveniently roll back. That is a git workflow decision disguised as an agent feature, and it only holds if the commits are small and reviewable, which is not guaranteed by a single commit per feature.

The second is that the first run failed. The notes record that an error appeared on startup, and that the fix was simple: send a screenshot. The pattern repeats for the UI work, where the first result was judged ugly, and a new skill was brought in with a one line instruction asking it to redesign the interface and interaction logic across the app and fill in the missing language switching. After three rounds of optimisation the result was accepted.

The timing is also stated. The whole first version of the system took close to 45 minutes of waiting. The model configuration was deliberately left unfinished in the first pass so that the later iteration phase could demonstrate changing an existing project, and that iteration is where the settings page appears, moving model configuration from environment variables to user supplied keys with multiple providers, per protocol support for text, image and video models, a default model list fetched through a model list API with a manual model id fallback, and keys stored locally.

What this record cannot tell you

There are gaps that matter if you are trying to reproduce the result rather than to read about it. The repository contains no code from the project it describes, so the final state of the platform has to be read in the other repository, and the notes here are screenshots and prose about a build that the reader cannot inspect.

The skill catalogue is a dependency list in disguise, and most of it points outside the project. Two entries come from Anthropic, one from Vercel, one from a community repository, one from a collection of community skills, and the notebooklm entry is cloned from an individual account's repository. The notes also do not record a version or a commit for any of these, so the described behaviour can change under the reader's feet, and the licences of the third party skills are not enumerated anywhere in this repository. That matters more than usual for the Claude Code ecosystem, where a skill is prompt text and code that executes on a developer's machine.

The alternative is the obvious one and it is not a criticism of the author: for a team that has already settled on an agent workflow, reading a curated list of skills from a third party post is a weaker source than the skill repositories themselves. What this record offers that those do not is the ordering. The sequence of documents, the plan review step, the commit per feature and the screenshot feedback loop are the transferable part, and the individual skill choices are the replaceable part.

Editorial conclusion

Read vibe-coding as a worked example if you are setting up your own AI-assisted development process and want to see the order of operations, the specific skills installed and how a plan is reviewed before code is written. Do not adopt it as a dependency or a framework, because it ships no code, no package and no licence, and it is written around Claude Code features such as Skills, Subagent and agent team mode that other tools do not provide. Before copying the workflow, check the skill sources yourself, since the installation commands point at third party repositories including several community ones, and confirm that the plan and review steps fit the way your team already decides what to build.

Frequently asked questions

Official sources

1. Issues
2. LingyiChen-AI/vibe-coding on GitHub
3. README