Token导航 LogoToken导航TokenDH.com
研究检索需要联网github未标认证来源可访问许可证需确认审计异常

living-docs生活文档

Agent Skill

用于辅助文档、README、Markdown、说明文和内容稿件的整理与改写。它适合让 Agent 提炼结构、补齐章节、统一术语、检查链接或把零散材料整理成可读文档。使用时应保留项目已有事实、命令和路径,不要把未确认的信息写成确定结论;涉及对外文案时,还需要控制语气,避免过度营销或夸大能力。

总安装

272

周安装

11

GitHub Stars

公开资料未说明

下载量

85
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:living-docs(生活文档)
来源仓库:https://github.com/rcrespodev/rcrespodev-skills
仓库路径:skills/living-docs
安装命令:
npx skills add https://github.com/rcrespodev/rcrespodev-skills --skill living-docs
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/rcrespodev/rcrespodev-skills --skill living-docs

简介

用于文档、README 和内容稿件的整理与改写,适合提炼结构与统一术语。

  • 可补齐章节、检查链接或整合零散材料为可读文档。
  • 使用时应保留项目事实与路径,避免将未确认信息写成确定结论。
  • 安装方式:通过 npx 从 GitHub 仓库添加,需确认权限与维护状态。
  • 注意:对外文案需控制语气,避免过度营销或夸大能力。

SKILL.md

Living Docs

Generate documentation driven by actual code changes. Every document traces to specific commits and files. When code changes, docs change.

Language policy: Generate all documentation in English. Include Spanish translations in the aliases frontmatter field.

Folder Structure

All generated docs live under ${GIT_REPO_ROOT}/docs/ (relative to the repository root). Create this structure if it doesn't exist:

docs/
├── components/          # Component Docs (services, apps, libraries)
│   ├── auth-service.md
│   ├── user-service.md
│   └── shared-utils.md
├── changelogs/          # Changelogs and release notes
│   ├── changelog-auth-service-2026-02-13.md
│   └── changelog-global-2026-02-13.md
├── adrs/                # Architecture Decision Records
│   ├── adr-001-redis-caching.md
│   └── adr-002-event-driven-auth.md
├── runbooks/            # Runbooks and SOPs
│   ├── runbook-deploy-auth-service.md
│   └── runbook-database-migration.md
└── index.md             # Auto-generated index linking all docs

File Naming Conventions

Doc TypeDirectoryFilename Pattern
Component Docdocs/components/{component-name}.md
Changelogdocs/changelogs/changelog-{scope}-{YYYY-MM-DD}.md
ADRdocs/adrs/adr-{NNN}-{slug}.md
Runbookdocs/runbooks/runbook-{operation-slug}.md
Indexdocs/index.md

Index File

After generating or updating docs, update docs/index.md with links to all docs:

# Documentation Index

> Auto-generated. Last updated: YYYY-MM-DD

## Components
- [[auth-service]] — Authentication and authorization service
- [[shared-utils]] — Shared utility library

## Recent Changelogs
- [[changelog-auth-service-2026-02-13]] — Added OAuth2 support

## Architecture Decisions
- [[adr-001-redis-caching]] — Accepted

## Runbooks
- [[runbook-deploy-auth-service]] — Deployment procedure

Workflow

1. Gather context     → Determine diff scope
2. Extract diff data  → Run extract-diff.sh or git commands
3. Classify changes   → Identify what matters (see references/analysis-patterns.md)
4. Select templates   → Pick doc types (see references/templates.md)
5. Generate docs      → Write markdown with full YAML frontmatter
6. Verify output      → Cross-check generated docs against diff
7. Present summary    → Show what was generated and why

Step 1: Gather Context

Determine from the user's message (ask only if not inferrable):

  • Diff scope: Branch comparison (e.g., feature/X vs Develop) or last N commits?
  • Existing docs: Any docs to update rather than create from scratch?

Defaults (when not specified):

  • Diff scope: Current branch vs default branch (auto-detected from repo)
  • Output path: Always ${GIT_REPO_ROOT}/docs/ (using the folder structure above)
  • Existing docs: Search ${GIT_REPO_ROOT}/docs/ for matching filenames before creating new docs

Step 2: Extract Diff Data

Run the extraction script from this skill's directory:

# Branch comparison (auto-detects default branch)
bash <this-skill-path>/scripts/extract-diff.sh <repo-path> --branch <target>

# Last N commits
bash <this-skill-path>/scripts/extract-diff.sh <repo-path> --commits 20

# Filtered by path (for monorepos)
bash <this-skill-path>/scripts/extract-diff.sh <repo-path> --branch Develop --path services/auth/

For multi-repo workspaces, run per repository.

Large Diff Strategy

When the diff is large (100+ files changed or output exceeds ~50KB):

  1. Start with --stat only — Use the file list and change counts to plan
  2. Read full diff only for high-impact files — APIs, schemas, configs, contracts, new files
  3. Read only changed hunks for medium-impact files — Business logic, services
  4. Skip full diff for low-impact files — Tests, formatting, comments
  5. Split by directory — If still too large, analyze one component/service at a time

Step 3: Classify Changes

Read references/analysis-patterns.md for the full classification guide.

Priority: High-impact changes (new components, public API changes, business logic changes, schema migrations, new dependencies, infra changes) are always documented. Medium-impact (internal refactors, test changes) only if significant. Low-impact (formatting, comments, patch bumps) are skipped.

Key distinctions (from analysis-patterns.md):

  • Business logic vs refactor: Did test expectations change? → business logic. Same tests pass? → refactor.
  • Interface exposure: External (public API) > Inter-component (shared packages) > Internal (same module). Document proportionally.

Map each significant change to doc types:

Change TypeImpactDoc Types
New component / moduleHighComponent Doc (new)
Public API changeHighComponent Doc + Changelog (Breaking if contract changed)
Business logic changeHighComponent Doc + Changelog
Inter-component interface changeHighComponent Doc + flag downstream consumers
Schema / data model changeHighADR + Component Doc
Major dependency addedMedium-HighADR + Component Doc
Infrastructure / deployment changeMediumRunbook
Internal refactor (same behavior)LowChangelog (Internal) or skip
Release milestoneChangelog

Step 4: Select and Fill Templates

Read references/templates.md for all templates and the frontmatter schema.

Frontmatter rules:

  • ALWAYS include all required fields: aliases, type, layer, status, owner, tech_stack, last_updated, source_branch, commit_range
  • Use [[wiki-links]] for owner, tech_stack, and cross-references
  • Set last_updated to today's date
  • Set source_branch and commit_range from the actual diff
  • Set status honestly: active, debt, zombie, or gap
  • Populate aliases with English keywords + Spanish equivalents
  • Infer owner and tech_stack using the heuristics in templates.md → "Inferring Frontmatter from Diffs"
  • Omit template sections that don't apply (e.g., don't include "Events Published" for a REST-only service)

Step 5: Generate Docs

Write docs to the folder structure defined above.

Updating existing docs: Read first, preserve frontmatter structure, update last_updated and commit_range, modify only affected sections, append to "Recent Changes".

Merge Strategy for Incremental Updates

When a doc already exists:

SectionStrategy
FrontmatterMerge: Update last_updated, commit_range, status. Preserve owner, aliases (append new ones)
What It DoesReplace only if the component's purpose fundamentally changed
API Surface / Exported APIMerge: Add new entries, update changed entries, mark removed entries as deprecated
DependenciesReplace with current state
ConfigurationMerge: Add new env vars, update changed ones
Key FilesReplace with current state
Recent ChangesAppend new changes at the top, keep last 5-10 entries

Step 6: Verify Output

Before presenting to the user, cross-check:

  • Every endpoint/export mentioned in docs exists in the diff or codebase
  • All frontmatter required fields are populated (no empty or placeholder values except owner: "[[TBD]]")
  • File paths referenced in "Key Files" actually exist
  • Breaking changes flagged in Changelog match actual contract changes in the diff
  • No duplicate docs (check existing files before creating new ones)

Step 7: Present Summary

Show the user what was generated:

## Documentation Generated

| File | Type | Reason |
|------|------|--------|
| docs/components/auth-service.md | Component Doc | New endpoints in routes/users.ts |
| docs/changelogs/changelog-auth-2026-02-13.md | Changelog | 12 commits with 3 features, 2 fixes |

### Key Changes Documented
- [bullets]

### Skipped (Low Impact)
- [what and why]

Always update ${GIT_REPO_ROOT}/docs/index.md with links to all generated docs (for multi-repo workspaces, do this per repository).


Quality Rules

  • No fluff: Every sentence carries information. Cut filler.
  • Trace to code: Every claim references a file, commit, or config.
  • Tables over prose: For endpoints, env vars, dependencies — always tables.
  • Be honest: If the diff reveals tech debt, set status: debt. Living docs tell the truth.
  • Aliases matter: Include concept name, Spanish translation, common abbreviations.
  • Omit empty sections: Don't include template sections that have no content for this component.

Few-Shot Example

Input: Diff Summary

=== FILE STATS ===
 services/auth/src/routes/auth.ts   | 45 +++++++++--
 services/auth/src/services/oauth.ts | 120 ++++++++++++++++++++++++++++
 services/auth/src/types/auth.dto.ts |  15 ++++
 packages/shared-types/src/user.ts   |   8 ++--
 services/auth/package.json          |   2 +  (added passport-google-oauth20)
 services/auth/tests/oauth.test.ts   |  85 ++++++++++++++++++++

=== COMMIT LOG ===
a1b2c3d feat: add Google OAuth2 login flow
d4e5f6g feat: add OAuth callback handler
h7i8j9k fix: handle missing email in OAuth profile
l0m1n2o chore: add passport-google-oauth20 dependency

Output: Classification

  1. New OAuth service file (oauth.ts, 120 lines) → High impact, new feature → Component Doc update
  2. Route changes (auth.ts, 45 lines) → Public API change → Component Doc + Changelog
  3. Shared types change (packages/shared-types/user.ts) → Inter-component interface → Component Doc + flag consumers
  4. New major dependency (passport-google-oauth20) → ADR candidate
  5. New tests with different expectations → Confirms business logic change, not refactor

Output: Generated Docs

  • docs/components/auth-service.md — Updated: added OAuth endpoints, new dependency, new key files
  • docs/changelogs/changelog-auth-2026-02-13.md — New: 2 features (OAuth login, callback handler), 1 fix
  • docs/adrs/adr-003-google-oauth.md — New: Decision to use passport-google-oauth20 for social login
  • docs/components/shared-types.md — Updated: flag that UserDTO interface changed (consumed by 2 services)

Resources

  • scripts/extract-diff.sh — Extract structured diff data (file stats, commit log, full diff)
  • references/templates.md — All doc templates with frontmatter schema
  • references/analysis-patterns.md — How to classify changes from diffs

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

35.49%
按下载量换算30

Claude

31.84%
按下载量换算27

Cursor

18.55%
按下载量换算16

Gemini CLI

9.08%
按下载量换算8

安全审计

Gen Agent Trust Hub

未通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills