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.