help-docs

Identifies user-facing changes in git history that require help documentation updates.

553|70|Updated Feb 28, 2023
One-click install
npx skills add https://github.com/operately/operately --skill help-docs-operately
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: help-docs
Source: https://github.com/operately/operately/tree/main/.agents/skills/help-docs
Command: npx skills add https://github.com/operately/operately --skill help-docs-operately

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? After a release, teams struggle to know which code changes require new or updated help documentation. This Skill scans git history since a baseline tag or SHA, filters out internal-only work, and produces a structured list of documentation candidates with exact UI labels and flows. ## Core Features & Use Cases - Change Discovery: Lists merge commits and PR titles in a baseline..HEAD range and filters them to user-facing changes using path watchlists and heuristics. - Code-Based Research: Infers how features work by reading frontend pages, routes, shared components, and feature tests, quoting UI labels exactly from source. - Doc Action Classification: Assigns each change cluster an action (new_page, update_page, api_auto_sync, or skip) and cross-checks the sibling operately-website repo for existing help pages. - Use Case: Before publishing release notes, run the audit against tag v1.6.0 to get a list of every feature needing a new help page, including suggested slugs, sections, and entry points. ## Quick Start Audit the operately repo for documentation gaps since tag v1.6.0 and list each user-facing change with its recommended doc action.

Frequently Asked Questions about help-docs

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

FAQPage Schema
How do I find what needs documenting since a release?▼

Provide a baseline tag or SHA, and the skill lists merge commits in the baseline..HEAD range, filters them to user-facing changes using path watchlists, and clusters them into documentation candidates with recommended doc actions.

How to identify user-facing changes in git history?▼

Filter commits by PR title prefixes like feat: and fix:, then check diffs against user-facing paths such as app/assets/js/pages/, features/, routes/, and turboui/src/. Exclude chore commits, backend-only changes, and test-only diffs.

What input does the help-docs audit require?▼

A baseline SHA or tag such as v1.6.0 is required. The skill validates the ref with git rev-parse before proceeding and asks for one if the user does not provide it.

Does it check existing help pages before suggesting new ones?▼

Yes, when the sibling operately-website repo is available on disk, it reads src/config/helpCenter.js and src/content/docs/help/ to decide between new_page and update_page and to name the closest existing page.

How are external API changes handled in documentation audits?▼

API endpoint changes are flagged as api_auto_sync rather than manual pages, because Operately.ApiDocs.Generator auto-generates API reference docs and CI syncs them to the website after deploy.

What are the limitations of git-history-based doc discovery?▼

It only covers changes in the operately repo within the given range and cannot detect undocumented features from before the baseline. Behavior is inferred from source code, so ambiguous flows may need manual product confirmation.