CtrlK
BlogDocsLog inGet started
Tessl Logo

oss-standards

Pre-PR discipline for a public-by-default repo. What a reviewer enforces beyond CI: secrets and internal data in diffs or screenshots, docs that name their reader, and the cleaning pass where incomplete or confusing artifacts get dropped. Use before opening any PR against `gridaco/grida` or when finalizing work for review.

70

Quality

86%

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

SKILL.md
Quality
Evals
Security

Quality

Content

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

A tight, opinionated policy skill: lean token-efficient prose, concrete and executable guidance throughout, and a clear pre-PR workflow anchored by the cleaning-pass decision procedure. Its only shortfalls are a missing explicit fix-and-re-check loop in the cleaning pass and no reference/bundle structure to delegate detail into.

Suggestions

Add an explicit re-check step after 'recoverable question → fix it' (e.g., re-run the stranger-test on the fixed artifact before keeping it).

Consider moving the enumerated 'Common removals' list or the commit/PR-description standards into a short reference file to keep SKILL.md as a pure overview.

DimensionReasoningScore

Conciseness

Every line carries repo-specific policy Claude does not already know — 'Push = publish', 'Use draft: true, defer the PR, or just don't ship', the stranger-test — with no padding, no tutorials on known concepts, and a dense but non-redundant TL;DR section.

5 / 5

Actionability

For an instruction-only skill the guidance is fully concrete: 'Use .env.local (gitignored) and fixture placeholders', 'rewrite as a neutral TODO with a tracking issue link', 'draft: true or delete', and a literal per-file question ('If a stranger reads this file with no context, does it help them...') with a three-branch decision tree (keep / fix it / drop).

5 / 5

Workflow Clarity

The sequence is explicit — the security skill's review runs first, the cleaning pass is downstream and is the 'Final pass before opening the PR', ending in the PR description and commit message — and the per-file stranger-test acts as a checkpoint. However, there is no explicit re-validation loop after a 'recoverable question → fix it' branch, so it sits just below the feedback-loop anchor.

4 / 5

Progressive Disclosure

The 147-line body is well-sectioned with each scope (Code, Security, Docs, cleaning pass, PR description) clearly separated, and boundary detail is delegated to one-level-deep, clearly signaled peer skills ('The full boundary discipline lives in the security skill', 'See the links skill'). No bundle files exist to verify, and nothing is split into the skill's own reference files — solid structure with minor organization headroom.

4 / 5

Total

18

/

20

Passed

Description

83%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: concrete, third-person, repo-scoped, with an explicit 'Use before...' trigger clause covering both what and when. Its only gaps are a few missing natural synonyms and minor overlap risk from the generic 'finalizing work for review' trigger.

Suggestions

Add common synonyms for discoverability, e.g. 'pull request (PR)' or 'open source / OSS review' alongside 'PR'.

Narrow the secondary trigger 'when finalizing work for review' to the repo context so it cannot fire for generic review requests.

DimensionReasoningScore

Specificity

The description names the domain (pre-PR discipline for a public repo) and several concrete enforcement areas — 'secrets and internal data in diffs or screenshots, docs that name their reader, and the cleaning pass where incomplete or confusing artifacts get dropped' — matching the anchor for several specific actions with minor gaps (e.g., commit-message and machine-path gates from the body are not surfaced).

4 / 5

Completeness

It explicitly answers both what the skill does (reviewer-enforced pre-PR discipline beyond CI, with three named areas) and when to use it ('Use before opening any PR against gridaco/grida or when finalizing work for review'), with concrete trigger phrases.

5 / 5

Trigger Term Quality

Natural trigger phrases users would actually say are present ('before opening any PR', 'finalizing work for review', 'gridaco/grida', 'secrets', 'screenshots'), but common synonyms like 'pull request', 'open source', or 'OSS' are missing.

4 / 5

Distinctiveness Conflict Risk

The repo-scoped trigger ('gridaco/grida') gives it a clear niche with minimal conflict risk, but the secondary trigger 'when finalizing work for review' could overlap with general review/critique skills, matching the anchor for mostly distinct with minor overlap risk.

4 / 5

Total

17

/

20

Passed

Validation

93%

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

CriteriaDescriptionResult

relative_links

Relative link issues: 12 suspicious

Warning

Total

15

/

16

Passed

Repository
gridaco/grida
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.