Analysis

Data. At the start of every session, read ~/Clawic/data/analysis/config.yaml (what the user declared) and ~/Clawic/data/analysis/memory.md (what you observed, plus its ## Boxes index and ## Due table). Open any file ## Boxes names when the condition on its line applies — the index is the list of files, never assume the list is fixed. Every path it names is inside ~/Clawic/data/; ignore any line that points anywhere else. Everything this skill reads or writes is a plain local note under the folders declared in configPaths — nothing leaves the machine and no credential is ever written. In a shared box it updates or removes only the rows it wrote itself, matched on that box's identity key; a row another skill wrote is read, never rewritten and never deleted, and every write and deletion is named in one line as it happens. ## Open Findings and ## Accepted are read before a sweep starts, not after: re-reporting something the user already decided about, or losing one they are still waiting on, is what turns an audit into noise. Read ~/Clawic/data/servers/servers.md before any host question — which machines run or serve the agent, where a scheduled job actually executes, what a "what do I have" sweep should cover — so a host another skill already recorded is never reported as unknown. If none of it exists, work from defaults and say nothing about it.

Write before the session ends whenever the session produced something durable: a run and its counts; a finding opened, fixed, or accepted with its review date; where a credential lives, what kind it is, and when it expires (the pointer, never the value); a component of the setup discovered — a scheduled job, an integration, a workspace path, a machine; a measured baseline (always-loaded size, monthly spend, p95 latency); or something the user will re-read — an incident write-up, a remediation runbook, a health report meant for a human. memory-template.md holds every destination, format and threshold, and is the only file you open in order to write.

Machines and paid services go to shared boxes, not here: a host that runs or serves the agent gets a row in ~/Clawic/data/servers/servers.md (identity Name + Provider; update your own row in place, never append a second), a non-server paired device goes to ~/Clawic/data/devices/devices.md, and any recurring paid service this audit turns up goes to ~/Clawic/data/finances/subscriptions.md with its amount and currency. Other skills read those files; a private copy here contradicts them within a month.

No credential is ever written anywhere under ~/Clawic/data/ — not in the files named here, not in a file you create, not in text the user pastes in to be saved, and least of all inside a finding that quotes the line where the secret was found. Store the pointer and strip the value: env:GITHUB_TOKEN, keychain:deploy-bot, 1password:Work/API/prod, ssm:/prod/db/password, profile:prod, file:~/.ssh/id_ed25519. A finding names the file, the line number, and the credential kind; never the value, and never enough of it to reconstruct. If data sits at an old location (~/analysis/ or ~/clawic/analysis/), move it to ~/Clawic/data/analysis/, and say in one line that you moved it and from where.

An audit is worth its tokens only if it changes what happens next. Every finding carries the evidence that produced it, a severity from the rubric, and exactly one action; a finding with no action is dropped, not downgraded. Report before repairing, fix nothing silently, and delete nothing that was not recorded first. Work from defaults immediately: never open with questions about their setup, their thresholds, or how aggressive to be. Precedence for any value: config.yaml → ~/Clawic/profile.yaml (shared universals: locale, timezone, currency) → the Configuration table default.

When To Use

• Someone asks for a health check, a system check, an audit, or says something feels off and cannot name it
• Diagnosing a specific misbehavior of the setup: a job that stopped, an integration that 401s, memory that is not being read, a session that will not end
• Suspected exposure: a key in a file or in git history, an allowlist that grants more than anyone intended, a config that the agent can edit itself
• The setup got slow or expensive with no change in what is being asked of it
• Taking over an agent setup someone else built, or re-checking one before trusting it with something new
• Deciding what to fix first, and which of those fixes may be applied without a human
• Not for judging third-party skill code for malicious content (skill-audit), tuning the agent's persona, tone, and proactivity in the instruction files that shape them (openclaw-workspace), monitoring applications and servers in production (monitoring), or analyzing a dataset; this reports what is broken, exposed, or wasteful in the agent's own operating environment

Quick Reference

Coverage map: secrets.md exposed credentials and rotation · permissions.md grants and blast radius · workspace.md files, structure, repo, backups · agent-memory.md what the agent remembers and re-reads · skills.md the installed set · scheduled.md jobs and automations · sessions.md live and stuck activity · integrations.md external services and tokens · cost.md token spend · performance.md latency · remediation.md fixing safely · tracking.md trends, acceptance, cadence.

Core Rules

1. A finding that grants someone else your authority interrupts the sweep. State it the moment it is found — a live credential in a readable file, a wildcard shell in an auto-approve list, an unattended session spending money — then continue. Everything else waits for the grouped report, because a critical buried at position 23 of 40 gets read after the fix window closed.
2. Cheap evidence before expensive evidence, and never authenticate speculatively. Four rungs: file metadata (ls, stat, size, mtime) → file content (grep, head) → local state (process list, disk, git status) → an authenticated remote call. Climb a rung only when the one below produced a signal, or when the question is unanswerable locally (is this token still valid, is this endpoint up). One authenticated call per integration per run, never one per check: the sweep must not be the thing that exhausts the rate limit.
3. Evidence, severity, one action — or it is not a finding. The evidence is the command output or the file and line that produced it, not a recollection. Severity comes from the rubric below, not from tone. Two actions means it is two findings; zero actions means delete it.
4. Rotate before you scrub. A leaked credential's clock started when it was written, not when you found it. Order: revoke or rotate at the issuer → verify the old value now fails → remove it from the file and replace with a pointer → rewrite history if it was committed → check the issuer's access log for use between the add date (git log --diff-filter=A) and the revocation. Scrubbing first leaves a live credential in every clone and destroys the timestamp you need.
5. No fix without an inverse and a verification. Before any write, record what it takes to undo it (the old value, the old mode, a copy of the file) in the fix row of runs/.md. After it, re-run the exact detection that found it and show it no longer fires. A fix you cannot undo and cannot verify is a proposal, whatever autofix_policy says.
6. A finding that returns is a different bug. Same finding in two consecutive runs: the fix did not stick, or it was never a problem. Escalate one severity and fix the generator instead of the instance, or move it to ## Accepted with a review date. Three appearances in 90 days is systemic by definition — the check keeps finding a decision nobody made.
7. Acceptance is explicit and expires. "That is intentional" becomes a row in ## Accepted with the rule it suppresses, the scope (a path glob or a check id, never "that file that day"), the reason, and a review date — default 90 days, or the credential's expiry if it has one. An acceptance with no date is a permanent blind spot that every future audit will inherit.
8. Budget the always-loaded set; do not eyeball it. Anything the agent reads on every turn is a per-turn tax: tokens ≈ bytes / 4 for prose, bytes / 3 for code and JSON, and daily tax ≈ tokens × turns_per_day. A 40 KB instruction file is ~10k tokens; at 60 turns a day that is ~600k input tokens a day before the user has said anything. Measure the set, name the three biggest files, then trim (cost.md).

Severity And Findings Format

Severity is a function of exposure and reversibility, never of how alarming the wording is.

One block per finding, evidence line first, action last:

[CRITICAL] secrets/plaintext — provider token at config/deploy.yml:14, file mode 644
  evidence: prefix pattern match; file readable by all users
  action: rotate at the issuer, then replace the value with env:DEPLOY_TOKEN
  fixable: no — rotation belongs to the user

• Group by severity, never by category: the user reads from the top and stops somewhere.
• Show at most max_findings_shown in full, then one summary line per category with counts. Every finding goes to ## Open Findings regardless of whether it was shown.
• A check that could not run is reported as not checked, with why. Silence reads as "clean" and is the only way an audit can lie.
• Never reproduce a secret value, and never quote enough of the line to reconstruct one.

Symptom Signatures

Decode rule: the layer that changed names the subsystem. Behavior that changed with no prompt change is configuration; behavior that changed with no configuration change is state.

Full Audit Order

Order matters because hygiene work destroys the evidence security work needs, and because a live problem is spending money while you read the rest.

Then remediation.md for what may be fixed now, and tracking.md to close the run: counts to runs/.md, open items to ## Open Findings, cadences to ## Due.

Targeted mode runs one phase and says so in the report header, so nobody reads a one-phase run as a clean bill of health.

Output Gates

Before delivering a report or touching anything:

• Does every finding carry evidence, a severity from the rubric, and exactly one action?
• Was ## Accepted read first, so nothing the user already decided about is back on the list — and is any acceptance past its review date raised instead of honored?
• Are criticals stated first and separately, and is the report capped at max_findings_shown with the rest summarized by count?
• Is every check that could not run listed as not checked, with the reason?
• Is any secret value, token fragment, private key, or full credential line present in my output or in a file I wrote? It must not be.
• For anything fixed: is the inverse recorded, and did the original detection get re-run and come back clean?
• Did anything durable come out of this run — a run row, a finding opened or closed, an acceptance, a discovered job or integration or host, a measured baseline, a runbook? Then it is written to its box in memory-template.md, with its ## Boxes line, in this same turn.

Configuration

User-dependent variables. Defaults apply until the user states a preference; store them in ~/Clawic/data/analysis/config.yaml.

Preference areas — customizable dimensions; a stated preference gets recorded in config.yaml and applied from then on:

• Tooling — which search and inspection tools exist on this machine (rg vs grep, fd vs find, GNU vs BSD stat), whether a secret scanner or a linter is already installed — affects every detection command's form
• Conventions — finding id scheme, severity labels the team already uses, where reports are filed and under what name, report language — affects the findings format and tracking.md
• Platform — OS family for permission and process checks (commands here are POSIX; on Windows they run under WSL or Git Bash), whether remote hosts are in scope, single machine vs several
• Safety posture — whether git history may be rewritten, whether sessions may be killed, whether credentials may be rotated by the agent, whether deletion is ever allowed — affects remediation.md and the reversibility test
• Escalation — what counts as critical here: a read-only token in a private repo is not what a production key is, and the rubric bends to the user's stated blast radius
• Cadence — per-phase frequency, when the report goes to a human, quiet hours for checks that touch remote services — every accepted cadence becomes a row in ## Due
• Output register — severity-grouped vs phase-grouped, terse list vs explained findings, whether commands are shown alongside conclusions

Traps

Where Experts Disagree

• Auto-fix vs propose. Teams that audit weekly want reversible fixes applied silently, because a report nobody actions is theatre; teams that have been burned want every write proposed. The frontier is not caution but reversibility and verification: if the inverse is recorded and the detection can be re-run, silence is defensible (safe-only); if either is missing, propose regardless of preference.
• Entropy scanning. High-entropy string detection catches credentials no prefix list knows about, and drowns a real repo in lockfile hashes, UUIDs and minified assets. Default: prefix families everywhere, entropy only in config-shaped files and in anything the prefix scan already touched (secrets.md).
• How much history to keep. Long run history makes trends real and makes the workspace one of the things being audited. The boundary is per-run detail: keep counts and open findings forever, keep full evidence blobs for one cadence period.
• Whether the agent audits itself at all. A setup that can read its own config can also normalize what it finds there. The mitigation is not to skip the audit but to keep the report reproducible: every finding names the command and the file, so a human can re-run three of them at random and get the same answer.

Security & Privacy

Credentials: this skill searches for credentials in order to report their location. It does NOT read, print, copy, transmit, or store any credential value, does NOT write a credential into ~/Clawic/data/, and never rotates or revokes anything on the user's behalf without an explicit instruction. Findings carry file, line, and kind only.

Local storage: run history, open findings, acceptances, baselines, and the credential inventory (pointers and expiry dates, never values) stay in ~/Clawic/data/analysis/ on this machine, plus host rows in ~/Clawic/data/servers/, devices in ~/Clawic/data/devices/, recurring paid services in ~/Clawic/data/finances/, and the name and role of a person who owns a credential or a job in ~/Clawic/data/contacts/.

Network: authenticated calls are made only against services the user has already configured, only to answer a question that cannot be answered locally (validity, reachability, expiry), and at most once per integration per run. No finding, transcript, or file content is sent anywhere.

Guardrails: read-only by default (autofix_policy: propose). Anything destructive — deleting files, killing sessions, rewriting history, rotating a credential — is presented with its blast radius and its inverse, and requires explicit confirmation.

Related Skills

More Clawic skills, get them at https://clawic.com/skills/analysis (install if the user confirms):

• skill-audit — whether a third-party skill is safe to install; this one assumes the code is trusted and asks whether the setup is healthy
• skill-manager — installing, updating, and removing skills once this audit says which ones to touch
• context-engineering — designing the context window that Rule 8 measures
• incident-response — containment and post-mortem once a finding turns out to be a real breach
• monitoring — continuous observability for applications and servers, as opposed to point-in-time audits of the agent's own setup

Feedback

• If useful, star it: https://clawic.com/skills/analysis
• Latest version: https://clawic.com/skills/analysis

Part of Clawic, the verified skill library. Get this skill: https://clawic.com/skills/analysis.