Work in a session

A Praxis session has three layers: the role skill tells the agent how to think and what artifact to produce; Runtime or a CLI performs bounded operations; Git and Jira preserve the result for the next person.

Current Desktop session

Use the installation guide, enable local computer access, and start a new Cowork session. Named Skills are Jira Epic Analysis, Plan Jira Epic, Materialize Work Package, Developer Status, and Implement Work Package. Private Quality users have Quality Status and Review Work Package. Each role needs Runtime and only its own integration.

Start with status and existing artifacts. Preview is not Apply. Developer completion writes evidence and leaves Jira In Progress; Quality Review executes tests without Jira writes, and a separately approved Apply can mark Done. Git Delivery follows Quality approval with separate commit/push/PR gates.

The deep canon recipes below remain available for teams using the local-canon workflow. Source CLI details were verified against the earlier monorepo snapshot; they are not installation instructions for current skills-only ZIPs. Prompt library contains the current Runtime examples.

One team, separate harnesses

The normal team setup gives each person only the harness for their responsibility.

Person	Harness	Working repository	Reads from the previous role	Produces for the next role
Business Analyst	BA	product canon	customer and product evidence	requirements, approved WP, BA handoff
Architect	Architect	product canon	BA handoff and canon	decisions, design package, Developer handoff
Developer	Developer	code repository, with canon checkout available	Architect handoff and design package	code, evidence, Quality handoff
Quality	Quality Harness	selected local project and review context	Developer evidence and design	persisted review/findings; approved Apply may write Jira

No role needs another role's plugin to continue. The handoff file is the API between people. Chat history is not.

product-canon/                       code-repository/
  vision.md                            .project  # file
  epics/                               src/
  cr/                                  test/
  wp/<WP>/                             ...
  design/<WP>/

BA and Architect work in product-canon; committing and syncing artifacts is an explicit team action. The Developer works in code-repository and opens product-canon/design/<WP>/... through a second workspace root, sibling checkout, or other explicit local path.

Invoke a skill

Use the skill name or state the intent in plain language:

/session-start
/capture-cr
/intake-audit
/claim-work-package

Start a Developer session in <code-path> for the mapped Runtime WP / PRX-4. Inspect the local manifest, current claim and handoff,
accept the package, research only inside the context slice, and prepare a plan.
Do not implement until I approve the plan.

Give the role, repository path, epic or Work Package ID, and input artifact path in the first message. The agent should not guess identifiers or assume that another harness is installed. Human gates remain explicit: vision confirmation, CR confirmation, plan approval, Jira writes, implementation approval, claim release, and final acceptance.

What session-start does

The source bootstrap resolves the repository, loads .project, derives product and service scope, selects applicable knowledge by role and stage, compares versions, and reports whether the session may continue.

Harness	Role	Stage
BA	ba	research
Architect	architect	plan
Developer	developer	implement
Quality	qa	quality

Knowledge may be loaded, skipped, or unavailable. Missing knowledge is visible; the agent must not pretend it loaded rules that were not present.

Connected team sessions

Each role starts a fresh session and opens the previous role's durable artifacts.

Business Analyst — product canon

/session-start
I am the Business Analyst. Product repository: <product-path>.
Canon package: WP-20260914-002. This workspace is the product canon repository.
Capture this request in the customer's words: “Export last month's report.”
Use /capture-cr, then /grill-cr one question at a time. Recommend an answer,
but wait for me on every product choice. Produce the spawns/amends impact set
and stop before confirmation. Do not make architecture or code decisions.

After confirmation:

Realize the confirmed impacts with /shape-requirement. For amendments, use the
versioned req edit transaction; never hand-edit an active or baselined page.
Run /ba-lint. Prepare the smallest coherent WP and ask me to approve its plan.
The current release requires wp/<WP>/plan.md but has no BA skill that authors it:
stop until I identify its owner and the file exists. Only after explicit approval,
emit the BA-to-Architect handoff.

Expected boundary: wp/<WP>/handoffs/ba-architect.handoff.json.

Architect — product canon

/session-start
I am the Architect in <product-path>. I have only the Architect harness.
Open the BA-created wp/WP-20260914-002/ and its
wp/WP-20260914-002/handoffs/ba-architect.handoff.json. Preserve its ID.
Run /intake-audit. If it is ready, map context and divergence points,
present real alternatives, apply the error-cost gate, and record only decisions
I choose. Map every incoming requirement ID to a design location, decision or
explicit N/A, ready feature, and verification point. Produce change-intent.json,
the context slice, and the Developer handoff. Do not edit requirements or code.

Expected boundary: design/<WP>/architect-developer.handoff.json with every feature ready for development.

Developer — code repository plus canon checkout

/session-start
I am the Developer. The code repository is <code-path>. The product canon
checkout is <product-path>. Canon WP: WP-20260914-002.
I have only the Developer source harness.
Open <product-path>/design/WP-20260914-002/architect-developer.handoff.json and run
/accept-work-package. Load stack rules from the code repository. Research only
inside the context slice and write a verifiable plan. Stop before implementation.

After plan approval:

Implement only the approved phases in <code-path>. Use TDD where the plan requires
it. Persist each phase result beside the design package, enter /repair-loop on
failure, and request an architecture deviation instead of changing a binding ADR.
Run /final-arbiter. When required checks pass, write the MR intention and Quality handoff.

Expected boundary: design/<WP>/dev/quality-handoff.json.

Quality — evidence and MR

I am using Quality Harness in <code-path> for the mapped Runtime WP.
Open the local design/<runtime-WP>/dev/quality-handoff.json and manifest.
Use the review-work-package skill. Check Runtime health and ensure the local
Quality service, then review this WP. Show the persisted review, actual test
results and findings. Do not change product source or apply a Jira outcome.
Show the Apply preview separately and wait for my approval.

Quality Harness reviews a selected work result through local Runtime. The separate private Quality Platform is planned to retain history for each project and support an overview across projects; scheduled customer evaluation is not established by the local review. Discuss Platform access.

Solo founder

A solo founder may install all three open harnesses. Keep the same boundaries: run separate BA, Architect, and Developer sessions; finish each durable handoff; and open the next role with only that role's mandate. Do not let one long chat substitute for the contracts above.

Team flow with Jira

The Jira lifecycle distinguishes the canon WP, the Runtime execution WP and Jira Task. Prepare the Runtime local files explicitly in the selected root; a sibling product checkout is not imported automatically. Record the mapping before claim.

The Jira lifecycle distinguishes two similarly named objects:

Object	Example	Meaning
Canon WP	wp/WP-20260914-002	A BA requirements package stored in the canon; the folder alone is not claimed
Runtime local WP	WP-20260914-002	An execution package with work-packages/<id>/manifest.json; Runtime resolves this ID or its mapped Jira key
Jira WP	PRX-4	An Architect-created execution package that a Developer claims

The intended Jira sequence is:

1. BA previews and applies the epic analysis.
2. Architect previews and materializes bounded Work Packages.
3. Developer checks status, claims one package, accepts its design, and plans.
4. Developer completes only after implementation and required evidence.
5. Quality verifies and returns or promotes the package.

Copy-ready Developer prompt:

/session-start
Work Package PRX-4. Re-read canonical members and exclude superseded work.
Show claim status. If unclaimed, ask Runtime to claim it.
Accept the design package and prepare the plan. Do not code before my approval.

If the claim is held by another actor, stop. The same actor may resume idempotently. Releasing another person's claim requires an explicit human decision.

Resume after interruption

Start with the role's resume skill:

Role	Skill	Reads
BA	resume-ba-work	canon state, WP state, pending acceptance marker
Architect	resume-architecture	audit, decisions, design package, handoff state
Developer	resume-work-package	claim, acceptance, plan, phase journal, repair state
Quality	resume-qa	Runtime state, WP, local report, review state

Ask the agent to report:

What is complete? What remains? Which gate is next? Which persisted artifact proves it?
Do not repeat a completed mutation.

Developer plan state survives context compression. BA acceptance also uses a pending marker, so a crash between baseline writes can be resumed without creating a second baseline.

Handle a failed handoff

• BA readiness fails: repair the canon or plan, then re-emit the BA handoff.
• Architect intake fails: return exact missing requirements or contradictions to BA.
• Developer acceptance fails: return the package to Architect; do not improvise outside it.
• A binding decision blocks implementation: issue request-architecture-deviation and wait.
• Verification fails: persist the fingerprint and use repair-loop; escalate repeated failures.
• Quality fails: create a return with findings tied to the WP and evidence.

Done means an artifact exists

Role	Completion evidence
BA	approved WP plus BA→Architect handoff; later, accepted baseline
Architect	decisions, bounded design package, Developer handoff
Developer	approved plan, green arbiter evidence, Quality handoff
Quality	local verification report or private review/audit record

The next role reads repository state and Jira. A summary in the previous chat is context, not proof.