admin-audit-log
Skill2 starsChanged 25 days agoApache-2.0View on GitHub
Use when admins, staff, or support can perform destructive or sensitive actions such as deleting users, changing roles, issuing refunds, exporting data, impersonating, or changing settings, and you need to check that these actions leave a durable who-did-what record without storing secrets. Do not use it to build a logging platform, to log passwords, tokens, or full personal data, or when no privileged actions exist.
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
When something goes wrong, "who changed that?" is the first question.
- Very specific: line 19
Before launch of anything with staff/support access to user data, and whenever admin-dashboard adds destructive actions.
- Distinctive: line 20
Not when there are no privileged actions, and not to add analytics or product telemetry.
- Distinctive: line 63
No privileged or destructive actions exist, or they are already logged with the right fields and no secrets.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
admin-audit-log
When something goes wrong, "who changed that?" is the first question. Without a record, you cannot answer, and you cannot show a user how their data was handled. But an audit log that stores passwords or full personal data becomes its own incident.
Activate when
- Privileged actions exist (
admin-authorizationlists them) and are destructive or sensitive. - Before launch of anything with staff/support access to user data, and whenever
admin-dashboardadds destructive actions. - Not when there are no privileged actions, and not to add analytics or product telemetry.
Working alone
This skill is self-contained. Its companions (declared in its metadata) are skills whose method it may need to do its own promised work. Use of a companion can be conditional: declaring one does not mean running it. When a companion's lane applies, use the skill if it is installed; if not, follow its short entry in references/companion-methods.md and say in your report which lanes ran inline at reduced depth. Never skip an applicable lane silently. Skills mentioned here only for escalation, referral, documentation, or optional deeper follow-up are not dependencies: report the hand-off and finish honestly.
Companions: admin-authorization.
Inspect
- Action list: from
admin-authorization: user deletion/suspension, role changes, refunds/credits, data exports, impersonation/"login as", content removal, settings/feature-flag changes, key/webhook changes, bulk operations. - Is each recorded? Find the code path; is there an append-only record with: actor (user ID, not just name), action, target object ID/type, timestamp (UTC), source (IP/request ID, optionally), and outcome? A
console.logis not an audit log. - Content of the record: describes what changed (fields changed, old→new for non-sensitive fields, or a diff summary), not secrets. No passwords, tokens, API keys, full card data, or full personal data payloads (reference IDs instead).
- Integrity and access: logs not editable by the actors they describe (append-only table, restricted DB privileges, or an external log sink); readable only by appropriate roles (
admin-authorization); retention stated by the owner (unspecified = indefinite). - Coverage of failure and bulk: failed/denied attempts on sensitive actions; bulk deletes logged as individual or grouped events with counts.
- Privacy consistency: the audit log's personal data (actor and target identifiers) is considered by deletion/retention decisions (
data-rights) and the notice (privacy-policy) where staff access to user data is disclosed. - Usability for incidents: can the owner actually query "who did X to user Y"? A table nobody can read is not a control.
Evidence that counts
Label each claim OBSERVED, SOURCE-INDICATED, DECLARED, INFERRED, UNKNOWN, or REVIEW REQUIRED. UNKNOWN is never a pass and never a failure.
- An entry created when you perform the action on a local/staging test: OBSERVED. Logging code seen: SOURCE-INDICATED.
- Provider-side logs (auth provider, hosting) may cover some actions: DECLARED/UNKNOWN unless the owner shows them.
May change
Add a minimal append-only audit table/logger and calls at existing privileged handlers following the project's patterns; strip secrets from existing log statements; add restricted read access. Keep it small: actor, action, target, time, details-without-secrets. Do not build dashboards, external SIEM integrations, or retention policies.
Must not claim
"Audit-ready", "tamper-proof", or "compliant logging". Describe what is recorded and what is not.
Verify
On local/staging: perform each privileged action and confirm one entry with the right fields and no secrets; try a denied attempt; confirm a normal user cannot read or edit the log; confirm log entries survive a restart.
Escalate
Staff access to sensitive or regulated data (need access reviews and formal controls), impersonation features, retention obligations, or incidents.
No change is valid when
No privileged or destructive actions exist, or they are already logged with the right fields and no secrets. Do not create a log for its own sake.
In this repository54 other files it gives its agents.
- wcag-readinessSkill
- admin-authorizationSkill
- admin-dashboardSkill
- payments-readinessSkill
- subscription-readinessSkill
- ai-features-readinessSkill
- analytics-privacySkill
- consent-managementSkill
- consumer-protection-readinessSkill
- cookie-and-storage-auditSkill
- data-flow-mappingSkill
- data-rightsSkill
- email-complianceSkill
- jurisdiction-applicabilitySkill
- legal-identity-noticesSkill
- minors-readinessSkill
- policy-consistencySkill
- privacy-policySkill
- privacy-readinessSkill
- regulated-domain-triggersSkill
- terms-of-serviceSkill
- third-party-privacySkill
- user-content-safetySkill
- compliance-allSkill
- compliance-diffSkill
- design-system-reconnaissanceSkill
- discoverability-allSkill
- launch-allSkill
- launch-verificationSkill
- production-allSkill
- quality-allSkill
- site-reconnaissanceSkill
- trust-allSkill
- search-console-readinessSkill
- seo-readinessSkill
- social-sharingSkill
- structured-dataSkill
- multilingual-readinessSkill
- rtl-readinessSkill
- content-trustSkill
- error-pagesSkill
- failure-resilienceSkill
- faq-readinessSkill
- forms-readinessSkill
- launch-identitySkill
- legal-navigationSkill
- link-integritySkill
- mobile-readinessSkill
- performance-readinessSkill
- public-supportSkill
- dependency-securitySkill
- deployment-cleanupSkill
- security-headersSkill
- web-securitySkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

