The user wants a structured implementation plan for creating chain recipe prompt files named with `c-` prefix instead of `p-`. They want 4 specific chains:
1. c-brainstorm -> c-plan -> c-test -> c-commit (design → plan → test → commit)
2. c-summarize -> c-diagnose -> c-debug -> c-test (understand → diagnose → fix → regression-test)
3. c-refactor -> c-test -> c-review -> c-commit (safe refactor → validate → review → commit)
4. c-secaudit -> c-review -> c-test (security-first review loop)

They also have questions:
2. what should I choose? (unsure about context handoff strategy)
3. use the slashed version but call the chain c- as in 1. (they want slash commands `/c-*` to invoke the chains)
4. explain `subagent: delegate`

I should produce a plan addressing all this. Since context-mode is active and I've already read the relevant files, I don't need to read more. I should use the codebase context I already have.

Key points to address:
- The existing `p-*.md` prompts are interactive parent-session templates. To chain them as subagent workflows, we can either:
  a) Add frontmatter to existing `p-*.md` to make them runnable via `/prompt-workflow` or `/chain-prompts`, OR
  b) Create new `c-*.md` wrapper files that reference the existing `p-*.md` content via the `chain:` frontmatter field

The user wants option (b): create `c-*.md` chain recipe files. The `chain:` frontmatter in pi-subagents lets you specify `chain: p-brainstorm -> p-plan -> ...` but the names refer to other prompt workflow files. Since they want `c-` chains, we could have:
- `c-design-build.md` with `chain: p-brainstorm -> p-plan -> p-test -> p-commit`
- `c-fix-commit.md` with `chain: p-summarize -> p-diagnose -> p-debug -> p-test`
- `c-refactor-commit.md` with `chain: p-refactor -> p-test -> p-review -> p-commit`
- `c-security-loop.md` with `chain: p-secaudit -> p-review -> p-test`

But wait - the `chain:` frontmatter in prompt-workflows.ts uses `splitPromptChain(workflow.chain)` and maps each step name to a workflow file found in the prompts directories. So the chain references other `.md` files by their base name (without .md). The existing `p-*.md` files would need to be loadable as prompt workflows.

However, the existing `p-*.md` files don't have `subagent:` frontmatter. The prompt-workflow adapter's `parseAgent` function defaults to `delegate` when `subagent` is not set or is `true`. So if no `subagent:` field, it defaults to `delegate`. That answers question 4: `subagent: delegate` is the default lightweight subagent that inherits parent model and has tools including edit/write/bash/etc.

Important issue: the existing `p-*.md` prompts are written to be run in the PARENT session, not as subagents. For example, `p-plan.md` says "Create a structured implementation plan for: ${@:-the current task}". If run as a subagent, the subagent will receive this as its task and will produce the plan. That's fine.

But the chain question is about context sharing. The subagent chain engine passes `{previous}` (the prior step's text response) to subsequent steps. However, the existing `p-*.md` templates don't reference `{previous}`. So each step would run with fresh context (if `fresh: true`) or forked context (if `fork: true`), but the prompt body doesn't instruct the agent to read/consume the previous output.

For the chains to be meaningful, we need the steps to share context. Options:
1. **Forked context** (`fork: true`): Each subagent inherits the parent conversation history. So when step 2 runs, it sees the user's original request AND step 1's output in the parent history (because step 1 was a subagent that returned output to the parent, which then queued step 2). Actually, in a chain, the chain runner executes steps sequentially and passes outputs. Forked context means the child session branches from the parent's persisted session, so it sees parent history up to the point of launch. Since chain steps are launched by the parent runner, each step sees the parent conversation including prior step outputs that were returned to the parent. This gives implicit context sharing.

2. **Fresh context** (`fresh: true`): Each child gets a minimal context. The chain runner passes `{previous}` as the prior step's output. But the prompt body doesn't use `{previous}`, so the child just gets the original task args. This breaks the chain.

3. **Hybrid**: Use `fresh: true` on the chain recipe but modify/wrap prompts to consume `{previous}`. This is more complex.

The user is unsure what to choose. I should explain the trade-offs clearly and recommend forked context for these chains because:
- It requires no changes to existing `p-*.md` bodies
- Each step naturally sees the accumulated conversation
- It's the simplest path to get working chains
- Downside: context bloat/cost. But for these short 3-4 step chains, it's acceptable.

Alternative: fresh context + wrapper prompts. More work but cleaner. Given the user wants minimal changes, recommend forked.

Wait, but there's a subtlety. The chain recipes use `chain: p-brainstorm -> p-plan -> ...`. The prompt-workflow code for `workflowParams` sets `context` from runtime options or workflow.context. For chain steps, `workflowChainStep` calls `workflowParams` which uses `runtime.fork ? "fork" : runtime.fresh ? "fresh" : workflow.context`. Since the chain step is derived from the target workflow (e.g., p-plan.md), it uses p-plan.md's context setting. If p-plan.md has no context setting, it defaults to no context field, which means the subagent tool's default context applies.

In pi-subagents, the default context for builtin agents like delegate is... let me check. The `delegate.md` agent has no `defaultContext`, so it uses whatever the subagent tool default is. The `subagent` tool defaults: if not specified, I believe it uses the agent's frontmatter `defaultContext` or the system default. The tool description says: "If omitted, each requested agent uses its own defaultContext; agents without defaultContext: 'fork' run fresh." Wait, looking at the tool description: "context: 'fresh' or 'fork' to branch from parent session. Explicit context overrides every child in the invocation. If omitted, each requested agent uses its own defaultContext; agents without defaultContext: 'fork' run fresh."

Hmm, that's a bit ambiguous. Looking at delegate.md: no `defaultContext`. So delegate would run fresh by default. But the ollama-orchestrator.md had `defaultContext: fresh`. The builtin agents like planner/worker/oracle have `defaultContext: fork`. The delegate agent does not specify, so it would default to fresh.

This means if we chain p-* prompts through the prompt-workflow adapter with default `subagent: delegate` and no context hint, each step runs fresh, and since the prompts don't use `{previous}`, the chain won't share context.

So we need to add `fork: true` to either:
- The existing p-*.md files (but user wants to keep p- as is maybe?), OR
- The c- chain recipe files? But the chain frontmatter derives context from each step workflow, not the recipe workflow. Looking at the code: `workflowChainStep` creates a ChainStep from `workflowParams(stepWorkflow, args, runtime)`. The `context` is determined by runtime options or `stepWorkflow.context` (the p-*.md file's context). The recipe workflow's context is NOT passed to chain steps.

Wait, let me re-read:
```typescript
function workflowParams(workflow: PromptWorkflow, args: string[], runtime: ReturnType<typeof parseRuntimeOptions>): SubagentParamsLike {
	const task = substituteArgs(workflow.body, args).trim();
	const context = runtime.fork ? "fork" : runtime.fresh ? "fresh" : workflow.context;
	return {
		agent: runtime.agentOverride ?? workflow.agent,
		task,
		...(context ? { context } : {}),
		...
	};
}
```

For a chain step, `workflow` is the step workflow (e.g. p-plan.md). `runtime` comes from the `/chain-prompts` command options or `/prompt-workflow` options. If no `--fork` or `--fresh` flag is passed, `context` falls back to `workflow.context` of the step (p-plan.md).

So to make the chain use forked context by default, we need to add `fork: true` to each p-*.md file used in chains.

But the user said: "create these mentioned chain recipes, but instead of p- use c-". This could mean they want the chain files to be named c-*.md but the steps still reference the p-*.md files. The user also said "use the slashed version but call the chain c- as in 1" which I interpret as: the slash command should be `/c-design-build` etc.

So the plan should be:
1. Create 4 new chain recipe files: `c-design-build.md`, `c-fix-commit.md`, `c-refactor-commit.md`, `c-security-loop.md` in `~/.pi/agent/prompts/`
2. Each recipe has frontmatter like:
   ```yaml
   ---
   description: Design, plan, test, and commit a feature
   argument-hint: "[task description]"
   chain: p-brainstorm -> p-plan -> p-test -> p-commit
   ---
   ```
   With maybe `subagent: true` or nothing (defaults to delegate).
3. To make steps share context, we need the existing p-*.md files to have `fork: true` in their frontmatter. This is a modification to existing files. Alternatively, we can create c- wrapper files that duplicate the p- content with fork: true, but that duplicates content.

Actually, wait. There's another option. The chain recipe itself could use the `chain:` field, and when invoked via `/prompt-workflow c-design-build`, the adapter reads the chain and executes each step. But as established, context is per-step. However, maybe forked context isn't strictly necessary if the chain engine itself passes the full previous output as part of the task template.

Looking at chain execution in `subagent-runner.ts`, the task template uses `{previous}` placeholder. For chain steps from prompt workflows, the task is the substituted body of the prompt. The body of p-plan.md is "Create a structured implementation plan for: ${@:-the current task}". When the chain runs, the task becomes that text (with args substituted). The `{previous}` is NOT inserted unless the prompt body contains `{previous}`.

Wait, looking at `workflowChainStep`, it returns:
```typescript
return {
	agent: params.agent ?? "delegate",
	task: params.task,
	...
};
```

The `params.task` is just the substituted body. There's no automatic prepending of previous output. So for fresh context, the chain steps don't see previous outputs.

Therefore, for the chains to work meaningfully with existing p-*.md bodies unchanged, we MUST use forked context. And to get forked context by default, we must add `fork: true` to the p-*.md files.

But is that safe? Adding `fork: true` to a prompt template frontmatter only affects how it runs when invoked via `/prompt-workflow` or as a chain step. It does NOT affect the normal `/p-plan` slash expansion in the parent session, because normal prompt template expansion doesn't read `fork`/`subagent`/`chain` — those are pi-subagents adapter extensions.

Wait, actually I should verify: when you type `/p-plan` in Pi, does it use the pi-subagents adapter or just expand the markdown into the editor? The pi-subagents README says: "It also includes a native prompt-workflow adapter for reusable subagent prompt templates... Then run it through the native adapter: `/prompt-workflow take-screenshot`". This suggests that `/prompt-name` still works the normal way (expanding into the editor/parent session), while `/prompt-workflow prompt-name` routes through the subagent adapter.

So adding `subagent:`/`fork:`/`chain:` frontmatter to p-*.md should not break `/p-plan`. It just enables them to also be used as subagent workflows.

Therefore, the plan should include:
- Add minimal frontmatter to p-*.md files used in chains: `subagent: true` (or omit, default is delegate anyway) and `fork: true`
- Create 4 c-*.md recipe files with `chain:` frontmatter
- Verify both `/p-plan` and `/c-design-build` work

Now, the user question 4: "i didnt get the one with the subagent: delegate explain please"

I should explain:
- `subagent:` in prompt frontmatter tells the pi-subagents native prompt-workflow adapter which agent role to use when running that prompt as a subagent.
- `delegate` is the built-in lightweight general-purpose subagent. It inherits the parent model, has read/bash/edit/write tools, and just executes the task directly.
- If `subagent` is omitted or set to `true`, the adapter defaults to `delegate`.
- So `subagent: delegate` means "run this prompt as a child subagent using the default flexible worker role".

For question 2: "what should i choose?" — I should recommend forked context with a clear explanation, and mention fresh+{previous} as the alternative if they want cleaner/cheaper chains later.

Question 3: "use the slashed version but call the chain c- as in 1." — This means the recipe files should be named `c-*.md` so they appear as `/c-*` slash commands (both in normal Pi prompt expansion and in `/prompt-workflow` listing). But since `chain:` frontmatter makes them chain recipes, invoking `/c-design-build` will expand the body, not run the chain. To run the chain, they'd use `/prompt-workflow c-design-build` or we could add body text that instructs the parent to run the chain? Hmm.

Wait, the slash command `/c-design-build` would just expand the markdown body into the editor as a normal prompt template. If the body says "Run the chain p-brainstorm -> p-plan -> p-test -> p-commit for: $@", then the parent agent sees that text and could invoke the chain. But that's not automatic.

Alternatively, the user might mean: they want to type `/c-design-build` and have it execute the chain. That requires the prompt to be recognized by the pi-subagents adapter, not just normal expansion. The `/prompt-workflow` command is what routes through the adapter. The `/c-design-build` without `/prompt-workflow` would just expand the body.

Hmm, but the pi-subagents prompt-workflow code registers `/prompt-workflow` and `/chain-prompts` commands. It does NOT make prompt templates with `chain:` frontmatter auto-execute as subagent chains when invoked via their normal `/name`. The normal `/name` expansion is handled by Pi core.

However, maybe we can make the body of c-*.md instruct the parent to run the chain via the subagent tool? Like:
```markdown
---
description: ...
argument-hint: ...
---
Run the prompt chain via: /chain-prompts p-brainstorm -> p-plan -> p-test -> p-commit -- $@
```

But that's just text expansion. The user (or parent agent) would need to actually run that command.

Actually, looking more carefully at the prompt-workflow code: `discoverPromptWorkflows` scans the prompts directories. Pi core also scans the same directories for normal prompt templates. So `c-design-build.md` will show up as both a normal prompt template (`/c-design-build`) and a prompt workflow (`/prompt-workflow c-design-build`). When invoked via `/c-design-build`, Pi core expands the body. When invoked via `/prompt-workflow c-design-build`, the adapter sees the `chain:` frontmatter and runs the chain.

So to "use the slashed version but call the chain c-", the user could type either:
- `/prompt-workflow c-design-build "task"` — runs the chain
- `/c-design-build "task"` — expands the body text (which could remind them to use `/prompt-workflow`)

Maybe the best approach is to put in the body a note that this is a chain recipe and should be invoked via `/prompt-workflow`. Or, we could omit the body entirely (or make it minimal) and rely on `/prompt-workflow`.

Actually, a better idea: the chain recipe file frontmatter can have `chain:` which is used by `/prompt-workflow`. The body can contain the human-readable expansion text for `/c-design-build` that explicitly says "Running chain: ..." but the chain is actually triggered via `/prompt-workflow`.

Hmm, but the user said "use the slashed version but call the chain c- as in 1." I think they mean: they want the slash command name to be `c-design-build` (not `p-design-build`), and they want it to run the chain. The pi-subagents adapter doesn't hijack normal slash expansion, so the practical answer is:
- Type `/prompt-workflow c-design-build "task"` to run the chain
- Optionally also create a normal `/c-design-build` prompt whose body tells you to run that command

Or, we could create a `c-design-build.md` with `chain:` frontmatter and the body could be empty/minimal. In Pi, if you type `/c-design-build`, it expands the body. If the body is empty, it might just send nothing or the filename. That's not useful.

I think the cleanest interpretation: the recipe files are named `c-*.md`, and they are invoked via `/prompt-workflow c-*` (or `/chain-prompts` for ad-hoc). The `/c-*` slash command exists as a normal prompt template too, but its body can be a helpful note.

Let me also reconsider: maybe we should NOT modify existing p-*.md files, and instead create c- wrapper files that duplicate the p- content with `fork: true`? But the user said "create chain recipes... instead of p- use c-". They likely mean the chain file names use c-, but the steps still reference p-*.

Actually, re-reading: "create these mentioned chain recipes, but instead of p- use c- (for chain)." This means the 4 chain recipe files should be named with c- prefix. It does NOT necessarily mean the individual steps should be renamed. The steps are still p-brainstorm, p-plan, etc.

And "use the slashed version but call the chain c- as in 1." — use slash commands, call them c-*.

OK so the plan is clear now.

Let me structure the response:

1. Goal — one sentence
2. Constraints — including the fact that p-*.md prompts are parent-session templates, pi-subagents adapter exists, chain frontmatter support, need fork context, etc.
3. Approach — create c-*.md chain recipe files with `chain:` frontmatter; add `fork: true` to the p-*.md files used as steps so each subagent inherits parent conversation; use `subagent: delegate` (or default).
4. Steps — numbered, actionable
5. Verification
6. Risks & Rollbacks
7. Open Questions — minimal since user has mostly answered them, but maybe ask about whether they want to modify existing p-*.md files or create c- wrapper copies

Actually, the user asked 4 questions embedded in their request. I should answer them within the plan, particularly in Approach/Open Questions. The plan format requires 7 sections, so I can address the questions in Approach (recommendation for #2), within steps (how to invoke), and Open Questions (anything remaining).

Wait, the user explicitly asked: "2. what should i choos? im unsure." This is about the context handoff strategy. I should give a clear recommendation in the Approach section.

"3. use the slashed version but call the chain c- as in 1." — I should explain how to invoke: `/prompt-workflow c-design-build "task"` or `/chain-prompts p-brainstorm -> p-plan -> p-test -> p-commit -- "task"`.

"4. i didnt get the one with the subagent: delegate explain please" — explain in Approach or a note.

I should also consider whether we can avoid modifying existing p-*.md files by adding `fork: true` to the chain recipe and expecting it to propagate. But as I established, the chain recipe's own `fork: true` does NOT propagate to chain steps. We need it on each step's workflow file (p-*.md) or we need to pass `--fork` on every `/prompt-workflow` or `/chain-prompts` invocation.

Could the c-*.md recipe body instruct the user to pass `--fork`? Like:
```markdown
Run this chain with forked context: /prompt-workflow c-design-build --fork "task"
```
But that's error-prone.

Alternatively, can we add `fork: true` to the c- recipe and have it work? No, because the adapter only uses `workflow.context` of the step workflow, not the recipe.

Wait, let me double-check. In `workflowChainStep`, it calls `workflowParams(stepWorkflow, args, runtime)`. The `context` is computed as:
```typescript
const context = runtime.fork ? "fork" : runtime.fresh ? "fresh" : workflow.context;
```
Here `workflow` is `stepWorkflow` (the p-* file). So the recipe's context is ignored.

But wait — when we invoke `/prompt-workflow c-design-build`, the code path is:
```typescript
if (workflow.chain) {
    const chainNames = splitPromptChain(workflow.chain);
    const chain = chainNames.map((stepName) => {
        const step = findWorkflow(workflows, stepName);
        ...
        return workflowChainStep(step, runtime.args, runtime);
    });
    await run({ chain, task: runtime.args.join(" "), ... }, ctx);
}
```

So `runtime` contains the parsed options from the invocation. If we pass `--fork`, `runtime.fork` is true, and ALL steps get forked context. So one option is to always invoke with `--fork`. But that's not "slashed version" friendly.

The better option is to add `fork: true` to each p-*.md used in chains. This is a small, safe change.

Another option: create c- wrapper files for each step too, like `c-brainstorm.md` that includes the same body as `p-brainstorm.md` but with `fork: true` and `chain: ...`? No, that would be confusing.

Actually, the simplest and most correct approach:
- Create c-*.md chain recipe files.
- Add `fork: true` to the p-*.md files used as chain steps.
- The chain recipe references the p-* files by name.

This means modifying existing files, but the modifications are only subagent-adapter metadata and don't affect normal `/p-*` usage.

Should we add `subagent: delegate` too? It's the default, so not strictly necessary, but being explicit helps. I recommend adding `subagent: true` or `subagent: delegate` to make the intent clear.

Wait, `subagent: true` is treated as `delegate` by `parseAgent`:
```typescript
function parseAgent(frontmatter: Record<string, string>): string {
	const subagent = stringField(frontmatter, "subagent");
	if (!subagent || subagent === "true") return "delegate";
	return subagent;
}
```
So `subagent: true` → delegate. `subagent: delegate` also → delegate. We can use either. Using `subagent: true` is simpler.

Now, what about the `chain:` field in c-*.md? The adapter reads `chain:` from frontmatter. So `c-design-build.md` frontmatter:
```yaml
---
description: Design → plan → test → commit
argument-hint: "[task or feature]"
subagent: true
fork: true
chain: p-brainstorm -> p-plan -> p-test -> p-commit
---
```

Wait, if c-design-build.md has `fork: true`, does that do anything? When invoked via `/prompt-workflow c-design-build`, the adapter sees `workflow.chain` and builds a chain. The recipe's own `subagent`/`fork`/`model` are NOT used because `workflowParams` is called on each step workflow, not the recipe. The recipe's body is not used as a task. Looking at the code, when `workflow.chain` is present:
```typescript
const chain = chainNames.map((stepName) => {
    const step = findWorkflow(workflows, stepName);
    if (!step) throw new Error(...);
    return workflowChainStep(step, runtime.args, runtime);
});
await run({ chain, task: runtime.args.join(" "), clarify: false, agentScope: "both", ...(runtime.bg ? { async: true } : {}) }, ctx);
```

So yes, the recipe's own `subagent`/`fork`/`model`/`skill`/`cwd`/`worktree` are ignored when `chain:` is present. Only `chain:` matters. We could still include them for documentation, but they have no effect. Better to keep the recipe frontmatter minimal:
```yaml
---
description: Design → plan → test → commit
argument-hint: "[task or feature]"
chain: p-brainstorm -> p-plan -> p-test -> p-commit
---
```

And put invocation guidance in the body for when someone types `/c-design-build`:
```markdown
Chain recipe. Run via: /prompt-workflow c-design-build "task"
Or step-by-step: /chain-prompts p-brainstorm -> p-plan -> p-test -> p-commit -- "task"
```

Actually, if the body is just informational, typing `/c-design-build` would paste that into the editor. That's not bad — it reminds the user how to run it. But it doesn't run the chain automatically.

Alternatively, we could put in the body a direct instruction that the parent agent would execute:
```markdown
Run the chain /prompt-workflow c-design-build for: $@
```
But that still requires the user/agent to run the command.

Given pi's architecture, there's no way to make `/c-design-build` automatically run a subagent chain without modifying Pi core or creating an extension. So `/prompt-workflow c-design-build` is the correct invocation.

Let me also think: could we use the existing `/chain-prompts` command with the c- names? `/chain-prompts` only works with individual prompt workflow names, not chain recipes. So `/chain-prompts c-design-build` wouldn't work because `c-design-build` is itself a chain recipe, not a single step. We could only do `/chain-prompts p-brainstorm -> p-plan -> ...`.

OK, I have enough understanding. Let me also verify a few more things from the codebase quickly. Actually, I've already read the key files. I can just write the plan now.

Wait, the session state says `<session_mode>investigate</session_mode>` and context-mode is active. I should maybe use `ctx_execute` or `ctx_batch_execute` if I need to process anything, but I don't need to — I can just produce the plan based on what I've read. The user asked not to write implementation code yet, only the plan.

I should be concise but complete. Since the user asked the same question in two turns (first general, now specific), I should produce the plan addressing the specific requirements.

Let me draft the plan.

One more consideration: should the p-*.md modifications include only the 10 prompts used in the 4 chains? Let's map:
- c-design-build: p-brainstorm, p-plan, p-test, p-commit
- c-fix-commit: p-summarize, p-diagnose, p-debug, p-test
- c-refactor-commit: p-refactor, p-test, p-review, p-commit
- c-security-loop: p-secaudit, p-review, p-test

All p-* prompts in the directory are used except... actually all 12 are used. p-doc and p-explain are not used in these chains. We could add metadata to all for consistency, or only to the ones in chains. For the plan, I recommend adding to all 12 for consistency and future-proofing, but it could be scoped to just the chain participants. I'll mention this as a decision point.

Also: `p-commit.md` says "Generate a commit message for: ${@:-the current uncommitted changes (run git status / git diff first)}". When run as a subagent in a chain, the subagent will run git status/diff itself, which is good.

`p-test.md` says "Write tests for: ${@:-the current code or context}". In a chain, the previous step's output provides context via forked context, so it can infer what to test.

`p-refactor.md` explicitly says "Do not combine refactor with new features." That's fine.

`p-secaudit.md` is security review. Good.

`p-review.md` is general review. Good.

OK, plan draft:

Goal: Create four `c-*.md` subagent chain recipes in `~/.pi/agent/prompts/` that reuse the existing `p-*.md` prompts as sequential steps, using forked context so each step inherits the accumulated conversation.

Constraints:
- Existing p-*.md are parent-session prompt templates; they must remain usable via `/p-<verb>`.
- pi-subagents native prompt-workflow adapter reads `chain:` frontmatter and runs named prompts as subagent steps.
- Chain steps derive their context mode from the step workflow file, not the recipe file.
- Reserved names must be avoided.

Approach:
- Add minimal subagent metadata (`subagent: true`, `fork: true`) to all 12 p-*.md files (or at least the chain participants). This makes them runnable as forked-context subagents without changing their standalone behavior.
- Create four new recipe files `c-design-build.md`, `c-fix-commit.md`, `c-refactor-commit.md`, `c-security-loop.md` with `chain:` frontmatter referencing the p-* steps.
- Recommend forked context because it requires no changes to prompt bodies; fresh+{previous} is the cleaner alternative if cost/context is a concern.

Steps:
1. Backup current prompts dir (git commit or copy).
2. Add `subagent: true` and `fork: true` to p-*.md frontmatter.
3. Create the four c-*.md recipe files with chain frontmatter and helpful body text.
4. Reload Pi (`/reload`) and list workflows (`/prompt-workflow list`).
5. Test `/p-plan` still works standalone.
6. Test `/prompt-workflow c-design-build "a toy feature"` in a scratch repo.
7. Inspect chain status and verify each step completed.
8. Run the other three chains.
9. Update `Doc/README.md`.
10. Commit changes.

Verification:
- `/prompt-workflow list` shows c-* recipes and p-* prompts with expected metadata.
- Standalone `/p-*` commands unchanged.
- Each chain completes all steps.
- Final step output references earlier steps.

Risks & Rollbacks:
- Frontmatter breaks normal slash expansion → test and rollback by removing metadata lines.
- Forked context bloat → switch to fresh + {previous} wrappers later.
- Chain step fails → chain stops; fix the step or split chain.

Open Questions:
- Should metadata be added to all 12 p-*.md or only the chain participants?
- Should we also create ad-hoc `/chain-prompts` aliases, or is `/prompt-workflow c-*` sufficient?
- Do you want async chains by default? (add `--bg` guidance)

And answer the user's questions inline:
- #2 recommendation: forked context
- #3: invoke via `/prompt-workflow c-design-build "task"`
- #4: explain `subagent: delegate`

The format must be exactly the 7 sections. I can weave answers into Approach and Open Questions.

Actually, the user wants the plan, not just answers. I should produce the full structured plan. The questions are answered within it.

Let me make sure I don't write implementation code. Just plan.

One final check: is `chain:` frontmatter in c-*.md enough, or do we also need `subagent:` in c-*.md? As established, `chain:` overrides and the recipe's own `subagent` is ignored. So c-*.md only needs `chain:`, `description`, `argument-hint`. The body can be informational.

Wait, but what about the `subagent: true` in p-*.md? The adapter needs to load them as prompt workflows. It will load them regardless of `subagent:` field; `subagent:` just determines the agent. Since the default is delegate, we could omit it. But including it makes the intent explicit.

Also, `fork: true` is critical. Without it, steps run fresh and don't share context.

Actually, one more subtle thing: the p-*.md files use `${@:-...}` for default args. When run through the adapter, `args` are passed and substituted. That's fine.

The chain recipe's `argument-hint` should probably be `[task]` since the same task is passed to all steps.

OK, I'm ready to write the final answer.

## Implementation Plan: Create `c-*` Subagent Chain Recipes Reusing `p-*` Prompts

### 1. Goal
Create four new `c-*.md` chain recipe files in `~/.pi/agent/prompts/` that run the existing `p-*.md` prompts as sequential `pi-subagents` workflows, while keeping the original `/p-<verb>` interactive prompts unchanged.

### 2. Constraints
- The existing `p-*.md` files are parent-session prompt templates; their standalone behavior via `/p-brainstorm`, `/p-plan`, etc. must not break.
- `pi-subagents` is installed and provides the native prompt-workflow adapter:
  - `/prompt-workflow <name> [args]` runs a prompt as a subagent step.
  - `/chain-prompts a -> b -> c -- args` runs prompts as an ad-hoc chain.
  - The adapter reads `chain:` frontmatter to build a saved chain.
- **Chain steps inherit their context mode from the step workflow file**, not from the recipe file. So the `p-*.md` files used as steps need explicit context metadata.
- Prompt frontmatter uses shell-style argument substitution (`$@`, `${@:-...}`) which the adapter also supports.
- Recipe file names must not collide with reserved `pi-subagents` command names (`chain-prompts`, `prompt-workflow`, `run`, `chain`, `parallel`, `run-chain`, `subagents-doctor`, `subagents-models`).

### 3. Approach

**Recommended context strategy: forked context.**
Each step in a chain needs to see what the previous step produced. The two ways to achieve this are:

| Strategy | How it works | Pros | Cons |
|---|---|---|---|
| **Forked context** (`fork: true` on each step) | Each subagent branches from the parent session and inherits the full conversation, including earlier step outputs. | No changes to existing prompt bodies; works immediately. | Higher context/cost because each child carries prior turns. |
| **Fresh context + `{previous}`** | Each child starts clean and the chain runner injects the prior step's text as `{previous}`; prompts must explicitly consume it. | Leaner, more focused subagents. | Requires editing every `p-*.md` body to reference `{previous}`, or creating wrapper files. |

For these four short chains, **forked context is the pragmatic choice**: it preserves the existing prompts exactly and is reliable from day one. You can migrate to fresh+`{previous}` later if context cost becomes a problem.

**What `subagent: delegate` means:**
In a prompt frontmatter, `subagent:` tells the `pi-subagents` prompt-workflow adapter which agent role should execute the prompt. `delegate` is the built-in lightweight general-purpose subagent — it inherits the parent model, has `read/bash/edit/write/contact_supervisor`, and simply executes the task. If you write `subagent: true` or omit the field entirely, the adapter also defaults to `delegate`. So `subagent: delegate` just means “run this prompt as a plain child subagent.”

**How to invoke the chains:**
Because normal Pi slash expansion (`/c-design-build`) just pastes the markdown body into the editor, the actual chain execution must go through the adapter:

- `/prompt-workflow c-design-build "task"`
- `/prompt-workflow c-fix-commit "weird behavior"`
- `/prompt-workflow c-refactor-commit "src/utils.ts"`
- `/prompt-workflow c-security-loop "auth endpoint"`

You can also run the same sequence ad-hoc with:
`/chain-prompts p-brainstorm -> p-plan -> p-test -> p-commit -- "task"`

### 4. Steps

1. **Snapshot the current prompts directory.**
   Commit the existing state of `~/.pi/agent/prompts/` so any frontmatter additions are easy to revert.

2. **Add minimal subagent metadata to the `p-*.md` files used in chains.**
   Insert two lines into the YAML frontmatter of the relevant prompts (all 12 for consistency, or only the 10 that appear in chains):
   ```yaml
   subagent: true
   fork: true
   ```
   This makes each prompt runnable as a forked-context subagent step without changing its normal `/p-<verb>` behavior.

3. **Create the four chain recipe files** in `~/.pi/agent/prompts/`:
   - `c-design-build.md` — `chain: p-brainstorm -> p-plan -> p-test -> p-commit`
   - `c-fix-commit.md` — `chain: p-summarize -> p-diagnose -> p-debug -> p-test`
   - `c-refactor-commit.md` — `chain: p-refactor -> p-test -> p-review -> p-commit`
   - `c-security-loop.md` — `chain: p-secaudit -> p-review -> p-test`

   Each recipe frontmatter should contain `description`, `argument-hint`, and `chain:`. The body can be a short reminder of how to run it via `/prompt-workflow`.

4. **Reload Pi resources.**
   Run `/reload` in Pi, then `/prompt-workflow list` and confirm all four `c-*` recipes appear plus the `p-*` prompts show `subagent: true` / `fork: true` metadata.

5. **Verify standalone prompts still work.**
   Type `/p-plan "test task"` and confirm it expands normally in the parent session.

6. **Dry-run the first chain in a scratch repo.**
   Run `/prompt-workflow c-design-build "a tiny CLI flag feature"` in an empty or throwaway git repo. Inspect progress with `/subagents-fleet` or `subagent({ action: "status" })`.

7. **Validate context flows between steps.**
   Check that `p-plan`'s output references alternatives from `p-brainstorm`, that `p-test` refers to the planned implementation, and that `p-commit` sees the resulting diff.

8. **Run the remaining three chains** with trivial inputs to confirm they all complete without “Unknown prompt workflow” or context errors.

9. **Update `Doc/README.md`.**
   Add a “Chaining prompts” subsection listing the four `/prompt-workflow c-*` recipes, their step sequences, and example invocations.

10. **Commit the dotfiles changes.**
   Stage and commit the new `c-*.md` files and the frontmatter additions to `p-*.md`.

### 5. Verification
- `/prompt-workflow list` shows `c-design-build`, `c-fix-commit`, `c-refactor-commit`, and `c-security-loop` with clear descriptions.
- The `p-*.md` entries in that list show `subagent: true` and `fork: true`.
- `/p-plan "test"` still expands as plain text in the parent session (no subagent launch).
- `/prompt-workflow c-design-build "test"` launches four sequential subagents, each appearing in `/subagents-fleet`.
- `subagent({ action: "status" })` reports each chain step as `complete`.
- The final chain output is coherent and references earlier steps.
- `Doc/README.md` renders correctly and the copied example commands work.

### 6. Risks & Rollbacks

| Risk | Mitigation / Rollback |
|---|---|
| Extra frontmatter breaks normal `/p-*` expansion | Test immediately after adding the two lines; rollback by reverting the frontmatter edit. |
| Forked context inflates token usage per chain | Accept for now; later migrate to fresh context with `{previous}` wrappers if needed. |
| A chain step fails and aborts the whole chain | Keep individual `/p-*` prompts available as fallbacks; fix the offending step in isolation. |
| Recipe names collide with reserved commands | Verify with `/prompt-workflow list`; rename if needed (`c-design-build` is safe). |
| `p-commit` or `p-test` subagent makes unexpected edits | Chains run sequentially with one writer at a time; review the diff before committing. |
| User forgets to use `/prompt-workflow` and types `/c-design-build` instead | The recipe body will contain a reminder; no accidental subagent launch occurs. |

### 7. Open Questions
1. **Scope of frontmatter additions:** Should `subagent: true` / `fork: true` be added to all 12 `p-*.md` files for consistency, or only the 10 that participate in the four chains?
2. **Async by default:** Do you want the recipes to recommend adding `--bg` so chains run in the background, or keep them foreground by default?
3. **Fresh-context migration:** After the chains work, do you want a follow-up plan to convert them to leaner fresh-context wrappers with explicit `{previous}` handling?


only the individual prompts should be used as subagents
chains can run in the background
not yet


## Implementation Plan: Create `c-*` Subagent Chain Recipes Reusing `p-*` Prompts

### 1. Goal
Create four new `c-*.md` chain recipe files in `~/.pi/agent/prompts/` that run only the existing `p-*.md` prompts as sequential `pi-subagents` workflows, while keeping the original `/p-<verb>` interactive prompts unchanged.

### 2. Constraints
- The existing `p-*.md` files are parent-session prompt templates; their standalone behavior via `/p-brainstorm`, `/p-plan`, etc. must not break.
- `pi-subagents` is installed and provides the native prompt-workflow adapter:
  - `/prompt-workflow <name> [args]` runs a prompt as a subagent step.
  - `/chain-prompts a -> b -> c -- args` runs prompts as an ad-hoc chain.
  - The adapter reads `chain:` frontmatter to build a saved chain.
- **Only the individual prompts should be used as subagents** — recipe files are just orchestration wrappers, not delegated agents.
- **Chains can run in the background** — recipe files should set `async: true` in frontmatter so `/prompt-workflow c-*` detaches by default.
- Prompt frontmatter uses shell-style argument substitution (`$@`, `${@:-...}`) which the adapter also supports.
- Recipe file names must not collide with reserved `pi-subagents` command names (`chain-prompts`, `prompt-workflow`, `run`, `chain`, `parallel`, `run-chain`, `subagents-doctor`, `subagents-models`).

### 3. Approach

**Context strategy: forked context.**
Each step in a chain needs to see what the previous step produced. The two ways to achieve this are:

| Strategy | How it works | Pros | Cons |
|---|---|---|---|
| **Forked context** (`fork: true` on each step) | Each subagent branches from the parent session and inherits the full conversation, including earlier step outputs. | No changes to existing prompt bodies; works immediately. | Higher context/cost because each child carries prior turns. |
| **Fresh context + `{previous}`** | Each child starts clean and the chain runner injects the prior step's text as `{previous}`; prompts must explicitly consume it. | Leaner, more focused subagents. | Requires editing every `p-*.md` body to reference `{previous}`, or creating wrapper files. |

For these four short chains, **forked context is the pragmatic choice**: it preserves the existing prompts exactly and is reliable from day one. You can migrate to fresh+`{previous}` later if context cost becomes a problem.

**What `subagent: true` on a `p-*.md` means:**
When a prompt template has `subagent: true` in its frontmatter, the `pi-subagents` prompt-workflow adapter knows it can be delegated to a child Pi session rather than pasted into the parent editor. `subagent: true` is the same as `subagent: delegate` — it uses the built-in lightweight general-purpose subagent that inherits the parent model, has `read/bash/edit/write/contact_supervisor`, and simply executes the task. The recipe file only declares `chain: p-foo -> p-bar`; the adapter automatically turns each step into a `delegate` subagent call because the referenced prompts declare `subagent: true`.

**How to invoke the chains:**
Because normal Pi slash expansion (`/c-design-build`) just pastes the markdown body into the editor, the actual chain execution must go through the adapter:

- `/prompt-workflow c-design-build "task"`
- `/prompt-workflow c-fix-commit "weird behavior"`
- `/prompt-workflow c-refactor-commit "src/utils.ts"`
- `/prompt-workflow c-security-loop "auth endpoint"`

Because the recipe frontmatter sets `async: true`, these will detach by default. You can also run the same sequence ad-hoc with:

- `/chain-prompts p-brainstorm -> p-plan -> p-test -> p-commit --bg -- "task"`

### 4. Steps

1. **Snapshot the current prompts directory.**
   Commit the existing state of `~/.pi/agent/prompts/` so any frontmatter additions are easy to revert.

2. **Add minimal subagent metadata to the `p-*.md` files used in chains.**
   Insert two lines into the YAML frontmatter of the relevant prompts (the 10 that appear in the four chains):
   ```yaml
   subagent: true
   fork: true
   ```
   This makes each prompt runnable as a forked-context subagent step without changing its normal `/p-<verb>` behavior.

3. **Create the four chain recipe files** in `~/.pi/agent/prompts/`:
   - `c-design-build.md` — `chain: p-brainstorm -> p-plan -> p-test -> p-commit`
   - `c-fix-commit.md` — `chain: p-summarize -> p-diagnose -> p-debug -> p-test`
   - `c-refactor-commit.md` — `chain: p-refactor -> p-test -> p-review -> p-commit`
   - `c-security-loop.md` — `chain: p-secaudit -> p-review -> p-test`

   Each recipe frontmatter should contain `description`, `argument-hint`, `chain:`, and `async: true`. The body can be a short reminder of how to run it via `/prompt-workflow`.

4. **Reload Pi resources.**
   Run `/reload` in Pi, then `/prompt-workflow list` and confirm all four `c-*` recipes appear plus the referenced `p-*` prompts show `subagent: true` / `fork: true` metadata.

5. **Verify standalone prompts still work.**
   Type `/p-plan "test task"` and confirm it expands normally in the parent session.

6. **Dry-run the first chain in a scratch repo.**
   Run `/prompt-workflow c-design-build "a tiny CLI flag feature"` in an empty or throwaway git repo. Because the recipe has `async: true`, it will run in the background; inspect progress with `/subagents-fleet` or `subagent({ action: "status" })`.

7. **Validate context flows between steps.**
   Once the chain completes, check that `p-plan`'s output references alternatives from `p-brainstorm`, that `p-test` refers to the planned implementation, and that `p-commit` sees the resulting diff.

8. **Run the remaining three chains** with trivial inputs to confirm they all complete without “Unknown prompt workflow” or context errors.

9. **Update `Doc/README.md`.**
   Add a “Chaining prompts” subsection listing the four `/prompt-workflow c-*` recipes, their step sequences, example invocations, and a note that they run async by default.

10. **Commit the dotfiles changes.**
    Stage and commit the new `c-*.md` files and the frontmatter additions to `p-*.md`.

### 5. Verification
- `/prompt-workflow list` shows `c-design-build`, `c-fix-commit`, `c-refactor-commit`, and `c-security-loop` with clear descriptions and `async: true`.
- The referenced `p-*.md` entries in that list show `subagent: true` and `fork: true`.
- `/p-plan "test"` still expands as plain text in the parent session (no subagent launch).
- `/prompt-workflow c-design-build "test"` immediately returns control and launches the chain as a background run.
- `/subagents-fleet` shows four sequential subagent steps; `subagent({ action: "status" })` reports them as `complete`.
- The final chain output is coherent and references earlier steps.
- `Doc/README.md` renders correctly and the copied example commands work.

### 6. Risks & Rollbacks

| Risk | Mitigation / Rollback |
|---|---|
| Extra frontmatter breaks normal `/p-*` expansion | Test immediately after adding the two lines; rollback by reverting the frontmatter edit. |
| Forked context inflates token usage per chain | Accept for now; later migrate to fresh context with `{previous}` wrappers if needed. |
| A chain step fails and aborts the whole chain | Keep individual `/p-*` prompts available as fallbacks; fix the offending step in isolation. |
| Recipe names collide with reserved commands | Verify with `/prompt-workflow list`; rename if needed (`c-design-build` is safe). |
| `p-commit` or `p-test` subagent makes unexpected edits | Chains run sequentially with one writer at a time; review the diff before committing. |
| User forgets to use `/prompt-workflow` and types `/c-design-build` instead | The recipe body will contain a reminder; no accidental subagent launch occurs. |
| `async: true` frontmatter not honored by adapter | Verify with a dry run; if ignored, add `--bg` to the invocation or add `bg: true` instead. |

### 7. Open Questions
1. **Scope of frontmatter additions:** Should `subagent: true` / `fork: true` be added to all 12 `p-*.md` files for consistency, or only the 10 that participate in the four chains?
2. **Fresh-context migration:** After the chains work, do you want a follow-up plan to convert them to leaner fresh-context wrappers with explicit `{previous}` handling?


1. only the 10 that participate in the cahins
2. not yet


The user wants me to implement the plan now. They confirmed:
1. Only the 10 prompts that participate in chains get frontmatter
2. Not yet on fresh-context migration

So I need to:
1. Add `subagent: true` and `fork: true` to 10 p-*.md files:
   - p-brainstorm.md
   - p-plan.md
   - p-test.md
   - p-commit.md
   - p-summarize.md
   - p-diagnose.md
   - p-debug.md
   - p-refactor.md
   - p-review.md
   - p-secaudit.md
2. Create 4 c-*.md chain recipe files with async: true and chain: frontmatter
3. Update Doc/README.md

I should use edit tool to add frontmatter. Let me first read the current frontmatter structure of each file to make precise edits.

The 10 files are:
- p-brainstorm.md
- p-commit.md
- p-debug.md
- p-diagnose.md
- p-doc.md (not in chains - skip)
- p-explain.md (not in chains - skip)
- p-plan.md
- p-refactor.md
- p-review.md
- p-secaudit.md
- p-summarize.md
- p-test.md

Now I'll add `subagent: true` and `fork: true` to the frontmatter. The existing structure is:
```
---
description: ...
argument-hint: ...
---
```

I need to add:
```
---
description: ...
argument-hint: ...
subagent: true
fork: true
---
```

Then create the 4 chain recipe files. Each should have:
- description
- argument-hint
- chain:
- async: true

Body should explain how to run via /prompt-workflow.

I need to be careful with context-mode instructions. Since this is implementation (read/edit files), I should use ctx_execute_file? Actually, the instructions say "Read/edit files → ctx_execute_file". But I already read the files earlier. The edit tool is available. However, context-mode says to use ctx_execute_file when editing files? Let me check the hierarchy: ctx_batch_execute > ctx_execute > ctx_execute_file > ctx_search. Read/edit files → ctx_execute_file. But ctx_execute_file is for running code over a file, not editing. The edit tool is still needed for actual text replacement. I think context-mode means use ctx_execute_file for analysis of files, but edits still use edit tool.

Actually, the user's message just activated context-mode. The tool use policy says hierarchy. For editing files, I should probably still use the edit tool because ctx_execute_file is read-only (processes FILE_CONTENT and prints summary). So I'll use edit for the actual edits.

Let me proceed with edits. I'll do all 10 files with multiple edit entries in one call.

For each file, the oldText is:
```
---
description: ...
argument-hint: ...
---
```

And newText is:
```
---
description: ...
argument-hint: ...
subagent: true
fork: true
---
```

Wait, the argument-hint values are different for each file. I should use oldText unique to each. Let me get the exact frontmatter for each. I have them from earlier reads.

Then create 4 new files with write tool.

Let me do the edits first.

edit

---
description: Generate 3–5 design alternatives with trade-offs before committing to an approach
argument-hint: "[problem or feature to design]"
subagent: true
fork: true
---

---
description: Generate 3–5 design alternatives with trade-offs before committing to an approach
argument-hint: "[problem or feature to design]"
---


Successfully replaced 1 block(s) in /home/liph/dotfiles/pi/.pi/agent/prompts/p-brainstorm.md.

  1 ---
  2 description: Generate 3–5 design alternatives with trade-offs before committing to an approach
  3 argument-hint: "[problem or feature to design]"
+ 4 subagent: true
+ 5 fork: true
  4 ---
  5 Brainstorm approaches for: ${@:-the current problem or feature}
  6
  7 Structure your answer as:
    ...

--- /home/liph/dotfiles/pi/.pi/agent/prompts/p-brainstorm.md
+++ /home/liph/dotfiles/pi/.pi/agent/prompts/p-brainstorm.md
@@ -1,7 +1,9 @@
 ---
 description: Generate 3–5 design alternatives with trade-offs before committing to an approach
 argument-hint: "[problem or feature to design]"
+subagent: true
+fork: true
 ---
 Brainstorm approaches for: ${@:-the current problem or feature}

 Structure your answer as:


---
description: Generate a conventional commit message and optional PR description from current changes
argument-hint: "[diff, file list, or 'auto' to use git status]"
subagent: true
fork: true
---

---
description: Generate a conventional commit message and optional PR description from current changes
argument-hint: "[diff, file list, or 'auto' to use git status]"
---

---
description: Diagnose a failing test, build, or runtime error
argument-hint: "[error message, test name, or stack trace]"
subagent: true
fork: true
---

---
description: Diagnose a failing test, build, or runtime error
argument-hint: "[error message, test name, or stack trace]"
---

---
description: Diagnose unexpected behavior, not just failures (race conditions, perf regressions, weird output)
argument-hint: "[symptom or observed behavior]"
subagent: true
fork: true
---

---
description: Diagnose unexpected behavior, not just failures (race conditions, perf regressions, weird output)
argument-hint: "[symptom or observed behavior]"
---

---
description: Create a structured implementation plan before coding
argument-hint: "[task or feature]"
subagent: true
fork: true
---

---
description: Create a structured implementation plan before coding
argument-hint: "[task or feature]"
---

---
description: Safely restructure code without changing behavior
argument-hint: "[file path or symbol to refactor]"
subagent: true
fork: true
---

---
description: Safely restructure code without changing behavior
argument-hint: "[file path or symbol to refactor]"
---

---
description: Review code, diffs, or changes with actionable feedback
argument-hint: "[target: file path, diff, or PR]"
subagent: true
fork: true
---

---
description: Review code, diffs, or changes with actionable feedback
argument-hint: "[target: file path, diff, or PR]"
---

---
description: Security-focused review covering OWASP-style categories
argument-hint: "[file path, diff, or feature to audit]"
subagent: true
fork: true
---

---
description: Security-focused review covering OWASP-style categories
argument-hint: "[file path, diff, or feature to audit]"
---

---
description: Summarize a long file, log, diff, or document into structured notes
argument-hint: "[file path, log, or topic to summarize]"
subagent: true
fork: true
---

---
description: Summarize a long file, log, diff, or document into structured notes
argument-hint: "[file path, log, or topic to summarize]"
---

---
description: Write or expand unit / integration tests for the given code
argument-hint: "[file path, function, or feature to test]"
subagent: true
fork: true
---

---
description: Write or expand unit / integration tests for the given code
argument-hint: "[file path, function, or feature to test]"
---


Successfully replaced 1 block(s) in /home/liph/dotfiles/pi/.pi/agent/prompts/p-commit.md.

  1 ---
  2 description: Generate a conventional commit message and optional PR description from current changes
  3 argument-hint: "[diff, file list, or 'auto' to use git status]"
+ 4 subagent: true
+ 5 fork: true
  4 ---
  5 Generate a commit message for: ${@:-the current uncommitted changes (run git status / git diff first)}
  6
  7 Structure your answer as:
    ...

--- /home/liph/dotfiles/pi/.pi/agent/prompts/p-commit.md
+++ /home/liph/dotfiles/pi/.pi/agent/prompts/p-commit.md
@@ -1,7 +1,9 @@
 ---
 description: Generate a conventional commit message and optional PR description from current changes
 argument-hint: "[diff, file list, or 'auto' to use git status]"
+subagent: true
+fork: true
 ---
 Generate a commit message for: ${@:-the current uncommitted changes (run git status / git diff first)}

 Structure your answer as:


Successfully replaced 1 block(s) in /home/liph/dotfiles/pi/.pi/agent/prompts/p-debug.md.

  1 ---
  2 description: Diagnose a failing test, build, or runtime error
  3 argument-hint: "[error message, test name, or stack trace]"
+ 4 subagent: true
+ 5 fork: true
  4 ---
  5 Diagnose the following failure: ${@:-the current failing test or error}
  6
  7 Structure your answer as:
    ...

--- /home/liph/dotfiles/pi/.pi/agent/prompts/p-debug.md
+++ /home/liph/dotfiles/pi/.pi/agent/prompts/p-debug.md
@@ -1,7 +1,9 @@
 ---
 description: Diagnose a failing test, build, or runtime error
 argument-hint: "[error message, test name, or stack trace]"
+subagent: true
+fork: true
 ---
 Diagnose the following failure: ${@:-the current failing test or error}

 Structure your answer as:


Successfully replaced 1 block(s) in /home/liph/dotfiles/pi/.pi/agent/prompts/p-diagnose.md.

  1 ---
  2 description: Diagnose unexpected behavior, not just failures (race conditions, perf regressions, weird output)
  3 argument-hint: "[symptom or observed behavior]"
+ 4 subagent: true
+ 5 fork: true
  4 ---
  5 Diagnose the following unexpected behavior: ${@:-the current code or recent change}
  6
  7 Structure your answer as:
    ...

--- /home/liph/dotfiles/pi/.pi/agent/prompts/p-diagnose.md
+++ /home/liph/dotfiles/pi/.pi/agent/prompts/p-diagnose.md
@@ -1,7 +1,9 @@
 ---
 description: Diagnose unexpected behavior, not just failures (race conditions, perf regressions, weird output)
 argument-hint: "[symptom or observed behavior]"
+subagent: true
+fork: true
 ---
 Diagnose the following unexpected behavior: ${@:-the current code or recent change}

 Structure your answer as:


Successfully replaced 1 block(s) in /home/liph/dotfiles/pi/.pi/agent/prompts/p-plan.md.

  1 ---
  2 description: Create a structured implementation plan before coding
  3 argument-hint: "[task or feature]"
+ 4 subagent: true
+ 5 fork: true
  4 ---
  5 Create a structured implementation plan for: ${@:-the current task}
  6
  7 Follow this format:
    ...

--- /home/liph/dotfiles/pi/.pi/agent/prompts/p-plan.md
+++ /home/liph/dotfiles/pi/.pi/agent/prompts/p-plan.md
@@ -1,7 +1,9 @@
 ---
 description: Create a structured implementation plan before coding
 argument-hint: "[task or feature]"
+subagent: true
+fork: true
 ---
 Create a structured implementation plan for: ${@:-the current task}

 Follow this format:


Successfully replaced 1 block(s) in /home/liph/dotfiles/pi/.pi/agent/prompts/p-refactor.md.

  1 ---
  2 description: Safely restructure code without changing behavior
  3 argument-hint: "[file path or symbol to refactor]"
+ 4 subagent: true
+ 5 fork: true
  4 ---
  5 Refactor: ${@:-the current code or context}
  6
  7 Structure your answer as:
    ...

--- /home/liph/dotfiles/pi/.pi/agent/prompts/p-refactor.md
+++ /home/liph/dotfiles/pi/.pi/agent/prompts/p-refactor.md
@@ -1,7 +1,9 @@
 ---
 description: Safely restructure code without changing behavior
 argument-hint: "[file path or symbol to refactor]"
+subagent: true
+fork: true
 ---
 Refactor: ${@:-the current code or context}

 Structure your answer as:


Successfully replaced 1 block(s) in /home/liph/dotfiles/pi/.pi/agent/prompts/p-review.md.

  1 ---
  2 description: Review code, diffs, or changes with actionable feedback
  3 argument-hint: "[target: file path, diff, or PR]"
+ 4 subagent: true
+ 5 fork: true
  4 ---
  5 Review the following code or changes: ${@:-the current file / diff / staged changes}
  6
  7 Provide feedback in these categories:
    ...

--- /home/liph/dotfiles/pi/.pi/agent/prompts/p-review.md
+++ /home/liph/dotfiles/pi/.pi/agent/prompts/p-review.md
@@ -1,7 +1,9 @@
 ---
 description: Review code, diffs, or changes with actionable feedback
 argument-hint: "[target: file path, diff, or PR]"
+subagent: true
+fork: true
 ---
 Review the following code or changes: ${@:-the current file / diff / staged changes}

 Provide feedback in these categories:


Successfully replaced 1 block(s) in /home/liph/dotfiles/pi/.pi/agent/prompts/p-secaudit.md.

  1 ---
  2 description: Security-focused review covering OWASP-style categories
  3 argument-hint: "[file path, diff, or feature to audit]"
+ 4 subagent: true
+ 5 fork: true
  4 ---
  5 Security-audit: ${@:-the current code, diff, or feature}
  6
  7 Structure your answer as:
    ...

--- /home/liph/dotfiles/pi/.pi/agent/prompts/p-secaudit.md
+++ /home/liph/dotfiles/pi/.pi/agent/prompts/p-secaudit.md
@@ -1,7 +1,9 @@
 ---
 description: Security-focused review covering OWASP-style categories
 argument-hint: "[file path, diff, or feature to audit]"
+subagent: true
+fork: true
 ---
 Security-audit: ${@:-the current code, diff, or feature}

 Structure your answer as:


Successfully replaced 1 block(s) in /home/liph/dotfiles/pi/.pi/agent/prompts/p-summarize.md.

  1 ---
  2 description: Summarize a long file, log, diff, or document into structured notes
  3 argument-hint: "[file path, log, or topic to summarize]"
+ 4 subagent: true
+ 5 fork: true
  4 ---
  5 Summarize: ${@:-the current file or context}
  6
  7 Structure your answer as:
    ...

--- /home/liph/dotfiles/pi/.pi/agent/prompts/p-summarize.md
+++ /home/liph/dotfiles/pi/.pi/agent/prompts/p-summarize.md
@@ -1,7 +1,9 @@
 ---
 description: Summarize a long file, log, diff, or document into structured notes
 argument-hint: "[file path, log, or topic to summarize]"
+subagent: true
+fork: true
 ---
 Summarize: ${@:-the current file or context}

 Structure your answer as:


Successfully replaced 1 block(s) in /home/liph/dotfiles/pi/.pi/agent/prompts/p-test.md.

  1 ---
  2 description: Write or expand unit / integration tests for the given code
  3 argument-hint: "[file path, function, or feature to test]"
+ 4 subagent: true
+ 5 fork: true
  4 ---
  5 Write tests for: ${@:-the current code or context}
  6
  7 Structure your answer as:
    ...

--- /home/liph/dotfiles/pi/.pi/agent/prompts/p-test.md
+++ /home/liph/dotfiles/pi/.pi/agent/prompts/p-test.md
@@ -1,7 +1,9 @@
 ---
 description: Write or expand unit / integration tests for the given code
 argument-hint: "[file path, function, or feature to test]"
+subagent: true
+fork: true
 ---
 Write tests for: ${@:-the current code or context}

 Structure your answer as:


write

---
description: Brainstorm → plan → test → commit in one background chain
argument-hint: "[task or feature]"
chain: p-brainstorm -> p-plan -> p-test -> p-commit
async: true
---
Run the design → plan → test → commit chain for: ${@:-the current task}

Invoke with:
/prompt-workflow c-design-build "add a rate-limiter to the API"

---
description: Summarize → diagnose → debug → test in one background chain
argument-hint: "[symptom, error, or observed behavior]"
chain: p-summarize -> p-diagnose -> p-debug -> p-test
async: true
---
Run the understand → diagnose → fix → regression-test chain for: ${@:-the current unexpected behavior}

Invoke with:
/prompt-workflow c-fix-commit "the checkout intermittently times out"

---
description: Refactor → test → review → commit in one background chain
argument-hint: "[file path or symbol to refactor]"
chain: p-refactor -> p-test -> p-review -> p-commit
async: true
---
Run the safe refactor → validate → review → commit chain for: ${@:-the current code or context}

Invoke with:
/prompt-workflow c-refactor-commit "src/utils.ts"

---
description: Security audit → review → test in one background chain
argument-hint: "[file path, diff, or feature to audit]"
chain: p-secaudit -> p-review -> p-test
async: true
---
Run the security-first review loop for: ${@:-the current code or feature}

Invoke with:
/prompt-workflow c-security-loop "auth endpoint"


Successfully wrote 328 bytes to /home/liph/dotfiles/pi/.pi/agent/prompts/c-design-build.md


Successfully wrote 390 bytes to /home/liph/dotfiles/pi/.pi/agent/prompts/c-fix-commit.md


Successfully wrote 354 bytes to /home/liph/dotfiles/pi/.pi/agent/prompts/c-refactor-commit.md


Successfully wrote 321 bytes to /home/liph/dotfiles/pi/.pi/agent/prompts/c-security-loop.md


# Prompts

Slash-style prompts for the interactive pi session. Each file is a `p-<verb>.md` template with a frontmatter `description` + `argument-hint` and a structured body. Invoke with `:p-<verb> [arg]` or via the `:prompts` TUI picker.

## When to use which

| Prompt             | Use it when…                                                                                | Pairs well with                                         |
| ------------------ | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
| **`p-plan`**       | You're about to start a non-trivial change and want a structured plan before coding.                            | `p-brainstorm` (first), then `p-refactor` / `p-test`    |
| **`p-brainstorm`** | You have a problem but no chosen approach yet; want 3–5 alternatives with trade-offs.                           | `p-plan` (after picking one)                            |
| **`p-explain`**    | You don't understand a piece of code, a concept, or an error message.                                           | `p-debug` / `p-diagnose` (if it's a problem)            |
| **`p-debug`**      | A test, build, or command is failing with a clear error. You have the error in hand.                            | `p-test` (add a regression test after the fix)          |
| **`p-diagnose`**   | Nothing is "failing" but behavior is wrong — wrong values, races, perf drift, "passes locally, broken in prod." | `p-debug` (if you find a hard failure)                  |
| **`p-review`**     | You want a code review of a diff, file, or staged change. General quality feedback.                             | `p-secaudit` (security subset)                          |
| **`p-secaudit`**   | Touching auth, input handling, secrets, network, deserialization, or any trust boundary.                        | `p-review` (broader quality), `p-test`                  |
| **`p-refactor`**   | Restructuring code without changing behavior. Safety-first, mechanical steps.                                   | `p-test` (first, as the safety net), `p-review` (after) |
| **`p-test`**       | You need to write or expand tests for existing or new code.                                                     | `p-debug` (after a failure), `p-refactor` (before)      |
| **`p-doc`**        | Writing or improving README, docstrings, JSDoc, godoc, or ADRs.                                                 | `p-summarize` (skim the code first)                     |
| **`p-commit`**     | About to commit. You want a conventional message and (optionally) a PR description.                             | `p-review` (final check before committing)              |
| **`p-summarize`**  | A file, log, diff, or document is too long to read in full. You need the gist + key details.                    | `p-plan` / `p-debug` (then dive into specifics)         |

## Decision flow

```
Got an idea or vague problem?
└─ Yes → p-brainstorm  →  pick an approach  →  p-plan  →  implement
                                                          └─ p-test  →  p-commit
Touching existing code that needs to change?
└─ p-refactor (after p-test confirms a safety net)  →  p-review  →  p-commit
Something is broken?
├─ Hard failure (error message, failing test)  →  p-debug
└─ Soft failure (wrong output, race, perf)      →  p-diagnose
                                       →  fix  →  p-test (regression)  →  p-commit
Touching a trust boundary, auth, secrets, or untrusted input?
└─ p-secaudit  (then p-review for general quality)
Need to understand a long file/log/diff quickly?
└─ p-summarize
Need to write or update docs?
└─ p-doc
Don't know what something does or what an error means?
└─ p-explain
```

## Conventions

- Every prompt uses `${@:-<default>}` so it works with or without an argument.
- Output is structured (numbered sections, fixed categories) so the result is diff-friendly and skim-friendly.
- Prompts intentionally do **not** overlap with subagent workflows (`agents/`, `chains/`, `skills/`) — those are for orchestration; these are for interactive turns.
- Prefer one prompt per turn. Chain them yourself (`p-brainstorm` → `p-plan` → `p-refactor`) rather than asking one prompt to do everything.


edit

## Chain recipes

The `c-*` files are not prompts you run directly in the editor. They are orchestration recipes that run a sequence of `p-*` prompts through the `pi-subagents` prompt-workflow adapter. Each `p-*` step is executed as a forked-context subagent, so later steps can see earlier outputs. Chains run asynchronously by default.

| Recipe             | Sequence                                  | Use it when…                                                               |
| ------------------ | ----------------------------------------- | -------------------------------------------------------------------------- |
| **`c-design-build`** | `p-brainstorm → p-plan → p-test → p-commit` | You want to design a feature, plan it, add tests, and commit in one go.    |
| **`c-fix-commit`** | `p-summarize → p-diagnose → p-debug → p-test` | You need to understand a bug, diagnose it, fix it, and add regression tests. |
| **`c-refactor-commit`** | `p-refactor → p-test → p-review → p-commit` | You want a safe refactor with tests, review, and a commit.                  |
| **`c-security-loop`** | `p-secaudit → p-review → p-test`           | You need a security-first review plus tests before proceeding.             |

Invoke a chain with `/prompt-workflow`, not `/c-recipe`:

```text
/prompt-workflow c-design-build "add a rate-limiter to the API"
/prompt-workflow c-fix-commit "the checkout intermittently times out"
/prompt-workflow c-refactor-commit "src/utils.ts"
/prompt-workflow c-security-loop "auth endpoint"
```

Each chain runs in the background. Watch it with `/subagents-fleet` or check status with `subagent({ action: "status" })`. If you want to run the same sequence ad-hoc, use `/chain-prompts`:

```text
/chain-prompts p-brainstorm -> p-plan -> p-test -> p-commit -- "add a rate-limiter"
```

## Conventions

- Every prompt uses `${@:-<default>}` so it works with or without an argument.
- Output is structured (numbered sections, fixed categories) so the result is diff-friendly and skim-friendly.
- Prompts intentionally do **not** overlap with subagent workflows (`agents/`, `chains/`, `skills/`) — those are for orchestration; these are for interactive turns.
- Prefer one prompt per turn. Chain them yourself (`p-brainstorm` → `p-plan` → `p-refactor`) rather than asking one prompt to do everything.


Successfully replaced 1 block(s) in /home/liph/dotfiles/pi/.pi/agent/prompts/Doc/README.md.

    ...
 40 Don't know what something does or what an error means?
 41 └─ p-explain
 42 ```
 43
+44 ## Chain recipes
+45
+46 The `c-*` files are not prompts you run directly in the editor. They are orchestration recipes that run a sequence of `p-*` prompts through the `pi-subagents` prompt-workflow adapter. Each `p-*` step is executed as a forked-context subagent, so later steps can see earlier outputs. Chains run asynchronously by default.
+47
+48 | Recipe             | Sequence                                  | Use it when…                                                               |
+49 | ------------------ | ----------------------------------------- | -------------------------------------------------------------------------- |
+50 | **`c-design-build`** | `p-brainstorm → p-plan → p-test → p-commit` | You want to design a feature, plan it, add tests, and commit in one go.    |
+51 | **`c-fix-commit`** | `p-summarize → p-diagnose → p-debug → p-test` | You need to understand a bug, diagnose it, fix it, and add regression tests. |
+52 | **`c-refactor-commit`** | `p-refactor → p-test → p-review → p-commit` | You want a safe refactor with tests, review, and a commit.                  |
+53 | **`c-security-loop`** | `p-secaudit → p-review → p-test`           | You need a security-first review plus tests before proceeding.             |
+54
+55 Invoke a chain with `/prompt-workflow`, not `/c-recipe`:
+56
+57 ```text
+58 /prompt-workflow c-design-build "add a rate-limiter to the API"
+59 /prompt-workflow c-fix-commit "the checkout intermittently times out"
+60 /prompt-workflow c-refactor-commit "src/utils.ts"
+61 /prompt-workflow c-security-loop "auth endpoint"
+62 ```
+63
+64 Each chain runs in the background. Watch it with `/subagents-fleet` or check status with `subagent({ action: "status" })`. If you want to run the same sequence ad-hoc, use `/chain-prompts`:
+65
+66 ```text
+67 /chain-prompts p-brainstorm -> p-plan -> p-test -> p-commit -- "add a rate-limiter"
+68 ```
+69
 44 ## Conventions
 45
 46 - Every prompt uses `${@:-<default>}` so it works with or without an argument.
 47 - Output is structured (numbered sections, fixed categories) so the result is diff-friendly and skim-friendly.
    ...

--- /home/liph/dotfiles/pi/.pi/agent/prompts/Doc/README.md
+++ /home/liph/dotfiles/pi/.pi/agent/prompts/Doc/README.md
@@ -40,8 +40,34 @@
 Don't know what something does or what an error means?
 └─ p-explain
 ```

+## Chain recipes
+
+The `c-*` files are not prompts you run directly in the editor. They are orchestration recipes that run a sequence of `p-*` prompts through the `pi-subagents` prompt-workflow adapter. Each `p-*` step is executed as a forked-context subagent, so later steps can see earlier outputs. Chains run asynchronously by default.
+
+| Recipe             | Sequence                                  | Use it when…                                                               |
+| ------------------ | ----------------------------------------- | -------------------------------------------------------------------------- |
+| **`c-design-build`** | `p-brainstorm → p-plan → p-test → p-commit` | You want to design a feature, plan it, add tests, and commit in one go.    |
+| **`c-fix-commit`** | `p-summarize → p-diagnose → p-debug → p-test` | You need to understand a bug, diagnose it, fix it, and add regression tests. |
+| **`c-refactor-commit`** | `p-refactor → p-test → p-review → p-commit` | You want a safe refactor with tests, review, and a commit.                  |
+| **`c-security-loop`** | `p-secaudit → p-review → p-test`           | You need a security-first review plus tests before proceeding.             |
+
+Invoke a chain with `/prompt-workflow`, not `/c-recipe`:
+
+```text
+/prompt-workflow c-design-build "add a rate-limiter to the API"
+/prompt-workflow c-fix-commit "the checkout intermittently times out"
+/prompt-workflow c-refactor-commit "src/utils.ts"
+/prompt-workflow c-security-loop "auth endpoint"
+```
+
+Each chain runs in the background. Watch it with `/subagents-fleet` or check status with `subagent({ action: "status" })`. If you want to run the same sequence ad-hoc, use `/chain-prompts`:
+
+```text
+/chain-prompts p-brainstorm -> p-plan -> p-test -> p-commit -- "add a rate-limiter"
+```
+
 ## Conventions

 - Every prompt uses `${@:-<default>}` so it works with or without an argument.
 - Output is structured (numbered sections, fixed categories) so the result is diff-friendly and skim-friendly.


bash

cd /home/liph/dotfiles && git status --short


 M nvim/.config/nvim/lazy-lock.json
 D nvim/.config/nvim/lua/plugins/obsidian.lua
 D pi/.pi/agent/.pi-subagents/artifacts/187b7128_ollama-orchestrator_0_input.md
 D pi/.pi/agent/.pi-subagents/artifacts/187b7128_ollama-orchestrator_0_meta.json
 D pi/.pi/agent/.pi-subagents/artifacts/187b7128_ollama-orchestrator_0_output.md
 D pi/.pi/agent/.pi-subagents/artifacts/187b7128_ollama-orchestrator_0_transcript.jsonl
 D pi/.pi/agent/agents/.pi-subagents/artifacts/4059014e_ollama-planner_0_input.md
 D pi/.pi/agent/agents/.pi-subagents/artifacts/4059014e_ollama-planner_0_meta.json
 D pi/.pi/agent/agents/.pi-subagents/artifacts/4059014e_ollama-planner_0_output.md
 D pi/.pi/agent/agents/.pi-subagents/artifacts/4059014e_ollama-planner_0_transcript.jsonl
 D pi/.pi/agent/agents/.pi-subagents/artifacts/outputs/4059014e/plan.md
 D pi/.pi/agent/agents/ollama-coder.md
 D pi/.pi/agent/agents/ollama-orchestrator.md
 D pi/.pi/agent/agents/ollama-planner.md
 D pi/.pi/agent/agents/ollama-researcher.md
 D pi/.pi/agent/agents/ollama-reviewer.md
 D pi/.pi/agent/chains/feature-build.chain.md
 D pi/.pi/agent/chains/research-brief.chain.md
 D pi/.pi/agent/profiles/pi-subagents/README.md
 D pi/.pi/agent/profiles/pi-subagents/ollama.quality.json
 D pi/.pi/agent/profiles/pi-subagents/ollama.quota.json
 M pi/.pi/agent/prompts/p-explain.md
 M pi/.pi/agent/prompts/p-plan.md
 M pi/.pi/agent/prompts/p-review.md
 M pi/.pi/agent/run-history.jsonl
 M pi/.pi/agent/sessions/--home-liph-dotfiles-pi-.pi-agent-prompts--/2026-07-04T11-50-03-152Z_019f2cf6-da90-7ce5-b860-89b3bc41e7cd.jsonl
 M pi/.pi/agent/settings.json
 M pi/.pi/context-mode/content/aa673b1056f331f7.db
 M pi/.pi/context-mode/sessions/0b552d378e09330e.db
 M pi/.pi/context-mode/sessions/12c859f108b03852.db
 M pi/.pi/context-mode/sessions/12c859f108b03852.db-shm
 M pi/.pi/context-mode/sessions/12c859f108b03852.db-wal
 M pi/.pi/context-mode/sessions/3ea71be6c83c47ea.db
 M pi/.pi/context-mode/sessions/aa673b1056f331f7.db
 D pi/.pi/teams/audit/prune.jsonl
 D pi/.pi/teams/state/metrics/2026-07-04.jsonl
 M zshrc/.aliases.zsh
?? nvim/.config/nvim/lua/plugins.inactive/obsidian.lua
?? pi/.pi/.pi-subagents/
?? pi/.pi/agent/prompts/Doc/
?? pi/.pi/agent/prompts/c-design-build.md
?? pi/.pi/agent/prompts/c-fix-commit.md
?? pi/.pi/agent/prompts/c-refactor-commit.md
?? pi/.pi/agent/prompts/c-security-loop.md
?? pi/.pi/agent/prompts/p-brainstorm.md
?? pi/.pi/agent/prompts/p-commit.md
?? pi/.pi/agent/prompts/p-debug.md
?? pi/.pi/agent/prompts/p-diagnose.md
?? pi/.pi/agent/prompts/p-doc.md
?? pi/.pi/agent/prompts/p-refactor.md
?? pi/.pi/agent/prompts/p-secaudit.md
?? pi/.pi/agent/prompts/p-summarize.md
?? pi/.pi/agent/prompts/p-test.md
?? pi/.pi/agent/sessions/--home-liph--/2026-07-23T18-25-35-096Z_019f9039-cd78-745f-91f1-bb6dd3cf77e6.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-23T18-25-35-096Z_019f9039-cd78-745f-91f1-bb6dd3cf77e6/
?? pi/.pi/agent/sessions/--home-liph--/2026-07-23T18-32-44-056Z_019f9040-5918-762b-811b-fb9850208280.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-23T18-32-44-056Z_019f9040-5918-762b-811b-feaabc3f9b9a.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-23T18-32-44-057Z_019f9040-5919-727f-b8ec-418a0aa8b20c.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-23T20-57-15-297Z_019f90c4-a921-71a7-9fdc-2f4209cb98b9.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-23T20-57-52-036Z_019f90c5-38a4-7f20-999e-3c03519de661.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-24T05-51-34-958Z_019f92ad-da2e-74fe-95b0-267fea0989b9.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-24T05-51-34-958Z_019f92ad-da2e-74fe-95b0-267fea0989b9/
?? pi/.pi/agent/sessions/--home-liph--/2026-07-24T06-13-46-544Z_019f92c2-2bb0-7e3b-9f6e-dbded9a290df.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-24T06-13-46-544Z_019f92c2-2bb0-7e3b-9f6e-dbded9a290df/
?? pi/.pi/agent/sessions/--home-liph--/2026-07-24T06-32-26-008Z_019f92d3-4098-7db8-8ad9-043be2a000ed.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-24T06-45-27-619Z_019f92df-2dc3-760d-8a73-4d74c76d438e.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-24T14-19-00-509Z_019f947e-6a1d-766b-bb2d-f3f67a77e93a.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-24T14-19-33-625Z_019f947e-eb79-7247-a9b3-082ca8e24ae0.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-24T14-19-44-138Z_019f947f-148a-7912-8113-05e1e7baf223.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-24T14-24-30-883Z_019f9483-74a3-7e2d-9887-f4047bdc6aa5.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-24T14-25-21-257Z_019f9484-3969-7efb-a573-fead87b87d16.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-24T14-26-27-525Z_019f9485-3c45-77e7-8816-702036ac50eb.jsonl
?? pi/.pi/agent/sessions/--home-liph--/2026-07-24T14-27-40-439Z_019f9486-5917-7b5e-8fed-2808a5849ca2.jsonl
?? pi/.pi/agent/sessions/--home-liph-.pi-subagents-artifacts--/
?? pi/.pi/agent/sessions/--home-liph-dotfiles-pi-.pi--/
?? pi/.pi/agent/sessions/--home-liph-dotfiles-pi-.pi-agent--/2026-07-24T06-05-55-700Z_019f92ba-fc74-7b34-b217-99583d070904.jsonl
?? pi/.pi/agent/sessions/--home-liph-dotfiles-pi-.pi-agent--/2026-07-24T06-05-55-700Z_019f92ba-fc74-7b34-b217-99583d070904/
?? pi/.pi/agent/sessions/--home-liph-dotfiles-pi-.pi-agent--/2026-07-24T06-07-49-964Z_019f92bc-bacc-759d-b548-969978281b98.jsonl
?? pi/.pi/agent/sessions/--home-liph-dotfiles-pi-.pi-agent--/2026-07-24T06-07-49-964Z_019f92bc-bacc-759d-b548-969978281b98/
?? pi/.pi/agent/sessions/--home-liph-dotfiles-pi-.pi-agent--/2026-07-24T07-39-48-126Z_019f9310-ee1e-7e02-8adc-277ee17bddc0.jsonl
?? pi/.pi/agent/sessions/--home-liph-dotfiles-pi-.pi-agent--/2026-07-24T07-49-24-675Z_019f9319-ba43-788b-93e4-6b42870de193.jsonl
?? pi/.pi/agent/sessions/--home-liph-dotfiles-pi-.pi-agent--/2026-07-24T14-29-40-567Z_019f9488-2e57-7c47-b1bf-f7cf02f89dcc.jsonl
?? pi/.pi/agent/sessions/--home-liph-dotfiles-pi-.pi-agent-prompts--/2026-07-24T14-46-31-236Z_019f9497-9a44-7a63-a1ef-46ded13c01a8.jsonl
?? pi/.pi/agent/sessions/--home-liph-dotfiles-pi-.pi-agent-prompts--/2026-07-24T15-15-24-515Z_019f94b2-0ce3-7c27-8099-78ceea97d2cf.jsonl
?? pi/.pi/agent/sessions/--home-liph-dotfiles-pi-.pi-agent-prompts-Doc--/
?? pi/.pi/agent/sessions/--home-liph-dotfiles-pi-.pi-agent-themes--/
?? pi/.pi/agent/sessions/--mnt-flash1-code-aerc--/
?? pi/.pi/agent/sessions/--mnt-flash1-code-candles--/
?? pi/.pi/agent/sessions/--mnt-flash1-code-feuerkreis--/
?? "pi/.pi/agent/sessions/--mnt-flash1-code-m\303\244nnerzirkel--/"
?? pi/.pi/agent/sessions/--mnt-flash1-code-webpage--/
?? pi/.pi/agent/sessions/--mnt-flash1-code-webstore--/
?? pi/.pi/agent/themes/rose-pine-beautiful.json
?? pi/.pi/context-mode/sessions/10f3e3c5d13d91cb.db
?? pi/.pi/context-mode/sessions/10f3e3c5d13d91cb.db-shm
?? pi/.pi/context-mode/sessions/10f3e3c5d13d91cb.db-wal
?? pi/.pi/context-mode/sessions/150ea8def36d4286.db
?? pi/.pi/context-mode/sessions/150ea8def36d4286.db-shm
?? pi/.pi/context-mode/sessions/150ea8def36d4286.db-wal
?? pi/.pi/context-mode/sessions/15bbe2b9c6a5cf3a.db
?? pi/.pi/context-mode/sessions/15bbe2b9c6a5cf3a.db-shm
?? pi/.pi/context-mode/sessions/15bbe2b9c6a5cf3a.db-wal
?? pi/.pi/context-mode/sessions/1632b17542982f7e.db
?? pi/.pi/context-mode/sessions/1632b17542982f7e.db-shm
?? pi/.pi/context-mode/sessions/1632b17542982f7e.db-wal
?? pi/.pi/context-mode/sessions/27411074f5f7a61e.db
?? pi/.pi/context-mode/sessions/27411074f5f7a61e.db-shm
?? pi/.pi/context-mode/sessions/27411074f5f7a61e.db-wal
?? pi/.pi/context-mode/sessions/36f8c52c1bab0f41.db
?? pi/.pi/context-mode/sessions/36f8c52c1bab0f41.db-shm
?? pi/.pi/context-mode/sessions/36f8c52c1bab0f41.db-wal
?? pi/.pi/context-mode/sessions/3bb61de67e8a4fe4.db
?? pi/.pi/context-mode/sessions/3bb61de67e8a4fe4.db-shm
?? pi/.pi/context-mode/sessions/3bb61de67e8a4fe4.db-wal
?? pi/.pi/context-mode/sessions/4480bf537cca1bcf.db
?? pi/.pi/context-mode/sessions/4480bf537cca1bcf.db-shm
?? pi/.pi/context-mode/sessions/4480bf537cca1bcf.db-wal
?? pi/.pi/context-mode/sessions/c340569da3996957.db
?? pi/.pi/context-mode/sessions/c340569da3996957.db-shm
?? pi/.pi/context-mode/sessions/c340569da3996957.db-wal
?? pi/.pi/context-mode/sessions/f05bb7382a9480de.db-shm
?? pi/.pi/context-mode/sessions/f05bb7382a9480de.db-wal
?? pi/.pi/context-mode/sessions/f9a74f35a5704572.db
?? pi/.pi/context-mode/sessions/f9a74f35a5704572.db-shm
?? pi/.pi/context-mode/sessions/f9a74f35a5704572.db-wal
?? pi/.pi/context-mode/sessions/stats-pid-218958.json
?? pi/.pi/context-mode/sessions/stats-pid-219161.json
?? pi/.pi/context-mode/sessions/stats-pid-223177.json
?? pi/.pi/context-mode/sessions/stats-pid-223858.json
?? pi/.pi/context-mode/sessions/stats-pid-225773.json
?? pi/.pi/context-mode/sessions/stats-pid-226205.json
?? pi/.pi/context-mode/sessions/stats-pid-227510.json
?? pi/.pi/context-mode/sessions/stats-pid-228197.json
?? pi/.pi/context-mode/sessions/stats-pid-229441.json
?? pi/.pi/context-mode/sessions/stats-pid-230590.json
?? pi/.pi/context-mode/sessions/stats-pid-235591.json
?? pi/.pi/context-mode/sessions/stats-pid-236348.json
?? pi/.pi/context-mode/sessions/stats-pid-236973.json
?? pi/.pi/context-mode/sessions/stats-pid-237788.json
?? pi/.pi/context-mode/sessions/stats-pid-239646.json
?? pi/.pi/context-mode/sessions/stats-pid-240289.json
?? pi/.pi/context-mode/sessions/stats-pid-240592.json
?? pi/.pi/context-mode/sessions/stats-pid-240593.json
?? pi/.pi/context-mode/sessions/stats-pid-241374.json
?? pi/.pi/context-mode/sessions/stats-pid-244139.json
?? pi/.pi/context-mode/sessions/stats-pid-248583.json
?? pi/.pi/context-mode/sessions/stats-pid-249076.json
?? pi/.pi/context-mode/sessions/stats-pid-249292.json
?? pi/.pi/context-mode/sessions/stats-pid-251943.json
?? pi/.pi/context-mode/sessions/stats-pid-253194.json
?? pi/.pi/context-mode/sessions/stats-pid-266999.json
?? pi/.pi/context-mode/sessions/stats-pid-267230.json
?? pi/.pi/context-mode/sessions/stats-pid-267545.json
?? pi/.pi/context-mode/sessions/stats-pid-270991.json
?? pi/.pi/context-mode/sessions/stats-pid-271215.json
?? pi/.pi/context-mode/sessions/stats-pid-273458.json
?? pi/.pi/context-mode/sessions/stats-pid-273690.json
?? pi/.pi/context-mode/sessions/stats-pid-273992.json
?? pi/.pi/context-mode/sessions/stats-pid-274378.json
?? pi/.pi/context-mode/sessions/stats-pid-274842.json
?? pi/.pi/context-mode/sessions/stats-pid-275196.json
?? pi/.pi/context-mode/sessions/stats-pid-276550.json
?? pi/.pi/context-mode/sessions/stats-pid-276948.json
?? pi/.pi/context-mode/sessions/stats-pid-277525.json
?? pi/.pi/context-mode/sessions/stats-pid-91796.json
?? pi/.pi/context-mode/sessions/stats-pid-92117.json
?? pi/.pi/context-mode/sessions/stats-pid-92239.json
?? pi/.pi/context-mode/sessions/stats-pid-92541.json
?? pi/.pi/context-mode/sessions/stats-pid-92766.json
?? pi/.pi/context-mode/sessions/stats-pid-94676.json
?? pi/.pi_1/


Implemented the chain recipes and frontmatter updates.

### What changed

**Added `subagent: true` + `fork: true` to the 10 prompts used in chains:**
- `p-brainstorm.md`
- `p-plan.md`
- `p-test.md`
- `p-commit.md`
- `p-summarize.md`
- `p-diagnose.md`
- `p-debug.md`
- `p-refactor.md`
- `p-review.md`
- `p-secaudit.md`

**Created 4 chain recipe files:**
- `c-design-build.md` → `p-brainstorm → p-plan → p-test → p-commit`
- `c-fix-commit.md` → `p-summarize → p-diagnose → p-debug → p-test`
- `c-refactor-commit.md` → `p-refactor → p-test → p-review → p-commit`
- `c-security-loop.md` → `p-secaudit → p-review → p-test`

Each recipe has `async: true`, so they run in the background by default.

**Updated `Doc/README.md`** with a “Chain recipes” section listing the sequences, usage examples, and `/chain-prompts` ad-hoc syntax.

### How to use

```text
/prompt-workflow c-design-build "add a rate-limiter to the API"
/prompt-workflow c-fix-commit "the checkout intermittently times out"
/prompt-workflow c-refactor-commit "src/utils.ts"
/prompt-workflow c-security-loop "auth endpoint"
```

Watch progress with `/subagents-fleet` or `subagent({ action: "status" })`.

### Next step

Reload Pi resources (`/reload`) and run `/prompt-workflow list` to confirm the new `c-*` recipes and updated `p-*` prompts appear correctly. Then dry-run one chain in a scratch repo.

Note: `git status` shows unrelated pre-existing changes in the dotfiles repo, so I did not commit anything. When you’re ready, stage only the prompts/Doc files under `pi/.pi/agent/prompts/`.


can you create a .md file in the Doc folder for clarity in the chain commands


write

# Chain Commands Reference

This file documents how to invoke the `c-*` chain recipes defined in `~/.pi/agent/prompts/`.

## What the chains are

The `c-*` files are orchestration recipes. They do not contain new prompts; they reuse the existing `p-*` prompts and run them in sequence through the `pi-subagents` prompt-workflow adapter. Each step is executed as a forked-context subagent, so later steps can see the outputs from earlier steps.

## Available chains

| Command file | Sequence | Use it when |
|---|---|---|
| `c-design-build.md` | `p-brainstorm → p-plan → p-test → p-commit` | You want to design a feature, plan it, add tests, and commit in one go. |
| `c-fix-commit.md` | `p-summarize → p-diagnose → p-debug → p-test` | You need to understand a bug, diagnose it, fix it, and add regression tests. |
| `c-refactor-commit.md` | `p-refactor → p-test → p-review → p-commit` | You want a safe refactor with tests, review, and a commit. |
| `c-security-loop.md` | `p-secaudit → p-review → p-test` | You need a security-first review plus tests before proceeding. |

## How to run a chain

Chains are not invoked with `/c-...` in the editor, because normal slash expansion just pastes the file body into the chat. Instead, run them through the `pi-subagents` adapter with `/prompt-workflow`:

```text
/prompt-workflow c-design-build "add a rate-limiter to the API"
/prompt-workflow c-fix-commit "the checkout intermittently times out"
/prompt-workflow c-refactor-commit "src/utils.ts"
/prompt-workflow c-security-loop "auth endpoint"
```

Each chain runs asynchronously by default. Check progress with:

```text
/subagents-fleet
```

or inspect a specific run with:

```text
subagent({ action: "status" })
```

## Ad-hoc chains

You can also run the same sequence on the fly without creating a recipe file:

```text
/chain-prompts p-brainstorm -> p-plan -> p-test -> p-commit -- "add a rate-limiter"
/chain-prompts p-summarize -> p-diagnose -> p-debug -> p-test -- "intermittent timeout"
/chain-prompts p-refactor -> p-test -> p-review -> p-commit -- "src/utils.ts"
/chain-prompts p-secaudit -> p-review -> p-test -- "auth endpoint"
```

Use `--bg` or `--async` to detach an ad-hoc chain:

```text
/chain-prompts p-refactor -> p-test -> p-review -> p-commit --bg -- "src/utils.ts"
```

## Why individual prompts are the subagents

Only the `p-*.md` files are marked with `subagent: true` and `fork: true`. The `c-*.md` recipe files are pure wrappers. When `/prompt-workflow` loads a recipe:

1. It sees the `chain:` frontmatter.
2. It resolves each named step to a `p-*.md` file.
3. It runs that prompt as a forked-context subagent (`delegate` by default).
4. The output of each step is passed to the next step via the chain runner.

This keeps the chain recipes small and the individual prompts reusable as both standalone slash templates and chain steps.

## Context flow

Because each `p-*` step uses `fork: true`, every subagent inherits the parent session history. That means later steps naturally see what earlier steps produced, without needing explicit `{previous}` placeholders inside the prompt bodies.

The trade-off is higher per-step context usage. If token cost becomes an issue, a future migration could switch the `p-*` prompts to `fresh: true` and introduce explicit `{previous}` handling inside their bodies.

## Troubleshooting

| Symptom | What to check |
|---|---|
| `/c-design-build` just pastes text | Use `/prompt-workflow c-design-build ...` instead. |
| Chain step fails with “Unknown prompt workflow” | Run `/reload`, then `/prompt-workflow list` and confirm each `p-*` in the chain appears. |
| Chain does not run in background | Confirm the recipe has `async: true` in frontmatter, or add `--bg` to the command. |
| Steps seem disconnected | `fork: true` is required on each `p-*.md`. Check frontmatter. |


Successfully wrote 3843 bytes to /home/liph/dotfiles/pi/.pi/agent/prompts/Doc/chain-commands.md


Created `Doc/chain-commands.md` with a full reference for the chain commands.

It covers:
- What the `c-*` recipes are
- The 4 available chains and their sequences
- How to run them via `/prompt-workflow`
- How to watch async progress
- Ad-hoc `/chain-prompts` syntax, including `--bg`
- Why only the individual `p-*` prompts are subagents
- How context flows between forked steps
- A troubleshooting table

Let me know if you want this merged into the main `README.md` instead, or if you want a shorter quick-reference card.


Step 1: delegate
Security-audit: ${@:-the current code, diff, or feature}

Structure your answer as:
1. **Trust boundary** — where untrusted input enters, where sensitive data leaves; map the attack surface in one paragraph
2. **Findings** — grouped by severity (Critical / High / Medium / Low / Info). For each:
   - **Category** — one of: Injection, AuthN/AuthZ, Secrets, Crypto, Input validation, Output encoding, Deserialization, SSRF, Path traversal, Race/TOC-TOU, Dependency, Logging/PII, Configuration, Supply chain
   - **Location** — file, line, function
   - **Description** — the vulnerability, with a concrete exploit scenario
   - **Fix** — the minimal secure change, with a code snippet
3. **Missing controls** — auth, rate limiting, audit logging, CSRF/CORS, headers, etc. that should exist but don't
4. **Dependencies** — any third-party packages with known CVEs in this surface (if you can determine versions)
5. **Threat model gaps** — what's out of scope for this audit but worth a separate pass

Be concrete and adversarial — describe a real attack, not "consider validating input." If the code is sound, say so explicitly and explain what you'd look for if it weren't. Do not pad with general security advice that doesn't apply to the specific code.

Step 2: delegate
Review the following code or changes: ${@:-the current file / diff / staged changes}

Provide feedback in these categories:
- **Correctness** — bugs, logic errors, edge cases, race conditions
- **Security** — injection, unsafe defaults, secrets, auth/z issues
- **Performance** — unnecessary work, memory leaks, hot-path inefficiencies
- **Maintainability** — naming, complexity, duplication, testability
- **Style & Idioms** — consistency with the surrounding codebase
- **Error Handling** — missing or misleading failure modes

For each issue, include:
- The specific location (file, line, function)
- A clear description of the problem
- A concrete suggestion or example fix

Also call out anything done well. Keep the review concise and prioritized.

Step 3: delegate
Write tests for: ${@:-the current code or context}

Structure your answer as:
1. **Existing conventions** — name patterns, framework, assertion style, fixtures; match what's already there
2. **Test cases to add** — grouped as:
   - **Happy path** — the primary expected behavior
   - **Edge cases** — empty, zero, max, boundary, off-by-one
   - **Error cases** — invalid input, missing deps, timeouts, permission failures
3. **Test code** — minimal, runnable, following the project's framework (jest, pytest, go test, etc.)
4. **How to run** — the exact command, plus how to run just the new tests
5. **Coverage gaps** — anything still untestable without a refactor; flag it but do not refactor in this pass

Keep tests independent, deterministic, and fast. Prefer many small tests over one large one. If the codebase has no test setup yet, propose the smallest viable setup and call it out clearly so the user can approve before you scaffold it.


## Subagent result

Cancelled

Cancelled


Run the security-first review loop for: this is a test

Invoke with:
/prompt-workflow c-security-loop "auth endpoint"


I see you tried to run `/prompt-workflow c-security-loop "this is a test"`, but the subagent result was cancelled. Let me check the status of the async run and see what happened.


Spawn budget: unlimited
No active subagent fleet. Background runs that already finished are available through completion notifications or subagent({ action: "status", id: "..." }).


No active subagent fleet — the chain was cancelled before it started, likely because of the `async: true` frontmatter but no active parent session to persist to.

The `pi-subagents` prompt-workflow adapter requires a persisted parent session to fork from. If the session is ephemeral (`--no-session`) or not yet saved, forked-context subagent chains will fail.

### Quick checks

1. **Is your current Pi session persisted?** Run `/session` and confirm a session file path is shown.
2. **Did you run this from a fresh/throwaway session?** Forked context only works once the session has been saved to disk.
3. **Does `/prompt-workflow list` show `c-security-loop` and the `p-*` prompts?** Run `/reload` first if you just added the files.

### To test the chain safely

Create a persisted session, then run:

```text
/prompt-workflow c-security-loop "this is a test"
```

or use ad-hoc fresh context instead:

```text
/chain-prompts p-secaudit -> p-review -> p-test --fresh -- "this is a test"
```

That avoids the forked-context requirement by running each step fresh.

### Do you want me to adjust the recipes?

I can change the `c-*` chain recipes to default to fresh context instead of forked context. This removes the persisted-session requirement, but later steps won’t automatically see earlier outputs unless we also add `{previous}` handling to the `p-*` prompts.

Which direction do you prefer?
- **A) Keep forked context** — chains work only from persisted sessions.
- **B) Switch to fresh context** — chains work anywhere, but individual prompts may need small `{previous}` edits.


i


The user just typed "i" and then context-mode became active. This seems like an accidental or incomplete input. I should wait or ask what they meant. But actually, the system says context-mode active, so maybe I should respond normally and ask for clarification about their preference (A or B) since my last message was asking them to choose.

The "i" might


Step 1: delegate
Brainstorm approaches for: ${@:-the current problem or feature}

Structure your answer as:
1. **Problem restatement** — one paragraph; what we're solving, what constraints matter, what "done" looks like
2. **Alternatives** — 3 to 5 distinct approaches. For each:
   - **Summary** — one or two sentences
   - **How it works** — the key mechanism
   - **Pros** — what it gets right
   - **Cons** — what it costs, risks, or breaks
   - **Best when** — the conditions that would make this the right pick
3. **Comparison table** — across the alternatives, score or rank on: complexity, time-to-ship, reversibility, performance, fit-with-existing-code
4. **Recommendation** — which one to pick *given the current codebase*, with the second choice as a fallback
5. **Unknowns** — questions that, if answered, would change the recommendation

Be opinionated. Surface real trade-offs, not strawmen. If the obvious approach wins decisively, say so and only enumerate 2 alternatives — don't manufacture options for the sake of a full set. If the problem is under-specified, ask clarifying questions before brainstorming.

Step 2: delegate
Create a structured implementation plan for: ${@:-the current task}

Follow this format:
1. **Goal** — one-sentence objective
2. **Constraints** — existing code, dependencies, tests, or assumptions to respect
3. **Approach** — high-level strategy and rationale
4. **Steps** — numbered, actionable tasks small enough to verify one at a time
5. **Verification** — how to confirm each step works (tests, logs, manual checks)
6. **Risks & Rollbacks** — what could go wrong and how to undo safely
7. **Open Questions** — anything that needs clarification before starting

Use the codebase context as needed. Do not write implementation code yet; only produce the plan.

Step 3: delegate
Write tests for: ${@:-the current code or context}

Structure your answer as:
1. **Existing conventions** — name patterns, framework, assertion style, fixtures; match what's already there
2. **Test cases to add** — grouped as:
   - **Happy path** — the primary expected behavior
   - **Edge cases** — empty, zero, max, boundary, off-by-one
   - **Error cases** — invalid input, missing deps, timeouts, permission failures
3. **Test code** — minimal, runnable, following the project's framework (jest, pytest, go test, etc.)
4. **How to run** — the exact command, plus how to run just the new tests
5. **Coverage gaps** — anything still untestable without a refactor; flag it but do not refactor in this pass

Keep tests independent, deterministic, and fast. Prefer many small tests over one large one. If the codebase has no test setup yet, propose the smallest viable setup and call it out clearly so the user can approve before you scaffold it.

Step 4: delegate
Generate a commit message for: ${@:-the current uncommitted changes (run git status / git diff first)}

Structure your answer as:
1. **Type & scope** — one of: feat, fix, refactor, perf, test, docs, build, ci, chore, style; scope is the affected module/subsystem
2. **Subject** — imperative mood, ≤72 chars, no trailing period, no emoji
3. **Body** — wrapped at 72 cols, explain *why* not *what*. Use bullet points for multiple distinct changes.
4. **Footer** — `BREAKING CHANGE: …` if applicable; `Refs: #123` for linked issues
5. **PR description** (if the change is non-trivial) — Summary, Motivation, Changes, Test plan, Risks

Format the final message in a single fenced block ready to copy. If the change spans multiple logical commits, propose a split with one subject per commit and the file groups that belong in each.

Read the diff before writing — never invent files, symbols, or behavior. If `git status` is empty or the diff is unclear, ask before fabricating.