security-ownership-map

Analyze git-history security ownership when sensitive files, CODEOWNERS coverage, bus factor, contributor concentration, and remediation evidence need mapping.

Quality

63%

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 ./Skills/security-ops/security-ownership-map/SKILL.md

Quality

Content

66%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 well-structured, safety-conscious skill body with clear sequencing, explicit validation/failure-mode checkpoints, and a properly signaled progressive-disclosure map backed by real bundle files. Its main weakness is actionability: it instructs at a high level without executable commands or script names.

Suggestions

Add at least one concrete executable example per the Workflow (e.g., a sample `git log --author` / CODEOWNERS inspection command, or name the archived ownership-map script to invoke) to lift actionability.

Move the inline Inputs/Outputs enumeration into references/contract.yaml and link to it, keeping the body lean and pushing progressive_disclosure toward 5.

Tighten prose like the Gotchas Cookbook sentence to a directive to nudge conciseness to 5.

Dimension	Reasoning	Score
Conciseness	Mostly efficient bullet-style sections that assume Claude's competence and avoid re-explaining git/CODEOWNERS basics, with only minor padding (e.g., 'Cookbook secure-quality patterns can shape the review questions' prose) that could be trimmed; not a 5 because a few explanatory sentences understate rather than direct.	4 / 5
Actionability	Guidance is concrete in intent ('Run or adapt the archived ownership-map scripts', 'Compare observed maintainers with CODEOWNERS') but provides no executable commands, script names, or code; it reads as instruction rather than executable steps, matching the score-3 pseudocode/missing-details anchor.	3 / 5
Workflow Clarity	The Workflow section gives a clear ordered sequence and the separate Validation and Failure Mode sections add explicit checkpoints and error-recovery loops; it stays at 4 rather than 5 because the main workflow steps lack the precise commands/feedback gates that the Validation section carries separately.	4 / 5
Progressive Disclosure	A well-organized Progressive Disclosure section points to real, one-level-deep bundle files (verified: references/contract.yaml, references/evals.yaml, references/task-profile.json exist) plus deferred Infrastructure paths, with clear routing; it is not 5 because the Skill.md still inlines substantial reference-style content (Inputs/Outputs lists, contract-like fields) that could live in contract.yaml.	4 / 5
	Total	15 / 20 Passed

Description

61%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 specific, domain-rich description that names concrete analytic surfaces and good trigger terms, but it lacks an explicit 'Use when...' trigger clause, which caps completeness at 3. Adding a concrete when-to-use phrase would lift it into the top tier.

Suggestions

Append an explicit trigger clause such as 'Use when reviewing who owns sensitive paths, assessing bus factor, or comparing CODEOWNERS against observed contributors.'

Reframe the noun-list ('...need mapping') as concrete verbs (e.g., 'Identify, compare, and map...') to push specificity toward 5.

Add common synonyms ('maintainer', 'contributor concentration') users might say alongside 'ownership' and 'bus factor'.

Dimension	Reasoning	Score
Specificity	Names the domain (git-history security ownership) and several concrete analytic surfaces ('sensitive files, CODEOWNERS coverage, bus factor, contributor concentration, and remediation evidence'), but the actions are framed as nouns-to-map rather than explicit verbs, leaving minor coverage gaps vs. the score-5 anchor.	4 / 5
Completeness	It clearly answers 'what' (maps security ownership evidence) but has no explicit 'when' / 'Use when...' clause, and the judging guidelines cap completeness at 3 for a missing explicit trigger guidance; the trailing 'need mapping' is a condition clause but not a user-facing trigger phrase.	3 / 5
Trigger Term Quality	Includes strong natural terms ('CODEOWNERS', 'bus factor', 'sensitive files', 'ownership', 'remediation') a reviewer or auditor might actually say, though it omits common synonyms like 'maintainer' or explicit file-type triggers, keeping it just below comprehensive.	4 / 5
Distinctiveness Conflict Risk	The niche is fairly distinct (git-history ownership risk, CODEOWNERS, bus factor) with low overlap against generic code skills, though it sits adjacent to general git-analysis skills so minor overlap risk remains.	4 / 5
	Total	15 / 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
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: jscraik/Agent-Skills
Path: Skills/security-ops/security-ownership-map/SKILL.md
Commit: b3478dc

Reviewed: 1 day 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.