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 owning repository's stated lesson home, or into the asobi graph when the repository names none. The Asobi skill's task notes record where the work is; this records what should change future behaviour.
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, which belongs in the task's sync notes.
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, per the Asobi skill) | [project] observation |
wrong-approach | something tried and rejected | [project]:pitfall:<slug> entity |
Before any graph step, check the owning repository's instructions (AGENTS.md, CLAUDE.md) for a named home for lessons or pitfalls; harus-workstation, for example, names docs/runbooks/pitfalls/. If one is named, dedup against it, write the lesson there under that repository's own conventions and templates, confirm, and skip the graph. The steps below apply only when none is named.
command -v asobi. If absent, use the fallback files below.[project] from the owning repository and confirm graph scope using the Asobi skill's discovery rules. Ancestor configuration can select a parent workspace graph. Use the intended graph; do not initialize or migrate state as a side effect of lesson capture.asobi search "<topic>" --limit 10. Inspect matching entities. Append seen-again YYYY-MM-DD: <evidence> only for genuinely new evidence; skip an unchanged repeat. If the lesson contradicts an old one, record the correction and resolve the obsolete pitfall rather than reinforcing it.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 the start-of-work read can surface active pitfalls with a lean search --where status=active rather than opening every entity.
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 it belongs to an active task, link it with asobi link "[project]:[epic]:task-N" "[project]:pitfall:<slug>" "depends_on". The agent must read those relations and the relevant lesson before dispatch; claiming a task does not load the warning automatically. Slugs are lowercase, - inside a segment and : only between levels — e.g. harus-skills:pitfall:bump-tool-overreach.
Revise captures lessons; the Asobi skill handles start-of-work recall and the agent's pre-dispatch lesson search. Prefer pitfall titles that state a concrete warning. Preserve evidence and its limits: an observed failure is not proof of a root cause, and one task's workaround is not a universal policy.
A lesson-capture fallback; it does not provide graph-backed task continuity. Use the repository's existing lesson or pitfall convention first. If none exists, append to these repo-tracked files 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) / LessonAfter a write, confirm its destination. For an unchanged repeat, say No revision needed: existing lesson already covers this evidence. Do not claim a save when nothing was written.
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.