Praxis

Praxis

Core principle

Route the person to the smallest lifecycle capability that changes the current outcome. Do not load or recreate the whole system for every task.

Praxis treats a workflow as a versioned operating model:

> Trigger → Evidence → Decisions → Actions → Deliverable → Verification → Durable learning

Route by lifecycle stage

| Current need | Use | |---|---| | Understand the person and their real work | praxis-interview | | Convert an approved profile into an architecture | praxis-blueprint | | Create vault files and personalized skills | praxis-setup | | Preserve useful residue from completed work | praxis-distill | | Review evidence and improve the operating system | praxis-retrospective | | Create or evolve a reusable skill | praxis-skill-forge | | Materialize an approved contract for a named model | Optional prompt-polish companion, when installed or explicitly requested |

When more than one stage is requested, preserve this order:

interview → blueprint approval → setup → real use → distillation → retrospective → skill evolution

Routing procedure

1. Inspect the conversation and available artifacts. Reuse facts already known.
2. Identify the current lifecycle stage and the deliverable the user expects now.
3. Load only the matching skill.
4. State the route in one sentence, then execute it.
5. When the selected skill reaches an approval gate, stop. Do not silently continue into the next stage.

Optional Prompt Polish handoff

Praxis owns intent, workflow structure, deliverables, quality gates, and human approval boundaries. When those are already approved and the user names a target model, prompt-polish may optionally turn that stable contract into a model-specific execution prompt.

Use the companion only when it is installed or explicitly requested. Pass the approved contract, target model, task form, constraints, and done-condition. Never ask Prompt Polish to invent or redefine the workflow, and never make core Praxis operation depend on it.

Hard gates

• Do not scaffold a workflow before the profile and blueprint are approved.
• Do not create a new skill merely because a task exists once.
• Do not write raw transcripts into durable memory.
• Do not move, rename, delete, or overwrite a person's existing vault by default.
• Do not treat third-party skills as trusted because they are popular.
• Do not automate an action beyond the person's approved risk boundary.

Existing-system mode

When the person already has a vault, prompts, SOPs, or skills:

1. inventory what exists;
2. infer the current architecture and naming conventions;
3. identify strengths worth preserving;
4. locate duplication, missing gates, stale references, and retrieval failures;
5. propose an augmentation path rather than a replacement.

Completion contract

A routed Praxis task is complete when:

• the correct lifecycle skill was used;
• its artifact or decision was produced;
• unresolved assumptions are visible;
• any required human approval was obtained;
• the next lifecycle stage is named but not automatically executed.

Common routing mistakes

| Mistake | Correction | |---|---| | Asking the entire interview in one message | Use praxis-interview; one consequential question per turn. | | Creating folders before understanding the work | Blueprint and approval first. | | Building a giant profession persona | Generate a small skill graph from work streams and shared primitives. | | Saving everything as memory | Distill only future-useful residue. | | Editing skills based on taste | Use evidence and praxis-skill-forge. | | Loading every skill “just in case” | Route narrowly; progressive disclosure is part of the architecture. |

See [references/lifecycle.md](references/lifecycle.md) for the artifact contracts between stages.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: mfarzanansari
• Source: mfarzanansari/praxis-workflow-os
• License: MIT

Install and usage instructions live in the source repository linked above.