Spark Program | CCC Vibe-Coding Scaffold (AI-Assisted Dev Starter Kit)
Project Name
CCC Vibe Scaffold — A CCC project template and test harness designed for safe AI-assisted (“vibe-coded”) development.
Team / Individual Profile and Contact Information
Name: George_Liam
Role: Sole developer and maintainer
Project Description
Problem
CKB development is entering a phase where a large share of application-layer code can be written by AI tools rather than by hand. In the discussion under the Spark Program’s 2025 Annual Report, a community member (janx) raised that AI-assisted, or “vibe-coded,” development is now roughly 100x faster for application-layer work, and proposed that the program actively support it. The Spark Committee (zz_tovarishch) responded positively but attached two explicit guardrails to that support: first, that any AI-assisted work must come with disclosure of which tool was used for which part, and second, that critical on-chain logic must stay manual-coded or audited even while off-chain logic is aggressively AI-accelerated. The committee went further and explicitly floated a concrete tooling category to support this: templates, CCC-based scaffolds, test harnesses, and verifiable-by-default workflows.
Despite this being named directly by the committee, nobody has built it. Today a developer who wants to vibe-code a CKB dApp starts from nothing. There is no scaffold that separates AI-safe off-chain logic from audit-required on-chain logic. There is no standard disclosure format, so every developer who wants to be transparent about AI usage has to invent their own convention, and most will simply skip it since there is no default to follow. There is no automated test harness bundled with a starting project, so AI-generated off-chain code is checked only by manual review, which is exactly the slow, unscalable process AI-assisted development is meant to move away from. This gap means the committee’s own guardrails currently exist only as a written expectation with no tooling to enforce or even encourage them in practice.
Solution
CCC Vibe Scaffold is a small, open-source project template, similar in spirit to a create-ckb-app starter, that turns the committee’s written guardrails into something a developer gets automatically just by starting a new project with it. It is built around three parts.
The first part is the project structure itself. The scaffold ships with a CCC-based folder layout that clearly separates off-chain logic, which is safe to heavily AI-generate, from on-chain script logic, which is flagged for manual review and audit. This is not a suggestion buried in a README; it is the actual folder convention the generated project uses, so the safety boundary is the path of least resistance rather than something a developer has to remember to enforce themselves.
The second part is the test harness. It is built on Vitest and covers unit and integration tests against off-chain logic such as transaction building and CCC calls. This gives AI-generated code an immediate, objective pass/fail signal instead of relying purely on manual review. On-chain script logic is intentionally left out of this automated testing scope, since the committee’s guardrail is that on-chain logic must be manually reviewed or audited rather than checked off by a test suite. The harness is wired to run automatically through a pre-commit hook and a CI workflow on any off-chain code change, so it functions as a real safety net rather than a tool that only helps if someone remembers to run it.
The third part is the AI Disclosure manifest. This is a YAML file named .ai-disclosure.yml, kept at the project root. YAML was chosen deliberately over a purely machine-generated format like a lockfile, because the manifest needs to stay human-editable. A solo developer vibe-coding a project should be able to open this file and add a few lines noting which file was AI-generated, which tool was used, and what the scope of that generation was, without needing a special tool to maintain it. This directly implements the disclosure guardrail the committee asked for, in a form that is actually likely to be used rather than ignored.
To prove all three parts work together rather than existing only in isolation, the scaffold ships with a worked example dApp implementing a minimal transfer and mint flow. This example is built using the scaffold itself, passes its own test harness, and includes a real, filled-out disclosure manifest that can be checked against its own commit history. This turns the scaffold from a theoretical convention into something reviewers can run and verify end to end.
How this differs from existing CKB tools
CCC already ships two visual applications. live.ckbccc.com is code-first: a developer writes TypeScript and sees the resulting transaction. app.ckbccc.com is task-first: a developer selects a pre-built operation, such as sending xUDT, and fills in parameters. CCC Vibe Scaffold is neither of these. It is not a visual tool or a playground at all; it is a project generator that a developer runs once, locally, at the very start of a new project, to get a folder structure, a test harness, and a disclosure convention already in place. It fills the gap that exists before a developer writes any code at all: the moment where they need a safe starting point for AI-assisted work and currently have none.
Expected Deliverables
-
Scaffold and Scaffolding CLI
An open-source project generator, usable via a single command, that produces a CCC-based project with the on-chain/off-chain folder convention already built in. -
Automated Test Harness
A Vitest-based test harness wired into the generated project, covering off-chain logic, and triggered automatically via pre-commit hook and CI on any off-chain code change. -
AI Disclosure Manifest Format
A YAML manifest format, .ai-disclosure.yml, along with a template file, designed to be edited by hand rather than only generated by a tool. -
Worked Example dApp
A minimal transfer and mint flow built using the scaffold, with its own disclosure manifest filled out as a real, checkable example. -
Documentation
A README explaining the on-chain/off-chain boundary convention, how the test harness works, and how to use the disclosure format.
How to Verify
-
Scaffold and Scaffolding CLI
Reviewer steps: Run the single scaffolding command from the README. Confirm it produces a working CCC-based project structure with no manual fixes needed. Confirm the on-chain/off-chain folder split is present and correctly labeled. -
Automated Test Harness
Reviewer steps: Run the included Vitest test harness against the worked example dApp. Confirm it passes cleanly. Make a small off-chain code change and confirm the harness re-triggers automatically via the pre-commit hook or CI workflow. -
AI Disclosure Manifest Format
Reviewer steps: Open the worked example’s .ai-disclosure.yml file. Cross-check each entry against the actual commit history in the repository. Confirm the disclosure accurately reflects what was AI-assisted versus manually written. -
Worked Example dApp
Reviewer steps: Run the worked example transfer and mint flow. Confirm it functions as described. Confirm its disclosure manifest is present, filled out, and consistent with the project’s own test results. -
Documentation
Reviewer steps: Open the README. Confirm it clearly explains the on-chain/off-chain boundary, how to run the test harness, and how to use and edit the disclosure format.
Required Funding
Total request: $1,000, 100% CKB.
This is a narrowly scoped request focused specifically on producing a usable scaffold, harness, and disclosure convention, not a broader tooling suite.
Budget Breakdown
Scaffold and Scaffolding CLI — $400
Covers building the project generator itself and the on-chain/off-chain folder convention it produces.
Test Harness — $300
Covers implementing the Vitest-based harness and wiring it into the pre-commit and CI automation so it runs without manual triggering.
AI Disclosure Format and Worked Example dApp — $300
Covers designing the YAML manifest format, building the template file, and building the worked example dApp with its own real, filled-out manifest.
Milestones
Milestone 1 — Scaffold and CLI
Timeline: Week 1
Goal: A working project generator that produces a correctly structured CCC-based project.
Tasks: Build the scaffold and template structure. Build the scaffolding CLI. Establish and document the on-chain/off-chain folder convention.
Completion criteria: Running the scaffolding command produces a working CCC-based project with no manual fixes needed, and the folder split is clearly labeled.
Milestone 2 — Test Harness
Timeline: Week 2
Goal: An automated, reliable safety net for off-chain code.
Tasks: Implement the Vitest test harness. Wire it to run via pre-commit hook and CI on off-chain changes. Validate it passes cleanly on a trivial project and correctly ignores on-chain script changes.
Completion criteria: The harness runs automatically on off-chain code changes without manual triggering and produces a clear pass/fail signal.
Milestone 3 — AI Disclosure and Worked Example
Timeline: Week 3
Goal: A disclosure convention that is actually usable, demonstrated with a real project.
Tasks: Finalize the YAML manifest format and template. Build the worked example transfer/mint dApp using the scaffold. Fill out its disclosure manifest to match its real commit history.
Completion criteria: The worked example’s manifest accurately reflects what was AI-assisted versus manually written, verifiable directly against the repository’s commit history.
Milestone 4 — Documentation and Submission
Timeline: Week 4
Goal: A polished, reviewable, and genuinely usable deliverable.
Tasks: Write the README covering the folder convention, the test harness, and the disclosure format. Polish the repository. Reserve buffer time for committee feedback. Submit the completion report.
Completion criteria: A new developer can read the README and use the scaffold correctly without needing additional explanation.
Estimated Completion Time
4 weeks.
This is achievable in the timeframe because each of the three components, the scaffold, the harness, and the disclosure format, is independently small in scope, and the project is building a focused starter template rather than a full application.
Clear To-do List
Week 1: Build scaffold and template structure. Build scaffolding CLI. Establish and document the on-chain/off-chain folder convention.
Week 2: Implement automated Vitest test harness. Wire the harness to a pre-commit hook and CI workflow. Validate it against a trivial project.
Week 3: Design and finalize the AI Disclosure manifest format in YAML. Build the worked example dApp using the scaffold. Fill out its real disclosure manifest.
Week 4: Write documentation. Polish the repository. Submit the completion report.
Relevance to the CKB Ecosystem
Directly requested tooling
This scaffold implements a tooling category the Spark Committee named explicitly, in writing, in their own forum thread, in direct response to a community member’s proposal. Few Spark applications can point to this level of directly stated demand.
Supports the committee’s own guardrails in practice
The committee asked for disclosure and an on-chain/off-chain safety split as conditions for supporting AI-assisted development. Right now those conditions exist only as written expectations. This scaffold is what turns them into something enforced by default, in the actual structure of a project, rather than something a developer has to remember and choose to follow.
Supports CCC adoption
CCC adoption is a named 2026 priority. By giving AI-assisted builders a safe, structured starting point, this scaffold lowers the time-to-first-dApp even further, specifically for the growing share of developers who are building with AI assistance.
Reusable beyond this grant
The YAML disclosure format is intentionally simple and generic. If it is adopted beyond this one project, it could become a small piece of ecosystem-wide convention for AI-assisted CKB development, giving the grant’s impact a life beyond the scaffold itself.
Reporting Approach
The final report will focus on whether the scaffold, test harness, and disclosure format work as intended, rather than on adoption or growth metrics, since this is a foundational tooling grant rather than a user-facing product. The report will include a summary of what was built, a link to the repository, the worked example dApp and its filled-out disclosure manifest, confirmation that the test harness runs automatically and passes cleanly, and any known limitations or ideas for future improvement.
Final Outcome
At the end of this Spark phase, a developer who wants to vibe-code a CKB dApp will be able to run a single command and immediately have a project structure that encodes the committee’s own on-chain/off-chain safety boundary, a lightweight and human-editable disclosure record they can maintain as they build, and an automated test harness acting as a real safety net for AI-generated off-chain code. This turns a tooling category the committee named in writing into something that actually exists, is verifiable, and can be used today.