Spark Program | CCC Vibe-Coding Scaffold (AI-Assisted Dev Starter Kit)
Project Name: CCC Vibe Scaffold — A CCC project template plus test harness designed for safe AI-assisted (“vibe-coded”) development. The name is meant to signal exactly what the tool does: it takes the increasingly common practice of “vibe-coding” — writing software quickly and iteratively with heavy AI assistance — and wraps it in the specific safety structure that the CKB ecosystem’s own community has already asked for, using CCC (the Common Chain Connector) as the underlying library so it fits naturally into the existing CKB developer workflow rather than introducing a competing toolchain.
Problem: This proposal did not originate from guesswork about what the ecosystem might need — it responds to an actual, on-the-record exchange in the Spark Program’s own 2025 Annual Report discussion thread. In that thread, a community member (janx) pointed out that AI-assisted, “vibe-coded” development has become roughly 100 times faster than traditional manual development for application-layer work, and argued that the Spark Program should actively support and encourage this shift rather than ignore it. The Spark Committee, represented by zz_tovarishch, responded favorably to the idea but attached two explicit conditions that any AI-assisted workflow would need to satisfy before it could be trusted. The first condition is disclosure: developers need to clearly state which AI tools were used to generate which parts of a codebase, so reviewers and users know exactly where AI involvement occurred. The second condition is a firm boundary around on-chain logic: because on-chain scripts control real value and cannot be easily patched after deployment, the committee insisted that critical on-chain logic remain manually written or, at minimum, professionally audited, even while off-chain logic is allowed to be aggressively AI-generated. In that same discussion, the committee went further and floated a whole future category of tooling that would embody these two guardrails — things like templates, CCC-based scaffolds, test harnesses, and workflows that are “verifiable by default.” That is a direct, written statement of ecosystem demand. But as of today, nobody has actually built any of it. The practical consequence is that any developer who wants to vibe-code a CKB dApp right now has to start from a blank slate. There is no existing scaffold that already encodes the disclosure requirement or the on-chain and off-chain safety boundary. Every developer who wants to do this responsibly has to invent their own disclosure format and their own convention for separating safe-to-automate code from code that needs human review, and they have to do this from scratch, every single time, with no shared standard to fall back on. That duplication of effort, and the risk that different developers will invent incompatible or weaker versions of these safeguards, is the core problem this project solves.
Solution: CCC Vibe Scaffold is a small, open-source project template — comparable in spirit to a “create-react-app” or “create-ckb-app” style starter — that bundles together everything a vibe-coding developer needs to work quickly while staying inside the guardrails the committee described. It has four main components, each addressing a specific part of the problem. First, the project structure itself is organized from the very first file so that off-chain logic (transaction building, wallet interaction, application logic, anything that calls into CCC) lives in clearly separated folders from on-chain script logic (the Rust or C code that actually runs on-chain and controls value). This isn’t just a cosmetic folder split — it is meant to be the physical embodiment of the committee’s stated boundary, so that a developer or reviewer can look at the repository layout alone and immediately know which parts were fair game for heavy AI generation and which parts need a human’s eyes and a proper audit before anything touches mainnet. Second, the scaffold ships with a built-in automated test harness that runs against any change to the off-chain code. The purpose of this harness is to give AI-generated code an objective, immediate pass-or-fail signal instead of relying purely on a human skimming the code and hoping it’s correct. The harness is built with a standard JavaScript/TypeScript testing framework (Vitest or Jest — the exact choice will be confirmed early in development based on compatibility with CCC) and covers unit tests and integration tests specifically for off-chain logic such as transaction construction and CCC library calls. On-chain script logic is deliberately excluded from this automated testing layer, not because it’s less important, but because the committee’s guardrail already treats on-chain code as something that requires manual review and audit rather than automated trust — automated tests would risk creating a false sense of security around code that genuinely needs a human expert to check it. To make sure this safety net is actually used rather than optional and forgotten, the tests are wired to run automatically through a pre-commit hook and a continuous integration workflow, triggered any time off-chain code changes, so there’s no manual step a rushed or distracted developer could skip. Third, the scaffold includes a simple, standardized “AI Disclosure” manifest, implemented as a YAML file named .ai-disclosure.yml sitting at the root of the project. YAML was chosen deliberately over a more complex or auto-generated format because the whole point of this manifest is that a solo developer, moving quickly, needs to be able to open it and add two or three lines by hand for a new file without running any generator or tool — it has to be at least as fast to maintain as it is to ignore, or people won’t keep it updated. A simple example of what an entry looks like: a file such as src/mint.ts might be listed with its AI tool noted as Claude and its scope described as full generation of off-chain logic, while a file such as contracts/lock.rs would be listed with its AI tool marked as none and its scope described as manual and audited. This gives anyone reviewing the project, whether that’s a Spark Committee reviewer, a future contributor, or an end user doing their own diligence, an immediate and human-readable map of exactly where AI was involved and where it wasn’t. Fourth, and finally, the scaffold ships with a complete worked example dApp — a minimal transfer and mint flow — built using the scaffold itself, so the entire pattern is demonstrated end-to-end rather than just described in documentation. This example includes its own fully filled-out disclosure manifest, so anyone evaluating the scaffold can see the whole workflow in action: the folder structure, the passing test suite, and an honest disclosure file, all working together on a real, working piece of software rather than a hypothetical.
Relevance to the CKB Ecosystem: This project matters to the CKB ecosystem for three distinct reasons, each worth spelling out on its own. First, and most directly, it implements a tooling category that the Spark Committee itself named explicitly, in writing, in a public forum thread. This isn’t a proposal reverse-engineered to sound aligned with ecosystem priorities after the fact — it’s about as direct and literal a response to a stated need as a Spark application can be, since the committee’s own words are effectively the specification being built against. Second, the project supports and accelerates CCC adoption, which has already been named a priority for 2026. By giving developers a ready-made, safe starting point for AI-assisted CCC-based development, this scaffold lowers the time it takes to go from a blank repository to a working first dApp, which matters especially now that AI-assisted development is making the pace of building dramatically faster — the ecosystem needs its tooling and conventions to keep up with that pace rather than lag behind it. Third, the AI Disclosure manifest format has value that extends well beyond this single grant. If this convention gets adopted more broadly, even informally, it could become a small but genuinely useful piece of ecosystem-wide practice — a shared, lightweight way for any CKB project, not just this one, to signal transparently how much of its codebase was AI-assisted and how much was manually written and audited. That’s a disproportionately large potential return for a very small, focused piece of tooling.
Expected Deliverables: By the end of this project, the following concrete artifacts will exist and be delivered. An open-source scaffold and template repository, licensed under either MIT or Apache-2.0 so it can be freely used and built upon by anyone in the ecosystem, usable by running a single scaffolding command that generates a new project from scratch. A built-in, automated test harness that is already wired into the off-chain and on-chain split described above, so it works out of the box rather than requiring additional setup. The AI Disclosure manifest format itself, specified clearly, along with a ready-to-use template file that any new project can drop in and start filling out immediately. One complete, worked example dApp built entirely on top of the scaffold, including its own genuinely filled-out disclosure manifest reflecting real development decisions rather than a placeholder. And a README file that documents, in plain language, the on-chain and off-chain boundary convention this scaffold enforces and explains exactly how to use the disclosure format, so a new developer picking this up for the first time can understand the whole system without needing outside help.
How to Verify: Verification of this project is designed to be simple and hands-on rather than something reviewers have to take on faith. A reviewer can run the single scaffolding command described in the README to generate a brand-new project from the template, and confirm that it produces a working, properly structured CCC-based project with no manual fixes or extra steps required — if the command works as documented, this deliverable is confirmed. A reviewer can then run the included test harness against the worked example dApp and confirm that it passes cleanly, which demonstrates that the test-harness-as-safety-net concept isn’t just described in theory but actually functions in practice on real code. Finally, a reviewer can open the worked example’s AI Disclosure manifest and cross-check its claims against the actual commit history of the repository, confirming that the manifest’s description of what was AI-assisted versus manually written genuinely matches what happened during development — this checks that the disclosure convention is not just present, but honest and accurate.
Requested Funding: The total funding requested is $1,000 USD, to be paid 100% in CKB. This amount is broken down according to the three main areas of work involved in the project, so that funding directly corresponds to concrete pieces of the deliverable rather than being a single lump sum. The first portion, $400, covers the scaffold and template structure along with the scaffolding CLI itself — this is the foundational piece of engineering work that defines the project generator and establishes the on-chain and off-chain folder convention that everything else in the project depends on, and it represents the largest share of the budget because it is the most technically involved component and the one every other deliverable builds on top of. The second portion, $300, covers the automated test harness — the work of wiring up a testing framework, writing the initial test infrastructure, and making sure tests trigger automatically through pre-commit hooks and CI without requiring manual steps, which is what turns AI-generated off-chain code from something that has to be trusted on faith into something that has an objective, repeatable pass-or-fail signal. The third portion, $300, covers the AI Disclosure format and the worked example dApp together, since these two pieces of work are closely linked in practice — designing a disclosure format that’s genuinely easy to maintain by hand requires building and iterating on a real example alongside it, and the worked example dApp is also what ultimately proves that the entire scaffold works end-to-end as a coherent system rather than as disconnected pieces.
Estimated Timeline: The project is expected to take four weeks from start to finish, broken into four weekly milestones so progress can be tracked and any issues surfaced early rather than at the very end. In week one, the focus is entirely on getting the scaffold structure and the scaffolding CLI working, meaning that by the end of week one, running the generator command should reliably produce a new project with the correct on-chain and off-chain folder separation already in place. In week two, the automated test harness gets wired into that structure and is validated by getting it passing cleanly on a trivial, minimal test project, confirming the testing infrastructure itself is solid before it gets applied to anything more complex. In week three, the AI Disclosure manifest format is finalized based on what was learned in the first two weeks, and the worked example dApp — the minimal transfer and mint flow — is built on top of the now-complete scaffold, exercising every part of the system together for the first time. In week four, the remaining time is spent on documentation, general polish, and fixing any rough edges, with buffer time deliberately built in to accommodate feedback from the Spark Committee before the project is considered complete, rather than treating committee feedback as an afterthought squeezed in after everything else is already finished.
To-Do List: The concrete, sequential steps to complete this project are as follows. Build the scaffold and template structure, meaning the actual file and folder layout that enforces the on-chain and off-chain separation. Build the scaffolding CLI, the command-line tool that generates a new project from that template. Implement the automated test harness, including its integration with pre-commit hooks and continuous integration. Design the AI Disclosure manifest format, finalizing the YAML schema and making sure it stays simple enough to edit by hand. Build the worked example dApp using the completed scaffold, so the whole system is demonstrated on a real, functioning piece of software. Fill out a genuine, accurate disclosure manifest for that example, reflecting exactly what was AI-assisted and what was manually written. Write the documentation, including the README that explains the boundary convention and the disclosure format to a new user. And finally, submit the completion report, which ties all of the above deliverables together for the Spark Committee’s review.