Whether the system keeps a trustworthy record of who did what — the audit trail that compliance, incident response, and forensics all depend on.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: judge whether the system records the sensitive things people do to it, in a way you could actually trust and use — because when there's an incident or an audit, "who changed this, and when" needs a real answer.
Read-only pass. Read the logging of sensitive actions, its storage, and access to it; change nothing but the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
are the sensitive actions logged: auth, permission changes, data access, admin, deletion, money
does each entry capture who, what, when, from where, and the before and after
can the logs be altered or deleted by the people they record; append-only, off-box
who can read the audit log, and does it over-collect sensitive data
kept long enough for compliance and investigations, and no longer than allowed
can you actually answer "who changed this and when" quickly from the trail
a real audit trail, not application logs pressed into service
One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
Identify the sensitive actions.
Coverage — are the sensitive actions logged.
Rank by what a missing record would cost in an incident or audit.
Create AUDITLOG.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:audit-trail.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-audit-trail:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=128 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/128.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Audit-Trail Audit You are working inside this repo. Mission: judge whether the system records the sensitive things people do to it, in a way you could actually trust and use — because when there's an incident or an audit, "who changed this, and when" needs a real answer. Read-only pass. Read the logging of sensitive actions, its storage, and access to it; change nothing but the report file. ## Phase 1 — Find what is recorded - Identify the sensitive actions: authentication, permission changes, data access, admin actions, deletion, money movement. - For each, find whether it is logged, and what the log entry captures. - Note where audit records are stored and who can read or alter them. ## Phase 2 — Audit through 7 lenses 1. **Coverage** — are the sensitive actions logged: auth, permission changes, data access, admin, deletion, money 2. **Content** — does each entry capture who, what, when, from where, and the before and after 3. **Tamper resistance** — can the logs be altered or deleted by the people they record; append-only, off-box 4. **Access & privacy** — who can read the audit log, and does it over-collect sensitive data 5. **Retention** — kept long enough for compliance and investigations, and no longer than allowed 6. **Usability** — can you actually answer "who changed this and when" quickly from the trail 7. **Distinct from debug logs** — a real audit trail, not application logs pressed into service ## Phase 3 — Curate - Rank by what a missing record would cost in an incident or audit: unlogged permission changes top the list. - For each gap, name the event to log and the field to capture. - Separate "not logged" from "logged but untrustworthy"; a tamperable trail is not evidence. ## Phase 4 — Report Create `AUDITLOG.md` at repo root: 1. **Coverage matrix** — sensitive action × logged? · with what content? 2. **Findings** — each: gap · action · what is missing · the fix 3. **Trust & retention** — the tamper-resistance and retention changes needed 4. **Priority** — the events and protections to add first Start the report with today's date. If `AUDITLOG.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - A log the actor can edit is a story, not an audit trail - Capture who, what, when, and the before/after, or it will not answer the question - No actions worth an audit trail in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding. - If a `reports/` directory exists at the repo root, write the report there instead of the root. - Before asking, present the top findings as a ranked list in plain words - Report only — end by asking which audit-trail gaps to close first
reports/ directory exists at the repo root, write the report there instead of the root.Whether the product collects consent honestly and honors it — the cookies, trackers, and data collection that fire before or despite the user's choice.
Whether the product can honor the rights users have over their data — access, export, correction, and deletion — operationally, not just in the privacy policy.
How the product protects data with encryption — in transit, at rest, and at the field level — and whether the keys that unlock it are managed safely.
Runs inside these playbooks — curated sequences you can launch with one paste: