Spark Program | CCC Vibe-Coding Scaffold (AI-Assisted Dev Starter Kit)

Spark Program | CCC Vibe-Coding Scaffold (AI-Assisted Dev Starter Kit)

Project Name
CCC Vibe Scaffold — A CCC project template + test harness designed for safe AI-assisted (“vibe-coded”) development

This proposal responds directly to a live, named discussion in the Spark Program’s own 2025 Annual Report thread — we’re not guessing at a need, we’re building the thing community members and committee members were actively discussing wanting.

Problem
In the discussion under the Spark Program’s 2025 Annual Report, a community member (janx) raised that AI-assisted (“vibe-coded”) development is now roughly 100x faster for application-layer work, and proposed the program actively support it. The Spark Committee (zz_tovarishch) responded positively but with two explicit guardrails: (1) disclosure of what AI tools were used for which parts, and (2) keeping critical on-chain logic manual-coded or audited while allowing aggressive AI acceleration off-chain. The committee explicitly floated “templates, CCC-based scaffolds, test harnesses, and verifiable-by-default workflows” as a future tooling category — but nobody has built one yet.

Right now, a developer who wants to vibe-code a CKB dApp has no starting scaffold that already encodes these guardrails. They’d have to invent the disclosure format and the on-chain/off-chain safety boundary themselves, every time.

Solution
CCC Vibe Scaffold is a small, open-source project template (a “create-ckb-app”-style starter) that:

Ships with a CCC-based project structure that clearly separates off-chain logic (safe to heavily AI-generate) from on-chain script logic (flagged for manual review/audit), matching the boundary the committee itself described.

Includes a built-in test harness that runs automatically against any off-chain code changes, so AI-generated code has an immediate, objective pass/fail signal rather than relying on manual review. The harness uses [Vitest/Jest — confirm which] and covers unit and integration tests against off-chain logic (transaction building, CCC calls). On-chain script logic is intentionally out of scope for automated testing and stays flagged for manual review, per the committee’s original guardrail. Tests trigger automatically via a pre-commit hook and CI workflow on any off-chain code change — no manual step required.

Includes a simple, standard “AI Disclosure” manifest — a YAML file (.ai-disclosure.yml) at the project root, chosen specifically because it needs to stay human-editable. A solo vibe-coding developer can update it by hand in a couple of lines per file rather than running a generator. Example:

yaml

files:
  - path: src/mint.ts
    ai_tool: Claude
    scope: "full generation, off-chain logic"
  - path: contracts/lock.rs
    ai_tool: none
    scope: "manual, audited"

Ships with a worked example dApp (a minimal transfer/mint flow) built using the scaffold, demonstrating the pattern end-to-end, including its own filled-out disclosure manifest.

Relevance to the CKB Ecosystem
Directly implements a tooling category the Spark Committee named explicitly, in writing, in their own forum thread — this is about as direct a response to stated demand as a Spark application can be.

Supports CCC adoption (a named 2026 priority) by lowering the time-to-first-dApp even further for AI-assisted builders.

Produces a reusable disclosure format that, if adopted, could become a small piece of ecosystem-wide convention — useful well beyond this one grant.

Expected Deliverables
Open-source scaffold/template repository (MIT or Apache-2.0), usable via a single scaffolding command. Built-in automated test harness wired to the off-chain/on-chain split. AI Disclosure manifest format (YAML) + template file. One worked example dApp built on the scaffold, with its own disclosure manifest filled out as a real example. README documenting the on-chain/off-chain boundary convention and how to use the disclosure format.

How to Verify
Run the single scaffolding command from the README to generate a new project — reviewers confirm it produces a working CCC-based project structure with no manual fixes needed. Run the included test harness against the worked example dApp — it should pass cleanly, demonstrating the test-harness-as-safety-net pattern actually works. Open the worked example’s AI Disclosure manifest and cross-check it against the actual commit history in the repo, confirming the disclosure accurately reflects what was AI-assisted versus manually written.

Requested Funding
$1,000 USD, 100% CKB.

Scaffold/template structure and scaffolding CLI: $400 — covers the project generator and the on-chain/off-chain folder convention. Test harness: $300 — covers the automated pass/fail signal for off-chain code. AI Disclosure format and worked example dApp: $300 — covers the manifest template and one filled-out real example.

Estimated Timeline
4 weeks total. Week 1: scaffold structure and scaffolding CLI working. Week 2: test harness wired in and passing on a trivial project. Week 3: AI Disclosure manifest format finalized and worked example dApp built. Week 4: docs, polish, buffer for committee feedback.

To-Do List
Build scaffold/template structure. Build scaffolding CLI. Implement automated test harness. Design AI Disclosure manifest format. Build worked example dApp using the scaffold. Fill out real disclosure manifest for the example. Documentation. Submit completion report.

2 Likes

Hi @George_Liam

I’m glad to see your interest in the “Spark” Program!

Before submitting this document to the committee for review, I have listed some of my personal observations below for your reference. These views reflect only my personal reading and do not represent the committee’s position.

1. Proposal format:

I noticed you formatted the proposal according to the template—thank you for your diligence. However, your proposal has issues similar to another project (DOB Pattern Studio) and still contains several deficiencies that need your attention:

  • The current proposal title still does not comply with requirement #0 of the proposal template. Please add "Spark Program | " to the beginning of the proposal title.
  • The budget and timeline sections contain excessive line breaks in multiple places, which clearly increases reading difficulty.

2. The specific format of the AI Disclosure:
The proposal mentions a “machine-readable manifest” but does not specify the exact format (JSON? YAML? Markdown?). The committee may be concerned whether this format is human-editable or purely machine-consumable—if vibe-coding developers need to maintain this file manually, the format design will directly affect adoption.

3. Technical choices for the test harness:
Which testing framework will be used? What is the scope of coverage? (Unit tests? Integration tests?) Is the “automated pass/fail signal” executed automatically after every code generation or does it require manual triggering?

4. Budget:
1000 USD does not exceed the cap of the pure technical budget. But please adjust the formatting of the related content so the committee can read it smoothly during review.

Please respond to this post referencing the above instructions.

Sincerely,
xingtian

1 Like

Hi @xingtianchunyan,

Thank you for the detailed review — this is really helpful. I’ll address each point:

1. Proposal format:
Apologies for missing this. I’ve updated the title to “Spark Program | CCC Vibe-Coding Scaffold (AI-Assisted Dev Starter Kit)” and cleaned up the excessive line breaks in the Budget and Timeline sections for easier reading.

2. AI Disclosure format:
Good catch — I should have specified this upfront. The manifest will be a YAML file (.ai-disclosure.yml) at the project root. I’m choosing YAML over JSON specifically because it needs to stay human-editable — the whole point is that a solo vibe-coding developer can update it by hand in a couple of lines per file, not run a generator. Rough shape:

yaml

files:
  - path: src/mint.ts
    ai_tool: Claude
    scope: "full generation, off-chain logic"
  - path: contracts/lock.rs
    ai_tool: none
    scope: "manual, audited"

3. Test harness technical choices:

  • Framework: [pick what you actually plan to use — e.g. Vitest/Jest for TS off-chain code]

  • Scope: primarily unit + integration tests against off-chain logic (transaction building, CCC calls); on-chain script logic is out of scope for automation and stays flagged for manual review, per the committee’s original guardrail.

  • Trigger: runs automatically via a pre-commit hook / CI workflow on any off-chain code change — no manual step required, so it acts as a real safety net rather than something a developer has to remember to run.

4. Budget:
Formatting fixed as noted above — no change to the $1,000 total or category breakdown, just cleaned presentation.

Let me know if any of this needs further detail before it goes to the committee. Appreciate you taking the time to review closely.

1 Like