Skill flagged — suspicious patterns detected

ClawHub Security flagged this skill as suspicious. Review the scan results before using.

Ontology

v1.0.0

Typed knowledge graph for structured agent memory and composable skills. Use when creating/querying entities (Person, Project, Task, Event, Document), linkin...

0· 169·0 current·0 all-time

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for onlyloveher/ontology-clawd.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "Ontology" (onlyloveher/ontology-clawd) from ClawHub.
Skill page: https://clawhub.ai/onlyloveher/ontology-clawd
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install ontology-clawd

ClawHub CLI

Package manager switcher

npx clawhub@latest install ontology-clawd
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Suspicious
medium confidence
!
Purpose & Capability
The skill's declared purpose (typed knowledge graph / agent memory) matches the included Python tool and SKILL.md workflows. However skill.yaml claims Node compatibility (node >=18.0.0) while the provided implementation is a Python script (scripts/ontology.py). The SKILL.md uses memory/ontology/graph.jsonl as the default storage path but skill.yaml's ONTOLOGY_PATH default is '~/clawd/ontology' — inconsistent defaults that could cause confusion. Metadata owner IDs/homepage also differ across files. These mismatches are not clearly malicious but are incoherent and warrant clarification.
Instruction Scope
Runtime instructions restrict operations to local graph files (create/query/relate/validate) and emphasize append-only history and a schema that forbids storing secrets directly (Credential.secret_ref). The instructions and script operate on local files (memory/ontology/graph.jsonl and memory/ontology/schema.yaml) and do not instruct network calls or access to unrelated system files. Caution: append-only logs preserve history, so any sensitive data written into entities will remain on disk; the skill explicitly calls out not storing secrets directly but relies on users/other skills to follow that.
Install Mechanism
No install spec is provided (instruction-only), and there are no downloads or package installs. The single bundled script is a plain Python CLI. This is low-install risk.
Credentials
The skill declares no required environment variables or credentials. The only config is an ONTOLOGY_PATH in skill.yaml (a storage path). The code does not require or reference external secrets or cloud credentials. This is proportionate to its stated purpose.
Persistence & Privilege
always is false and the skill is user-invocable; it does normal local storage of its own data and does not request persistent privileges or modify other skills' configs. The append-only storage model gives it persistent local data — ordinary for this functionality.
What to consider before installing
This skill implements a local, append-only ontology stored on disk and the bundled Python CLI mostly matches the documentation. Before installing or enabling it: (1) Verify which storage path the agent will actually use (SKILL.md uses memory/ontology; skill.yaml sets ~/clawd/ontology) and adjust to a safe directory you control. (2) Confirm your environment runs Python (the implementation is Python) — skill.yaml's Node requirement is incorrect and should be clarified with the author. (3) Do not store secrets directly in the graph — the schema enforces secret_ref, but other skills or users might accidentally write sensitive values; treat the graph files as potentially sensitive and restrict file permissions. (4) Inspect the full scripts/ontology.py (particularly the truncated schema-loading/validation code) for any network I/O before granting broad access. (5) If you need cross-skill sharing, require skills to declare exact read/write contracts per the Skill Contract. These inconsistencies look like sloppy packaging rather than overtly malicious behavior, but confirm the above points before trusting the skill with sensitive data.

Like a lobster shell, security has layers — review code before you run it.

latestvk97ftdwt1v6wqxg5cgw62wwcss83b9q7
169downloads
0stars
1versions
Updated 1mo ago
v1.0.0
MIT-0

Ontology

A typed vocabulary + constraint system for representing knowledge as a verifiable graph.

Core Concept

Everything is an entity with a type, properties, and relations to other entities. Every mutation is validated against type constraints before committing.

Entity: { id, type, properties, relations, created, updated }
Relation: { from_id, relation_type, to_id, properties }

When to Use

TriggerAction
"Remember that..."Create/update entity
"What do I know about X?"Query graph
"Link X to Y"Create relation
"Show all tasks for project Z"Graph traversal
"What depends on X?"Dependency query
Planning multi-step workModel as graph transformations
Skill needs shared stateRead/write ontology objects

Core Types

# Agents & People
Person: { name, email?, phone?, notes? }
Organization: { name, type?, members[] }

# Work
Project: { name, status, goals[], owner? }
Task: { title, status, due?, priority?, assignee?, blockers[] }
Goal: { description, target_date?, metrics[] }

# Time & Place
Event: { title, start, end?, location?, attendees[], recurrence? }
Location: { name, address?, coordinates? }

# Information
Document: { title, path?, url?, summary? }
Message: { content, sender, recipients[], thread? }
Thread: { subject, participants[], messages[] }
Note: { content, tags[], refs[] }

# Resources
Account: { service, username, credential_ref? }
Device: { name, type, identifiers[] }
Credential: { service, secret_ref }  # Never store secrets directly

# Meta
Action: { type, target, timestamp, outcome? }
Policy: { scope, rule, enforcement }

Storage

Default: memory/ontology/graph.jsonl

{"op":"create","entity":{"id":"p_001","type":"Person","properties":{"name":"Alice"}}}
{"op":"create","entity":{"id":"proj_001","type":"Project","properties":{"name":"Website Redesign","status":"active"}}}
{"op":"relate","from":"proj_001","rel":"has_owner","to":"p_001"}

Query via scripts or direct file ops. For complex graphs, migrate to SQLite.

Append-Only Rule

When working with existing ontology data or schema, append/merge changes instead of overwriting files. This preserves history and avoids clobbering prior definitions.

Workflows

Create Entity

python3 scripts/ontology.py create --type Person --props '{"name":"Alice","email":"alice@example.com"}'

Query

python3 scripts/ontology.py query --type Task --where '{"status":"open"}'
python3 scripts/ontology.py get --id task_001
python3 scripts/ontology.py related --id proj_001 --rel has_task

Link Entities

python3 scripts/ontology.py relate --from proj_001 --rel has_task --to task_001

Validate

python3 scripts/ontology.py validate  # Check all constraints

Constraints

Define in memory/ontology/schema.yaml:

types:
  Task:
    required: [title, status]
    status_enum: [open, in_progress, blocked, done]
  
  Event:
    required: [title, start]
    validate: "end >= start if end exists"

  Credential:
    required: [service, secret_ref]
    forbidden_properties: [password, secret, token]  # Force indirection

relations:
  has_owner:
    from_types: [Project, Task]
    to_types: [Person]
    cardinality: many_to_one
  
  blocks:
    from_types: [Task]
    to_types: [Task]
    acyclic: true  # No circular dependencies

Skill Contract

Skills that use ontology should declare:

# In SKILL.md frontmatter or header
ontology:
  reads: [Task, Project, Person]
  writes: [Task, Action]
  preconditions:
    - "Task.assignee must exist"
  postconditions:
    - "Created Task has status=open"

Planning as Graph Transformation

Model multi-step plans as a sequence of graph operations:

Plan: "Schedule team meeting and create follow-up tasks"

1. CREATE Event { title: "Team Sync", attendees: [p_001, p_002] }
2. RELATE Event -> has_project -> proj_001
3. CREATE Task { title: "Prepare agenda", assignee: p_001 }
4. RELATE Task -> for_event -> event_001
5. CREATE Task { title: "Send summary", assignee: p_001, blockers: [task_001] }

Each step is validated before execution. Rollback on constraint violation.

Integration Patterns

With Causal Inference

Log ontology mutations as causal actions:

# When creating/updating entities, also log to causal action log
action = {
    "action": "create_entity",
    "domain": "ontology", 
    "context": {"type": "Task", "project": "proj_001"},
    "outcome": "created"
}

Cross-Skill Communication

# Email skill creates commitment
commitment = ontology.create("Commitment", {
    "source_message": msg_id,
    "description": "Send report by Friday",
    "due": "2026-01-31"
})

# Task skill picks it up
tasks = ontology.query("Commitment", {"status": "pending"})
for c in tasks:
    ontology.create("Task", {
        "title": c.description,
        "due": c.due,
        "source": c.id
    })

Quick Start

# Initialize ontology storage
mkdir -p memory/ontology
touch memory/ontology/graph.jsonl

# Create schema (optional but recommended)
python3 scripts/ontology.py schema-append --data '{
  "types": {
    "Task": { "required": ["title", "status"] },
    "Project": { "required": ["name"] },
    "Person": { "required": ["name"] }
  }
}'

# Start using
python3 scripts/ontology.py create --type Person --props '{"name":"Alice"}'
python3 scripts/ontology.py list --type Person

References

  • references/schema.md — Full type definitions and constraint patterns
  • references/queries.md — Query language and traversal examples

Instruction Scope

Runtime instructions operate on local files (memory/ontology/graph.jsonl and memory/ontology/schema.yaml) and provide CLI usage for create/query/relate/validate; this is within scope. The skill reads/writes workspace files and will create the memory/ontology directory when used. Validation includes property/enum/forbidden checks, relation type/cardinality validation, acyclicity for relations marked acyclic: true, and Event end >= start checks; other higher-level constraints may still be documentation-only unless implemented in code.

Comments

Loading comments...