void-source-driven-development

Grounds third-party tool configuration in version-matched official documentation instead of training memory.

Updated May 29, 2026
One-click install
npx skills add https://github.com/voidcorp-core/void-harness --skill void-source-driven-development-voidcorp-core
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: void-source-driven-development
Source: https://github.com/voidcorp-core/void-harness/tree/main/packages/core/skills/void-source-driven-development
Command: npx skills add https://github.com/voidcorp-core/void-harness --skill void-source-driven-development-voidcorp-core

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? AI coding agents write third-party tool configs from training memory, which blends multiple versions into plausible-looking but subtly wrong settings: renamed options, removed flags, and flipped defaults that compile and run but break later. This Skill enforces reading the official documentation of the actually installed version before writing any config, and requires citing the source so the reasoning survives the session. ## Core Features & Use Cases - Version-matched doc verification: Reads the lockfile (pnpm-lock.yaml, package-lock.json, Cargo.lock) to find the resolved version, then consults the official docs for that exact version rather than latest-docs or tutorials. - Source citation discipline: Requires every non-obvious config option to carry a traceable reference (URL plus section) in the commit body, PR, or an adjacent comment, composing with commit-discipline workflows. - Offline source-debt workflow: When no network is available, config is authored against injected doc excerpts validated at the boundary, or a tracked source-debt IOU (PR label, mandatory checkbox, commit note) blocks auto-merge until a human verifies against the real docs. - Use Case: Before setting a Vite build target, the agent checks the lockfile for the resolved Vite 7.x version, reads the v7 build-options docs, writes the config, and cites the doc URL in the commit message. ## Quick Start Before writing any third-party tool configuration, check the installed version in the lockfile and read the official docs for that version, then cite the source in your commit.

Frequently Asked Questions about void-source-driven-development

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify third-party config against official documentation?

First find the resolved version in your lockfile (pnpm-lock.yaml, package-lock.json, or Cargo.lock), not the semver range in package.json. Then read the official docs pinned to that version, write the config, and cite the doc URL and section in the commit body or a comment.

Why is writing config from AI memory unreliable?

Training memory blends multiple versions of a framework into one plausible config that compiles and runs but is subtly wrong: renamed options, removed flags, or defaults that flipped between majors. The official docs for the installed version describe exactly one version and override memory.

Can I configure tools offline without network access to docs?

Yes, via two approaches: inject a version-pinned doc excerpt as validated input to the decision, or record a source-debt IOU with a PR label, a mandatory verification checkbox, and a commit note. Auto-merge is blocked until a human clears the checkbox by reading the real docs.

Should I trust tutorials or Stack Overflow for tool configuration?

No. Tutorials and third-party answers rarely state which version they target and rot silently as tools evolve. The official, version-matched vendor documentation is the authoritative source; when sources conflict, official docs for the installed version win.

When does source-driven development not apply?

It does not apply to first-party code you own (read the source directly), stable language built-ins with no version ambiguity, or throwaway exploration you will delete. The moment exploratory config lands in the repo, the documentation rule applies.