shdoc-shell-docs
Write and review shellscript documentation with shdoc annotations. Use when creating, editing, or reviewing `.sh` files or shell executables that need `@file`, `@brief`, `@description`, `@arg`, `@option`, and `@example` comments added, repaired, or normalized to match shdoc conventions.
- License 许可
- MIT
- 所属仓库
- mryfmo/dotfiles
- 最近更新
- 2026-11-14
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- shdoc-shell-docs
- description
- Write and review shellscript documentation with shdoc annotations. Use when creating, editing, or reviewing `.sh` files or shell executables that need `@file`, `@brief`, `@description`, `@arg`, `@option`, and `@example` comments added, repaired, or normalized to match shdoc conventions.
02 资源文件 2
- 参考文档agents/openai.yaml212 B
- 参考文档references/shdoc-rules.md2.5 KB
03 SKILL.md 正文
Shdoc Shell Docs
Overview
Use this skill to make shellscript comments parseable by shdoc without bloating simple code with boilerplate. Inspect the file first, then document the script and the non-trivial functions that benefit from generated reference docs.
Workflow
- Inspect the target shell file before writing comments.
- Read
references/shdoc-rules.mdbefore editing comments. - Use
scripts/generate-docs.shas the repo-local style example when working in this repository. - Add or repair file-level annotations near the top of the file:
- Prefer
@filefor the script identifier. - Add
@brieffor a single-sentence summary. - Add multiline
@descriptiononly when the script needs more context.
- Prefer
- Add function-level annotations only where they help:
- Start with
@description. - Add
@argfor positional parameters. - Add
@optionfor flags and option-value pairs. - Add
@examplewhen the call shape is not obvious. - Add
@stdout,@stderr,@exitcode, or@seeonly when they clarify observable behavior.
- Start with
- Rewrite existing free-form comments into valid
shdocannotations instead of keeping two parallel comment styles.
Review Checklist
- Confirm the docs match the implementation instead of guessing arguments or options.
- Keep annotations immediately above the file header or function they describe.
- Prefer behavior and operator-facing intent over internal implementation notes.
- Skip boilerplate comments for trivial private helpers unless the user asks for exhaustive coverage.
- Keep multiline annotation blocks compact and easy to render as Markdown.
References
- Read
references/shdoc-rules.mdfor the minimal tag set, concise examples, and external reference policy.
04 同仓库更多 Skills
x
暂无简介
y
暂无简介
status-report
Generate a status report with KPIs, risks, and action items. Use when writing a weekly or monthly update for leadership, summarizing project health with green/yellow/red status, surfacing risks and decisions that need stakeholder attention, or turning a pile of project tracker activity into a readable narrative.
runbook
Create or update an operational runbook for a recurring task or procedure. Use when documenting a task that on-call or ops needs to run repeatably, turning tribal knowledge into exact step-by-step commands, adding troubleshooting and rollback steps to an existing procedure, or writing escalation paths for when things go wrong.
risk-assessment
Identify, assess, and mitigate operational risks. Trigger with "what are the risks", "risk assessment", "risk register", "what could go wrong", or when the user is evaluating risks associated with a project, vendor, process, or decision.
change-request
Create a change management request with impact analysis and rollback plan. Use when proposing a system or process change that needs approval, preparing a change record for CAB review, documenting risk and rollback steps before a deployment, or planning stakeholder communications for a rollout.