git-workflow

Squad branching model: dev-first workflow with insiders preview channel

Quality

61%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.copilot/skills/git-workflow/SKILL.md

Quality

Content

68%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.

The body is a strong, command-dense operational guide with good decision tables and anti-patterns, held back by missing validation checkpoints around destructive cleanup and parallel batch work, plus a vague promotion pipeline. Splitting the advanced worktree/multi-repo material into reference files would make SKILL.md a tighter overview.

Suggestions

Add explicit validation before destructive cleanup steps, e.g. "Verify the PR shows Merged (gh pr view --json state) and dev CI is green before `git branch -d` / `git push origin --delete` / `git worktree remove`".

Add a checkpoint before marking a PR ready (e.g. run tests locally and confirm CI passes on the draft) so the batch multi-issue workflow has a verify-then-proceed loop.

Make the Promotion Pipeline section actionable: name the automation or CI job that syncs dev → insiders, and show the concrete commands (or a reference link) for tagging a stable release and cherry-picking hotfixes to main.

Dimension	Reasoning	Score
Conciseness	The body is dense with tables, commands, and anti-patterns, and assumes git/gh competence without re-explaining basics. Minor over-explanation could be trimmed — e.g. the bullets "Has its own working directory and index" / "Shares the same .git object store (disk-efficient)" and "No filesystem collisions, no branch-switching overhead" explain worktree behavior Claude already knows. Fits anchor 4 (efficient, minor instances that could be trimmed) rather than 5; not 3 because padding is the exception, not the rule.	4 / 5
Actionability	Nearly all guidance is copy-paste-ready: branch creation, `gh issue edit`, `gh pr create --base dev --draft`, concrete worktree examples (`git worktree add ../squad-195 -b squad/195-fix-stamp-bug origin/dev`), cleanup commands, and per-ecosystem local-linking snippets. It falls short of anchor 5 because the Promotion Pipeline section is high-level ("Automated sync on green build", "Manual merge when ready") with no commands or pointers to the automation, and hotfix cherry-picking is described but not shown.	4 / 5
Workflow Clarity	Sequences are clear (six-step issue workflow; worktree setup → per-worktree work → cleanup; multi-repo merge order with dependencies first), but validation checkpoints are missing or implicit around destructive and batch operations — branch deletion and `git push origin --delete` after merge, `git worktree remove`, and parallel multi-issue work have no verify-merged/CI-green step before cleanup, capping this at 3 per the judging guidelines. It is not 2 because the sequences are well-defined with concrete commands; not 4 because the destructive-cleanup and batch paths lack explicit checkpoints.	3 / 5
Progressive Disclosure	The document is well-sectioned with clear headers, tables, and decision guidance (worktrees vs sequential vs multi-repo), and with no bundle files present there are no dangling or nested references — structure matches anchor 4. It is not 5 because at ~206 lines the worktree and multi-repo downstream scenarios are substantial advanced material that could live in one-level-deep reference files, keeping SKILL.md closer to an overview; it is not 3 because nothing is buried and navigation is easy.	4 / 5
	Total	15 / 20 Passed

Description

53%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.

The description is concise and establishes a distinct, project-specific niche, but it reads as a label rather than a capability statement: no concrete actions are listed, and it lacks any "Use when..." trigger guidance, capping completeness at 3. Adding a trigger clause and common terms like "git", "pull request", and "branch" would substantially improve it.

Suggestions

Append an explicit trigger clause, e.g. "Use when creating branches or PRs in Squad repos, or when the user asks where feature work, previews, or releases should land."

Name concrete actions in the description itself, such as "Create squad/{issue}-{slug} branches from dev, open draft PRs targeting dev, and manage parallel worktrees" so users can tell what the skill does.

Include natural trigger synonyms users would actually say — "git", "pull request", "PR", "merge", "preview", "release" — to improve trigger-term coverage beyond the current jargon-heavy set.

Dimension	Reasoning	Score
Specificity	The description names the domain ("Squad branching model") and identifies two concrete specifics ("dev-first workflow", "insiders preview channel"), but lists no concrete actions or operations (no branching, PR, or publishing verbs). It fits anchor 3 (domain plus 1-2 concrete specifics, not comprehensive) better than anchor 2 because the named model elements are concrete rather than generic, and better than anchor 4 because no specific actions are enumerated.	3 / 5
Completeness	The "what" is fairly clear (a three-channel branching model centered on dev), but the "when" is entirely absent — there is no "Use when..." clause or equivalent trigger guidance, which caps completeness at 3 per the judging guidelines. Anchor 3 (clear what, when missing) is the exact fit; it is not 4 because the when-clause is not merely weak, it is absent.	3 / 5
Trigger Term Quality	Some relevant keywords are present ("branching", "workflow", "dev", "preview"), but common natural terms a user would say are missing: "git", "pull request", "PR", "merge", "release". This matches anchor 3 (some relevant keywords, missing common variations and synonyms); anchor 4 would require broader natural-term coverage, anchor 2 would require only generic language.	3 / 5
Distinctiveness Conflict Risk	The project-specific terms ("Squad", "dev-first", "insiders preview channel") establish a clear niche with only minor overlap risk against generic git-workflow skills, matching anchor 4. It is not 5 because the description contains no explicit trigger phrases, so distinctiveness rests on the niche vocabulary alone; it is not 3 because "Squad branching model" is considerably more specific than "Works with document files"-level generality.	4 / 5
	Total	13 / 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
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: bradygaster/squad
Path: .copilot/skills/git-workflow/SKILL.md
Commit: 29e69f5

Reviewed: 5 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.