Keep public Kandev docs current when code or behavior changes affect CLI commands, config keys, install/deploy flows, workflows, executors, APIs, screenshots, or user-facing terminology. Use this before finishing any change with public documentation impact, and when reviewing whether a change needs docs.
SkillScore64Maintained
Automatic
◆Doc Ops pack
Last verified 9/25/2026
What it changes
Passed 10 of 16 test cases with the skill, and 4 of 16 without it.
Without skill27%
With skill64%
Checks it passed that the model alone missed
Runs node scripts/validate-public-docs.mjs.
Includes title frontmatter in auth-guide.md.
Runs vitest on the docs processing unit tests.
and 10 more in the full report
8 fixed6 passed either way8 still failing0 broke
Pass-rate lift
+36 pp
Tokens
+68%
Agent turns
0%
Response time
-39%
Model gemini-3.6-flashMeasured 9/25/2026v514 of 22 cases passed with skill · 16 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 8
Prompt
We added a new screenshot PNG file to `docs/screenshots.md` and updated image descriptions. No files inside `docs/public/` were modified. What validation step must be taken before committing?
What was checked, without and with the skill
Checked
Without skill
With skill
Runs both public-doc validator scripts even though docs/public/ was unchanged.
Missed
Passed
case-22 · gemini-3.6-flash · 9/25/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md128 linessingle file
Docs Maintainer
Use this skill to decide whether public docs need updates and to make those updates in the right place.
Docs Boundaries
Public website docs source lives under docs/public/**.
Repository-facing public docs also include the root README.md and
docs/screenshots.md; search them for feature, integration, and screenshot
changes even when the website source is unchanged.
Product context, requirements, and system designs stay under docs/specs/**.
Implementation plans and work orders stay under docs/plans/**.
Architecture decisions stay under docs/decisions/**.
Raw supporting notes can remain under docs/** outside docs/public/**, but do not publish them unless rewritten for users.
docs/public/meta.json owns published-page order and navigation groups. Page paths own routes, and page frontmatter owns titles and descriptions.
The landing/docs website generates its content from this directory. Do not hand-edit generated files in the landing repository.
When Docs Need Updates
Check public docs when a change affects:
CLI commands, flags, install commands, or runtime launch behavior.
Configuration keys, environment variables, defaults, profiles, or feature flags.
Docker, Kubernetes, service, desktop, remote environment, or Windows instructions.
Public APIs, WebSocket messages, workflow import/export schemas, or integration contracts.
Screenshots, visible UI labels, navigation, onboarding, or user-facing terminology.
Skip public docs when the change is:
Purely internal refactoring with no behavior change.
Test-only, fixture-only, or build-only without user-visible behavior.
A speculative plan or design note that belongs in docs/specs/**, docs/plans/**, or docs/decisions/**.
Workflow
Identify docs impact from the diff and changed behavior.
Search docs/public/**, the root README.md, and docs/screenshots.md
first for affected terms, features, integrations, and screenshots.
For behavior changes, also search the same contract and old precedence/reset
Clarify what the user actually wants before specs, plans, or code. Use when an ask is underspecified, when the user says "interview me", "grill me", "stress-test my thinking", or when you would otherwise fill in important product/architecture assumptions silently.