Source owner audit
Skill perhapsspy/project-legibility/plugins/project-legibility/skills/source-owner-audit
Use for read-only source-of-truth audits: identify the current code, API, config, doc, or behavior to follow; compare a proposed, migrated, ported, or current change against it; and report evidence, mismatches, unresolved decisions, and owner-level recommendations.From its SKILL.md
npx -y skills add perhapsspy/project-legibility --skill source-owner-auditAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.7 KB, 659 tokens by cl100k_base, as published. Nobody here has run it
Source Owner Audit
Purpose and Scope
Answer from current source evidence:
- What should we follow?
- What differs?
- What still needs a decision?
Default to read-only evidence, comparison, classification, and owner-level recommendation. Explicit investigation-only, prohibition, exclusion, and scope-limit wording is binding. Owner evidence identifies responsibility; it does not authorize edits, cleanup, implementation sequencing, or any expansion beyond the user-approved scope.
Evidence Rules
Resolve each candidate owner independently from the smallest current source path. Start with the feature, route, API, config, document, or behavior named by the user; prefer path-specific reads over broad scans. When local changes may affect the answer, inspect worktree status and the relevant diff.
Current source outranks memory, prior summaries, old task notes, stale documentation, and candidate implementations. Until the current owner is confirmed, label conclusions as inference or insufficient current evidence. Do not select an owner or product value by plausibility when evidence is insufficient; report the missing decision instead. Separate confirmed fact from inference.
Trace only the ownership path needed for the question, such as caller, adapter/client, route/API, command/service, persistence/schema, test, config, runbook, or owner document. Distinguish current production owners from derived/router, legacy/compatibility, stale/superseded, generated/copied, and evidence-only surfaces.
When the question crosses those boundaries, distinguish source/contract, caller/UX, write/read, document/task, migration, and decision owners.
Capability does not prove caller intent, access policy, product approval, or UX parity; each needs its own evidence. Preserve existing product and UX contracts unless current owner evidence says otherwise.
Compare and Decide
Compare the proposed, migrated, ported, or current surface against its owner. For UX parity, compare relevant affordances, labels, state transitions, empty/error states, density, and permission behavior—not backend capability alone.
Mark a difference as implementation work only when both owner evidence and user-approved scope support it. If source evidence leaves policy, product, access, or ownership open, name the decision needed and its owner when known.
Use labels only when they clarify the answer:
Surface role:Owner,Derived/Router,Legacy/Compatibility,Stale/Superseded,Evidence-onlyComparison:Matches owner,Owner divergence,Parity gap,Not comparedEvidence state:Confirmed,Caller intent/access policy unconfirmed,Decision needed,Insufficient current evidence,Out of scope
A derived surface may match its owner; an owner divergence may still require a decision. Disposition: may summarize legacy compatibility when useful.
Output and Handoff
Lead with the practical answer. Use Recommendation, Evidence, Difference, and Decision needed only when they clarify it. For multiple surfaces, use compact findings. If evidence is incomplete, state what was checked and classify the uncertainty explicitly.
Stop at an owner-backed recommendation unless the user expands scope to execution or planning. Treat adjacent domains as source-owner audits only when the user asks a concrete ownership question; otherwise hand the audit result to the workflow that owns the follow-up work.
What ships with it: 2 files
3.9 KB alongside SKILL.md
agents/
- openai.yaml243 B
- SKILL.ko.md3.6 KB
Gives 0 of the 12 instructions most audit compliance skills give in 659 tokens
Counted across 937 of the 1,487 authors here whose files we hold, read 2026-08-07
- Fetch latest guidelines before each reviewin 43 of 937, across 3 files
- Group findings by severityin 43 of 937
- Check files against all fetched rulesin 42 of 937, across 2 files
- Output findings in terse file:line formatin 41 of 937, across 3 files
- Ask user which files to review if none specifiedin 41 of 937, across 3 files
- Read specified files or prompt user for filesin 39 of 937, across 1 file
- Generate the audit reportin 33 of 937, across 30 files
- Assign a severity to every findingin 25 of 937
- Run automated accessibility scansin 23 of 937, across 13 files
- Output a markdown audit reportin 22 of 937
- Map findings to WCAG criteriain 20 of 937, across 10 files
- Confirm audit scopein 19 of 937, across 9 files
Said here and by no other author read
- resolve owners from smallest current source path
- prefer path-specific reads over broad scans
- rank current source above memory or stale notes
- report missing decisions instead of guessing
- trace only the ownership path needed
- compare surfaces against their owners
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.