repo-guidance-sync
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- Design
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Env read
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: repo-guidance-sync
description: Keep repository documentation, AGENTS.md, and contributor/test guidance aligned with code, desig…
category: design
runtime: no special runtime
---
# repo-guidance-sync output preview
## PART A: Task fit
- Use case: Keep repository documentation, AGENTS.md, and contributor/test guidance aligned with code, design, and product changes. Use when Codex changes or reviews behavior that affects user-facing docs, developer runbooks, architecture notes, CLI/API references, setup instructions, design-system guidance, operational commands, E2E assumptions, or agent instructions; when a user asks to update docs after implementation; or when stale repo guidance could mislead future contributors. Use when this capability is needed..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Overview / Workflow / AGENTS.md Rules” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Keep repository documentation, AGENTS.md, and contributor/test guidance aligned with code, design, and product changes. Use when Codex changes or reviews behavior that affects user-facing docs, developer runbooks, architecture notes, CLI/API references, setup instructions, design-system guidance, operational commands, E2E assumptions, or agent instructions; when a user asks to update docs after implementation; or when stale repo guidance could mislead future contributors. Use when this capability is needed.”.
- **02** When the source has headings, the agent prioritizes “Overview / Workflow / AGENTS.md Rules” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, read environment variables; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, read environment variables; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, read environment variables.
Start with a small task and check whether the result follows “Overview / Workflow / AGENTS.md Rules”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: repo-guidance-sync
description: Keep repository documentation, AGENTS.md, and contributor/test guidance aligned with code, desig…
category: design
source: tomevault-io/skills-registry
---
# repo-guidance-sync
## When to use
- Keep repository documentation, AGENTS.md, and contributor/test guidance aligned with code, design, and product changes…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Overview / Workflow / AGENTS.md Rules” and keep inference separate from source facts.
- read files, write/modify files, read environment variables; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "repo-guidance-sync" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Overview / Workflow / AGENTS.md Rules
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, read environment variables | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Repo Guidance Sync
Overview
Use this skill to decide what documentation must change after a code, design, or product update, then make those edits in the right files with verifiable links back to source behavior.
Workflow
Identify the change surface.
- Inspect the diff, touched packages, new commands, config flags, UI behavior, API shapes, CRDs, generated schemas, deployment manifests, and tests.
- If the change affects setup, CLI workflows, operator reconciliation, ingress/gateway behavior, auth/policy, registry/image handling, observability, or cache-mode assumptions, identify the matching E2E scenario in
test/e2e/kind.shor adjacent integration tests before editing docs. - Search for existing docs before adding new files:
rg -n "<command|field|feature|concept>" README.md AGENTS.md docs website config api internal services. - Prefer updating the nearest existing guide, reference, or runbook over creating a new document.
Classify required doc updates.
- User-facing product change: update README, docs guides, CLI examples, API/reference pages, screenshots or UI copy references if present.
- Developer workflow change: update AGENTS.md, build/test instructions, local setup notes, failure modes, environment variables, or repo map entries.
- Codebase architecture or contributor-flow change: review
docs/internals/and decide whether the overview, package tours, or Mermaid diagrams need updates. Add or revise diagrams only when they clarify package boundaries, request flow, reconciliation flow, service interactions, or contributor decision points. - Design change: update design-system rules, component guidance, UX behavior notes, or docs that describe screens/workflows.
- Operational change: update install, deployment, TLS, registry, Kubernetes, observability, and rollback/debug instructions.
- Schema/contract change: update CRD/API docs, examples, generated docs if the repo owns them, and any golden snapshots tied to CLI help.
- E2E-visible behavior change: update or add the relevant E2E assertion in
test/e2e/kind.shwhen the behavior is exercised through Kind, real MCP traffic, policy/session state, OAuth, observability, registry/image paths, orcluster doctor. If narrower unit/integration coverage is sufficient, note why in the final validation summary.
Verify source truth before writing.
- Treat code, tests, CRD types, OpenAPI specs, CLI definitions, workflow files, and manifests as source of truth.
- For commands and examples, confirm exact flags, defaults, resource names, paths, and environment variables from implementation.
- Avoid inventing roadmap promises or behavior not present in code unless the user explicitly asks for planned-product wording.
Edit with the right scope.
- Keep docs concise and task-oriented; remove stale claims instead of layering caveats.
- Preserve the repo's voice, terminology, command style, and existing document structure.
- For
docs/internals/, prefer updating the nearest existing walkthrough, mental model, or diagram over adding a new page. Use diagrams for relationships and flows, not for listing files that a table can express more clearly. - Update AGENTS.md only for durable contributor or agent guidance, not one-off implementation details.
- Keep examples copy-pasteable: include required tags, namespaces, paths, auth headers, and prerequisite environment variables.
- Update links and table-of-contents entries when adding or renaming pages.
Validate.
- Run the narrowest relevant checks: markdown/docs build if available, golden tests for CLI help changes, generated-doc drift checks when docs are generated, E2E scenario checks for behavior covered by
test/e2e/kind.sh, and targeted code tests if examples exercise behavior. - At minimum, run searches for old field names, commands, or stale wording that the change replaces.
- If validation cannot be run, state the blocker and what was manually checked.
- Run the narrowest relevant checks: markdown/docs build if available, golden tests for CLI help changes, generated-doc drift checks when docs are generated, E2E scenario checks for behavior covered by
AGENTS.md Rules
Update AGENTS.md when a change affects how future agents or contributors should work in the repo. Good reasons include new required checks, changed setup commands, new failure modes, changed repository layout, new service ownership, changed CLI workflows, or new operational safety rules.
Do not put product marketing, exhaustive API reference, release notes, or transient PR context in AGENTS.md. Link or summarize stable docs instead.
Output Standard
When finished, summarize:
- docs and AGENTS.md files changed
- source behavior each update reflects
- validation run, including searches for stale terms
- known doc gaps left intentionally open
Source: Agent-Hellboy/mcp-runtime — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review