So, for a while I’ve been working on my own harness, which was fun and interesting, but ultimately there comes a point where you have to admit defeat and just start using something a bit more serious (ever tried to write your own search engine?).
In my case I’ve decided to start using pi as a frontend for DeepClause. The result is the new DeepClause extension for pi.
Installation is easy:
pi install git:github.com/deepclause/deepclause-pi
Before you start using DeepClause from a project, you need to initialize the .pi/deepclause folder using the “/dc” command. Then you’re ready to go!
In the following I will now briefly describe the two main use cases for this extension:
Creating and running small agentic automations (Run DML from Pi)
Controlling pi using logic programs as executable plans (Run Pi from DML)
If you like deepclause and the deepclause pi extension, please consider starring the projects on github.
https://github.com/deepclause/deepclause-pi
https://github.com/deepclause/deepclause-sdk
Use Case 1: Running DML inside pi for automating common workflows
DML (DeepClause Meta Language) is a small DSL that can be used to encode agents and agentic workflows as small executable logic programs. For some more background, please take a look at some recent posts, such as this one.
DML programs meant to be executed by pi live in .pi/deepclause/skills/ and can be run with a slash command:
/dc-run exampleThe extension uses the model currently selected in pi. It does not ask for another API key or try to guess the provider. Model calls, cancellation, input prompts and usage stay connected to the current pi session.
A minimal DML file (or “compiled skill”):
agent_main(Topic) :-
system("You are a concise technical analyst."),
format(string(Request),
"Explain ~w. Store the final explanation in Summary.",
[Topic]),
task(Request, string(Summary)),
answer(Summary).
Run it as follows:
/dc-run skills/explain.dml "constraint logic programming"Once you have the extension installed, pi will also know about how to write DML programs via a conjext injection. So you can directly ask it to e.g implement a lot of recurring workflows as DML!
Use Case 2: Executable Plans from Specs
There have been a lot of discussions around “Spec Driven Development”, “Software Factories”, “Loop Engineering” etc. All of these approaches somehow aim at formalizing and automating the software development process.
However, what I always felt was a bit weird, is that whatever approach is chosen, the end result is a bunch of markdown plan files combined with the hope that the model/harness combination is smart enough to turn this into working software.
And to some extent the models and harnesses are good enough, that is if you pay enough money to Anthropic and OpenAI. However, even SOTA models do sometimes decide to go off the rails and once your agents are running it is often very hard to follow what’s going on. Also, the entire modern agentic development process is hardly reproducible.
So, if you’d like a bit more sanity in all of this, why not try turning your markdown specs into actual exectuable plans! Let’s explore how DeepCLause and pi can help with that!
deepclause-pi and /dc-plan + /dc-run
The extension adds this command:
/dc-plan <request> [--name=slug]
For example:
/dc-plan build a small Three.js Space Invaders game and verify it --name=threejs-space-invaders
This starts a normal pi turn. The planner will then start to understand the current project environment, read its instructions, see loaded skills and consider the currently active tools. It does not directly return a Markdown checklist and it does not generate arbitrary DML source in one shot.
Instead, the planning turn finishes by calling a temporary tool named dc_plan_commit. The tool accepts a typed plan specification with:
a title and objective
ordered steps
an executor for each step
exact required tool names
relevant pi skills
an expected result for every step
a fallback message
The extension validates this object and shows a preview. After user confirmation, it deterministically assembles the DML file, parses the generated program and writes it under .pi/deepclause/plans/ without overwriting an existing file.
This follows the same general idea as the planner used in my DeepPlanning experiments: ask the model for a constrained intermediate representation and let normal code produce the executable DML. This is generally simpler and more reliable than letting and LLM try to implement a plan (how would we test it anyways without executing the plan and potentially wasting a lot of tokens?).
A generated plan looks like this:
agent_main :-
output("Step 1/3: Inspect the workspace"),
exec(pi_agent_step(
instruction: "Inspect repository instructions and identify the target app.",
tools: ["bash", "read"],
expected: "A target directory and concrete implementation baseline.",
skills: []
), Step1Summary),
Step1Summary \= "",
output("Step 2/3: Implement the application"),
exec(pi_agent_step(
instruction: "Implement the agreed application and keep changes scoped.",
tools: ["read", "write", "edit"],
expected: "A runnable implementation with a concise change summary.",
skills: []
), Step2Summary),
Step2Summary \= "",
output("Step 3/3: Validate the result"),
exec(pi_agent_step(
instruction: "Run the relevant checks and fix implementation failures.",
tools: ["bash", "read", "write", "edit"],
expected: "Passing checks or a precise account of remaining failures.",
skills: []
), Step3Summary),
Step3Summary \= "",
answer([Step1Summary, Step2Summary, Step3Summary]).
The full file is executable.
What pi_agent_step does
pi_agent_step is the bridge between DML orchestration and a normal pi coding turn.
When the DML runtime reaches one of these calls, the extension:
checks that every named tool is installed and currently active
rejects DeepClause control tools to prevent recursive planning or execution
saves pi’s current active-tool set
temporarily activates only the tools named by the step
sends the instruction through a normal pi turn
captures the final textual summary and tool failures
restores the previous active-tool set on success, failure or cancellation
The important point is that pi still executes the turn. A third-party extension tool therefore keeps its own UI, approvals and policy. DeepClause only controls which tools are available to that particular step and what should happen next.
The user must start such a plan explicitly:
/dc-run plans/threejs_space_invaders.dml
Before execution, the extension shows the required tools and asks for confirmation.
Links
Repository: https://github.com/deepclause/deepclause-pi
DeepClause SDK: https://github.com/deepclause/deepclause-sdk