boss-skill: an event-sourced workflow layer for coding agents
Boss Skill - BMAD 全自动研发流水线（多 Agent 编排）
At a glance
- What is it?
- Boss Skill turns a single coding agent into a PM, Architect, Tech Lead, QA and DevOps chain, and writes every stage to a .boss/<feature>/ folder. The value is the audit trail, not the autonomy.
- Who is it for?
- Adopt Boss Skill if you need a traceable .boss/<feature>/ folder for medium-sized feature work and you are willing to keep the boss CLI installed, because the README states that without it the workflow degrades to plain Markdown artifacts and you lose event sourcing, replayable resume and runtime gates. Skip it for one-line fixes, pure code reading, or any task where you already have a complete spec.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Boss Skill is trying to close
Prompt-only agent teams are easy to assemble and hard to audit. A prompt can instruct an agent to run tests and wait for QA, and the agent can narrate that it did. Nothing in the transcript proves the plan was followed or that state was not invented. Boss Skill is aimed at that specific gap. Its README describes it as an auditable agent-team workflow, and the mechanism it offers is evidence rather than instruction: pipeline state is appended to .boss/<feature>/.meta/events.jsonl and projected into read-only execution state, so the record of what happened is a file you can open. The target user is an engineer or small team doing medium-sized product work (API, full-stack, UI) who wants PRDs, architecture docs, task lists, QA reports and deploy reports to land on disk in a predictable location. The README's own rule of thumb is blunt: if you do not need a traceable .boss/ folder, you probably do not need the full /boss pipeline.
Nine roles, four stages, one append-only event log
Boss is not one monolithic command. The full pipeline is /boss, and it can be decomposed: /boss:plan for PM plus Architect, /boss:review for a read-only Tech Lead pass, /boss:qa for QA with gates, /boss:ship for DevOps build and deployment checks, /boss:extend to add a custom agent, pack or gate, and /boss:upgrade to refresh the skill and reinstall hooks. The role set named in the README is PM, Architect, UI Designer, Tech Lead, Scrum Master, Frontend, Backend, QA and DevOps. The architectural claim that separates Boss from a folder of prompts is the event-sourced runtime: events are appended to .meta/events.jsonl and then projected into execution.json and workflow-plan.json. Gates for QA, deployment and final checks are modeled as runtime stages, which the README calls non-bypassable, rather than as loose instructions the agent may skip. Captured transcripts can also be scored deterministically without calling a real LLM, which matters if you want regression checks on the workflow itself rather than on the generated code.
Install paths: skills CLI, Boss's own installer, or plugin mode
There are two supported routes and they are not equivalent. The recommended one is agent-agnostic: npx skills add echoVic/boss-skill, which discovers boss from the repo, prompts for target agent, scope and install method, and records a skills-lock.json you can commit. Boss ships a single skill root, so the picker shows only boss and the internal methodologies travel with it. The alternative is Boss's own installer, which auto-detects Claude Code, Codex, OpenClaw, Antigravity and Hermes and installs into all of them, merging Codex hooks along the way. That route is npx @blade-ai/boss-skill for a one-shot run, or npm install -g @blade-ai/boss-skill followed by boss-skill for the self-install wizard. Claude Code plugin mode uses claude --plugin-dir "$(boss-skill path)". Install commands include boss-skill install --dry-run, boss-skill uninstall, boss-skill path and boss-skill --version. Note the framing in the README: Boss is a skill you install into your coding agent, not a tool that installs other skills.
Running a scoped pipeline and reading the output
A lightweight run looks like this inside the agent: /boss Build a local personal todo app --roles core --skip-deploy. The --roles core flag restricts the run to PM, Architect, Dev and QA, and --skip-deploy stops after implementation and test evidence. Inspection happens through the CLI, not the agent: boss status todo-app --json and boss runtime inspect-pipeline todo-app. The artifact layout the README gives is .boss/todo-app/ containing design-brief.md, prd.md, architecture.md, tasks.md, qa-report.md, and a .meta/ directory with events.jsonl, execution.json and workflow-plan.json. Two details in that layout are worth noticing. The Markdown files are the human-facing deliverables, and the .meta/ files are the machine-facing record. If you only ever read the Markdown, you are getting the same thing a well-organized prompt chain would produce, minus the reason to use Boss. The JSON output flag, --describe, dry runs and structured errors are described as agent-friendly CLI affordances, which suggests the CLI is meant to be called by the agent as much as by you.
The degradation path when the CLI is absent
Boss detects the boss CLI at runtime. Without it, the README states the workflow can degrade to Markdown artifacts under .boss/<feature>/ instead of the event stream. That is a real limitation, not a footnote: event sourcing, replayable resume, deterministic evals, runtime gates and structured diagnostics all sit on the CLI side of that line. A team that installs the skill through the skills CLI and never installs the npm package gets the folder structure and the role prompts but not the auditability the project is named for. The second limitation is stated plainly in the README: Boss does not mean install once and get guaranteed autonomous delivery. It provides a runtime workflow and evidence gates, and the active coding agent still has to follow the Boss protocol. If your agent drifts, the gates are only as non-bypassable as the runtime that enforces them, and the README does not claim to control an uncooperative model. For one-line fixes, pure code reading, or tasks with a complete existing spec where you only need a quick patch, the README's own poor-fit column applies.
How this differs from BMAD and from plain prompt chains
The topics list includes bmad and bmad-workflow, and the descriptions of both the repository and the README frame Boss as a BMAD-oriented pipeline. BMAD's published methodology is a set of agent personas and document templates driven by prompts. The difference in approach here is that Boss moves the parts that can be verified out of the prompt and into a runtime: state goes to events.jsonl, gates become stages, and transcripts become deterministic eval inputs. That is a meaningful shift for anyone who has tried to prove after the fact that a prompt-driven pipeline ran its tests. It is also a heavier shift. A prompt-only chain has no install step, no Node.js version floor, no hooks to merge, and no CLI that has to be present for the workflow to work as advertised. The trade is auditability for setup surface, and the README is unusually direct about which side of that trade you land on depending on whether the CLI is installed.
Platform, licence and maintenance surface
Boss targets Node.js >=20 and runs on Linux, macOS and Windows. The README states that the CLI shells out only through spawnSync with explicit argument arrays and never shell: true, and that it resolves npm and npx to their .cmd variants on Windows, so there is no POSIX-only assumption in the core pipeline. The README text supplied here is truncated mid-sentence at a paragraph beginning "Two capabilities depend on optional external tools and degrade gracefu", so which two capabilities those are, and how they degrade, cannot be confirmed from the material available. The licence is MIT, which permits commercial use and modification; the usual obligations apply, and this is a description of the licence identifier rather than legal advice. On upgrade cost: /boss:upgrade is documented as upgrading the Boss Skill and reinstalling hooks, which tells you hooks are configuration that a skill upgrade can rewrite. If you have customized hook behavior for Codex, that is the step to watch. The repository shows no releases retrieved, so there is no versioned changelog to read before upgrading. The npm package @blade-ai/boss-skill is the distribution channel, and the last push recorded is 2026-09-06.
Editorial conclusion
Adopt Boss Skill if you need a traceable .boss/<feature>/ folder for medium-sized feature work and you are willing to keep the boss CLI installed, because the README states that without it the workflow degrades to plain Markdown artifacts and you lose event sourcing, replayable resume and runtime gates. Skip it for one-line fixes, pure code reading, or any task where you already have a complete spec. Before committing, verify two things yourself: that your agent actually follows the protocol (Boss does not guarantee autonomous delivery), and that the npm package @blade-ai/boss-skill installs cleanly on your platform, since the repository ships no releases to pin against.
Community notes