wiki-doc-sync

Estrelas14

Forks3

Atualizado8 de julho de 2026 às 13:00

Detect documentation pages whose covered code has drifted and open one doc-sync PR per stale page. Use when running the documentation wiki's self-firing lint (scheduled or on demand), or when asked to sync the architecture docs with the code.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

vippsas

vippsas/manifold

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

SKILL.md

readonly

name	wiki-doc-sync
description	Detect documentation pages whose covered code has drifted and open one doc-sync PR per stale page. Use when running the documentation wiki's self-firing lint (scheduled or on demand), or when asked to sync the architecture docs with the code.

Wiki doc-sync

The self-firing half of Manifold's documentation wiki (see docs/llm-wiki.md). The staleness signal is git-measurable, so this needs no human to notice drift — it turns each stale page into one reviewable PR. The signal fires the work; a human only approves.

Procedure

Lint. From the repo root, run:
```
bash scripts/wiki-lint.sh
```
- If structural checks: FAILED, fix those first — a broken covers: ref, a missing subsystem page, an orphan, or frozen-spec misuse is a correctness bug in the wiki itself. Handle it in its own PR.
- Collect every STALE … line. Each names a page and the covers: paths that moved.
Nothing stale ⇒ stop. No PRs, no noise.
README is review-only. If README.md is flagged, do not auto-edit it — it is the editorial, user-facing front door. Note it for a human ("README flagged: check whether a runtime, npm script, or ~/.manifold/** path actually changed"). Never fabricate front-door copy changes just to clear the flag.
For each stale docs/architecture/*.md page — one page, one PR:
1. Branch: docs/sync-<page-basename> (e.g. docs/sync-session).
2. Read the page, then read its covers: code as it is now. Code is ground truth.
3. Apply surgical corrections only: wrong file:line citations, renamed/removed symbols, changed behavior, broken cross-references. Do not rewrite wholesale or change tone/structure. Match the page's style; docs/architecture/session.md is the template.
4. Bump the page's updated: to today's date.
5. Prepend a ## [sync] <date> — synced <page> with code entry to log.md (newest first) summarizing what drifted.
6. Verify (writer ≠ verifier): re-run bash scripts/wiki-lint.sh and confirm that page no longer reports STALE and structural checks: PASS. The lint certifies the fix — not your own say-so. Then run git status --porcelain and confirm only the doc page and log.md are modified: reading the covers: code is required, editing it is not. Revert any stray change to a tracked file under covers: before committing — a dirtied src/** file left in a worktree is what blocks a later ff-only sync (#835).
7. Commit (with a Co-Authored-By trailer) and open a PR titled docs: sync <page> with code, body summarizing the drift and the corrections. Request review from the covered code's owner (.github/CODEOWNERS). Do not merge — a human approves.

Rules

One page → one PR. Never bundle multiple pages into a single PR.
Never touch the code under covers: — only the docs.
Never cite a frozen spec (docs/superpowers|planning|research) as current truth.
Keep deep internals in the wiki; the README only points to it.
Conventions live in CLAUDE.md §5 / AGENTS.md. Promote anything that survives a few sync cycles; drop the rest.

Mais deste repositório

mesmo repositório

testing

vippsas/manifold

Use whenever running tests in this project — verifying a fix, validating a PR, running the suite after changes, or checking a single file. Covers which command to use, how the `better-sqlite3` ABI rebuild fits in, and how to target individual files.

2026-07-0814

gh-create-issue

vippsas/manifold

Create GitHub issues from agent findings, bugs, regressions, UX problems, or follow-up work. Use when the user asks to create, file, or draft a GitHub issue and the result should be a structured issue body plus a `gh issue create` command.

2026-06-1314

gh-process-issues

vippsas/manifold

Sweep the GitHub issue queue and deliver one reviewable PR per labeled issue. Use when running the autonomous issue pipeline's self-firing sweep (scheduled or on demand), or when asked to process issues labeled `llm-github-issue`.

2026-06-1214

watch

vippsas/manifold

Watch a video that Manifold has pre-staged. Manifold's main process downloads the video, extracts auto-scaled frames with ffmpeg, and produces a timestamped transcript (native captions or gpt-4o-transcribe). This skill receives the report path and tells Claude to read each frame.

2026-06-1114

gh-create-pr

vippsas/manifold

Create GitHub pull requests for completed fixes or features. Use when the user asks to prepare, push, or open a PR and the result should include a meaningful remote branch name, commit, and PR title tied to the actual bug fix or main change rather than an agent or worktree name.

2026-05-2214

design

vippsas/manifold

Manifold design system — philosophy, principles, and patterns for UI work. Use when creating or modifying UI components, styling, theming, layout, or any visual aspect of the application.

2026-03-2914

name	wiki-doc-sync
description	Detect documentation pages whose covered code has drifted and open one doc-sync PR per stale page. Use when running the documentation wiki's self-firing lint (scheduled or on demand), or when asked to sync the architecture docs with the code.

Wiki doc-sync

Procedure

Lint. From the repo root, run:
```
bash scripts/wiki-lint.sh
```
- If structural checks: FAILED, fix those first — a broken covers: ref, a missing subsystem page, an orphan, or frozen-spec misuse is a correctness bug in the wiki itself. Handle it in its own PR.
- Collect every STALE … line. Each names a page and the covers: paths that moved.
Nothing stale ⇒ stop. No PRs, no noise.
README is review-only. If README.md is flagged, do not auto-edit it — it is the editorial, user-facing front door. Note it for a human ("README flagged: check whether a runtime, npm script, or ~/.manifold/** path actually changed"). Never fabricate front-door copy changes just to clear the flag.
For each stale docs/architecture/*.md page — one page, one PR:
1. Branch: docs/sync-<page-basename> (e.g. docs/sync-session).
2. Read the page, then read its covers: code as it is now. Code is ground truth.
3. Apply surgical corrections only: wrong file:line citations, renamed/removed symbols, changed behavior, broken cross-references. Do not rewrite wholesale or change tone/structure. Match the page's style; docs/architecture/session.md is the template.
4. Bump the page's updated: to today's date.
5. Prepend a ## [sync] <date> — synced <page> with code entry to log.md (newest first) summarizing what drifted.
6. Verify (writer ≠ verifier): re-run bash scripts/wiki-lint.sh and confirm that page no longer reports STALE and structural checks: PASS. The lint certifies the fix — not your own say-so. Then run git status --porcelain and confirm only the doc page and log.md are modified: reading the covers: code is required, editing it is not. Revert any stray change to a tracked file under covers: before committing — a dirtied src/** file left in a worktree is what blocks a later ff-only sync (#835).
7. Commit (with a Co-Authored-By trailer) and open a PR titled docs: sync <page> with code, body summarizing the drift and the corrections. Request review from the covered code's owner (.github/CODEOWNERS). Do not merge — a human approves.

Rules

One page → one PR. Never bundle multiple pages into a single PR.
Never touch the code under covers: — only the docs.
Never cite a frozen spec (docs/superpowers|planning|research) as current truth.
Keep deep internals in the wiki; the README only points to it.
Conventions live in CLAUDE.md §5 / AGENTS.md. Promote anything that survives a few sync cycles; drop the rest.