Releases: enthali/syspilot
v0.5.5
v0.5.5 - 2026-05-13
Summary
Patch release fixing the CI version-validation workflow. The GitHub Actions release.yml was still reading from the removed version.json file; it now reads the version: field directly from the Setup Agent frontmatter, restoring CI validation for all future release tags. Also includes a process improvement establishing the 3-class Artefakt-Removal Rule in the CM Workflow and Change Document Template.
🔧 Fixes & Improvements
- CI Version Source Fix (
ci-version-source-fix)- GitHub Actions
release.ymlupdated to read version fromsyspilot/agents/syspilot.setup.agent.mdfrontmatter instead of the removedsyspilot/version.json - CI now correctly validates that a pushed release tag matches the Setup Agent
version:field - All remaining
version.jsonreferences removed from CI workflows and scripts - All documentation references to
version.jsonremoved fromdocs/architecture.md,docs/methodology.md, anddocs/workflows.md
- GitHub Actions
📋 Change Requests
| Change Document | Scope |
|---|---|
ci-version-source-fix |
CI workflow reads version from Setup Agent frontmatter |
v0.5.4
Summary
Minor release completing the Duties/Workflow conformance sweep across all agents, establishing Skill Architecture as a first-class architectural component, and introducing Bootloader Schema v2 (\iles[]\ array + Soul/Guardrail alignment). Includes housekeeping cleanup of deferred skill-architecture findings and PM Duties completeness extensions.
Architecture
-
Skill Architecture Foundation (\skill-architecture-foundation)
- Skill Architecture anchored alongside Agent Architecture in the spec hierarchy
- New \SYSP_US_SKILL_ARCH\ User Story and \SYSP_REQ_SKILL_DEFINITIONS\ Requirement created
- \docs/syspilot/conventions.md\ documents Agent and Skill conventions including DEFINITIONS Dictionary pattern and Mutual Exclusion per group
-
Agent Architecture: Duties/Workflow Definition (\�gent-arch-duties-workflow-definition)
- \SYSP_REQ_AGENT_ARCH_DUTIES\ and \SYSP_REQ_AGENT_ARCH_WORKFLOW\ now establish a clear conceptual separation: Duties = outcome guarantees (WHAT), Workflow = ordered execution steps (HOW)
- Removes structural ambiguity that forced content duplication across both sections
Fixes and Improvements
- Bootloader Schema v2 (\�ootloader-schema-v2): \�ootstrap.json\ uses \iles[]\ array with \source/\destination\ per entry; Soul/Guardrail contradiction resolved; new Manifest Fidelity Duty
- PM Duties Completeness (\pm-duties-completeness): Release-Trigger + Setup-Trigger Duties; \SYSP_US_DESIGN\ AC1 clarified
- Duties Conformance — Implement, MECE, PM (\�gent-files-conformance-implement-mece-pm): Outcome-based Duties (4/4/6)
- Duties Conformance — CM, UAT, Design (\�gent-files-conformance-cm-uat-design): Outcome guarantees; end-state ACs
- Duties Conformance — Release (\�gent-files-conformance-release): Outcome guarantees; end-state ACs
- Duties Conformance — Verify, QM (\�gent-files-conformance-verify-qm): CE-gap pattern fix (each Duty has at least one AC)
Housekeeping
- Cleanup: Skill Architecture Followups (\cleanup-skill-arch-followups): RST-lint fixes (double-backticks); \SYSP_US_SETUP\ Mutual Exclusion AC added
Change Requests
| Change Document | Scope |
|---|---|
| \skill-architecture-foundation\ | Skill Architecture as spec-level component |
| \�gent-arch-duties-workflow-definition\ | Duties vs. Workflow conceptual separation |
| \�ootloader-schema-v2\ | Bootloader \iles[]\ schema + Soul/Guardrail fix |
| \pm-duties-completeness\ | PM Release-Trigger + Setup-Trigger Duties |
| \�gent-files-conformance-implement-mece-pm\ | Implement + MECE + PM Duties conformance |
| \�gent-files-conformance-cm-uat-design\ | CM + UAT + Design Duties conformance |
| \�gent-files-conformance-release\ | Release Engineer Duties conformance |
| \�gent-files-conformance-verify-qm\ | Verify + QM Duties conformance |
| \cleanup-skill-arch-followups\ | RST-lint fixes + SYSP_US_SETUP MECE AC |
v0.5.3 - QM MECE per level, Release Agent explicit sources, version consolidation
v0.5.3 - 2026-05-02
Summary
Patch release with three process and tooling fixes: QM now dispatches separate MECE checks per specification level, the Release Agent uses deterministic file scanning for archival and release notes generation, and version tracking is consolidated in the Setup Agent frontmatter (removing the redundant version.json). Includes model assignment sync (Opus 4.6 / Sonnet 4.6 / Haiku 4.5).
Fixes & Improvements
-
QM MECE Per Level (
qm-mece-per-level)- QM dispatches separate MECE checks for each specification level (L0 User Stories, L1 Requirements, L2 Design Specs)
- Each MECE invocation receives exactly one level as input — no combined cross-level runs
- Findings Report clearly indicates per-level pass/fail results
-
Release Explicit Sources (
release-explicit-sources)- Archive step explicitly scans all
*.mdfiles indocs/changes/(excluding subdirectories) — no session-context dependency - Document step generates release notes from the archived
docs/changes/<version>/folder as the authoritative source - Prevents incomplete archival and missing release notes entries due to context drift
- Archive step explicitly scans all
-
Release Version Source (
release-version-source)- Release Agent bumps the
version:field insyspilot/agents/syspilot.setup.agent.md(product source of truth) - Redundant
syspilot/version.jsondeleted - Setup Agent propagates the version to the installed instance on next setup run
- Release Agent bumps the
Housekeeping
- Agent model assignments synced from tested instance to product files:
- Claude Opus 4.6: design, implement (complex engineering tasks)
- Claude Sonnet 4.6: cm, pm, qm, setup, release, uat, docu (orchestration and documentation)
- Claude Haiku 4.5: mece, trace, verify (fast quality checks)
v0.5.2
v0.5.2 - 2026-05-01
Summary
Patch release with internal process fixes: PM/CM role boundaries clarified, merge gate process formalized, QM reduced to pure auditor role, Setup Agent preserves instance-specific tools on update, and CM sends post-merge confirmation to PM.
🔧 Fixes & Improvements
-
PM/CM Role Boundary (
pm-cm-role-boundary)- PM writes CRs from user perspective only (intent + user-visible ACs, no implementation details)
- CM always follows the complete change process independently
- Design Agent gets
vscode/askQuestionsin frontmatter for user-guided mode
-
Merge Gate Process (
qm-merge-gate)- CM does not merge to development without PM approval
- QM results are always routed to PM who decides: fix now / defer / accept as-is
- Formal merge gate between QM review and development merge
-
QM Auditor Only (
qm-auditor-only)- QM always produces Findings Reports addressed to PM — never creates CRs directly
- Simplified QM model: one output format (Findings Report → PM)
- Aligns with the Merge Gate pattern
-
Setup Preserve Tools (
setup-preserve-tools)- Setup Agent preserves instance-specific
tools:frontmatter field during updates - Fresh installs copy
tools:from product as-is - New agents are always copied completely
- Setup Agent preserves instance-specific
-
CM Merge Confirmation (
cm-merge-confirmation)- After merging to development, CM sends confirmation to PM with commit hash and branch name
- Existing pre-merge notification remains unchanged
📋 Change Requests
| Change Document | Scope |
|---|---|
pm-cm-role-boundary |
PM/CM guardrails, CR intent stays high-level |
qm-merge-gate |
Merge Gate process (CM waits for PM approval) |
qm-auditor-only |
QM is pure auditor (Findings Reports only) |
setup-preserve-tools |
Setup Agent preserves instance tools: frontmatter |
cm-merge-confirmation |
CM post-merge confirmation to PM |
v0.5.1
v0.5.1 - 2026-04-27
Summary
Three workflow improvements and housekeeping: Setup Manager added as a 4th manager role with prompt specification, Release workflow fixed for correct development-first prep and back-merge, Impact Analysis mandated as a required step in the CM and Design workflows.
✨ New Features
- Setup Manager as 4th Manager (CR15,
agent-prompts-perspective)- Setup Manager (
@syspilot.setup) formally added as a 4th user-invocable manager role alongside PM, CM, QM - Prompt specification added: only user-invocable agents (managers) SHALL have prompt files
- Agent Frontmatter and Prompt Frontmatter established as qualified terms in the spec hierarchy
- Engineer User Story perspective corrected from "As a syspilot user, I want to have a [Agent]..." to "...I want my agentic managers to have a [Agent] that..."
- Setup Manager (
🔧 Fixes & Improvements
-
Release Workflow Fix (CR16)
- Prep steps (archive, version bump, release notes, sphinx validation) now run on
developmentfirst — not onmain - Back-merge (
development ← main) added as explicit step after tagging to sync the squash commit - Conflict guidance:
-X theirsstrategy documented for squash-merge conflicts (development wins)
- Prep steps (archive, version bump, release notes, sphinx validation) now run on
-
Mandatory Impact Analysis (CR17)
- Impact Analysis is now a required step (SHALL) in the CM workflow before dispatching to System Designer
- Impact Analysis is now a required step (SHALL) in the System Designer workflow before analysis
- Acceptance Criterion AC-5 language corrected from MUST to SHALL for consistency
🏠 Housekeeping
.gitignoreupdated: installed product copies (agents, prompts, skills, scripts) are now gitignored in consumer workspacesdocs/changes/structure flattened: archives live directly atdocs/changes/vX.Y.Z/(noarchive/subfolder)- v0.5.0 release notes backfilled on
developmentbranch
📋 Change Requests
| CR | Change Document | Scope |
|---|---|---|
| CR15 | agent-prompts-perspective |
Setup Manager, Prompt Specification, Engineer US perspective |
| CR16 | (workflow fix) | Release workflow prep + back-merge + conflict guidance |
| CR17 | (workflow fix) | Mandatory Impact Analysis in CM and Design workflows |
v0.5.0
v0.5.0 - 2026-04-16
Summary
Major architecture overhaul: complete green-field Agent Architecture v2 with new SYSP_ prefix, Git-Flow branching model, impact analysis skill, and full spec coverage for all 11 agents plus the Verify Engineer. Includes 14 Change Requests (CR1–CR14).
⚠️ Breaking Changes
- Agent Architecture v2 (CR1–CR7) — All specifications migrated from
SYSPILOT_toSYSP_prefix. Old RST files removed. New traceability chain covers all 11 agents with Soul/Duties/Workflow/Frontmatter structure. - Instance Layer Removed (CR5) —
docs/inst/syspilot/eliminated; single product layer architecture.
✨ New Features
-
Agent Architecture v2 (CR1–CR7,
agent-architecture-v2)- Full specification set (US → REQ → SPEC) for all 11 agents: PM, CM, QM, Design, Implement, UAT, Docu, MECE, Trace, Release, Setup
- Meta-level architecture spec (
SYSP_US_AGENT_ARCH,SYSP_REQ_AGENT_ARCH_*,SYSP_SPEC_AGENT_ARCH_*) - Agent structure: Soul (immutable identity), Duties (customizable), Workflow (customizable)
- YAML frontmatter configuration specified per agent (CR5)
- Agents distributed as product artifacts in
syspilot/agents/andsyspilot/prompts/
-
Skill Specifications (CR2,
skill-specs-and-branching)- Full spec chain for
syspilot.ask-questions,syspilot.orchestration,syspilot.branchingskills - Skills follow VS Code folder format:
.github/skills/<name>/SKILL.md
- Full spec chain for
-
Git-Flow Branching Model (CR8,
git-flow-and-modes)- Permanent
developmentintegration branch replaces chained branching - Feature branches created from and squash-merged back to
development - Change Manager modes:
autonomousanduser-guided - CM-completion notification triggers QM targeted checks
- Permanent
-
Impact Analysis Skill (CR9,
impact-analysis-skill)- New
syspilot.impact-pythonskill wrappingget_need_links.py - System Designer queries full dependency tree before analysis
- Spec chain:
SYSP_US_SKILL_IMPACT→SYSP_REQ_SKILL_IMPACT_*→SYSP_SPEC_SKILL_IMPACT_*
- New
-
Verify Engineer Specs (CR14,
verify-agent-specs)- Full spec set (US → REQ → SPEC) for the Verify Engineer agent
SYSP_US_VERIFY→SYSP_REQ_VERIFY_*→SYSP_SPEC_VERIFY_*
-
Main Branch Protection (CR4,
main-branch-protection)- Only
@syspilot.releasemay commit to, merge to, or push tomain - All agents receive guardrail preventing direct
maincommits
- Only
🔧 Fixes & Improvements
- ID Rename (CR10) —
CHANGErole slug renamed toDESIGNacross all specs - Documentation Update (CR12+CR13) —
docs/architecture.md,docs/workflows.md,docs/methodology.md,docs/namingconventions.mdupdated for v2 architecture and skills-authoring principle - Branching & Completion Reporting (CR3) — CM workflow Step 0 branch creation; orchestration skill completion reporting rule
- Phase 2 Cleanup (CR6) — Removed 27 superseded
SYSPILOT_RST files, updated toctree indexes, cleaned dangling references
📋 Change Requests
| CR | Change Document | Scope |
|---|---|---|
| CR1–CR7 | agent-architecture-v2 |
Agent Architecture v2 green-field |
| CR2 | skill-specs-and-branching |
Skill specs + branching skill |
| CR3 | branching-and-reporting |
CM branch step + completion reporting |
| CR4 | main-branch-protection |
Main branch guardrail |
| CR5 | frontmatter-and-instance-cleanup |
Frontmatter specs + instance removal |
| CR6 | phase2-cleanup |
Old SYSPILOT_ file removal |
| CR8 | git-flow-and-modes |
Git-Flow model + change modes |
| CR9 | impact-analysis-skill |
Impact analysis skill |
| CR10 | (within CR9) | ID rename CHANGE→DESIGN |
| CR12+CR13 | (within docs) | Documentation updates |
| CR14 | verify-agent-specs |
Verify Engineer specs |
v0.4.0
v0.4.0 - 2026-04-07
Summary
Two workflow improvements that make the development loop tighter and safer: the Change Agent now runs @syspilot.mece as an automatic subagent after each level write for advisory validation, and the Setup Agent now creates a git baseline commit after a successful fresh install or adoption.
✨ New Features
-
MECE Agent as Subagent in Change Agent (SYSPILOT_SPEC_CHG_LIVE_RST_PER_LEVEL)
- After each level write
@syspilot.changeautomatically invokes@syspilot.meceas a subagent - MECE results are shown as advisory findings — non-blocking, but surfaced before moving on
- Requires the
agents:frontmatter field in the agent file (SYSPILOT_SPEC_AGENT_FRAMEWORK) - Replaces manual per-level write process; RST files are written immediately after approval
- After each level write
-
Git Baseline Commit after Fresh Install / Adoption (#11, SYSPILOT_SPEC_INST_INSTALL_COMMIT)
@syspilot.setupnow stages and commits all placed files after successful sphinx-build validation- Commit message:
chore: install syspilot v{version}(new project) orchore: adopt syspilot v{version}(existing project) - Confirmation-gated: user approves commit before it is created
- Handles pre-existing uncommitted changes: offers to commit only syspilot files separately, or skip
- Graceful skip if git is not initialized or identity is not configured (informational message)
- Does not run in update mode (that is handled by the update branch workflow)
🔧 Fixes & Improvements
@syspilot.changewrites RST per level immediately after approval (:status: draft), enabling live link traversal viaget_need_links.pyduring analysis- Change Document is always a lean decision log from the start, not a verbose RST dump
📋 Specs
- New:
SYSPILOT_REQ_INST_INSTALL_COMMIT,SYSPILOT_SPEC_INST_INSTALL_COMMIT - Modified:
SYSPILOT_SPEC_INST_SETUP_AGENT(Section 8: Git Baseline Commit) - Modified:
SYSPILOT_US_INST_NEW_PROJECT,SYSPILOT_US_INST_ADOPT_EXISTING(AC-6 added) - Modified:
SYSPILOT_SPEC_CHG_LIVE_RST_PER_LEVEL(MECE subagent step) - Modified:
SYSPILOT_SPEC_AGENT_FRAMEWORK(agents:frontmatter field documented)
v0.3.1 - Post-Update Review + Update Branch Workflow
v0.3.1 - 2026-04-03
Summary
Safety improvement to the update workflow: the Setup Agent now creates a dedicated update/v{version} branch before performing any updates, detects project-specific extensions that would be silently lost when replacing methodology-owned files, and creates a change document summarizing what was updated.
✨ New Features
-
Update Branch Workflow (#16, SYSPILOT_SPEC_INST_UPDATE_BRANCH)
@syspilot.setup(update mode) now createsupdate/v{version}branch before any file changes- All update work is committed on the dedicated branch
- A change document
docs/changes/update-v{version}.mdis created summarizing replaced/skipped files - User reviews the branch diff and merges when ready
-
Post-Update Extension Review (#16, SYSPILOT_SPEC_INST_POST_UPDATE_REVIEW)
- After replacing methodology-owned files, compares old vs new content using
git show HEAD:<path> - If a file had project-specific additions that are missing in the new version, the user is alerted
- Per-file options: accept new version / merge back manually / restore old version
- Silent skip if no custom extensions are detected
- After replacing methodology-owned files, compares old vs new content using
🔧 Fixes & Improvements
- Resolves silent data loss when updating syspilot if methodology-owned files had been customized (e.g., extra verification steps in
syspilot.verify.agent.md)
📋 Specs
- New:
SYSPILOT_REQ_INST_POST_UPDATE_REVIEW,SYSPILOT_REQ_INST_UPDATE_BRANCH - New:
SYSPILOT_SPEC_INST_POST_UPDATE_REVIEW,SYSPILOT_SPEC_INST_UPDATE_BRANCH - Modified:
SYSPILOT_SPEC_INST_UPDATE_PROCESS(Steps 0a, 3/4a, 6/7 added) - Modified:
SYSPILOT_US_INST_UPDATE(AC-7 and AC-8 added)
v0.3.0 — Local install, skill format, architecture docs, Mermaid
v0.3.0 - 2026-04-02
Summary
Structural improvements: local install support, skill format migration to VS Code standard, new architecture and workflows documentation pages with Mermaid diagrams, and branching strategy documentation.
⚠️ Breaking Changes
- Skill Format Migration (#12, SYSPILOT_SPEC_AGENT_SKILL_FORMAT)
- Skills now use folder format:
.github/skills/<name>/SKILL.md - Old format
.github/skills/<name>.skill.mdis no longer recognized - Run
@syspilot.setupto migrate existing installations - YAML frontmatter with
name/descriptionenables automatic skill discovery
- Skills now use folder format:
✨ New Features
-
Local Install Support (#9, SYSPILOT_REQ_INST_LOCAL_SOURCE)
- Setup agent detects
syspilot/directory and offers local vs GitHub install - Enables testing agent changes before pushing (dogfooding workflow)
- File ownership rules apply equally to local install
- Setup agent detects
-
Architecture Documentation (#15, SYSPILOT_REQ_DOC_ARCHITECTURE)
- New
docs/architecture.md— explains Product/Instance separation concept - 7 chapters: Why, What (Product + Instance), How They Relate, Concrete Example, Update Safety
- New
-
Workflows Documentation (#15, SYSPILOT_REQ_DOC_WORKFLOWS)
- New
docs/workflows.md— central syspilot process description - Covers all 3 workflows: Change, Quality, Release
- Agent decision guide, workflow diagrams, branching strategy
- New
-
Mermaid Diagram Support
- Added
sphinxcontrib-mermaidto Sphinx extensions - All ASCII diagrams replaced with Mermaid flowcharts across docs and specs
- Client-side rendering via mermaid.js (no build-time dependency)
- Added
-
Branching Strategy (SYSPILOT_SPEC_DOC_WORKFLOWS_STRUCTURE)
- Documented chained feature branches model
- Main = releases only, squash merge during
@syspilot.release
🔧 Improvements
-
Housekeeping
- Removed version tracking from memory agent scope (SYSPILOT_SPEC_MEM_SCOPE)
- Archived v0.2.2 change documents to
docs/changes/archive/v0.2.2/
-
Traceability
- Added outgoing links from SPEC_DOC_WORKFLOWS_STRUCTURE to agent design specs
- Impact analysis now catches documentation when agent specs change
📋 Issues Closed
v0.2.3
v0.2.3 - 2026-03-30
Summary
Agent Family Framework with product/instance architecture, plus setup agent update process with file ownership model. Specs are now organized around agent families with independent spec trees. Instance-level specs capture project-specific decisions for release and implement agents. The setup agent bootstraps itself first, then uses a 3-category ownership model (methodology/project/user) to decide which files to update.
✨ New Features
-
Agent Family Framework (SYSPILOT_US_CORE_SPEC_AS_CODE, SYSPILOT_REQ_CORE_FAMILY_ARCH)
- Product/Instance two-layer spec architecture
- Product specs define WHAT (generic), instance specs define HOW (project-specific)
- Family-based naming:
SYSPILOT_*(product),INST_SYSPILOT_*(instance) - Framework-level docs separated from family-specific docs
docs/syspilot/= product specs,docs/inst/syspilot/= instance specs
-
Instance Spec Tree (SYSPILOT_US_INST_AGNOSTIC, SYSPILOT_REQ_INST_CUSTOM_PRESERVE)
- 14 new INST spec elements across all 3 levels (US → REQ → SPEC)
- Release agent instance config: version file, tag format, archive policy, validation
- Implement agent instance config: language, framework, testing conventions
-
Setup Agent Self-Update (SYSPILOT_US_INST_UPDATE, SYSPILOT_REQ_INST_BOOTSTRAP_SELF)
- Bootstrap Step 0: setup agent updates itself first before updating anything else
- 3-category file ownership model: methodology (always replace), project (copy once), user (never touch)
- Template banner on generic release/implement agents prompting customization
🐛 Bug Fixes
-
Release Agent (INST_SYSPILOT_SPEC_REL_AGENT_CONFIG)
- Replaced 441-line v0.2.1 fossil with customized KISS template (~60 lines)
- Fixed: agent still contained
git rm(delete) instead ofgit mv(archive) - Added squash merge step per SYSPILOT_SPEC_REL_WORKFLOW
-
Stale Path References
- Fixed 12×
templates/→syspilot/in spec_release.rst, spec_change.rst - Moved
change-document.mdtosyspilot/templates/
- Fixed 12×
📦 Migration
- 130 spec IDs renamed with
SYSPILOT_prefix - 6 directory moves:
docs/{userstories,requirements,design}→docs/syspilot/ - ~510 cross-reference updates across all RST files
copilot-instructions.mdupdated with instance-level architecture