Menú
Ontology management for syspilot. Schema documentation for ontology.toml and governance guardrails. USE FOR: adding or modifying Work-Product types, statuses, link types; classifying ontology changes as additive or breaking.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Implements the SEND/RECEIVE/RESPOND orchestration vocabulary using Jarvis session-messaging tools. USE FOR: any agent that passes work to another session (SEND), obtains its triggering instructions (RECEIVE), or returns results to the initiator (RESPOND). Also use when agents need to determine whether they were triggered by a message or started directly. DO NOT USE FOR: general agent design, skill architecture rules, or spec writing.
Git branching strategy and commit conventions for syspilot. Development branch with feature branches, main = releases only. Who may create/commit to which branches. USE FOR: any git operation, branch creation, committing, pushing, merging.
Implements the SEND/RECEIVE/RESPOND orchestration vocabulary synchronously using runSubagent() only — no session-messaging infrastructure required. USE FOR: any agent that passes work to another agent (SEND), obtains its triggering instructions (RECEIVE), or returns results to the initiator (RESPOND). This is the graceful-degradation variant for workspaces without Jarvis. DO NOT USE FOR: general agent design, skill architecture rules, or spec writing.
Impact analysis using sphinx-needs dependency trees. Discovers affected specification elements by traversing traceability links. USE FOR: change scoping, blast radius analysis, element discovery before spec writing.
Presenting choices to users via VS Code selection menus (quick-pick UI) during syspilot agent sessions. USE FOR: workflow transitions, decisions with 2-6 options, confirmations with alternatives. DO NOT USE FOR: free-form questions, single yes/no confirmations.
| name | syspilot.ontology |
| description | Ontology management for syspilot. Schema documentation for ontology.toml and governance guardrails. USE FOR: adding or modifying Work-Product types, statuses, link types; classifying ontology changes as additive or breaking. |
| implements | ["SYSP_SPEC_ONTOLOGY_SKILL_CONTENT"] |
| requirements | ["SYSP_REQ_ONTOLOGY_SKILL"] |
The canonical ontology lives at .syspilot/ontology.toml. Sphinx-needs reads
it directly via needs_from_toml in docs/conf.py.
The file has two kinds of top-level sections:
[needs] sections — understood by sphinx-needs / ubCode.
Sphinx-needs reads only [needs] and ignores sibling keys.[needs] sections (e.g. [syspilot]) — syspilot-specific metadata,
ignored by sphinx-needs.[needs])[needs]
id_required = true
build_json = true
build_json_per_id = true
flow_engine = "graphviz"
extra_options = ["priority", "rationale", "acceptance_criteria"]
[[needs.types]]
directive = "story"
title = "User Story"
prefix = "US_"
color = "#E8D5B7"
style = "node"
# ... more types ...
[[needs.statuses]]
name = "draft"
description = "Draft - Work in progress"
# ... more statuses ...
[[needs.extra_links]]
option = "defines"
incoming = "is defined by"
outgoing = "defines"
[syspilot]
schema_version = "1.0"
# Future phases will add:
# [syspilot.actors]
# [syspilot.capabilities]
# [syspilot.process]
[[needs.types]] entry to .syspilot/ontology.toml:
[[needs.types]]
directive = "mytype"
title = "My Type"
prefix = "MT_"
color = "#AABBCC"
style = "node"
sphinx-build -W.Add a [[needs.statuses]] entry:
[[needs.statuses]]
name = "my_status"
description = "My Status - description"
Add a [[needs.extra_links]] entry:
[[needs.extra_links]]
option = "mylink"
incoming = "is linked by"
outgoing = "links to"
ontology.toml is a guarded artifact. Every change must be classified.
| Change | Classification | Gate |
|---|---|---|
| Add a new type | Additive | Normal CR |
| Add a new status | Additive | Normal CR |
| Add a new link type | Additive | Normal CR |
| Add a new extra_option | Additive | Normal CR |
Add/modify [syspilot] metadata | Additive | Normal CR |
| Remove or rename a type | Breaking | Migration CR required |
| Remove or rename a status | Breaking | Migration CR required |
| Remove or rename a link type | Breaking | Migration CR required |
| Change a type's directive or prefix | Breaking | Migration CR required |
A breaking change triggers a migration CR that must:
sphinx-build -W passes after migration.sphinx-build -W (every CR) — catches type/link mismatches immediately.