CtrlK
BlogDocsLog inGet started
Tessl Logo

github-publish-changes

Publish intentional local changes by confirming scope, creating a branch when needed, staging selected files, committing, pushing, and creating a Draft Pull Request through the connected GitHub service.

58

Quality

66%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./examples/plugin-packages/github/.opencode/skills/github-publish-changes/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

70%

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

The body is an exemplar of brevity and clean sectioning for a single-purpose orchestration skill, but several workflow steps stay abstract instead of giving exact commands or templates, and the destructive push/PR path lacks an explicit validation gate before commit. Progressive disclosure is appropriately minimal for a skill this size.

Suggestions

Make step 5 an explicit validation gate — e.g. "Run the project's checks; if any fail, fix before committing. Only proceed when checks pass." — to add the missing feedback loop.

Add concrete command templates for the abstract steps: a commit message format for step 6, an exact `git push -u origin <branch>` form for step 7, and an example `gh`/create-pull-request payload shape for step 9.

Specify how to resolve owner/repo in step 8 (e.g. parse `git remote get-url origin`) so the action is copy-paste ready.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence — a 10-step workflow plus a short Safety section with no padding or explanation of concepts Claude already knows (e.g., no primer on what git or a PR is). Every line earns its place.

3 / 3

Actionability

It gives specific commands and tool calls ("git status -sb", "agent/<short-description>", create-pull-request) but key steps are abstract rather than copy-paste ready — "Run the most relevant checks", "Resolve the GitHub owner, repo...", and "Commit with a short message" lack exact commands or templates.

2 / 3

Workflow Clarity

The 10 steps are clearly sequenced, but this is a destructive/batch-adjacent operation (push, PR creation) and the validation checkpoints are only implicit — step 5 says run checks "if they have not already passed" but there is no explicit gate or feedback loop before commit/push, which caps workflow clarity at 2 per the feedback-loops note.

2 / 3

Progressive Disclosure

This is a short, single-purpose skill with no external bundle files and no nested references; the body is well-organized into Workflow and Safety sections. Per the simple-skills scoring note, this can score 3 on the basis of well-organized sections alone.

3 / 3

Total

10

/

12

Passed

Description

62%

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 strong on concrete capabilities and enumerates the full publish-to-PR pipeline, but it omits an explicit "Use when..." trigger clause and relies on the body to state invocation conditions, which limits trigger-term quality and completeness. It is distinguishable but not sharply so without explicit triggers.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user explicitly asks to commit, push, or open a pull request for local changes."

Mirror the natural terms users say ("commit", "open a PR", "make a PR", "send changes") to improve trigger-term coverage.

Tighten distinctiveness by naming the output (Draft PR) earlier and clarifying it is scoped to intentional local changes only.

DimensionReasoningScore

Specificity

Lists multiple concrete actions verbatim — "confirming scope, creating a branch when needed, staging selected files, committing, pushing, and creating a Draft Pull Request" — matching the top anchor's multi-action bar.

3 / 3

Completeness

The "what" is clearly and comprehensively stated, but the description lacks any "Use when..." clause or equivalent explicit trigger for when to invoke it, which per the guidelines caps completeness at 2.

2 / 3

Trigger Term Quality

Relevant terms appear ("committed", "pushed", "Pull Request") but it omits common natural variations a user would say such as "commit", "open a PR", "make a PR", or "send changes"; it states intent rather than enumerating the terms users actually utter.

2 / 3

Distinctiveness Conflict Risk

It targets a fairly specific niche (publish local changes via Draft PR through a GitHub service), but the phrase "Publish intentional local changes" could still overlap with generic git/commit skills; without explicit trigger wording the boundary is only implied.

2 / 3

Total

9

/

12

Passed

Validation

100%

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

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
Devin-AXIS/iPolloWork
Reviewed

Table of Contents

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.