---
title: "Praxis for Developers"
route: "/for/developer"
template: role
intent: "Help a developer start implementation with decisions and acceptance already attached."
parent: "/for"
primaryCta: { label: "Read the Developer setup", href: "/docs/getting-started/cli" }
description: "Stop re-reading chat transcripts to trust the work. Praxis hands a developer a resolved package — requirement, design, contracts, budgets — and closes on evidence a person can inspect."
schemaType: WebPage
personaAngle: "Pain → why → solution → how → case → proof: package in, working feature out, verdict instead of vibe"
hero:
  eyebrow: "For Developer"
  headline: "Start coding with the decisions already attached."
  sub: "Most AI tooling promises speed and hands you a transcript. Praxis hands you a resolved package — requirement, design, contracts, budgets — and closes on evidence a person can inspect."
  primaryCta: { label: "Read the Developer setup", href: "/docs/getting-started/cli" }
  secondaryCta: { label: "Docs", href: "/docs" }
sections:
  - { id: pain, kind: pain, heading: "Less hype, more checkable work" }
  - { id: why-prompts-are-not-a-package, kind: explanation, heading: "Why a faster assistant isn't enough" }
  - { id: bounded-input, kind: flow, heading: "You become the product engineer" }
  - { id: evidence-output, kind: cards, heading: "What you actually get" }
  - { id: proof, kind: proof, heading: "Proof you can open" }
  - { id: next-step, kind: cta, heading: "Install it and see" }
---

## Less hype, more checkable work

A fast patch is hard to trust when you have to reconstruct acceptance from a transcript. You need to know which work package is current, what the Architect decided, which repository is in scope and what evidence the next reviewer expects.

## Why a faster assistant isn't enough

The handoff may reference files in a separate product repository. Neither a ticket link nor a handoff JSON alone makes those files available. Before coding, inspect the selected package, its referenced design and the local code context. Resolve missing or stale inputs with the owner.

## You become the product engineer

Receive Architect's prepared WP, connect the chosen code checkout, and confirm the package identity and acceptance. Research the affected code, plan the bounded change, implement it, then record the commands and results that actually ran. Request Quality Harness review of the result. Applying that review and publishing with Git are separate decisions; publication leaves a PR or MR awaiting review and merge.

## What you actually get

- **Linked input** — accepted scope, selected decisions, contracts and constraints rather than a bare ticket.
- **Repository choice** — a source-tool path can read a separate design directory; current Runtime expects its design and manifest inputs in the selected `repo`. The handoff requires explicit preparation.
- **Conditional assistance** — use research and specialist agents when needed. No fixed six-agent launch applies to every request.
- **Evidence with limits** — show passed, failed and skipped checks for this operation. No universal verdict or automatic commit pin is promised.

### The case

[Digital Winery](/cases/digital-winery) illustrates why product intent and implementation need a durable connection; it is not evidence that today's Runtime operated the historical project.

## Proof you can open

Open the WP and its referenced files, the code diff, the implementation record and the Quality findings. Confirm which approval remains before publishing or applying a result.

## Install it and see

Start with the [Claude Code CLI setup](/docs/getting-started/cli), or use the [Developer workflow guide](/docs/plugins/developer) for the documented local path.