Skip to content

Releases: enthali/syspilot

v0.5.5

13 May 12:32

Choose a tag to compare

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.yml updated to read version from syspilot/agents/syspilot.setup.agent.md frontmatter instead of the removed syspilot/version.json
    • CI now correctly validates that a pushed release tag matches the Setup Agent version: field
    • All remaining version.json references removed from CI workflows and scripts
    • All documentation references to version.json removed from docs/architecture.md, docs/methodology.md, and docs/workflows.md

📋 Change Requests

Change Document Scope
ci-version-source-fix CI workflow reads version from Setup Agent frontmatter

v0.5.4

13 May 11:39

Choose a tag to compare

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

02 May 00:58

Choose a tag to compare

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 *.md files in docs/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
  • Release Version Source (release-version-source)

    • Release Agent bumps the version: field in syspilot/agents/syspilot.setup.agent.md (product source of truth)
    • Redundant syspilot/version.json deleted
    • Setup Agent propagates the version to the installed instance on next setup run

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

01 May 19:24

Choose a tag to compare

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/askQuestions in 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
  • 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

27 Apr 20:18

Choose a tag to compare

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..."

🔧 Fixes & Improvements

  • Release Workflow Fix (CR16)

    • Prep steps (archive, version bump, release notes, sphinx validation) now run on development first — not on main
    • Back-merge (development ← main) added as explicit step after tagging to sync the squash commit
    • Conflict guidance: -X theirs strategy documented for squash-merge conflicts (development wins)
  • 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

  • .gitignore updated: installed product copies (agents, prompts, skills, scripts) are now gitignored in consumer workspaces
  • docs/changes/ structure flattened: archives live directly at docs/changes/vX.Y.Z/ (no archive/ subfolder)
  • v0.5.0 release notes backfilled on development branch

📋 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

15 Apr 23:39

Choose a tag to compare

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_ to SYSP_ 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/ and syspilot/prompts/
  • Skill Specifications (CR2, skill-specs-and-branching)

    • Full spec chain for syspilot.ask-questions, syspilot.orchestration, syspilot.branching skills
    • Skills follow VS Code folder format: .github/skills/<name>/SKILL.md
  • Git-Flow Branching Model (CR8, git-flow-and-modes)

    • Permanent development integration branch replaces chained branching
    • Feature branches created from and squash-merged back to development
    • Change Manager modes: autonomous and user-guided
    • CM-completion notification triggers QM targeted checks
  • Impact Analysis Skill (CR9, impact-analysis-skill)

    • New syspilot.impact-python skill wrapping get_need_links.py
    • System Designer queries full dependency tree before analysis
    • Spec chain: SYSP_US_SKILL_IMPACTSYSP_REQ_SKILL_IMPACT_*SYSP_SPEC_SKILL_IMPACT_*
  • Verify Engineer Specs (CR14, verify-agent-specs)

    • Full spec set (US → REQ → SPEC) for the Verify Engineer agent
    • SYSP_US_VERIFYSYSP_REQ_VERIFY_*SYSP_SPEC_VERIFY_*
  • Main Branch Protection (CR4, main-branch-protection)

    • Only @syspilot.release may commit to, merge to, or push to main
    • All agents receive guardrail preventing direct main commits

🔧 Fixes & Improvements

  • ID Rename (CR10) — CHANGE role slug renamed to DESIGN across all specs
  • Documentation Update (CR12+CR13) — docs/architecture.md, docs/workflows.md, docs/methodology.md, docs/namingconventions.md updated 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

07 Apr 20:06

Choose a tag to compare

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.change automatically invokes @syspilot.mece as 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
  • Git Baseline Commit after Fresh Install / Adoption (#11, SYSPILOT_SPEC_INST_INSTALL_COMMIT)

    • @syspilot.setup now stages and commits all placed files after successful sphinx-build validation
    • Commit message: chore: install syspilot v{version} (new project) or chore: 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.change writes RST per level immediately after approval (:status: draft), enabling live link traversal via get_need_links.py during 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

02 Apr 23:04

Choose a tag to compare

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 creates update/v{version} branch before any file changes
    • All update work is committed on the dedicated branch
    • A change document docs/changes/update-v{version}.md is 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

🔧 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

02 Apr 11:10

Choose a tag to compare

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.md is no longer recognized
    • Run @syspilot.setup to migrate existing installations
    • YAML frontmatter with name/description enables automatic skill discovery

✨ 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
  • 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
  • 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
  • Mermaid Diagram Support

    • Added sphinxcontrib-mermaid to Sphinx extensions
    • All ASCII diagrams replaced with Mermaid flowcharts across docs and specs
    • Client-side rendering via mermaid.js (no build-time dependency)
  • 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

  • #9 — Setup Agent: Support local install from syspilot/ directory
  • #12 — Migrate skills to VS Code standard format
  • #15 — Documentation: Architecture page for Product/Instance concept

v0.2.3

30 Mar 21:36

Choose a tag to compare

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 of git 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.md to syspilot/templates/

📦 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.md updated with instance-level architecture