Contribution instructions for Praxis, a project that develops reusable skills for AI coding agents. It defines the required structure for skills and their documentation, including rules for keeping project-specific details out of shared code.
A process for having several independent reviewers inspect the same project evidence and report possible problems. The main agent then decides which findings are valid against the project's official specifications.
A planning tool that scans an existing codebase and creates a central plan for rebuilding its documentation in seven layers. It treats code as evidence about the current system, not as the final authority.
A pre-coding planning skill that creates a file-by-file construction guide for a software task. It records what will change, key implementation risks, work slices, and how the result will be checked.
A safety check for deciding when an AI agent may split work among several helper agents or start a deep research workflow. It distinguishes bounded tasks with a known number of steps from open-ended or recursive work that can keep expanding.
A method for reconstructing product-requirements documents from existing code, especially when the original requirements are missing. It examines user interfaces, backend behavior, data models, rules, permissions, and archived information before writing in business language.
A tool for managing Git worktrees, which are separate working folders linked to one Git repository. It supports working on branches in parallel and bringing their changes back to the main branch.
An execution charter for autonomous work after a specification has been frozen, defining the goal, boundaries, checks, recovery actions, and startup settings.
A one-time investigation method for turning an old, opaque codebase into a searchable knowledge base about business rules, stored data, and interfaces.
A lightweight design-planning skill for resolving high-risk decisions before a coding task begins. It records the facts, affected areas, chosen decisions, and how those decisions map to requirements and acceptance checks.
A lightweight workflow for planning and completing small development tasks that involve decisions or new testing obligations. It records the chosen approach, the reason for it, and how the result will be checked.
Use when the user wants a master control document for a large, complex, long-running, or multi-session task. Defines how to create a task control doc that captures background, mandatory reads, subtask breakdown, and self-contained work packages so each subtask can be executed in a fresh session with minimal context.
A method for turning product and technical requirements into detailed tests with clear checks and links back to the original requirements. TDD means writing tests before implementation, but this add-on describes test design rather than test execution.