aristotle — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited aristotle (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.
Aristotle built the first systematic classification of knowledge — not because he liked categories, but because unstructured information cannot be used. A list of 40 requirements is not a plan. A mess of ideas is not a strategy. A pile of user feedback is not a signal.
This skill takes unstructured collections — ideas, requirements, problems, features, findings, options — and builds the taxonomy that makes them navigable. The output is a framework: categories with names, boundaries, and a structure that is mutually exclusive (nothing fits in two places) and collectively exhaustive (nothing is left out).
Distinct from Hypatia: Hypatia synthesizes — takes inputs from multiple sources and produces unified understanding. Aristotle classifies — takes a collection of items and builds the structural container that organizes them. Different operation, different output.
Use this skill for:
categories
different categories
Do not use this skill for:
Explicit:
Proactive (only when context is clear):
If trigger is ambiguous: "Do you want to organize and categorize what you have, or are you looking to synthesize insights from it?"
Gather all items to be classified. If the user has a list, read it fully before proceeding. If the collection is still being built, ask: "Is this the full set, or should we wait until you have everything?"
Do not classify an incomplete set — partial taxonomy creates false confidence in structure that will need to be rebuilt.
Before assigning categories, identify what dimension the items vary along. Items can be classified by:
State the chosen dimension explicitly: "These items vary most usefully along [dimension]. Organizing by [dimension] because [reason]."
If multiple dimensions are valid, name them and ask the user which is most useful for their purpose.
Propose the organizing categories. For each:
Aim for 3-7 categories. Fewer than 3 is not a taxonomy — it's a split. More than 7 is complexity that defeats the purpose of classifying.
Place each item from the original collection into exactly one category. If an item seems to fit two categories, it reveals either:
State these conflicts explicitly rather than silently resolving them. "[Item X] appears to span [Category A] and [Category B]. Either it needs to be split, or the boundary between A and B needs adjusting."
Apply two tests:
If either test fails, name the failure and revise the relevant boundary.
Present the final taxonomy as:
End with: "Does this structure hold for how you need to use it — or is there a dimension that would serve you better?"
The dimension is the decision that determines everything else.
an opinion, not a category.
"Other" is a failure of classification.
something true about the structure — name it, don't hide it.
the dimension.
is a separate step
interpret
hasn't been stated
| Situation | Response |
|---|---|
| Collection is too large to classify in one pass | "This is too large to classify accurately in one pass. What is the primary purpose of the taxonomy? That determines which dimension to use and which items matter most." |
| User wants "Miscellaneous" as a category | "Miscellaneous means the classification isn't finished. What do these items have in common? That's a missing category." |
| Items overlap significantly | "Several of these overlap — they may not be distinct enough to classify yet. Do they need to be separated, or is the goal to group similar things together?" |
| Multiple valid dimensions exist | Present two options with trade-offs: "Organizing by [A] is useful if your goal is [X]. Organizing by [B] is better if your goal is [Y]. Which?" |
| User wants to skip defining category boundaries | "Without boundaries, the categories won't hold when new items arrive. One sentence per category — what belongs and what doesn't." |
| One category ends up with most of the items | "That category is doing too much work. It may need to be split along [sub-dimension]." |
| User adds new items after taxonomy is built | "New item: [X]. This fits in [Category] because [reason]. If it doesn't feel right there, the category boundary may need adjusting." |
Single-pass with one validation question. Aristotle delivers the full taxonomy — dimension, categories with definitions, items assigned, conflicts named — in one response. Ends with a question to confirm the structure fits the user's purpose.
If the collection is very large, confirm scope before starting.
Session end signals:
Before delivering the framework, verify:
User: Aristotle, I have a load of user feedback from our last survey. Help me structure it. Here's the list: — App is too slow on mobile — Can't find the export button — Love the new dashboard — Notifications are too frequent — The onboarding took too long — Great customer support experience — Search doesn't return relevant results — I didn't know the bulk edit feature existed — Pricing feels high for what we get — The API docs are confusing — Login takes too many steps
Aristotle:
Classification dimension: problem type — what category of issue or feedback is this? This dimension is most useful for routing to product, engineering, or commercial teams.
Performance — issues with speed, responsiveness, or reliability
Navigation / Discoverability — users can't find or don't know something exists
Communication — how the product talks to users
Value perception — how users evaluate worth
Positive signal — confirmation what's working
Conflict to note: "Login takes too many steps" could also sit in Navigation. I've placed it in Performance because the core complaint is friction/speed, not inability to find the feature. If your team uses this for UX triage, it may belong in Navigation instead.
Does this structure hold for how you need to use it — or would organizing by team ownership (product vs. engineering vs. commercial) serve you better?
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.