Start with Praxis

Praxis connects four roles through durable artifacts: Business Analyst, Architect, Developer, and Quality. Each harness can be used alone. The full chain is where the largest benefit appears because the next role opens a versioned package instead of reconstructing intent from chat.

For a team, install one role harness per person. BA and Architect work in the product canon repository. Developer works in the code repository and keeps the canon available as a second checkout or workspace root. Installing every role in every workspace is unnecessary and weakens the responsibility boundary.

Choose how you will run it

Environment	Install	Best for
Claude Desktop or Cowork	Praxis Runtime MCPB, then the ZIP for this person's role	A guided session with the local Runtime tool catalog
Claude Code	A released marketplace source or a checked-out plugin directory	Repository work with slash commands and local artifacts
CI or terminal	The praxis CLI and the packaged role tools	Deterministic gates, diagnostics, and automation

The supported Desktop artifact sequence is Runtime first, role ZIPs second. A role ZIP contains skills; Runtime supplies shared tools. Public registry publication is not currently a supported installation promise. A source checkout is a maintainer path, not a requirement for normal operators.

Release boundary

BA, Architect and Developer role packages are distributed separately from Runtime, and their source inventories are broader than installed Skills ZIPs. Quality Harness is also a delivered role package. The planned multi-project Quality Platform is a separate private product; discuss its access with the team. Check each release for its own license and supported setup.

Requirements

• BA or Architect: a local workspace rooted at the product canon repository.
• Developer: a workspace rooted at the code repository plus readable access to the product canon checkout.
• Desktop/Cowork with local computer access for the current Runtime workflow. Ordinary Desktop installation does not require Node, npm, Make, Docker, or SQLite. Advanced source/CLI environments must satisfy their own pinned release requirements.
• Git for durable artifacts and evidence.
• A Jira connection only when your team uses the Jira lifecycle.

Keep credentials in the host application's secure settings. Never paste a token into chat or store it in .project.

Install in Claude Desktop or Cowork

Follow the complete installation guide for current Release links, exact settings, credentials, and ZIP structure. Products version independently; check their compatibility metadata. The Desktop/Jira walkthrough starts from a product folder with the required canon/design artifacts available. The separate-repository pattern below is an explicit team setup, not automatic Runtime checkout discovery.

1. Install the Praxis Runtime MCPB supplied with your release.
2. Configure the Runtime. Add Jira settings only if your workflow uses Jira.
3. Import the ZIP for this person's role. A BA does not need the Architect or Developer ZIP.
4. Open the repository owned by that role: product canon for BA/Architect, code for Developer.
5. For source Developer sessions, pass the canon design-package path explicitly. For Runtime, prepare the complete local execution package in the selected root; a sibling checkout is not imported automatically.
6. Start with the role's session-start skill.

The source bootstrap reports plugin and Core versions, repository, .project state, product scope, knowledge slice, and whether work may continue. Runtime status is a separate connection check. If the BA harness cannot find .project, it explains the defaults and waits for acknowledgement.

Install in Claude Code

Follow the CLI installation guide for the verified role-package source and separate Runtime MCP connection check.

When your release is delivered as a marketplace, add its exact source and pin the supplied tag, branch, or commit. When developing from a source checkout, Claude Code can load each plugin directory directly.

After installation:

/plugin marketplace list
/plugin list

Confirm that the intended role is enabled and reload the session. Open the product canon for BA/Architect or the code repository for Developer. A BA-only, Architect-only, or Developer-only setup is the normal team configuration; contracts let another person continue without the previous person's plugin.

Bootstrap the product repository

In Desktop, ask the Skill for praxis_project_init_preview, inspect the proposed .project, then approve praxis_project_init_apply with confirmation=YES. Do not create a repository .env for Desktop credentials. The CLI examples below are an advanced source/CI path validated against the earlier canon implementation; use the help from your installed release.

Praxis reads .project, .project.yaml, or .project.yml, in that order. Start by inspecting the repository:

praxis project status --repo . --json
praxis project init --infer --repo . --json

The second command is a preview. Inspect it, then apply the minimal file explicitly:

praxis project init --infer --confirm YES --repo . --json

Inference is conservative. It recognizes scripts that exist; it does not invent build, test, or coverage commands.

A project file can define:

• product and optional service identifiers;
• a relative path to the knowledge corpus;
• Jira/provider settings without credentials;
• build, test, lint, and coverage commands used by the role gates;
• role-specific execution settings.

Your first session

Start the role in the repository it owns:

/session-start
I am the <Business Analyst | Architect | Developer>.
My working repository is <path>. The product canon is <path when separate>.
Show project scope, knowledge slice, version compatibility, artifacts relevant
to my role, and the next safe action. Do not perform another role's work.

Then choose the entry point:

Situation	Start here
New product	BA: ba-scaffold, then confirm-vision
Existing product without a canon	BA: ba-onboard
New request	BA: capture-cr, then grill-cr
BA handoff exists	Architect: intake-audit
Developer handoff exists	Developer: accept-work-package
Work package is ready for QA	With private access: Quality Status, then Review Work Package; review and Apply are separate
Interrupted work	The role's resume skill; reconstruct state from files and Jira

See Working in a session for copy-ready prompts, Artifacts and handoffs for the files each role produces, and CLI and recovery for the complete command surface.

A first connected flow

BA                Architect               Developer                Quality
request           intake                  accept                   verify
  ↓                  ↓                        ↓                       ↓
requirements  →  decisions + design  →  plan + code + evidence  →  verdict

The arrows are files and validated contracts. Chat context is useful during a role's session; it is never the handoff format.

Safety rules

• Preview before applying Jira mutations.
• Keep confirmation separate from the proposed mutation.
• Do not implement until the Developer plan is approved.
• Return an incomplete handoff to the previous role.
• Use accept as the only BA path into a baseline.
• Treat Quality failures as completed findings that block promotion, not as transport errors.
• Resume from persisted state after interruption instead of repeating completed writes.