Use this order for a new ProcessForge installation, workplace, and project:
- Install ProcessForge distribution.
- Verify ProcessForge itself.
- Run guided workplace setup by default for human-led setup, or direct
workplace-initonly for explicit automatic setup. - Configure path constants and roots.
- Configure knowledge roots, especially local documentation roots.
- Register tools and MCP servers.
- Create or import knowledge packages.
- Create reusable templates.
- Create platform contracts.
- Onboard project.
- Create run/task workflow.
- Create custom processes as needed.
Platform contract is not a primary resource. It is a composition over existing packages, templates, tools, MCP servers, processes, coding standards, and capabilities.
Do not start by creating a platform contract if its required packages, templates, or tools do not exist yet. Create or register the dependencies first, then create the platform contract.
Do not onboard a project until the workplace exists and the required workplace resources are created, registered, validated, or explicitly out of scope.
Base languages and web technologies are part of those dependencies. Model them as knowledge packages and capabilities, then include them from the platform contracts that need them.
Heavy local documentation and source trees stay outside public package manifests. Reference them through knowledge_roots.local-docs and package resources that use path_ref.
Do not copy the whole ProcessForge repository into .codex, .claude, .agents, or similar agent configuration folders.
Install ProcessForge once as a tool, initialize a workplace, and add a short instruction to the agent configuration telling it where ProcessForge is installed and that project-specific instructions live in .pf/START_AGENT_HERE.md.