Praxis

Appearance

Work as Developer only ​

The Developer works in the code checkout. Two supported recipes have different inputs and tools. A Jira URL or sibling product checkout is not, by itself, a prepared Runtime execution package.

Local source-tool recipe ​

Prerequisites: an authorized Developer source checkout with its tracked package-lock.json and vendor/*.tgz, Node.js 20 or newer, a code checkout at <code-path>, and a reviewed product checkout containing design/WP-20260914-002/ with the Architect handoff, change spec, context slice and linked decisions/requirements. Run npm ci from the Developer source root before using its executables. The installed Skills ZIP alone does not provide accept-work-package.mjs or run-work-package.mjs. The source install may also need registry access for locked dependencies; follow CLI installation for the checked release and role setup.

For a Claude Code session using that source plugin, start Claude from the code checkout after installation:

bash
cd <code-path>
claude --plugin-dir <developer-source>/plugins/developer

Check plugin discovery separately from Runtime MCP connectivity. Supply the external product path in the opening prompt below; loading the plugin does not import the product repository.

From the code checkout, inspect and accept the external package:

bash
node <developer-source>/plugins/developer/tools/accept-work-package.mjs \
  --arch-handoff <product-path>/design/WP-20260914-002/architect-developer.handoff.json \
  --design-dir <product-path>/design/WP-20260914-002
node <developer-source>/plugins/developer/tools/run-work-package.mjs \
  --arch-handoff <product-path>/design/WP-20260914-002/architect-developer.handoff.json \
  --design-dir <product-path>/design/WP-20260914-002 \
  --product <code-path>

The first command writes dev/acceptance.md under the design directory. The second prepares a plan and stops before implementation. After reviewing that plan, rerun the second command with --approve; it changes the code checkout and writes dev/ evidence and dev/quality-handoff.json under the external design directory. Review and stage files in each repository explicitly. Missing or stale references require an Architect refresh and a new acceptance check.

text
I am the Developer. Code checkout: <code-path>. Prepared canon design:
<product-path>/design/WP-20260914-002. Use the source-tool workflow.
Validate the handoff and every referenced file first. Show resolved read,
code-write and evidence-write paths plus blockers and a plan before coding.
Do not change BA requirements or accepted design decisions.

Current Runtime/Jira recipe ​

Prerequisites: Developer role ZIP, connected Runtime, configured Jira when this workflow uses it, and a complete local work-packages/<runtime-WP>/manifest.json plus design and referenced inputs at the selected Runtime root. Record canon WP ↔ Runtime WP ↔ Jira key mapping. Runtime searches the selected local project root; it does not import the sibling product checkout automatically. See CLI setup for terminal users.

Start Developer Status for the local WP or mapped Jira key. Verify manifest, claim and design files. Preview/approve claim, plan bounded code work, implement, and complete with evidence. Completion leaves Jira In Progress and qualityState=pending. Quality Harness Review and separately approved Apply follow; Git Delivery has its own commit, publish and PR/MR approvals and leaves the request awaiting review.

text
Use Developer Status in <code-path> for <runtime-WP-or-mapped-Jira-key>.
Verify the local manifest, design package, referenced files and canon mapping.
Show missing inputs and current claim. Do not reconstruct design from Jira or
import a sibling repository silently. Propose the next action and its approval.

See the Developer playbook and resume guide.