Menu
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.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.
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.
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.
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.impact-python |
| group | impact |
| description | 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. |
Implements: SYSP_SPEC_SKILL_IMPACT_QUERY, SYSP_SPEC_SKILL_IMPACT_EXCHANGE, SYSP_SPEC_SKILL_IMPACT_GROUP Requirements: SYSP_REQ_SKILL_IMPACT_QUERY, SYSP_REQ_SKILL_IMPACT_EXCHANGE, SYSP_REQ_SKILL_IMPACT_GROUP
.github/skills/syspilot.impact-python/scripts/get_need_links.py — run with --help for parameter details.
Requires docs/_build/html/needs.json — run sphinx-build first if stale.
To replace this implementation: create a new skill folder, provide the same
query-by-ID capability, update the description for Copilot discovery.
No agent changes required.
Impact Analysis is mandatory for every change. File lists provided in a Change Request are input hints, not the complete scope. This skill MUST be executed before any spec changes are made — the result defines the actual scope.
A newly created element has no incoming links. Run the query from each consumer element that the new element satisfies.
Example: You created SYSP_US_SKILL_IMPACT which :links: to SYSP_US_DESIGN
and SYSP_US_PM. Run the impact query from SYSP_US_DESIGN and SYSP_US_PM
(not from the new US).
--direction in for level transitionsin = "who links to me" = "who implements me at the next level down".
REQs link upward to USes, SPECs link upward to REQs. So querying a US with
--direction in yields its REQ candidates.
| Transition | Depth | Rationale |
|---|---|---|
| Level 0 → Level 1 | 1 | US → REQ, direct links |
| Level 1 → Level 2 | 1 | REQ → SPEC, direct links |
| Level 2 cross-check | 2 | Catches second-order consumers (e.g. doc SPECs aggregating workflow SPECs) |
At Level 0 present candidates to the user without verdicts. Assessment (affected / not affected) happens when writing the next level.