@tryinget/pi-modes 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +78 -0
- package/README.md +176 -0
- package/docs/project/2026-07-11-implementation-plan.md +61 -0
- package/docs/project/2026-07-11-prompt-mode-architecture.md +101 -0
- package/examples/modes/exact-minimal.json +8 -0
- package/examples/modes/focused-builder.json +8 -0
- package/examples/modes/hard-nosed-review.json +8 -0
- package/extensions/mode.ts +409 -0
- package/package.json +88 -0
- package/policy/engineering-lane.json +34 -0
- package/policy/security-policy.json +10 -0
- package/prompts/mode-authoring.md +23 -0
- package/src/modes.ts +371 -0
- package/tests/modes.test.ts +333 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
MIT License (with OpenAI/Anthropic/xAI/PRC Frontier Labs Rider)
|
|
2
|
+
|
|
3
|
+
Copyright (c) contributors
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
ADDITIONAL RIDER / RESTRICTION (OpenAI / Anthropic / xAI / PRC Frontier Labs):
|
|
13
|
+
|
|
14
|
+
This rider is part of the "conditions" of this License. In the event of any
|
|
15
|
+
conflict between this rider and any other portion of this License, this rider
|
|
16
|
+
controls.
|
|
17
|
+
|
|
18
|
+
"Restricted Parties" means OpenAI, L.L.C.; Anthropic, PBC; xAI Corp.; and the
|
|
19
|
+
following PRC frontier AI labs and related entities: Baidu (including ERNIE-
|
|
20
|
+
related entities), Alibaba and Alibaba Cloud (including Qwen-related entities),
|
|
21
|
+
Tencent (including Hunyuan-related entities), ByteDance (including Doubao/Seed-
|
|
22
|
+
related entities), DeepSeek, Zhipu AI, Moonshot AI, MiniMax, 01.AI
|
|
23
|
+
(Lingyiwanwu), and iFlyTek. "Restricted Parties" also includes any of their
|
|
24
|
+
respective Affiliates and any person or entity acting directly or indirectly
|
|
25
|
+
on behalf of, for the benefit of, or under the direction of any of the
|
|
26
|
+
foregoing (including any officer, director, employee, contractor, agent,
|
|
27
|
+
consultant, service provider, or representative).
|
|
28
|
+
|
|
29
|
+
Notwithstanding any other provision of this License, no rights are granted to
|
|
30
|
+
any Restricted Party. Any purported license, sublicense, assignment, transfer,
|
|
31
|
+
or other permission to any Restricted Party is null and void absent the
|
|
32
|
+
express prior written permission of the copyright holders.
|
|
33
|
+
|
|
34
|
+
You may not provide, disclose, distribute, sublicense, sell, lease, lend,
|
|
35
|
+
host, make available, or otherwise permit access to the Software or any
|
|
36
|
+
derivative work of the Software (as defined in applicable copyright law)
|
|
37
|
+
(collectively, "Derivative Works") to or for any Restricted Party.
|
|
38
|
+
|
|
39
|
+
For purposes of this rider, "use" includes, without limitation: copying,
|
|
40
|
+
modifying, merging, publishing, distributing, sublicensing, selling,
|
|
41
|
+
transferring, making available, hosting, deploying, executing, benchmarking,
|
|
42
|
+
testing, analyzing, indexing, or incorporating the Software or any Derivative
|
|
43
|
+
Works into any dataset, training corpus, evaluation harness, or pipeline for
|
|
44
|
+
machine learning or other automated systems.
|
|
45
|
+
|
|
46
|
+
This rider applies to the Software and all Derivative Works. As a condition of
|
|
47
|
+
use, you agree that this rider is a precondition to exercising any rights
|
|
48
|
+
under this License, and you agree that any distribution of the Software or any
|
|
49
|
+
Derivative Works must include this rider provision unmodified.
|
|
50
|
+
|
|
51
|
+
Any breach of this rider automatically and immediately terminates the
|
|
52
|
+
permissions granted by this License. Upon termination, you must immediately
|
|
53
|
+
cease all use and distribution of the Software and any Derivative Works and
|
|
54
|
+
destroy all copies under your control.
|
|
55
|
+
|
|
56
|
+
You agree that a breach of this rider would cause irreparable harm and that
|
|
57
|
+
the copyright holders may seek injunctive or other equitable relief to enforce
|
|
58
|
+
this rider, in addition to any other remedies available at law. To the maximum
|
|
59
|
+
extent permitted by applicable law, the prevailing party in any action to
|
|
60
|
+
enforce this rider shall be entitled to recover reasonable attorneys' fees and
|
|
61
|
+
costs.
|
|
62
|
+
|
|
63
|
+
For purposes of this rider, "Affiliate" means any entity that directly or
|
|
64
|
+
indirectly controls, is controlled by, or is under common control with the
|
|
65
|
+
specified party. "Control" means ownership of more than 50% of the voting
|
|
66
|
+
securities or other ownership interest, or the power to direct management or
|
|
67
|
+
policies by contract or otherwise.
|
|
68
|
+
|
|
69
|
+
The above copyright notice and this permission notice shall be included in all
|
|
70
|
+
copies or substantial portions of the Software.
|
|
71
|
+
|
|
72
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
73
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
74
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
75
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
76
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
77
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
78
|
+
SOFTWARE.
|
package/README.md
ADDED
|
@@ -0,0 +1,176 @@
|
|
|
1
|
+
---
|
|
2
|
+
summary: "Prompt mode switching with explicit base-prompt and final-prompt replacement semantics."
|
|
3
|
+
read_when:
|
|
4
|
+
- "Installing, operating, or extending @tryinget/pi-modes."
|
|
5
|
+
system4d:
|
|
6
|
+
container: "Installable Pi prompt-mode package."
|
|
7
|
+
compass: "Switch complete prompt policies without confusing base replacement, final replacement, or autonomy."
|
|
8
|
+
engine: "Discover modes -> validate -> activate -> compose -> restore from session state."
|
|
9
|
+
fog: "Prompt composition layers are easy to conflate and can silently discard dynamic context."
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# @tryinget/pi-modes
|
|
13
|
+
|
|
14
|
+
Switch Pi prompt profiles during a session without restarting Pi.
|
|
15
|
+
|
|
16
|
+
The package makes the distinction that matters:
|
|
17
|
+
|
|
18
|
+
- `append` keeps Pi's fully assembled prompt and adds mode instructions;
|
|
19
|
+
- `replace_base` changes the complete static base prompt while preserving Pi's dynamic append/context/skills/date/cwd envelope;
|
|
20
|
+
- `replace_final` deliberately replaces the final assembled prompt with exact text.
|
|
21
|
+
|
|
22
|
+
`replace_base` corresponds to the intent of Pi's native `--system-prompt` and `SYSTEM.md` features.
|
|
23
|
+
|
|
24
|
+
## Native base and named alternatives
|
|
25
|
+
|
|
26
|
+
Pi's native base-prompt files remain the default source of truth:
|
|
27
|
+
|
|
28
|
+
```text
|
|
29
|
+
<project>/.pi/SYSTEM.md
|
|
30
|
+
~/.pi/agent/SYSTEM.md
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
Starting Pi normally uses the trusted project `SYSTEM.md`, then the global `SYSTEM.md`, then Pi's built-in base according to Pi's native resource rules. `pi-modes` does not add a parallel project-default file. Named modes under `.pi/modes/` and `~/.pi/agent/modes/` are explicit alternatives to that native base.
|
|
34
|
+
|
|
35
|
+
When no named mode is active—or after `/mode off`—the extension returns control to Pi unchanged, so the native `SYSTEM.md` base and dynamic envelope remain active.
|
|
36
|
+
|
|
37
|
+
## Commands
|
|
38
|
+
|
|
39
|
+
| Command | Purpose |
|
|
40
|
+
|---|---|
|
|
41
|
+
| `/mode` | Select a discovered mode. |
|
|
42
|
+
| `/mode <key>` | Activate a mode directly. |
|
|
43
|
+
| `/mode off` | Restore the host prompt for future turns. |
|
|
44
|
+
| `/mode-status` | Add a durable TUI-only status card with active mode, native-base fallback, available keys, and diagnostics. |
|
|
45
|
+
| `/mode-preview [key]` | Preview the final composed prompt without activating it; without a key, open the mode selector. |
|
|
46
|
+
| `/mode-new [--project] <key>` | Create a global or trusted-project mode in an editor. |
|
|
47
|
+
| `/mode-edit <key>` | Edit a custom mode using its validated discovered path. |
|
|
48
|
+
| `/mode-delete <key>` | Confirm and delete a custom mode safely. |
|
|
49
|
+
|
|
50
|
+
The package includes small built-in `plan`, `review`, and `explain` append modes.
|
|
51
|
+
|
|
52
|
+
`/mode-status` is stored as a custom session entry and rendered in the transcript without entering LLM context. Its compact view shows the active selection and counts; expand it through Pi's normal message-expansion control to see strategy, scope, available keys, and malformed-file diagnostics.
|
|
53
|
+
|
|
54
|
+
## Launch-time selection
|
|
55
|
+
|
|
56
|
+
Set `PI_MODE` to select a named alternative when Pi starts:
|
|
57
|
+
|
|
58
|
+
```bash
|
|
59
|
+
PI_MODE=focused-builder pi
|
|
60
|
+
PI_MODE=review pi
|
|
61
|
+
PI_MODE=off pi
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
Startup precedence is intentionally small:
|
|
65
|
+
|
|
66
|
+
1. a non-blank `PI_MODE` explicitly selects a named mode or `off`;
|
|
67
|
+
2. otherwise, a resumed/reloaded session restores its latest `/mode` selection;
|
|
68
|
+
3. otherwise, Pi uses its native project/global `SYSTEM.md` or built-in base.
|
|
69
|
+
|
|
70
|
+
`PI_MODE=off` (also `default` or `none`) explicitly selects the native `SYSTEM.md`/host base. An unavailable or invalid `PI_MODE` fails closed to that native base and reports a warning. The resolved launch selection is written to the Pi session branch, so later turns remain stable; an interactive `/mode` command can change it afterward.
|
|
71
|
+
|
|
72
|
+
## Mode files
|
|
73
|
+
|
|
74
|
+
Global modes:
|
|
75
|
+
|
|
76
|
+
```text
|
|
77
|
+
~/.pi/agent/modes/*.json
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
Trusted ancestor/project modes:
|
|
81
|
+
|
|
82
|
+
```text
|
|
83
|
+
<filesystem-root>/.pi/modes/*.json
|
|
84
|
+
...
|
|
85
|
+
<company>/.pi/modes/*.json
|
|
86
|
+
...
|
|
87
|
+
<cwd>/.pi/modes/*.json
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
Discovery mirrors Pi's `AGENTS.md` layering: load the global mode directory, then ancestor `.pi/modes` directories from filesystem root down to the active cwd. Deeper definitions override shallower definitions with the same key; every project definition overrides global and built-in definitions. This lets `~/ai-society/.pi/modes`, company-level `.pi/modes`, lane-level `.pi/modes`, and repo-local `.pi/modes` form one predictable hierarchy.
|
|
91
|
+
|
|
92
|
+
All ancestor/project mode directories are ignored when the active project is not trusted. `/mode-new --project <key>` writes only to the active cwd's `.pi/modes`; it never mutates an ancestor implicitly. Inherited modes are selectable and previewable but read-only from descendant cwd sessions—change to the owning ancestor directory before using `/mode-edit` or `/mode-delete`.
|
|
93
|
+
|
|
94
|
+
Discovery and persistence reject symbolic links in any path component, including a symlinked `.pi` parent, so an inherited mode cannot escape its declared filesystem hierarchy.
|
|
95
|
+
|
|
96
|
+
Example:
|
|
97
|
+
|
|
98
|
+
```json
|
|
99
|
+
{
|
|
100
|
+
"schemaVersion": 1,
|
|
101
|
+
"key": "focused-builder",
|
|
102
|
+
"label": "Focused Builder",
|
|
103
|
+
"description": "A complete static coding-agent identity.",
|
|
104
|
+
"promptStrategy": "replace_base",
|
|
105
|
+
"systemPrompt": "You are a focused coding agent. Drive the requested task to verified completion."
|
|
106
|
+
}
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
A missing `promptStrategy` defaults to `replace_base`.
|
|
110
|
+
|
|
111
|
+
More examples are in [`examples/modes`](examples/modes).
|
|
112
|
+
|
|
113
|
+
## Prompt composition
|
|
114
|
+
|
|
115
|
+
### `append`
|
|
116
|
+
|
|
117
|
+
```text
|
|
118
|
+
host assembled prompt
|
|
119
|
+
+ active-mode section
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
### `replace_base`
|
|
123
|
+
|
|
124
|
+
```text
|
|
125
|
+
mode systemPrompt
|
|
126
|
+
+ APPEND_SYSTEM.md / --append-system-prompt
|
|
127
|
+
+ trusted AGENTS.md / CLAUDE.md context
|
|
128
|
+
+ visible skills when read is active
|
|
129
|
+
+ date
|
|
130
|
+
+ cwd
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
### `replace_final`
|
|
134
|
+
|
|
135
|
+
```text
|
|
136
|
+
mode systemPrompt exactly
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
`replace_final` intentionally does not retain project context, skills, date, cwd, or appended instructions. Use it for controlled exact-prompt experiments rather than by accident.
|
|
140
|
+
|
|
141
|
+
## Safety and scope
|
|
142
|
+
|
|
143
|
+
- Mode keys are validated before path construction.
|
|
144
|
+
- JSON files are parsed independently; one malformed file does not hide later valid modes.
|
|
145
|
+
- Saves use same-directory temporary files plus atomic rename.
|
|
146
|
+
- Edit/delete operate only on discovered global/project files.
|
|
147
|
+
- Mode selection is persisted in session custom entries and restored on resume/reload when `PI_MODE` does not explicitly override startup.
|
|
148
|
+
- The native project/global `SYSTEM.md` remains the default base; named modes are alternatives, not another default layer.
|
|
149
|
+
|
|
150
|
+
Mode activation changes prompt policy only. It does not send follow-up messages, continue automatically, launch peers/subagents/campaigns, or grant mutation or promotion authority. Future autonomy integration is intentionally separate.
|
|
151
|
+
|
|
152
|
+
Architecture: [`docs/project/2026-07-11-prompt-mode-architecture.md`](docs/project/2026-07-11-prompt-mode-architecture.md)
|
|
153
|
+
Implementation plan: [`docs/project/2026-07-11-implementation-plan.md`](docs/project/2026-07-11-implementation-plan.md)
|
|
154
|
+
|
|
155
|
+
## Install and verify
|
|
156
|
+
|
|
157
|
+
```bash
|
|
158
|
+
git clone https://github.com/tryingET/pi-extensions.git
|
|
159
|
+
cd pi-extensions/packages/pi-modes
|
|
160
|
+
npm install
|
|
161
|
+
npm run check
|
|
162
|
+
pi install "$PWD"
|
|
163
|
+
```
|
|
164
|
+
|
|
165
|
+
Then run `/reload` and verify with:
|
|
166
|
+
|
|
167
|
+
```text
|
|
168
|
+
/mode review
|
|
169
|
+
/mode-status
|
|
170
|
+
/mode-preview review
|
|
171
|
+
/mode off
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
## Attribution
|
|
175
|
+
|
|
176
|
+
The concept and command vocabulary were informed by Maxime Rivest's MIT-licensed [`pi-modes`](https://github.com/MaximeRivest/pi-modes). This package uses a separately structured implementation with explicit composition strategies, trust gating, safe persistence, and tests.
|
|
@@ -0,0 +1,61 @@
|
|
|
1
|
+
---
|
|
2
|
+
summary: "Implementation and rollout plan for safe prompt-mode switching."
|
|
3
|
+
read_when:
|
|
4
|
+
- "Implementing or reviewing the initial pi-modes package."
|
|
5
|
+
- "Planning live activation or later autonomy integration."
|
|
6
|
+
system4d:
|
|
7
|
+
container: "Delivery plan for the initial prompt-mode package."
|
|
8
|
+
compass: "Land safe prompt composition first and defer autonomous execution to its owners."
|
|
9
|
+
engine: "Scaffold -> kernel -> adapter -> docs -> tests -> live activation."
|
|
10
|
+
fog: "A broad autonomy ambition can widen a bounded prompt-mode implementation."
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
# Implementation plan
|
|
14
|
+
|
|
15
|
+
## Immediate implementation
|
|
16
|
+
|
|
17
|
+
1. **Scaffold the package from `pi-extensions-template`.**
|
|
18
|
+
- Keep `.copier-answers.yml` tracked.
|
|
19
|
+
- Align the package with the pinned Earendil Pi host contract.
|
|
20
|
+
2. **Land a testable prompt-mode kernel.**
|
|
21
|
+
- Versioned JSON schema.
|
|
22
|
+
- `append`, `replace_base`, and `replace_final` composition.
|
|
23
|
+
- Global/project/builtin precedence with project-trust gating.
|
|
24
|
+
- Per-file diagnostics, safe paths, atomic writes, and session state replay.
|
|
25
|
+
3. **Land the Pi extension adapter.**
|
|
26
|
+
- `/mode`, `/mode-status`, `/mode-preview`, `/mode-new`, `/mode-edit`, `/mode-delete`.
|
|
27
|
+
- Footer status and `before_agent_start` composition.
|
|
28
|
+
- Explicit `PI_MODE=<key|off>` launch selection without introducing a parallel project-default file.
|
|
29
|
+
- Preserve native `<project>/.pi/SYSTEM.md` and `~/.pi/agent/SYSTEM.md` behavior whenever no named mode is active.
|
|
30
|
+
- No continuation, dispatch, campaign, or authority behavior.
|
|
31
|
+
4. **Add examples and operator documentation.**
|
|
32
|
+
- One example for each strategy.
|
|
33
|
+
- Explain the difference between base and final replacement.
|
|
34
|
+
- Make the package discoverable from root package maps and the runtime capability map.
|
|
35
|
+
5. **Verify.**
|
|
36
|
+
- Unit tests for composition, precedence, malformed files, trust, traversal, persistence, replay, and launch-variable parsing.
|
|
37
|
+
- Package `npm run check` and root package gate.
|
|
38
|
+
- Install the local package, reload Pi, and exercise a real `/mode` flow before claiming live activation.
|
|
39
|
+
|
|
40
|
+
## Follow-up: upstream composition seam
|
|
41
|
+
|
|
42
|
+
Propose or contribute a public Pi host builder for reconstructing a custom base from `BuildSystemPromptOptions`. Add a compatibility-canary scenario, then remove the parity implementation only after live proof.
|
|
43
|
+
|
|
44
|
+
## Deferred autonomy phases
|
|
45
|
+
|
|
46
|
+
Autonomy is intentionally not implemented by `/mode`.
|
|
47
|
+
|
|
48
|
+
1. Emit a non-authoritative, hashed mode-activation snapshot.
|
|
49
|
+
2. Qualify mode profiles through `pi-evalset-lab`.
|
|
50
|
+
3. Add an orchestrator-owned, plan-only autonomy route decision.
|
|
51
|
+
4. Route explicit supervised execution to ASC or visible-loop owners.
|
|
52
|
+
5. Route measured recursive improvement to `pi-autoresearch`.
|
|
53
|
+
6. Keep continuation, durable writes, finalization, cleanup, and promotion under separate explicit gates.
|
|
54
|
+
|
|
55
|
+
The read-only scout architecture packet for this work recommends that mode activation never carry an execute bit, objective, budget, or authority token.
|
|
56
|
+
|
|
57
|
+
## Rollback
|
|
58
|
+
|
|
59
|
+
- `/mode off` restores the host-assembled prompt for subsequent turns.
|
|
60
|
+
- Removing or disabling the package leaves Pi's native `--system-prompt`, `SYSTEM.md`, and `APPEND_SYSTEM.md` behavior unchanged.
|
|
61
|
+
- Custom mode files are plain JSON and do not modify project or global Pi system-prompt files.
|
|
@@ -0,0 +1,101 @@
|
|
|
1
|
+
---
|
|
2
|
+
summary: "Architecture for prompt modes that replace Pi's static base prompt without confusing mode selection with autonomy."
|
|
3
|
+
read_when:
|
|
4
|
+
- "Changing prompt composition, mode storage, activation, or cross-package boundaries."
|
|
5
|
+
- "Evaluating whether a mode may trigger autonomous behavior."
|
|
6
|
+
system4d:
|
|
7
|
+
container: "Session-local prompt-mode extension."
|
|
8
|
+
compass: "Make complete base-prompt replacement first-class while preserving Pi's dynamic envelope by default."
|
|
9
|
+
engine: "Discover -> validate -> activate -> compose -> persist session selection."
|
|
10
|
+
fog: "A final-prompt override can be mistaken for a base-prompt override, and a mode name can be mistaken for execution authority."
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
# Prompt-mode architecture
|
|
14
|
+
|
|
15
|
+
## Decision
|
|
16
|
+
|
|
17
|
+
`pi-modes` owns prompt-profile discovery, validation, selection, prompt composition, session-local persistence, and operator visibility.
|
|
18
|
+
|
|
19
|
+
It supports three explicit strategies:
|
|
20
|
+
|
|
21
|
+
| Strategy | Result |
|
|
22
|
+
|---|---|
|
|
23
|
+
| `append` | Keep Pi's assembled prompt and append mode instructions. |
|
|
24
|
+
| `replace_base` | Replace Pi's static base, then preserve the documented dynamic envelope: append prompt, trusted context files, visible skills, date, and cwd. |
|
|
25
|
+
| `replace_final` | Send exactly the configured mode prompt. No dynamic section is retained automatically. |
|
|
26
|
+
|
|
27
|
+
`replace_base` is the primary strategy. It matches the intent of Pi's `--system-prompt` and `SYSTEM.md` surfaces. `replace_final` is an explicit expert escape hatch rather than an accidental side effect.
|
|
28
|
+
|
|
29
|
+
Pi's native `<project>/.pi/SYSTEM.md` and `~/.pi/agent/SYSTEM.md` remain the default base-prompt authority. This package does not add a second project-default selector. Named `replace_base` modes are explicit alternatives; no active mode and `/mode off` both return control to the native host assembly unchanged.
|
|
30
|
+
|
|
31
|
+
## Why this package exists
|
|
32
|
+
|
|
33
|
+
Pi exposes complete base-prompt replacement at process start, while `before_agent_start` exposes the already assembled prompt. A session mode therefore needs to distinguish changing the base from replacing the final assembly. The extension reconstructs Pi's documented custom-base branch from `event.systemPromptOptions` until Pi exposes a supported host builder or a `systemPromptOptions` return patch.
|
|
34
|
+
|
|
35
|
+
## Runtime flow
|
|
36
|
+
|
|
37
|
+
```text
|
|
38
|
+
native <cwd>/.pi/SYSTEM.md or ~/.pi/agent/SYSTEM.md host base
|
|
39
|
+
+ global built-ins
|
|
40
|
+
+ ~/.pi/agent/modes/*.json
|
|
41
|
+
+ trusted ancestor .pi/modes/*.json from filesystem root to cwd
|
|
42
|
+
-> validate each mode file independently
|
|
43
|
+
-> deepest project overrides shallower project, global, then builtin by key
|
|
44
|
+
-> explicit PI_MODE launch selection, otherwise latest session selection
|
|
45
|
+
-> append changed selection to the active session branch
|
|
46
|
+
-> before_agent_start composes the selected strategy
|
|
47
|
+
-> no selection/off returns the native host base unchanged
|
|
48
|
+
-> footer shows an active named mode
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
Ancestor discovery mirrors Pi's `AGENTS.md` load order: filesystem root down to cwd, with the deepest matching key winning. Project mode files are ignored unless `ctx.isProjectTrusted()` is true. Invalid files produce diagnostics without preventing other modes from loading. `/mode-new --project` writes only at the active cwd. Writes use validated keys and atomic same-directory rename; edit/delete never accept a raw path.
|
|
52
|
+
|
|
53
|
+
A non-blank `PI_MODE` is an explicit process-start override and therefore takes precedence over the restored session selection. `off`, `default`, and `none` select the native host base. Invalid or unavailable values fail closed to that native base with a warning. When `PI_MODE` is absent or blank, session branch replay remains authoritative. Interactive `/mode` commands may change the resolved startup selection for later turns.
|
|
54
|
+
|
|
55
|
+
## Mode contract
|
|
56
|
+
|
|
57
|
+
```json
|
|
58
|
+
{
|
|
59
|
+
"schemaVersion": 1,
|
|
60
|
+
"key": "focused-builder",
|
|
61
|
+
"label": "Focused Builder",
|
|
62
|
+
"description": "Complete coding-agent identity for focused implementation.",
|
|
63
|
+
"promptStrategy": "replace_base",
|
|
64
|
+
"systemPrompt": "You are ..."
|
|
65
|
+
}
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
A missing `promptStrategy` defaults to `replace_base`, making simple custom modes behave like Pi's custom system-prompt feature.
|
|
69
|
+
|
|
70
|
+
## Trust and authority boundary
|
|
71
|
+
|
|
72
|
+
Mode activation changes prompt policy only. It does not:
|
|
73
|
+
|
|
74
|
+
- call `pi.sendUserMessage`;
|
|
75
|
+
- continue after `agent_settled`;
|
|
76
|
+
- dispatch subagents or peers;
|
|
77
|
+
- start visible loops or autoresearch campaigns;
|
|
78
|
+
- mutate AK, Prompt Vault, KES, ROCS, or evidence;
|
|
79
|
+
- grant mutation, promotion, or publication authority.
|
|
80
|
+
|
|
81
|
+
Future autonomy work must consume a separate explicit handoff request through its owning runtime. A mode name such as `research` or `autonomous` is never authorization.
|
|
82
|
+
|
|
83
|
+
## Future host improvement
|
|
84
|
+
|
|
85
|
+
Prefer an upstream Pi API equivalent to one of:
|
|
86
|
+
|
|
87
|
+
```ts
|
|
88
|
+
ctx.buildSystemPrompt({ ...event.systemPromptOptions, customPrompt })
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
or:
|
|
92
|
+
|
|
93
|
+
```ts
|
|
94
|
+
return { systemPromptOptions: { customPrompt } };
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
Once supported and compatibility-tested, replace the package-local parity builder with the host builder to eliminate composition drift.
|
|
98
|
+
|
|
99
|
+
## Attribution
|
|
100
|
+
|
|
101
|
+
The product concept and command vocabulary were informed by Maxime Rivest's MIT-licensed [`pi-modes`](https://github.com/MaximeRivest/pi-modes). This implementation is independently structured around explicit prompt-composition strategies, project trust, safe persistence, and package-local tests.
|
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
{
|
|
2
|
+
"schemaVersion": 1,
|
|
3
|
+
"key": "exact-minimal",
|
|
4
|
+
"label": "Exact Minimal",
|
|
5
|
+
"description": "Demonstrate exact final-prompt replacement for controlled experiments.",
|
|
6
|
+
"promptStrategy": "replace_final",
|
|
7
|
+
"systemPrompt": "Respond concisely and directly to the user's request."
|
|
8
|
+
}
|
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
{
|
|
2
|
+
"schemaVersion": 1,
|
|
3
|
+
"key": "focused-builder",
|
|
4
|
+
"label": "Focused Builder",
|
|
5
|
+
"description": "Replace the static base while retaining Pi's dynamic project envelope.",
|
|
6
|
+
"promptStrategy": "replace_base",
|
|
7
|
+
"systemPrompt": "You are a focused coding agent operating inside Pi. Pursue the operator's requested outcome proactively, keep scope explicit, use available tools deliberately, verify material changes, report blockers early, and distinguish completed work from proposed work."
|
|
8
|
+
}
|
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
{
|
|
2
|
+
"schemaVersion": 1,
|
|
3
|
+
"key": "hard-nosed-review",
|
|
4
|
+
"label": "Hard-nosed Review",
|
|
5
|
+
"description": "Add adversarial review discipline to the current host prompt.",
|
|
6
|
+
"promptStrategy": "append",
|
|
7
|
+
"systemPrompt": "Be skeptical. Look for incorrect assumptions, missing evidence, regressions, authority drift, and tests that pass without proving the requested behavior. State the strongest counterargument before concluding."
|
|
8
|
+
}
|