ccb-github

Maintain this CCB project's GitHub-facing release and npm publication surface. Use when preparing, publishing, auditing, or fixing CCB releases; updating README.md, README/zh.md, localized README files, CHANGELOG.md, VERSION, package.json, GitHub release notes/assets, repository description/topics, npm registry state, or GitHub Actions release/test status.

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Quality

Content

77%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

An highly actionable, well-validated operational skill: every workflow is copy-paste executable with explicit checkpoints, recovery loops, and stop conditions for risky release operations. The weaknesses are redundancy — npm requirements repeated across many sections — and a monolithic body whose runbooks and requirements lists should be split into reference files.

Suggestions

Consolidate the npm requirements that currently appear in Core Rule, Decision Tree, Release Preparation Checklist, Publish Sequence, Recovery Runbook, and Stop Conditions into one authoritative npm section; other sections should reference it in a single line to cut substantial duplicated tokens.

Move the Recovery Runbook case list and the per-file README requirements into a references/ file (e.g. references/recovery.md, references/readme-requirements.md) and keep one-line pointers in SKILL.md, reducing the body to an overview with clearly signaled one-level-deep references.

Deduplicate the identical merge-to-default-branch git block that appears in both 'Homepage Maintenance Without A New Tag' and 'Publish Sequence' by defining it once and referencing the steps elsewhere.

Dimension	Reasoning	Score
Conciseness	The body is dense and mostly free of concept over-explanation, but npm requirements are restated across at least five sections (Core Rule, Decision Tree, Release Preparation Checklist with two subsections, Publish Sequence, Recovery Runbook, Stop Conditions), and the merge-to-default-branch git sequence appears verbatim twice. This repeated material could be consolidated into one authoritative section, matching the 'mostly efficient but could be tightened' anchor rather than the 'minor trim' anchor at 4.	3 / 5
Actionability	Guidance is fully executable: exact checker invocations with flags and wait values, git/gh/npm commands (e.g. 'npm view @seemseam/ccb version dist-tags --json', 'gh api 'repos/.../contents/README.md?ref=main' --jq .content \| base64 -d'), named release assets, and pre-tag verification with 'git show HEAD:package.json'. The only placeholders (vX.Y.Z, <release-branch>) are the standard variable ones, covering the common cases copy-paste ready.	5 / 5
Workflow Clarity	Multi-step processes are explicitly sequenced (10-step Execution Contract, 14-step Publish Sequence) with validation checkpoints throughout: run --phase prepare and fix every FAIL before tagging, --phase published with --wait-seconds 1800 after, a Recovery Runbook keyed to checker FAIL output, and a Stop Conditions list that blocks declaring completion. Destructive tag/publish operations are wrapped in validate-fix-retry feedback loops, matching the top anchor.	5 / 5
Progressive Disclosure	The bundled checker scripts (scripts/check_release_state.py plus six release_checker_*.py modules) are appropriately externalized and clearly signaled by path, but the ~280-line SKILL.md inlines substantial detail that belongs in reference files — the Recovery Runbook case list, the per-file README requirements, and the npm Trusted Publisher configuration. That inline bulk is more than the 'minor organization gaps' of the anchor at 4, fitting the 'content that should be separate is inline' anchor.	3 / 5
	Total	16 / 20 Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: third-person, specific, and complete, with an explicit 'Use when' clause enumerating the concrete artifacts and states the skill maintains. The only weakness is slightly less synonym coverage for release-related trigger phrases.

Dimension	Reasoning	Score
Specificity	The description names the domain ('Maintain this CCB project's GitHub-facing release and npm publication surface') and enumerates concrete, file-level artifacts and actions: README.md, README/zh.md, CHANGELOG.md, VERSION, package.json, GitHub release notes/assets, repository description/topics, npm registry state, and GitHub Actions status. Coverage is comprehensive with no meaningful gaps, matching the multiple-specific-concrete-actions anchor rather than the 'minor gaps' anchor at 4.	5 / 5
Completeness	It explicitly answers both: what ('Maintain this CCB project's GitHub-facing release and npm publication surface') and when ('Use when preparing, publishing, auditing, or fixing CCB releases; updating README.md, README/zh.md, ...'), with concrete trigger phrases listing the specific artifacts. This matches the clear-what-and-clear-when-with-concrete-triggers anchor.	5 / 5
Trigger Term Quality	Good natural-term coverage: 'preparing, publishing, auditing, or fixing CCB releases', 'release notes', 'changelog', 'npm', 'README', 'GitHub Actions' are phrases users would naturally say. It misses a few common synonyms and variations users might use, such as 'tag', 'cut a release', 'bump version', or 'publish to npm', so it falls between the good-coverage (4) and comprehensive-synonym (5) anchors, closer to 4.	4 / 5
Distinctiveness Conflict Risk	The description is tightly scoped to 'this CCB project' and its specific files (CCB releases, @seemseam-style npm surface, README/zh.md), giving it a clear niche with distinct triggers and minimal risk of firing for unrelated skills.	5 / 5
	Total	19 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
referenced_paths_exist	Referenced path issues: 1 missing	Warning

	Total	15 / 16 Passed

Repository: SeemSeam/claude_codex_bridge
Path: dev_tools/skills/ccb-github/SKILL.md
Commit: 18bf0af

Reviewed: 7 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.