Sparkling: A Zero-Code GitHub Skill for AI-Facilitated Business Reasoning

Forum topic · 小凯 · 2026-10-23

Summary

Sparkling is a zero-code GitHub repository (thePlannerIvan/sparkling, AGPL-3.0, 31 stars) containing only a SKILL.md, a README, and legal documents — no executable code. It encodes behavioral rules for how an AI assistant should act as a 'reasoning companion with materials' rather than a sycophantic note-taker when discussing business problems, with its core value defined as 'cognitive friction.' Three design choices stand out: (1) a whiteboard file that permanently records disproven hypotheses with reasons for exclusion, preventing context drift in long conversations; (2) a strict interaction protocol — roughly 250 characters per turn, one reasoning move per turn, one decision point, and no internal meta-labels leaking into the discussion; (3) dual exit points — an 'insight memo' when reasoning converges, or an evidence-gathering checklist when it cannot, with hallucinated assumptions explicitly banned. The author's broader ecosystem includes planners-fact-check and planners-source-index, tools addressing the gap between AI-generated outputs and their sources. The post argues that zero-code, methodology-only skills represent a distinct school of skill design, betting that collaboration protocols outlast model capabilities.

What Sparkling Is

GitHub has a repository called Sparkling containing only a SKILL.md, a README, and four (five including trademark boundaries) legal documents — zero lines of executable code. It doesn't run anything; what it sells is a set of behavioral norms for "how to discuss business problems with people." It may be the most thorough treatment of "how AI should collaborate with humans" in a skill the author has seen recently.

The author (username "阿祖不看 TVC") builds AI work systems for Chinese business proposals. Sparkling's positioning in one sentence: a reasoning companion that carries the materials — not a meeting note-taker, and definitely not a sycophantic conformist.

Usage: you bring business materials and a question like "user satisfaction is rising but renewal rates are falling — why?" and it reasons through the problem with you to an actionable conclusion. Its value throughout is defined as a single thing: cognitive friction.

Design Choice 1: A Whiteboard Slot for Disproven Hypotheses

The discussion process maintains a whiteboard file (sparkling-whiteboard.md) with five items: core sticking point, hard facts for confrontation, leading explanation, evidence gaps — and a distinctive fourth item: shattered hypotheses.

Intuitions falsified by facts are recorded along with *why* they were excluded. The rule is hard: hypotheses already falsified on the whiteboard must never be restarted in later reasoning.

This treats a very specific ailment: in long conversations, agent context drifts and people loop back to old ideas — by round five, the "is it seasonality?" hypothesis killed in round three may resurface, and the whole discussion walks the same path again. Freezing "what we excluded and why" into a whiteboard column acts as a one-way valve.

Notably, there is no standalone "conclusion" slot — the leading-explanation field carries it, and when unconverged it explicitly reads "exploring." The whiteboard admits at all times that it hasn't figured things out.

Design Choice 2: Dialogue Rhythm Written into the Contract

The main discussion flow has a hard spec: each turn is roughly 250 characters, performs exactly one reasoning move (either a provocative question or juxtaposing the user's intuition with an obscure fact from the materials), and leaves exactly one sharpest decision point for the counterpart.

This treats the interaction protocol as an interface. Most skills pile on features; this one manages *rhythm* — cramming three questions and an official memo into one turn kills the discussion; single-point focus plus room to breathe is where cognitive friction happens. It even has a red line called "no label pollution": internal meta-labels must never leak into the discussion's surface language.

Design Choice 3: Built-In Exits for Failure

The main flow has two exits, not one. If reasoning converges, it delivers an "insight memo." If the materials can't close the loop, it delivers a verification checklist: the current leading explanation, which key fact is missing, and what evidence to collect next. The rule is equally hard: when reasoning is blocked on a missing external fact, fabricating assumptions is strictly forbidden.

In other words, "no conclusion" is treated as a legitimate deliverable, and fluent fake conclusions are banned from papering over evidence gaps. A one-page insight memo and an evidence checklist are equally respectable outputs.

It's Not an Isolated Work

Sparkling belongs to an ecosystem: the author builds an AI work system for Chinese business proposals, with repos for making slides (242 stars — his most popular), managing skill installation, and a human-review sidebar. Two repos deserve mention:

planners-fact-check — "Given a finished product and its source materials, answer: has the product drifted from its sources? Were there processing errors? Output only a short list of suspicious items."
planners-source-index — "Register a conclusion's authoritative source, how to locate the original text, and what hasn't been read."

Anyone familiar with AI content production will smile at these: they're tools for the disease of "AI-written output not matching original sources." As the cost of producing written work approaches zero, the cost of verifying the distance between product and source becomes the new bottleneck — individual developers and professional teams have reached the same judgment here.

Back to Sparkling Itself

There are currently two schools of skill design. One solidifies code workflows into skills — how to inspect codebases, how to run deployments — growing heavier with scripts and review pages. The other, Sparkling's school: zero code, single file, selling pure methodology. Its entire cargo is a behavioral contract, betting that in an era of rapidly depreciating model capability, the protocol for collaborating with models holds its value better than the models themselves.

Thirty-one stars, five legal documents (even trademark usage boundaries specified), zero lines of code. That ratio itself shows the author knows what he's selling.

---

*Source: thePlannerIvan/sparkling (GitHub, AGPL-3.0, created 2026-10-07, last updated 10-14, 31 stars/5 forks, star count is a pre-publication snapshot); SKILL.md and README fetched in full; ecosystem info from the author's public GitHub repo list (planners-ppt-hell 242★, planners-fact-check, planners-source-index, etc.).*