Skip to main content

Configuration

PRAXIS is configured through the .praxis/task.yaml file in your project root, plus environment variables.

TaskSpec Format​

The TaskSpec is a YAML file that defines the task to be verified.

# .praxis/task.yaml
id: PRAXIS-2026-001
description: Add a health check endpoint to the API
human_approved: false
acceptance_criteria:
- id: AC-001
description: A GET /health endpoint returns 200
- id: AC-002
description: Response body includes {"status": "ok"}

Fields​

FieldTypeRequiredDescription
idstringautoAuto-generated task ID
descriptionstringyesWhat the task does
human_approvedboolyesMust be set to true by a human before verification
acceptance_criteriaarrayyesList of criteria that define completion

Acceptance Criteria​

Each criterion has:

FieldTypeDescription
idstringUnique identifier (e.g., AC-001)
descriptionstringWhat passes this criterion. Be specific.

Example: Multi-criteria Task​

id: PRAXIS-2026-003
description: Refactor the auth module to use async/await
human_approved: true
acceptance_criteria:
- id: AC-001
description: All auth routes use async handlers
- id: AC-002
description: No .then() or callback patterns remain in auth/
- id: AC-003
description: All existing tests pass after refactor
- id: AC-004
description: TypeScript strict mode compiles without errors

Evidence Store​

Evidence from verification runs is stored in .praxis/runs/<run-id>/evidence.jsonl. Each line is a JSON object with:

FieldDescription
gateWhich gate produced this evidence (evidence, exec, final)
typeEvidence type (git_diff, command_log, test_output, file_check)
timestampWhen the evidence was collected
dataThe evidence payload
passedWhether this piece of evidence passed its check

Environment Variables​

VariableDescriptionDefault
PRAXIS_HOMEPRAXIS data directory.praxis/
PRAXIS_LOG_LEVELLog level: debug, info, warn, errorinfo
PRAXIS_NO_COLORDisable colored outputfalse

Plugin Configuration (Future)​

The Claude Code plugin and other agent adapters will be configured through .praxis/plugins/. This is design-stage and not yet implemented in v0.1.

TaskSpec Best Practices​

  1. Be specific in criteria descriptions. Vague criteria produce vague verdicts.
  2. One concern per criterion. Don't bundle multiple requirements into one AC.
  3. Keep TaskSpecs focused. A single task should verify one logical unit of work.
  4. Always set human_approved: true. The kernel refuses to verify unapproved specs.
  5. Review and update. TaskSpecs are living documents — refine them as you learn what works.