revise — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited revise (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Persist durable lessons from the current work into the asobi graph. /asobi end records where we are (session status); /revise records what should change future behavior.
After a meaningful discovery — a workflow worth repeating, a non-obvious project fact, or (most importantly) a dead end an agent should not re-walk. Capture while context is fresh. Not for ordinary task status; that is /asobi end.
Read the user's free-form text and classify it yourself; ask only if it is too vague to preserve. Keep each lesson short and actionable — "do X because Y", not a transcript.
| Class | Means | Destination |
|---|---|---|
work-experience | how work was actually done | [project] observation |
finding | a non-obvious fact or gotcha (an architectural choice → a decision entity, see /asobi recall) | [project] observation |
wrong-approach | something tried and rejected | [project]:pitfall:<slug> entity |
command -v asobi. If absent, use the fallback files below.[project] (repo basename). Use shared XDG state unless ./asobi.toml exists; never run asobi init --local.asobi search "<topic>" --limit 10. If a matching entity exists, append seen-again YYYY-MM-DD: <evidence> rather than creating a duplicate.asobi new "[project]" "project"), then: asobi obs "[project]" "experience YYYY-MM-DD: <lesson>" # work-experience
asobi obs "[project]" "finding YYYY-MM-DD: <lesson>" # findingFor a wrong-approach, write the pitfall entity below.
A pitfall warns future agents away from a rejected path — it is not an ADR (ADRs explain chosen paths). One entity per dead end; status and title are truths so /asobi start can surface active pitfalls cheaply.
asobi new "[project]:pitfall:<slug>" "concept"
asobi truth "[project]:pitfall:<slug>" status active # active | resolved
asobi truth "[project]:pitfall:<slug>" title "<short warning>"
asobi obs "[project]:pitfall:<slug>" "tried: <approach attempted>"
asobi obs "[project]:pitfall:<slug>" "why-it-failed: <root cause / symptom>"
asobi obs "[project]:pitfall:<slug>" "do-instead: <better path, or 'open'>"
asobi obs "[project]:pitfall:<slug>" "date: YYYY-MM-DD"When the dead end is obsolete: upsert status resolved and append obs "resolved YYYY-MM-DD: <why it no longer applies>". If the lesson belongs to an active task, link it so dispatch surfaces it — asobi link "[project]:[epic]:task-N" "[project]:pitfall:<slug>" "depends_on" (the task depends on knowing the warning). Slugs are lowercase, - inside a segment and : only between levels — e.g. harus-skills:pitfall:bump-tool-overreach.
/revise only writes; recall lives in asobi. /asobi start reports active pitfalls, and /asobi tasks dispatch queries task-relevant lessons and includes linked pitfalls. Prefer pitfall titles that read as warnings in a dispatch brief.
A /revise-only fallback — it does not relax asobi's requirement for session continuity. Append to repo-tracked files, creating each as needed with the header > Project-local fallback lessons captured when asobi was unavailable. Migrate into asobi when possible.
docs/lessons/pitfalls.md — ## YYYY-MM-DD — <slug>, then Status / Tried / Why it failed / Do insteaddocs/lessons/learnings.md — ## YYYY-MM-DD — <title>, then Type (work-experience|finding) / LessonEnd with one terse line:
Revision saved: <class> -> <destination>. # or: -> docs/lessons/<file>.md (asobi unavailable)~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.