syncing-claude-config

Estrelas9

Forks1

Atualizado30 de julho de 2026 às 06:44

Sync this Claude Code config against new release notes — find config features added since the pinned baseline that this config should adopt. Use when Claude Code has been updated, when the user asks what's new / what changed / whether to adopt new settings or hooks, after a version bump, or when checking config currency against the latest release. Reports adoptable settings/hooks/env-vars/permissions as a risk-tiered proposal, then bumps the baseline. Do NOT use for auditing existing config quality, debugging hooks, or organizing rules — that is `maintaining-claude-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

TrevorS

TrevorS/dot-claude

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

Explorador de arquivos

3 arquivos

SKILL.md

readonly

name	syncing-claude-config
description	Sync this Claude Code config against new release notes — find config features added since the pinned baseline that this config should adopt. Use when Claude Code has been updated, when the user asks what's new / what changed / whether to adopt new settings or hooks, after a version bump, or when checking config currency against the latest release. Reports adoptable settings/hooks/env-vars/permissions as a risk-tiered proposal, then bumps the baseline. Do NOT use for auditing existing config quality, debugging hooks, or organizing rules — that is `maintaining-claude-code`.
argument-hint	[check]

Syncing Claude Code Config

Diff this config against Claude Code release notes published since the pinned baseline, surface the config-relevant changes worth adopting, apply the ones Teej picks, and bump the baseline. The relevance filter is computed live each run — there is no hand-maintained catalog.

check (or a bare invocation) is report-only: never write to config or to baseline.json until Teej approves the proposal.

State lives in ~/.claude/skills/syncing-claude-config/baseline.json:

{ "claudeCodeVersion": "2.1.193", "syncedDate": "2026-06-25", "adopted": [...], "declined": [...] }

Boundary

This skill answers "what did new releases add that I'd want?" — forward drift against release notes. It does not judge whether existing config is well-formed; hand any "is this edit correct / well-shaped" question to the maintaining-claude-code skill after applying.

Workflow

1. Establish the version window

jq -r .claudeCodeVersion ~/.claude/skills/syncing-claude-config/baseline.json   # pinned baseline
claude --version                                                                 # installed

If installed == baseline, report ❨✓❩ Config targets <version> — up to date and stop. Nothing to sync.

2. Fetch release notes for the window

Sync off the releases API, not CHANGELOG.md — it carries per-release published_at dates and clean record boundaries the markdown lacks.

gh api 'repos/anthropics/claude-code/releases?per_page=100' \
  --jq '.[] | {tag: .tag_name, date: .published_at, body: .body}'

Keep only releases whose tag (strip the v) is > the baseline version and <= installed. Each body is a flat markdown bullet list.

3. Pre-filter to config-relevant bullets (cheap, high-recall)

Most bullets are UI / streaming / MCP-reliability fixes with no config surface — drop them. Keep a bullet if it matches any of:

An env var: \b(CLAUDE_CODE_|CLAUDE_|ANTHROPIC_|OTEL_)[A-Z0-9_]+\b — this pattern is ~100% precise; never drop one of these.
A backtick token plus one of the words: setting, settings.json, environment variable, env var, frontmatter, hook, permission, matcher.
A dotted.camelCase identifier in backticks (e.g. sandbox.credentials, autoMode.classifyAllShell).

Backticks are overloaded — slash commands (/rewind), tool names (ExitWorktree), CLI subcommands (claude mcp login), and UI strings are also backticked. Backtick-presence alone over-selects; require identifier shape, not just any backtick. Typical survivors: 0–2 bullets per release, zero on patch-only releases.

4. Classify each survivor

For each surviving bullet, determine — reading the prose, not just the token:

Surface: settings.json key · nested key · env var · hook event/matcher · skill frontmatter field · permission syntax · CLI-only (skip CLI-only).
Anchor: the exact identifier(s) it adds/changes. Watch multi-anchor bullets (display-name, default-enabled, … in one line) and wildcards (metadata.*).
Change kind: added · changed · deprecated/removed. A bullet can promote one key and deprecate another (CLAUDE_CODE_MAX_RETRIES → CLAUDE_CODE_RETRY_WATCHDOG).

5. Intersect with the live config — relevance = anchor ∩ usage

Read the current config and keep only changes that touch a surface Teej actually uses, or that he plausibly should:

jq 'keys' ~/.claude/settings.json                       # top-level keys
jq '.env | keys' ~/.claude/settings.json                # env vars in use
jq '.hooks | keys' ~/.claude/settings.json              # wired hook events
jq '.permissions' ~/.claude/settings.json               # allow/deny/ask
rg -l '^---' ~/.claude/skills/*/SKILL.md                # skill frontmatter surfaces

Demote, never delete: changes that don't intersect go into a collapsed "other release changes" bucket so nothing silently vanishes. Drop anything already in baseline.json's declined list (don't re-nag).

6. Present the proposal (two-zone)

Lead with a scannable table, risk-tiered, safest first:

Setting	Current → Proposed	Risk	Why

Risk tiers:

additive-safe — new optional key/flag, no behavior change. Candidate for quick approval.
behavioral — changes how something already behaves. Propose; gate on Teej hitting the symptom.
breaking — renamed/removed key in use. Always preview the before/after diff; never auto-apply.

Under each row, cite the exact changelog line that justifies it, with the version. Then the collapsed "other release changes" bucket. End with the version window covered and the bump that will be recorded.

7. Apply (only on approval)

For each accepted change, edit the real config (~/.claude/settings.json, hooks, skill frontmatter). Leave a self-documenting breadcrumb on non-obvious edits (e.g. // added <key> — <version>: <one-line reason>). One logical change per edit so git is the undo layer. After applying, hand the result to maintaining-claude-code for a well-formedness pass if any edit was non-trivial.

8. Bump the baseline

Update ~/.claude/skills/syncing-claude-config/baseline.json: set claudeCodeVersion to installed, syncedDate to today (from the environment context, not a guess), append accepted changes to adopted (with the version that introduced them) and rejected ones to declined. The declined list is what stops the same proposal resurfacing next run.

Notes

Patch-only releases legitimately yield zero config changes — reporting "nothing to adopt" is a correct, expected outcome, not a failure.
If the releases API is unreachable, fall back to https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md (same bullets, no dates).
Never propose enforceAvailableModels, requiredMinimumVersion, or other managed/enterprise keys for this single-user config unless Teej asks — they target shared/managed deployments.

Mais deste repositório

mesmo repositório

monitoring-ci

TrevorS/dot-claude

Monitor and watch GitHub Actions CI/CD pipeline runs in real time. Use when the user has pushed code and wants to watch the build, check CI status, see if tests passed, monitor a pipeline, or wait for a workflow run to complete. Also use after any `jj git push` or `git push` command. Reports pass/fail with failed job logs. Do NOT use for writing or editing CI workflow YAML files, optimizing CI config, or debugging CI configuration — only for monitoring active runs.

2026-07-309

cleaning-commit-history

TrevorS/dot-claude

Reorganize and clean up messy commit history on a feature branch into logical, reviewable commits. Use when cleaning up commits, preparing a branch for review, separating formatting from logic changes, fixing broken intermediate states, or squashing WIP commits.

2026-07-309

maintaining-claude-code

TrevorS/dot-claude

Audit and improve Claude Code hooks, rules, and settings.json. Use when adding/debugging a hook, organizing rules, auditing settings.json (permissions, env vars, stale flags), or deciding between hook vs skill vs rule vs CLAUDE.md. For SKILL.md authoring use the skill-creator plugin; for CLAUDE.md audits use the claude-md-improver plugin.

2026-06-019

executing-test-plans

TrevorS/dot-claude

Execute a structured test plan and emit a concise results document (JSON + Markdown). Use when running test plans, executing QA workflows, verifying acceptance criteria systematically, or producing test results documentation.

2026-06-019

searching-history

TrevorS/dot-claude

Search past Claude Code sessions to recall prior solutions, commands, fixes, and decisions. Use when the user references earlier work ("how did I fix", "last time we", "pick up where we left off", "a few months ago", "what was that … I set up", "didn't I once").

2026-06-019

using-linear

TrevorS/dot-claude

Query, create, and manage Linear issues from the command line. Use when checking assigned work, viewing issue details, creating new issues, or updating issue status.

2026-06-019

name	syncing-claude-config
description	Sync this Claude Code config against new release notes — find config features added since the pinned baseline that this config should adopt. Use when Claude Code has been updated, when the user asks what's new / what changed / whether to adopt new settings or hooks, after a version bump, or when checking config currency against the latest release. Reports adoptable settings/hooks/env-vars/permissions as a risk-tiered proposal, then bumps the baseline. Do NOT use for auditing existing config quality, debugging hooks, or organizing rules — that is `maintaining-claude-code`.
argument-hint	[check]

Syncing Claude Code Config

check (or a bare invocation) is report-only: never write to config or to baseline.json until Teej approves the proposal.

State lives in ~/.claude/skills/syncing-claude-config/baseline.json:

{ "claudeCodeVersion": "2.1.193", "syncedDate": "2026-06-25", "adopted": [...], "declined": [...] }

Boundary

Workflow

1. Establish the version window

jq -r .claudeCodeVersion ~/.claude/skills/syncing-claude-config/baseline.json   # pinned baseline
claude --version                                                                 # installed

If installed == baseline, report ❨✓❩ Config targets <version> — up to date and stop. Nothing to sync.

2. Fetch release notes for the window

Sync off the releases API, not CHANGELOG.md — it carries per-release published_at dates and clean record boundaries the markdown lacks.

gh api 'repos/anthropics/claude-code/releases?per_page=100' \
  --jq '.[] | {tag: .tag_name, date: .published_at, body: .body}'

Keep only releases whose tag (strip the v) is > the baseline version and <= installed. Each body is a flat markdown bullet list.

3. Pre-filter to config-relevant bullets (cheap, high-recall)

Most bullets are UI / streaming / MCP-reliability fixes with no config surface — drop them. Keep a bullet if it matches any of:

An env var: \b(CLAUDE_CODE_|CLAUDE_|ANTHROPIC_|OTEL_)[A-Z0-9_]+\b — this pattern is ~100% precise; never drop one of these.
A backtick token plus one of the words: setting, settings.json, environment variable, env var, frontmatter, hook, permission, matcher.
A dotted.camelCase identifier in backticks (e.g. sandbox.credentials, autoMode.classifyAllShell).

4. Classify each survivor

For each surviving bullet, determine — reading the prose, not just the token:

Surface: settings.json key · nested key · env var · hook event/matcher · skill frontmatter field · permission syntax · CLI-only (skip CLI-only).
Anchor: the exact identifier(s) it adds/changes. Watch multi-anchor bullets (display-name, default-enabled, … in one line) and wildcards (metadata.*).
Change kind: added · changed · deprecated/removed. A bullet can promote one key and deprecate another (CLAUDE_CODE_MAX_RETRIES → CLAUDE_CODE_RETRY_WATCHDOG).

5. Intersect with the live config — relevance = anchor ∩ usage

Read the current config and keep only changes that touch a surface Teej actually uses, or that he plausibly should:

jq 'keys' ~/.claude/settings.json                       # top-level keys
jq '.env | keys' ~/.claude/settings.json                # env vars in use
jq '.hooks | keys' ~/.claude/settings.json              # wired hook events
jq '.permissions' ~/.claude/settings.json               # allow/deny/ask
rg -l '^---' ~/.claude/skills/*/SKILL.md                # skill frontmatter surfaces

6. Present the proposal (two-zone)

Lead with a scannable table, risk-tiered, safest first:

Setting	Current → Proposed	Risk	Why

Risk tiers:

additive-safe — new optional key/flag, no behavior change. Candidate for quick approval.
behavioral — changes how something already behaves. Propose; gate on Teej hitting the symptom.
breaking — renamed/removed key in use. Always preview the before/after diff; never auto-apply.

7. Apply (only on approval)

8. Bump the baseline

Notes

Patch-only releases legitimately yield zero config changes — reporting "nothing to adopt" is a correct, expected outcome, not a failure.
If the releases API is unreachable, fall back to https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md (same bullets, no dates).
Never propose enforceAvailableModels, requiredMinimumVersion, or other managed/enterprise keys for this single-user config unless Teej asks — they target shared/managed deployments.