BSW.DevSpark

The Baylor Scott & White Adaptive System Life Cycle Development (ASLCD) Toolkit

Build high-quality software faster with AI-driven lifecycle management — built by Baylor, for Baylor.

bsw.devspark is Baylor Scott & White's Adaptive System Life Cycle Development (ASLCD) Toolkit: an agent-agnostic, multi-user, full-lifecycle methodology that combines specification-driven development with constitution-powered quality assurance and right-sized workflows for tasks of any complexity.

0external dependencies added to your repo
100%hosted inside the Baylor ecosystem
18AI coding assistants supported
8 moproven in production on FCN
$0license cost — no vendor

🛡️ Fully self-contained. Entirely within the Baylor ecosystem.

BSW.DevSpark has no external libraries, no external dependencies, and no external references. It is plain markdown and scripts — there is nothing to install and nothing that calls out.

bsw.devspark lives entirely inside the Baylor Scott & White ecosystem:

  • Source of truth — the Baylor Scott & White Azure DevOps organization (bswdev/HealthSource/bsw.devspark)
  • Distribution — the Baylor-hosted Static Web App (bsw-devspark.bswhive.com)
  • Mirroring/collaboration — the Baylor GitHub organization (where applicable)

Nothing leaves Baylor. There is no public package, no third-party service, and no outside vendor in the loop.

The closed loop — nothing crosses the Baylor boundary

flowchart LR
  subgraph BSW["🔒 Baylor Scott & White Enterprise"]
    direction LR
    A["bsw.devspark repo<br/>(Azure DevOps)"] --> B["CI Pipeline<br/>builds + versions"]
    B --> C["bsw-devspark.bswhive.com<br/>Static Web App"]
    C --> D["Your BSW repo<br/>.devspark snapshot"]
  end

No arrow leaves the box. No public package registry, no third-party SaaS, no external CDN, no outside vendor — ever.

Every Concern, Answered

The methodology occasionally flagged as a governance risk is the one best positioned to solve governance. Full detail on the Enterprise Overview.

The concern The answer
🔗 Vendor / AI lock-in Agent-agnostic plain-text prompts. Switch Copilot ↔ Claude ↔ Cursor with zero rework — your specs and decisions stay put.
📦 Supply-chain risk Static text copied into your repo. No package reference, no external call at build time or runtime.
🛂 Governance & standards The constitution actively enforces standards at every step — not a wiki page that drifts out of date.
⚖️ Compliance & audit A documented chain of intent: human-authored spec → AI implementation → human review. A stronger audit trail than most traditional workflows.
🔐 Security review No executables, no network calls, no data transmission. There is nothing to audit at runtime because nothing runs.
🧑‍💻 Adoption friction Entirely voluntary. Ignore it and your repo is unaffected. Eight months of voluntary FCN adoption proves it earns its place.

How You Get BSW.DevSpark — No Repo Access Required

BSW.DevSpark is delivered as a managed internal standard, not a repository you clone. The bsw.devspark repository is the single source of truth and is owned by the BSW.DevSpark maintainers; a CI pipeline publishes every release to one front door:

https://bsw-devspark.bswhive.com

Consuming teams never need access to the source repository. They reach exactly one surface for everything:

What you need Where it comes from
📘 Documentation (this site) https://bsw-devspark.bswhive.com/
📦 Install / upgrade packages …/dist/<version>/ + …/dist/manifest.json
⚡ Prompt-first onboarding files …/raw/...

This is the enterprise control point: the standard is governed centrally (only maintainers and the pipeline can change what ships), while developers consume it with read-only distribution access — decoupled from access to the source.

 bsw.devspark repo  ──►  CI pipeline  ──►  bsw-devspark.bswhive.com  ──►  your repo
 (owned standard)       (builds + tags)     (versioned front door)       (consumes)

Access is open during validation and tightens to Microsoft Entra ID without changing the front-door URL — the CLI already authenticates with your Azure identity when required.

Install or Upgrade

Two ways to adopt BSW.DevSpark in your repository — both pull only from the front door, never from the source repo.

Prompt-first (no install)

Paste this into your AI agent; it fetches everything it needs from the Static Web App:

Follow the instructions at https://bsw-devspark.bswhive.com/raw/quickstart/devspark_quickstart_copilot.md

Swap copilot for your agent: claudecode, cursor, codex, antigravity, or generic.

CLI (optional)

Install (or update) the bsw.devspark CLI from the front door — no repo access needed:

uv tool install devspark-cli --find-links https://bsw-devspark.bswhive.com/dist/cli/

It then resolves versions and packages from the same surface:

devspark init --here --ai copilot                       # set up BSW.DevSpark in the current repo
devspark upgrade                                        # move to the latest published version
devspark init --here --ai copilot --release-tag v2.7.0  # pin a specific version

The CLI reads …/dist/manifest.json to resolve latest, then installs the matching package into .devspark/ — your .documentation/ is never touched.

Versioning & Releases

BSW.DevSpark follows a structured, predictable versioning model so every consuming repository knows exactly what it is running and how to move forward safely.

Aspect Policy
Scheme Semantic Versioning — MAJOR.MINOR.PATCH
MAJOR Breaking changes to the command/prompt contract or install layout
MINOR New commands, new agent support, additive capabilities (backward-compatible)
PATCH Fixes and clarifications to existing prompts, scripts, and templates
Source of truth Annotated git tags vX.Y.Z on bsw.devspark; CI publishes on tag
Discovery …/dist/manifest.json exposes latest, the current tag, and published assets
Installed stamp Each consuming repo records its version in .devspark/VERSION
Upgrade devspark upgrade compares .devspark/VERSION to manifest.latest
Pinning Install or hold a specific release with --release-tag vX.Y.Z

Because the installed .devspark/ is fully replaceable and your work in .documentation/ is never touched, upgrades are safe and reversible — you always know your current version and can pin, advance, or roll back deliberately.

Three Pillars

🔀 Agent-Agnostic by Default

Every AI coding assistant is a first-class citizen. Stock command prompts live in .devspark/defaults/commands/, repository overrides live in .documentation/commands/, and each platform receives only thin shims. Switch agents, use multiple agents on the same project, or onboard new team members on different tools.

👥 Multi-User Personalization

Teams share prompts, but individuals can customize any command via /devspark.personalize. Personalized overrides live in .documentation/{git-user}/commands/, are committed to git, and take priority over shared defaults. Delete the override to revert.

🔄 Full Lifecycle Coverage

From greenfield creation through brownfield discovery, ongoing maintenance, documentation cleanup, release management, and constitution evolution — every phase of the SDLC is supported.

⚙️ Optional Harness Runtime

For teams that want terminal-driven execution, BSW.DevSpark also ships an additive CLI runtime for declarative workflow specs, adapter management, validation, tracing, and environment diagnostics. See Harness Engineering for the runtime model and operator guidance.

About BSW.DevSpark

BSW.DevSpark is a structured development process for AI coding assistants — 28 slash-command prompts plus helper templates and scripts that give any AI agent a repeatable workflow from requirements through release. An internal Baylor Scott & White project.

The ASLCD Vision

Traditional spec-driven development works well for greenfield projects with major features. But real-world development includes bug fixes, hotfixes, brownfield codebases, and documentation that drifts over time. Adaptive System Life Cycle Development addresses these gaps:

Challenge ASLCD Solution
Greenfield bias /devspark.discover-constitution generates constitutions from existing code
Task overhead /devspark.quickfix provides lightweight workflow for small tasks
Documentation drift /devspark.release archives artifacts and maintains living documentation
Repo clutter /devspark.harvest consolidates knowledge and archives obsolete artifacts
Constitution staleness /devspark.evolve-constitution proposes amendments from PR findings
Context management Right-sized workflows optimize AI agent effectiveness

What's Included

Feature Status
Core SDD Workflow ✅ Full support
/devspark.constitution ✅ Included
/devspark.discover-constitution ✅ Brownfield discovery
/devspark.pr-review ✅ Constitution-based PR review
/devspark.address-pr-review ✅ Author-side PR review remediation with commit isolation
/devspark.site-audit ✅ Full codebase auditing
/devspark.critic ✅ Adversarial risk analysis
/devspark.quickfix ✅ Lightweight workflow
/devspark.release ✅ Release documentation
/devspark.evolve-constitution ✅ Constitution evolution
/devspark.harvest ✅ Knowledge harvest and cleanup
Agent-agnostic architecture ✅ Stock prompts + repo overrides + thin shims
Multi-user personalization ✅ /devspark.personalize per-user overrides
Multi-agent support ✅ 18+ AI agents
Multi-app monorepo support ✅ Optional — profile-based inheritance, scoped commands
Harness runtime ✅ devspark harness, devspark adapter, devspark doctor

Getting Started

Follow the Quick Start Guide to bootstrap BSW.DevSpark with a single prompt -- no CLI required. For updates, see the Upgrade Guide.

Guides

Full Development → Release Cycle

The recommended command order from first requirements through a tagged release:

Phase 1 — Feature Development

Step Command Purpose
1 /devspark.specify Define requirements (route-aware: quickfix, quick-spec, or full-spec)
2 /devspark.plan Technical architecture and stack choices
3 /devspark.tasks Break the plan into actionable implementation tasks
4 /devspark.analyze Cross-artifact consistency check
5 /devspark.implement Execute tasks — spec status moves to In Progress, then Complete

CLI shortcut: devspark run create-spec chains steps 1–4 automatically and pauses after analyze. Requires the BSW.DevSpark CLI.

Phase 2 — Pull Request

Step Command Purpose
6 /devspark.create-pr Draft the pull request with spec and gate context
7 /devspark.pr-review Constitution-based review
8 /devspark.address-pr-review Remediate review findings with enforced commit isolation
9 /devspark.pr-review UPDATE Focused re-review against the fix iteration, then merge

CLI shortcut: devspark run execute-plan chains steps 5–7 automatically and pauses after create-pr. Requires the BSW.DevSpark CLI.

Phase 3 — Release

Step Command Purpose
10 /devspark.site-audit Optional final compliance and quality audit
11 /devspark.release --dry-run Preview artifacts to archive and documentation to generate
12 /devspark.release {version} Archive complete specs, generate CHANGELOG, release notes, and bump version
13 /devspark.harvest Post-release cleanup of stale artifacts

Prerequisites before /devspark.release:

  • All tasks.md items checked [x]
  • All spec.md statuses set to Complete
  • All PRs merged and branch synced with main (git fetch origin && git status)
  • Markdownlint passes — the release command blocks on lint errors

See Implementation Lifecycle Guide for sprint cadence, spec status rules, and right-sizing guidance.

Core Concepts

The Constitution

The constitution is the foundational document defining your project's architecture, coding standards, and development guidelines. All BSW.DevSpark commands reference the constitution for validation.

  • Create: /devspark.constitution - Define principles for new projects
  • Discover: /devspark.discover-constitution - Generate from existing code
  • Evolve: /devspark.evolve-constitution - Propose amendments
  • Learn More: Constitution Guide

Right-Sized Workflows

Match process overhead to task complexity:

Task Type Workflow When to Use
Major Feature Full Spec Multiple files, architectural impact
Bug Fix Quickfix Single file, clear root cause
Hotfix Quickfix (expedited) Production emergency
Minor Feature Quick Spec or Quickfix Depends on scope

/devspark.specify is the default intake command for new work. It recommends the right route first, then asks the user to confirm or override that recommendation.

Adaptive Documentation

Documentation evolves with your system:

  1. Development: Specs, plans, tasks guide implementation
  2. Release: Artifacts archived, decisions extracted as ADRs
  3. Maintenance: Constitution updated as architecture evolves

Command Categories

Constitution Commands

Command Purpose Guide
/devspark.constitution Create/update constitution Constitution Guide
/devspark.discover-constitution Generate from existing code Constitution Guide
/devspark.evolve-constitution Propose amendments Constitution Guide

Full Spec Workflow

For major features and architectural changes.

Command Purpose Next Step
/devspark.specify Define requirements /devspark.plan
/devspark.plan Technical planning /devspark.tasks
/devspark.tasks Task breakdown /devspark.critic
/devspark.critic Risk analysis /devspark.implement
/devspark.implement Execute tasks /devspark.create-pr
/devspark.create-pr Draft or update the PR with workflow context /devspark.pr-review
/devspark.update-pr Refresh an existing PR description after new commits or review fixes /devspark.pr-review
/devspark.address-pr-review Address open review findings and commit review updates in isolation /devspark.pr-review UPDATE

Lightweight Workflow

For bug fixes, hotfixes, and small features.

Command Purpose
/devspark.quickfix Create, validate, and track quick fixes

Quality Assurance

Constitution-powered quality commands that work independently.

Command Purpose Guide
/devspark.pr-review Review PRs against constitution PR Review Guide
/devspark.site-audit Codebase compliance audit Site Audit Guide
/devspark.critic Adversarial risk analysis Critic Guide

Lifecycle Commands

Command Purpose Guide
/devspark.release Archive artifacts, generate release docs
/devspark.harvest Canonical knowledge-preserving cleanup and archival workflow Harvest Guide
/devspark.repo-story Evidence-based repository narrative generation Repo Story Guide
/devspark.commit-audit Analyze commit history for workflow, hygiene, and delivery signals
/devspark.address-pr-review Address open PR review findings with enforced commit isolation
/devspark.taskstoissues Convert tasks.md into GitHub issues
/devspark.clarify Clarify specification requirements
/devspark.checklist Generate quality checklists Checklist Guide
/devspark.analyze Artifact consistency checking
/devspark.personalize Create per-user prompt customizations
/devspark.upgrade Check installed version and guide safe upgrade Upgrade Guide

/devspark.harvest is the only lifecycle cleanup command documented for ongoing use. /devspark.archive remains as a deprecated compatibility alias.

Optional CLI Runtime

These are terminal commands, not slash commands. They are available when you install devspark via the optional CLI or work from a compatible source checkout.

Command Purpose Guide
devspark harness run Execute a declarative harness workflow spec Harness Engineering
devspark harness validate Validate a harness spec without executing steps Harness Engineering
devspark harness trace Inspect persisted events from a prior run Harness Engineering
devspark adapter list Show built-in adapters and local availability Harness Engineering
devspark adapter default Persist the default adapter in user config Harness Engineering
devspark doctor Check the current machine for harness prerequisites Harness Engineering

Multi-App Commands (Optional)

For repositories containing multiple applications with different platforms or governance rules. Single-app repositories can skip these entirely.

Command Purpose
/devspark.add-application Register a new application in the multi-app registry
/devspark.list-applications Display all registered applications and profiles
/devspark.validate-registry Validate registry schema, references, and consistency

Opt-in only: Multi-app support is activated by creating a registry at .documentation/devspark.json. Without it, BSW.DevSpark operates in standard single-app mode with no behavior changes.

Harness Runtime at a Glance

The harness runtime lets you author a YAML or JSON spec, execute it through the CLI, and collect a structured audit trail under .documentation/devspark/runs/.

Typical flow:

devspark doctor
devspark harness validate sample.harness.yaml
devspark harness run sample.harness.yaml --dry-run
devspark harness trace latest

Built-in adapters are noop, manual, claude_code, codex, copilot, and cursor. The saved default adapter is stored in the user config directory, not in .devspark/ or .documentation/, so upgrades do not overwrite it.

Future Direction

BSW.DevSpark is actively developed with plans for:

  • Enhanced Debt Tracking - Structured metrics storage and visualization
  • Business Value Alignment - Link features to business goals
  • CI/CD Integration - Run audits as pipeline steps
  • Cross-Project Governance - Organizational-level consistency

Contributing

BSW.DevSpark welcomes contributions:

See CONTRIBUTING.md for setup instructions.

Credit & Attribution

BSW.DevSpark is maintained by the Baylor Scott & White engineering community.

Edit this page