Menu
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.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação 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.
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 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.branching |
| description | 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. |
ONLY @syspilot.release may commit to, merge to, or push to main. No exceptions.
If you are on main and need to make any change, create feature/<name> from development first.
Main always equals the latest release — any non-release commit on main is a violation.
syspilot uses a permanent development integration branch with short-lived feature branches:
gitGraph
commit id: "v0.2.3" tag: "v0.2.3"
branch development
checkout development
commit id: "dev-start"
branch feature/CR7
checkout feature/CR7
commit id: "CR7: specs"
commit id: "CR7: implement"
commit id: "CR7: verify"
checkout development
merge feature/CR7 id: "squash CR7"
branch feature/CR8
checkout feature/CR8
commit id: "CR8: specs"
commit id: "CR8: implement"
commit id: "CR8: verify"
checkout development
merge feature/CR8 id: "squash CR8"
checkout main
merge development id: "v0.2.4" tag: "v0.2.4"
Key Properties:
development as integration target — all features merge heredevelopment and mainv{version} tags mark published releasesgit checkout development && git merge main prevents conflicts on next release-X theirs (development wins)| Agent | May create | May commit to |
|---|---|---|
@syspilot.release | (none) | main (squash merge from development + tag); development (prep + back-merge) |
@syspilot.pm | feature/<name> | feature/<name> (the branch it created) |
@syspilot.installer | (none) | pre-install and final commit on the branch that was checked out when invoked (no dedicated branch created) |
@syspilot.implement | (none) | current feature branch |
@syspilot.verify | (none) | current feature branch |
@syspilot.docu | (none) | current feature branch |
| All other engineers | (none) | current feature branch |
development is a permanent branch that all feature branches merge into. No agent creates development — it exists permanently.
| Pattern | Created by | Purpose |
|---|---|---|
development | (permanent) | Integration branch, all features merge here |
feature/<name> | @syspilot.pm | Feature work, fixes, refactors |
main | (protected) | Release-only, always latest release |
After a feature branch is squash-merged into development and the release
that includes it completes, the default policy is to retain the branch
(locally and on remote) rather than delete it.
A project MAY opt into automatic deletion of merged feature branches by
stating so in tailoring.md, e.g.:
Delete feature branches after they are merged into development and released — do not retain them.
Absent such an override, branches are retained indefinitely; retaining them costs nothing and preserves forensic/bisect history.
The Release Engineer applies this policy during its branch-retention workflow step.
Format: <type>: <short description>
| Type | When to use | Example |
|---|---|---|
feat | New feature or specification | feat: add branching skill RST specs |
fix | Bug fix or correction | fix: correct traceability link in REQ_123 |
docs | Documentation changes (non-spec) | docs: update PM context with CR5 status |
chore | Maintenance, cleanup, tooling | chore: archive v0.2.2 change documents |
refactor | Restructuring without behavior change | refactor: reorganize index.rst toctrees |
Rules:
main — only @syspilot.release may. No exceptions.