CodeGraph, OpenSpec, Impeccable: A Vibe-Coding Stack That Covers Debugging, Intent, and UI

Preface

Now that we are in the Vibe coding era, I have gained a lot from using it over the past few months. Let me recommend a few good tools: CodeGraph, OpenSpec, and Impeccable. They help me with three things: clarifying code relationships when troubleshooting, sorting out the purpose and solution when developing a feature, and continuing to polish the UI presentation after the feature lands on the page.

These tasks often appear in the same project, but the problems to solve are not the same. When something goes wrong, you need to find the cause; when preparing to build a feature, you need to think clearly about why you are doing it and how far you will go this time; after the page is made, you still need to check whether the information is clear and whether the layout is appropriate.

This article revolves around these practical uses and discusses my approach.

Body

CodeGraph: Troubleshooting Along Code Relationships

GitHub repo: colbymchenry/codegraph

In simple terms, CodeGraph is like a queryable map of the codebase. It sorts out where code lives and how each part relates to the others, making it easier for AI to find relevant content and understand how a feature works.

Honestly, the main reason is that the official docs say it saves token.

OpenSpec: Making the Purpose, Solution, and Changes of a Feature Traceable

GitHub repo: Fission-AI/OpenSpec

To me, the most valuable part of OpenSpec is that it records the "why" and "how" of a complete feature for future development reference. But OpenSpec only makes sense when the whole team uses it. Otherwise, there is no documentation of what someone did.

In plain terms, you first explain what needs to be done, organize it into a plan and tasks, then let the AI implement according to the tasks, and finally check the results and save the records. Below, I walk through this process following the default workflow.

After installing OpenSpec, run openspec init in the terminal in the project directory and select the AI coding tool you use when prompted. The /opsx:... commands that follow are entered in the AI assistant's chat box.

1. First, talk through the requirements. If you haven't figured out the specifics, use /opsx:explore to look at the existing code with the AI, discuss the problem, and consider alternatives. If you already know what to do, go straight to the next step.
2. Turn the requirements into a proposal. Use /opsx:propose with the requirement description to start a change. The AI will organize the reason for doing it, what changes this time, how the feature should behave, the intended implementation approach, and the tasks to complete. This content is saved in the project's changes directory.
3. Review the proposal to confirm alignment. Focus on checking for missed requirements, scope creep, or misunderstandings of the implementation approach. For example, if adding a search feature, you should first clarify what to search and how to display empty results. When adjustments are needed, use /opsx:update to update the plan and tasks.
4. Implement the feature according to the tasks. Once the plan is clear, use /opsx:apply to have the AI modify the code based on the task list and update the completion status. If you find the original plan unsuitable during development, you can go back, adjust the relevant docs, and continue implementing.
5. Check the result against the requirements. After all tasks are checked off, actually run the feature, test normal operations, edge cases, and related tests. If something is missing, keep fixing; if the final approach changes, update the records so the docs and code correspond.
6. Sync the description and archive. After checking, use /opsx:sync to merge the newly added or adjusted feature requirements into the project's official documentation, then use /opsx:archive to archive the change. Later, you can separately look up how a feature should work and why it was changed that way.

The commands and flow above can be referenced in the OpenSpec official workflow documentation.

What I value is this process: a clear purpose and plan before development, tasks to follow during development, and records to review after completion. When a future requirement involves an existing feature, you can first look at what was done before and why, then determine the new change scope with the current code.

Impeccable: Making Pages Better Carry Features

GitHub repo: pbakaus/impeccable

I mainly use Impeccable to refine pages.

After a feature lands on the page, there are many details to adjust. How content is organized, whether the emphasis is right, and whether the layout is easy to understand all affect the process of users encountering and using the feature.

Typography, spacing, and visual hierarchy are common angles I use when looking at a page. For example, which information should be seen first, which elements can be de-emphasized, and where space is needed all have to be judged based on the page's content and purpose.

In my usage, Impeccable sits at this continued polishing stage, helping me focus on the presentation of the feature.

Conclusion

I choose these three tools based on the current work:

• When troubleshooting, use CodeGraph to help locate and understand code.
• When advancing a full feature, use OpenSpec to organize the purpose, scope, and plan, and leave a record of changes.
• When optimizing pages, use Impeccable to continue adjusting content organization and visual presentation.

Among them, the records left by OpenSpec have a longer-term value: after the feature is done, the context from that time still helps the next development. Knowing what was done before and why makes new changes easier to fit into the project's existing thinking.

I still strongly recommend trying them all.