CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

agentwhy-session-audit

Checks which private files (.env, keys, secrets) Claude Code and its subagents reached in this project, whether a value came into an agent's context, and which key to change, by running the open source agentwhy CLI over the session records Claude Code already keeps on disk. Use when the user asks whether the agent or a subagent read their .env or other secrets, which private files a session touched, whether a key leaked into the conversation, or which key to rotate. Runs locally and never prints a secret value.

75

Quality

94%

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

88%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 strong, thoroughly executable skill body: exact pinned commands, complete edge-case handling (refusals, missing sessions, output labels), and a confirmation gate before any mutating mark. The only weaknesses are minor — a few over-packed sentences that could be tightened, and a single-file layout whose label table could move to a reference file as the skill grows.

Suggestions

Conciseness: split the multi-clause passages — the IN RESULT table cell and the final bullet of section 4 ("A hand-made pass sees which files a call named, but not...") — into shorter standalone directives so each rule is scannable at a glance.

Progressive disclosure: consider moving the section 1 label-interpretation table into a reference file, keeping only the command, its options, and the routing rules in SKILL.md, so the main body stays an overview.

Conciseness: the opening block before section 1 mixes tool facts, default private-file patterns, and run-location rules in one dense paragraph; grouping them under short labels would aid scanning.

DimensionReasoningScore

Conciseness

The body is efficient — no explanations of concepts Claude already knows; every section is operational ("By default it treats these as private: .env*, *.env, .npmrc, secrets/, .ssh/, id_rsa*"). It is not a 5: a few passages pack several directives into single sentences — the IN RESULT table cell combines three instructions plus a caveat, and the final bullet of section 4 chains four clauses ("A hand-made pass sees which files a call named, but not a value printed by a search that named no file, which is the route that matters most...") — which could be split or trimmed without losing meaning. It is not a 3: there is no padding or over-explanation, only density that occasionally needs a second read.

4 / 5

Actionability

Everything is copy-paste executable: `npx -y @agentwhy/cli@0.4.1 check`, `start --detach --quiet`, `check --mark rotated <path>` with `--note` and `--unmark`, `init`, options `--since 30d`, `--full`, `--share`, and even the exact permission strings ("Bash(npx -y @agentwhy/cli@0.4.1 check)") to add to settings. It is not a 4: the common cases are all covered, including interpretation of each output label, the no-sessions-found case, and the command-refused path — nothing needed to execute is missing.

5 / 5

Workflow Clarity

The process is clearly routed by user intent (question → check, section 1; report or Codex question → page, section 2) with explicit error-recovery loops: no sessions stored → ask which folder the user worked in; command refused → section 3's two concrete remedies. Mutating operations carry a confirmation checkpoint ("Never mark a line the user has not confirmed"), and the tool's own non-destructive nature is stated ("writes nothing, and exits 0 whatever it found"). It is not a 4: validation checkpoints and failure feedback paths are explicit, not merely implied — the destructive-operation cap does not apply since the core flow is read-only.

5 / 5

Progressive Disclosure

A single well-sectioned file (numbered sections 1–5 plus Limits) with external detail correctly deferred rather than inlined: detection gaps point to the project's own "docs/detection.md" and the report detail to agentwhy's page. It is not a 5: at ~110 lines, the full label-interpretation table and the rules sections sit inline in SKILL.md; while defensible at this size, the table in particular is the kind of material a reference file would absorb if the skill grows. It is not a 3: structure is clear, navigation is easy, and the one external reference is clearly signaled and one level deep.

4 / 5

Total

18

/

20

Passed

Description

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

An exemplary description: third-person, dense with concrete actions, an explicit multi-phrase "Use when" trigger clause, and a distinct niche with essentially no conflict risk. Length is justified by information content rather than padding.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions — "Checks which private files (.env, keys, secrets) Claude Code and its subagents reached", "whether a value came into an agent's context", "which key to change, by running the open source agentwhy CLI over the session records" — with comprehensive coverage of the tool's function. It is not a 4: the action list covers detection, attribution to subagents, exposure determination, and remediation target, leaving no notable gaps, and it stays in third person ("Checks", "Runs locally and never prints").

5 / 5

Completeness

Both parts are explicit: the "what" ("Checks which private files ... reached, whether a value came into an agent's context, and which key to change, by running the ... CLI over the session records") and the "when" ("Use when the user asks whether the agent or a subagent read their .env or other secrets, which private files a session touched, whether a key leaked into the conversation, or which key to rotate"). It is not a 4: the "when" clause enumerates concrete trigger phrases rather than being merely present or generic.

5 / 5

Trigger Term Quality

Natural user phrasings with synonyms and extensions are all present: ".env", "secrets", "read their .env or other secrets", "which private files a session touched", "whether a key leaked into the conversation", "which key to rotate". It is not a 4: coverage matches the top anchor — everyday phrasings (leaked, rotate, change, touched, read) plus the concrete file extension, not just domain keywords.

5 / 5

Distinctiveness Conflict Risk

It occupies a clear niche — auditing private-file access in Claude Code session records — with triggers ("did the agent read my .env", "which key to rotate") no other plausible skill would claim. It is not a 4: overlap risk is minimal because the trigger set is specific to this exact audit task rather than to a broader file- or security-related family of skills.

5 / 5

Total

20

/

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

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

davepoon/buildwithclaude

Path

plugins/all-skills/skills/agentwhy-session-audit/SKILL.md

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.