CtrlK
BlogDocsLog inGet started
Tessl Logo

finishing-a-development-branch

Use this when you have completed some feature implementation and have written passing tests, and you are ready to create a PR.

57

Quality

65%

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 ./.agency/plugins/nori/skills/finishing-a-development-branch/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

73%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 well-sequenced, validation-rich workflow with strong executable guidance and clear feedback loops, scoring highest on workflow clarity. Its main weaknesses are minor padding and a couple of under-specified steps (type checking, demo).

Suggestions

Remove the duplicated 'you do NOT have to follow the subagent's suggestions / fresh pair of eyes' text and the Nori promo lines from the PR template to tighten token use.

Add a concrete typecheck command block to step 5 (e.g. tsc --noEmit / mypy / go vet) for parity with the format and lint steps.

Replace step 12's vague 'spin up the server and the ui in a demo localhost link' with a concrete start command and a check that the server is reachable before sharing the link.

DimensionReasoningScore

Conciseness

The bulk is tight, executable command blocks, but it carries unnecessary padding: the 'fresh pair of eyes' reassurance is repeated verbatim for steps 6 and 7, and the PR body template includes Nori marketing lines that are irrelevant to the task.

3 / 5

Actionability

Most steps give concrete, executable commands (npm test, cargo clippy --fix, ruff check --fix, gh pr create, gh pr checks), but step 5 (type checking) has no command block — a noticeable gap next to steps 3 and 4 — and step 12's 'spin up the server and ui' is vague.

4 / 5

Workflow Clarity

A clearly numbered 12-step sequence with explicit validation checkpoints (tests must pass before proceeding, not-on-main check, CI must succeed) and feedback loops (CI fail → fix → push → repeat; tests fail → fix → retry) for its destructive/batch git operations.

5 / 5

Progressive Disclosure

The skill is appropriately self-contained as one linear workflow with no external references needed and clear numbered navigation; minor organization quirks (inline <system-reminder> tags scattered through the steps) keep it just short of fully clean.

4 / 5

Total

16

/

20

Passed

Description

57%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 has a strong, explicit trigger ('when') but a weak 'what' that undersells the multi-step workflow, and its second-person voice costs it specificity. It is distinct and unlikely to mis-trigger, yet could be much more capability-rich.

Suggestions

Rewrite in third person and surface the skill's actual actions, e.g. 'Runs the project test suite, formatters, linters, and type checks, performs a self-review, then pushes the branch and opens a PR with CI verification.'

Add natural synonyms and trigger phrases such as 'pull request', 'open a PR', 'finish a branch', and 'ship a feature' so users phrasing it differently still activate the skill.

Keep the explicit 'Use when...' clause but attach it to the fuller capability list so 'what' and 'when' are both comprehensive.

DimensionReasoningScore

Specificity

Natural specificity is ~3 (names the PR-creation domain plus one concrete action, 'create a PR', but omits the skill's other actions like lint/typecheck/CI/review), reduced by 1 because the description uses second-person voice ('you have completed', 'you are ready') per the rubric's voice penalty.

2 / 5

Completeness

It has both an explicit 'when' ('Use this when you have completed... and are ready to create a PR') and a 'what' (create a PR / finish the branch), but the 'what' is thin — it surfaces only PR creation and not the full test/lint/typecheck/review/CI workflow the skill performs.

4 / 5

Trigger Term Quality

It includes some natural terms users would say ('create a PR', 'PR', 'feature implementation', 'passing tests') but misses common synonyms and variations like 'pull request', 'open a PR', 'finish/merge a branch', or 'ship'.

3 / 5

Distinctiveness Conflict Risk

The trigger (feature complete, tests passing, ready for PR) carves a fairly distinct niche, with only minor overlap risk against generic git/PR skills.

4 / 5

Total

13

/

20

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
microsoft/FluidFramework
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.