docs-maintenance

Updates project documentation to match code, schema, and workflow changes.

Updated Sep 6, 2026
One-click install
npx skills add https://github.com/malikkotb/shellpluscore --skill docs-maintenance-malikkotb
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: docs-maintenance
Source: https://github.com/malikkotb/shellpluscore/tree/main/.agents/skills/docs-maintenance
Command: npx skills add https://github.com/malikkotb/shellpluscore --skill docs-maintenance-malikkotb

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code changes often leave documentation stale, causing onboarding friction and misleading contributors. This Skill keeps README, GETTING-STARTED, and docs/ pages synchronized with actual behavior whenever features, Sanity setup, routes, environment variables, or workflows change. ## Core Features & Use Cases - Trigger-based scope detection: Maps changed files (middleware, Sanity schema, plopfile, env config) to the exact docs that need updates. - Surgical edit rules: Prefers targeted updates over rewrites, keeps root README concise, and routes detail into docs/features/ and docs/sanity/. - Onboarding sync: Keeps GETTING-STARTED.md aligned with the real first-run path including setup wizard, seed import, and scaffolding commands. - Use Case: After modifying src/middleware.ts basic-auth behavior, the Skill directs you to update docs/features/basic-auth.md and verify related links in docs/README.md. ## Quick Start Ask the assistant to apply the docs-maintenance skill after changing a feature, Sanity schema, or setup script so all affected documentation is updated in the same task.

Frequently Asked Questions about docs-maintenance

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

FAQPage Schema
How do I keep documentation in sync with code changes?

Identify impacted docs before editing code, then update them in the same task using the file-to-doc mapping in the Skill's Scope Guidance. Finish by verifying docs match real behavior and listing touched files in the final response.

When should I create a new documentation page?

Create a new doc only when no existing page covers a new capability: docs/features/ for runtime features and docs/sanity/ for CMS, schema, studio, query, or revalidation concerns. Always link new pages from docs/README.md.

Does this apply to small internal refactors?

No. Rewriting docs for refactors that do not change behavior is an explicit non-goal. The Skill only triggers when behavior, environment contracts, setup steps, or contributor workflows actually change.

What documentation updates are needed for environment variable changes?

Changes to src/lib/env.ts or .env.example require updating whichever feature or Sanity doc documents those variables, often docs/sanity/project-setup.md. If required vars affect first-run setup, also update GETTING-STARTED.md.

How do I update onboarding docs after changing setup scripts?

Edit GETTING-STARTED.md to reflect the new first-run commands and flow while keeping it a guided path that links to detail docs. Update the linked doc, such as docs/sanity/project-setup.md, with the implementation detail.