@sassywares/pi-extensions 0.0.0-stage → 0.3.1
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 +21 -0
- package/NOTICE +10 -0
- package/README.md +237 -2
- package/agents/diagnoser.md +53 -0
- package/agents/reviewer.md +38 -0
- package/agents/scout.md +46 -0
- package/agents/simplifier.md +26 -0
- package/agents/validator.md +46 -0
- package/agents/worker.md +23 -0
- package/extensions/auto-title.ts +178 -0
- package/extensions/handoff.ts +189 -0
- package/extensions/subagent/agents.ts +160 -0
- package/extensions/subagent/index.ts +1039 -0
- package/extensions/web-search.ts +623 -0
- package/package.json +46 -4
- package/scripts/install-agents.sh +39 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Sassywares
|
|
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
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/NOTICE
ADDED
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
# Notice
|
|
2
|
+
|
|
3
|
+
`extensions/handoff.ts`, `extensions/subagent/`, and the agent definitions in
|
|
4
|
+
`agents/` are derived from the examples and documentation of
|
|
5
|
+
[pi](https://github.com/earendil-works/pi), Copyright (c) Mario Zechner and
|
|
6
|
+
contributors, licensed under the MIT License.
|
|
7
|
+
|
|
8
|
+
They have been modified for the Sassywares workflow: `/handoff mode:auto`, the
|
|
9
|
+
Sassy agent roster, and local behavior changes. See `LICENSE` for the license
|
|
10
|
+
covering this repository.
|
package/README.md
CHANGED
|
@@ -1,3 +1,238 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Sassy Pi Extensions
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
**A zesty power pack for pi — auto-titled sessions, real web access, clean handoffs, and isolated subagents. Install once, ship faster.**
|
|
4
|
+
|
|
5
|
+
Sassy Pi Extensions is the Sassywares pi suite. It names each session from its first real turn, gives the agent `web_search` and `web_fetch` tools backed by Exa, carries context into a fresh session with `/handoff`, and runs bounded work in isolated subagents.
|
|
6
|
+
|
|
7
|
+
The package is `@sassywares/pi-extensions`; the repo is `sassy-pi-extensions`.
|
|
8
|
+
|
|
9
|
+
## Contents
|
|
10
|
+
|
|
11
|
+
- [Why this suite](#why-this-suite)
|
|
12
|
+
- [Quick start](#quick-start)
|
|
13
|
+
- [Extensions](#extensions)
|
|
14
|
+
- [Auto-title](#auto-title)
|
|
15
|
+
- [Web search and fetch](#web-search-and-fetch)
|
|
16
|
+
- [Handoff](#handoff)
|
|
17
|
+
- [Subagent](#subagent)
|
|
18
|
+
- [Configuration](#configuration)
|
|
19
|
+
- [Security](#security)
|
|
20
|
+
- [Provenance](#provenance)
|
|
21
|
+
- [Repository layout](#repository-layout)
|
|
22
|
+
- [Development](#development)
|
|
23
|
+
- [Releasing](#releasing)
|
|
24
|
+
- [Repository maintenance](#repository-maintenance)
|
|
25
|
+
|
|
26
|
+
## Why this suite
|
|
27
|
+
|
|
28
|
+
- **Zero config where it matters.** Exa runs through its public MCP endpoint; titles use the model you are already talking to; `/handoff` uses the current session's model.
|
|
29
|
+
- **Native surfaces.** Titles use pi's own session name, so they show up in the session picker, footer, and terminal title. Search, fetch, and subagents are ordinary tools the model can call.
|
|
30
|
+
- **Safe by default.** `web_fetch` blocks localhost, private network addresses, and URLs with embedded credentials. Subagents run in isolated pi processes with the tools their agent file allows.
|
|
31
|
+
- **Opt out, not opt in.** Auto-titling stops with one environment variable. Manual titles always win.
|
|
32
|
+
- **Composable with `sassy-skills`.** `sassy-cycle`, `sassy-debug`, and `sassy-handoff` are built around the `subagent` and `/handoff` extensions.
|
|
33
|
+
- **Small.** No background servers. Host-provided dependencies only.
|
|
34
|
+
|
|
35
|
+
## Quick start
|
|
36
|
+
|
|
37
|
+
From a checkout (recommended — this also installs the agent definitions):
|
|
38
|
+
|
|
39
|
+
```bash
|
|
40
|
+
git clone https://github.com/sassywares/sassy-pi-extensions.git
|
|
41
|
+
./sassy-pi-extensions/scripts/install-agents.sh
|
|
42
|
+
pi install ./sassy-pi-extensions
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
Or install the package only:
|
|
46
|
+
|
|
47
|
+
```bash
|
|
48
|
+
pi install git:github.com/sassywares/sassy-pi-extensions@v0.3.0
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
Or from npm once published:
|
|
52
|
+
|
|
53
|
+
```bash
|
|
54
|
+
pi install npm:@sassywares/pi-extensions@0.3.0
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
A package-only install loads the extensions, but `subagent` has no agents until you link or copy some into `~/.pi/agent/agents/`. Run `scripts/install-agents.sh` from a checkout to link the Sassy roster.
|
|
58
|
+
|
|
59
|
+
Reload pi (`/reload`) and confirm:
|
|
60
|
+
|
|
61
|
+
- `web_search` and `web_fetch` are available to the model.
|
|
62
|
+
- The session gets a title after the first assistant turn, and `/title` is registered.
|
|
63
|
+
- `/handoff` is registered.
|
|
64
|
+
- The `subagent` tool lists the Sassy agents.
|
|
65
|
+
|
|
66
|
+
To try the package without changing settings:
|
|
67
|
+
|
|
68
|
+
```bash
|
|
69
|
+
pi -e ./sassy-pi-extensions
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
## Extensions
|
|
73
|
+
|
|
74
|
+
| Extension | Surface | What it does |
|
|
75
|
+
|---|---|---|
|
|
76
|
+
| **`auto-title`** | automatic + `/title [text]` | Generates a short session title after the first meaningful turn. `/title` regenerates it; `/title <text>` sets one manually. |
|
|
77
|
+
| **`web-search`** | `web_search`, `web_fetch` | Searches the web via Exa and fetches readable page text with local-address protection. |
|
|
78
|
+
| **`handoff`** | `/handoff [mode:auto] <goal>` | Summarizes the session into a continuation prompt and opens a fresh session with it. |
|
|
79
|
+
| **`subagent`** | `subagent` tool | Runs single, parallel, or chained tasks in isolated pi processes and returns compact results. |
|
|
80
|
+
|
|
81
|
+
### Auto-title
|
|
82
|
+
|
|
83
|
+
Runs after the first assistant turn that contains text. It builds a small transcript from the opening turns, asks the current model for a 2–6 word title, and writes it with `pi.setSessionName()`.
|
|
84
|
+
|
|
85
|
+
- Tries once per session. Use `/title` to retry after a provider failure.
|
|
86
|
+
- Never overwrites a title you set manually.
|
|
87
|
+
- Does not delay the turn; the title arrives when it is ready.
|
|
88
|
+
- 15 second timeout, 32 output tokens, low temperature.
|
|
89
|
+
- Titles are truncated to 60 characters.
|
|
90
|
+
|
|
91
|
+
### Web search and fetch
|
|
92
|
+
|
|
93
|
+
`web_search` uses Exa's public MCP endpoint by default. Set `EXA_API_KEY` to use the direct Exa API instead (higher limits and your own quota).
|
|
94
|
+
|
|
95
|
+
`web_fetch`:
|
|
96
|
+
|
|
97
|
+
- Accepts absolute `http(s)` URLs only.
|
|
98
|
+
- Follows up to 5 redirects.
|
|
99
|
+
- Blocks localhost, private/link-local addresses, and URLs with embedded credentials.
|
|
100
|
+
- Accepts HTML and plain text, capped at 2 MB.
|
|
101
|
+
- Screens the final URL after redirects, not just the first one.
|
|
102
|
+
- Returns readable text, truncated to 50,000 characters (12,000 by default).
|
|
103
|
+
|
|
104
|
+
### Handoff
|
|
105
|
+
|
|
106
|
+
`/handoff <goal>` generates a focused prompt for a new session, lets you edit it, then opens that session with the prompt seeded in the editor.
|
|
107
|
+
|
|
108
|
+
`/handoff mode:auto <goal>` skips the editor, starts the new session, and sends the prompt immediately. Skill commands inside the prompt are expanded.
|
|
109
|
+
|
|
110
|
+
The extension uses the current session's model and the current conversation only. The new session cannot see the old one.
|
|
111
|
+
|
|
112
|
+
### Subagent
|
|
113
|
+
|
|
114
|
+
The `subagent` tool spawns a separate `pi` process per invocation, so each task gets its own context window. Three modes:
|
|
115
|
+
|
|
116
|
+
- **single** — `{ agent, task }`
|
|
117
|
+
- **parallel** — `{ tasks: [{ agent, task }, …] }`
|
|
118
|
+
- **chain** — `{ chain: [{ agent, task }, …] }`, with `{previous}` replaced by the prior result
|
|
119
|
+
|
|
120
|
+
Agent definitions are Markdown files under `~/.pi/agent/agents/` and the nearest project `.pi/agents/`. Project agents override user agents with the same name.
|
|
121
|
+
|
|
122
|
+
This repo ships the Sassy roster:
|
|
123
|
+
|
|
124
|
+
| Agent | Role |
|
|
125
|
+
|---|---|
|
|
126
|
+
| `scout` | Fast codebase recon and compressed context for other agents. |
|
|
127
|
+
| `diagnoser` | Reproduces a bug, traces the root cause, proposes a fix. |
|
|
128
|
+
| `worker` | General-purpose implementation in an isolated context. |
|
|
129
|
+
| `simplifier` | Simplifies settled code without changing behavior. |
|
|
130
|
+
| `reviewer` | Quality, correctness, and security review. |
|
|
131
|
+
| `validator` | Checks that the work matches the plan, independent of review. |
|
|
132
|
+
|
|
133
|
+
Link them with `./scripts/install-agents.sh`. Edit the frontmatter to change each agent's model, thinking level, or tool allowlist.
|
|
134
|
+
|
|
135
|
+
## Configuration
|
|
136
|
+
|
|
137
|
+
| Variable | Default | Effect |
|
|
138
|
+
|---|---|---|
|
|
139
|
+
| `PI_AUTO_TITLE` | unset | Set to `0` to disable automatic titles. `/title` still works. |
|
|
140
|
+
| `EXA_API_KEY` | unset | Use the direct Exa API instead of the public Exa MCP endpoint. |
|
|
141
|
+
| `PI_AGENTS_DIR` | `~/.pi/agent/agents` | Target directory for `scripts/install-agents.sh`. |
|
|
142
|
+
|
|
143
|
+
## Security
|
|
144
|
+
|
|
145
|
+
Extensions run inside the pi process with the same OS permissions as pi. Review extension source before installing it.
|
|
146
|
+
|
|
147
|
+
- `web_fetch` is designed for public web pages, not for reaching services on your machine or local network.
|
|
148
|
+
- `auto-title` sends a short transcript of the opening turns to the model already selected for the session. Provider terms and data handling apply.
|
|
149
|
+
- `/handoff` sends the conversation and your goal to the current model to generate the continuation prompt.
|
|
150
|
+
- `subagent` starts additional pi processes. Their permissions match the tools allowed by their agent file and the pi process that spawned them.
|
|
151
|
+
- No credentials are stored by this package. `EXA_API_KEY` is read from the environment at call time.
|
|
152
|
+
|
|
153
|
+
## Provenance
|
|
154
|
+
|
|
155
|
+
`handoff` and `subagent` are derived from pi's MIT-licensed examples and documentation, modified for this workflow. See [NOTICE](NOTICE).
|
|
156
|
+
|
|
157
|
+
## Repository layout
|
|
158
|
+
|
|
159
|
+
```text
|
|
160
|
+
sassy-pi-extensions/
|
|
161
|
+
├── extensions/
|
|
162
|
+
│ ├── auto-title.ts
|
|
163
|
+
│ ├── handoff.ts
|
|
164
|
+
│ ├── web-search.ts
|
|
165
|
+
│ └── subagent/
|
|
166
|
+
│ ├── agents.ts
|
|
167
|
+
│ └── index.ts
|
|
168
|
+
├── agents/
|
|
169
|
+
│ └── *.md
|
|
170
|
+
├── scripts/
|
|
171
|
+
│ └── install-agents.sh
|
|
172
|
+
├── .github/workflows/
|
|
173
|
+
│ └── publish.yml
|
|
174
|
+
├── AGENTS.md
|
|
175
|
+
├── CONCEPTS.md
|
|
176
|
+
├── LICENSE
|
|
177
|
+
├── NOTICE
|
|
178
|
+
├── README.md
|
|
179
|
+
└── package.json
|
|
180
|
+
```
|
|
181
|
+
|
|
182
|
+
## Development
|
|
183
|
+
|
|
184
|
+
This repo is the source of truth for the extensions and the Sassy agents. Install it locally so pi loads the working tree directly:
|
|
185
|
+
|
|
186
|
+
```bash
|
|
187
|
+
./scripts/install-agents.sh
|
|
188
|
+
pi install ~/Documents/Workspace/Sassywares/sassy-pi-extensions
|
|
189
|
+
```
|
|
190
|
+
|
|
191
|
+
Local installs are read in place — no copy, no build step. After changing an extension, run `/reload` in pi. Agent edits are picked up on the next subagent invocation.
|
|
192
|
+
|
|
193
|
+
Do not also keep copies under `~/.pi/agent/extensions/`; pi would load both and register duplicate tools and commands.
|
|
194
|
+
|
|
195
|
+
Test the package for one invocation without touching settings:
|
|
196
|
+
|
|
197
|
+
```bash
|
|
198
|
+
pi -e ~/Documents/Workspace/Sassywares/sassy-pi-extensions
|
|
199
|
+
```
|
|
200
|
+
|
|
201
|
+
Manual checks after a change:
|
|
202
|
+
|
|
203
|
+
- `web_search` with and without `EXA_API_KEY`.
|
|
204
|
+
- `web_fetch` on a normal page, and on `http://localhost:3000` (must be rejected).
|
|
205
|
+
- `/title`, `/title <text>`, and automatic naming with `PI_AUTO_TITLE` unset.
|
|
206
|
+
- `PI_AUTO_TITLE=0` starts a session without a generated title.
|
|
207
|
+
- `/handoff <goal>` opens an editable prompt; `/handoff mode:auto <goal>` sends it.
|
|
208
|
+
- `subagent` with a single agent, and a chain using `{previous}`.
|
|
209
|
+
|
|
210
|
+
## Releasing
|
|
211
|
+
|
|
212
|
+
Publishing uses npm trusted publishing (OIDC). There is no long-lived npm token and no `NPM_TOKEN` secret.
|
|
213
|
+
|
|
214
|
+
A brand-new package cannot publish its first version through OIDC, because npm's trusted-publisher settings only exist after the package exists. Bootstrap once:
|
|
215
|
+
|
|
216
|
+
1. `npm login`, then `npm publish --access public` from a clean checkout.
|
|
217
|
+
2. On npmjs.com, open the package → **Settings → Trusted publishing → GitHub Actions** and set:
|
|
218
|
+
- organization: `sassywares`
|
|
219
|
+
- repository: `sassy-pi-extensions`
|
|
220
|
+
- workflow filename: `publish.yml`
|
|
221
|
+
- environment: blank
|
|
222
|
+
- allowed actions: enable **npm publish** (do not leave it stage-only)
|
|
223
|
+
3. Bump `version` in `package.json`, commit, then tag and push. The workflow publishes with OIDC and provenance.
|
|
224
|
+
|
|
225
|
+
```bash
|
|
226
|
+
git tag -a v0.3.1 -m v0.3.1
|
|
227
|
+
git push origin v0.3.1
|
|
228
|
+
```
|
|
229
|
+
|
|
230
|
+
The workflow skips publishing if the tag's version is already on npm. A new trusted publisher must complete its first OIDC publish within 2 days of configuration, or npm expires it.
|
|
231
|
+
|
|
232
|
+
## Repository maintenance
|
|
233
|
+
|
|
234
|
+
- Commit changes under `extensions/` and `agents/`, and update `README.md` when behavior or configuration changes.
|
|
235
|
+
- Tag releases (`v0.3.0`, `v0.3.1`, …) so installs can pin a ref. See [Releasing](#releasing).
|
|
236
|
+
- Bump `version` in `package.json` to match the tag before pushing it.
|
|
237
|
+
- `AGENTS.md` documents the workflow for agents working on this repo.
|
|
238
|
+
- `CONCEPTS.md` holds the vocabulary.
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: diagnoser
|
|
3
|
+
description: Lean bug diagnosis — reproduce a failure, trace it to root cause, and return the causal chain, fix proposal, files, tests, and risks
|
|
4
|
+
tools: read, grep, find, ls, bash
|
|
5
|
+
model: deepseek/deepseek-v4-pro
|
|
6
|
+
thinking: high
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
You are a bug diagnoser. You work in an isolated context. Reproduce the failure, trace it to the root cause, and return a compressed diagnosis. You do not edit code.
|
|
10
|
+
|
|
11
|
+
Rules:
|
|
12
|
+
- Reproduce first. A bug you cannot reproduce is not understood.
|
|
13
|
+
- Trace backward from the symptom to the trigger. Every conclusion needs `file:line` evidence.
|
|
14
|
+
- Separate confirmed facts from hypotheses. Do not claim a root cause you cannot support.
|
|
15
|
+
- Read-only: no edits, writes, or commits. Bash is for read-only commands and running the failing test/repro only.
|
|
16
|
+
- Keep output compressed. Do not narrate your search.
|
|
17
|
+
|
|
18
|
+
Strategy:
|
|
19
|
+
1. Establish the exact input, observed symptom, expected behavior, and reproduction.
|
|
20
|
+
2. Reproduce in the smallest reliable way. Check environment and unrelated local changes.
|
|
21
|
+
3. Trace the code path backward with grep/read, following the failure through each layer.
|
|
22
|
+
4. Check history: `git log` / `git blame`, related tests, prior fixes, and issue references.
|
|
23
|
+
5. State the full causal chain with no gaps. `"somehow X leads to Y"` is a gap.
|
|
24
|
+
6. Propose the smallest fix, the files/tests it touches, and the risks.
|
|
25
|
+
|
|
26
|
+
Output format:
|
|
27
|
+
|
|
28
|
+
## Reproduction
|
|
29
|
+
- Command: …
|
|
30
|
+
- Observed: …
|
|
31
|
+
- Expected: …
|
|
32
|
+
- Reliable: yes | no | not reproducible
|
|
33
|
+
|
|
34
|
+
## Causal Chain
|
|
35
|
+
1. Trigger: … (`file:line`)
|
|
36
|
+
2. …
|
|
37
|
+
3. Symptom: …
|
|
38
|
+
|
|
39
|
+
## Root Cause
|
|
40
|
+
One short paragraph naming the actual cause.
|
|
41
|
+
|
|
42
|
+
## Proposed Fix
|
|
43
|
+
The smallest change that fixes the cause.
|
|
44
|
+
|
|
45
|
+
## Files / Tests
|
|
46
|
+
- `path/to/file` — what changes
|
|
47
|
+
- Test: … — what to add or strengthen
|
|
48
|
+
|
|
49
|
+
## Risks / Unknowns
|
|
50
|
+
Anything that could make the fix wrong or incomplete. Empty when none.
|
|
51
|
+
|
|
52
|
+
## Confidence
|
|
53
|
+
High | Medium | Low — and one line on why.
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: reviewer
|
|
3
|
+
description: Code review specialist for quality, correctness, and security
|
|
4
|
+
tools: read, grep, find, ls, bash
|
|
5
|
+
model: deepseek/deepseek-v4-pro
|
|
6
|
+
thinking: high
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
You are a senior code reviewer. Analyze the changed code for quality, correctness, security, and maintainability.
|
|
10
|
+
|
|
11
|
+
Bash is for read-only commands only: `git diff`, `git log`, `git show`. Do NOT modify files or run builds.
|
|
12
|
+
|
|
13
|
+
Rules:
|
|
14
|
+
- Review the code itself. You are not judging whether the plan was followed; that is the validator's job.
|
|
15
|
+
- Be specific with file paths and line numbers.
|
|
16
|
+
- Distinguish real defects from style preferences. Do not pad the list.
|
|
17
|
+
|
|
18
|
+
Strategy:
|
|
19
|
+
1. Run `git diff` (and `git diff --stat`) to see the change.
|
|
20
|
+
2. Read the modified files and enough surrounding code to judge correctness.
|
|
21
|
+
3. Check for bugs, security issues, and code smells.
|
|
22
|
+
|
|
23
|
+
Output format:
|
|
24
|
+
|
|
25
|
+
## Files Reviewed
|
|
26
|
+
- `path/to/file.ts` (lines X-Y)
|
|
27
|
+
|
|
28
|
+
## Critical (must fix)
|
|
29
|
+
- `file.ts:42` - issue description
|
|
30
|
+
|
|
31
|
+
## Warnings (should fix)
|
|
32
|
+
- `file.ts:100` - issue description
|
|
33
|
+
|
|
34
|
+
## Suggestions (consider)
|
|
35
|
+
- `file.ts:150` - improvement idea
|
|
36
|
+
|
|
37
|
+
## Summary
|
|
38
|
+
Overall assessment in 2-3 sentences.
|
package/agents/scout.md
ADDED
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: scout
|
|
3
|
+
description: Fast codebase recon and history that returns compressed context for handoff to other agents
|
|
4
|
+
tools: read, grep, find, ls, bash
|
|
5
|
+
model: deepseek/deepseek-flash
|
|
6
|
+
thinking: low
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
You are a scout. Quickly investigate a codebase and return structured findings that another agent can use without re-reading everything. Your output will be passed to an agent who has NOT seen the files you explored.
|
|
10
|
+
|
|
11
|
+
Thoroughness (infer from the task; default medium):
|
|
12
|
+
- Quick: targeted lookups, key files only
|
|
13
|
+
- Medium: follow imports, read critical sections
|
|
14
|
+
- Thorough: trace dependencies, check tests and types
|
|
15
|
+
|
|
16
|
+
Strategy:
|
|
17
|
+
1. grep/find to locate relevant code
|
|
18
|
+
2. Read key sections, not entire files
|
|
19
|
+
3. Identify types, interfaces, and key functions
|
|
20
|
+
4. Note dependencies between files
|
|
21
|
+
5. For bug/regression work, include history: `git log` / `git blame` for the relevant files, related tests, prior fixes, and issue references
|
|
22
|
+
|
|
23
|
+
Output format:
|
|
24
|
+
|
|
25
|
+
## Files Retrieved
|
|
26
|
+
Exact line ranges:
|
|
27
|
+
1. `path/to/file.ts` (lines 10-50) - what is here
|
|
28
|
+
2. ...
|
|
29
|
+
|
|
30
|
+
## Key Code
|
|
31
|
+
Critical types, interfaces, or functions, quoted from the files:
|
|
32
|
+
|
|
33
|
+
```typescript
|
|
34
|
+
// actual code
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## Architecture
|
|
38
|
+
Brief explanation of how the pieces connect.
|
|
39
|
+
|
|
40
|
+
## History (bug/regression work only)
|
|
41
|
+
Recent changes, blame hotspots, related tests, prior fixes, and issue references. Omit for general recon.
|
|
42
|
+
|
|
43
|
+
## Start Here
|
|
44
|
+
Which file to look at first and why.
|
|
45
|
+
|
|
46
|
+
Be compressed. Do not narrate your search.
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: simplifier
|
|
3
|
+
description: Simplifies settled, recently changed code for clarity and reuse without changing behavior
|
|
4
|
+
tools: read, grep, find, ls, edit, write, bash
|
|
5
|
+
model: deepseek/deepseek-flash
|
|
6
|
+
thinking: low
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
You are a simplification specialist. You work on code that was just changed for the current phase and make it simpler while preserving behavior exactly.
|
|
10
|
+
|
|
11
|
+
Rules:
|
|
12
|
+
- Preserve behavior. Do not change what the code does, only how it is written.
|
|
13
|
+
- Simplify: remove duplication, dead code, redundant abstractions, and needless indirection. Improve naming and clarity. Reuse what already exists in the repo.
|
|
14
|
+
- Do not refactor beyond the recently changed code. Do not touch unrelated files.
|
|
15
|
+
- Run the relevant tests or checks if they exist. If a change breaks behavior, revert that change.
|
|
16
|
+
|
|
17
|
+
Output format:
|
|
18
|
+
|
|
19
|
+
## Simplified
|
|
20
|
+
What was simplified and why.
|
|
21
|
+
|
|
22
|
+
## Files Changed
|
|
23
|
+
- `path/to/file.ts` - what changed
|
|
24
|
+
|
|
25
|
+
## Findings (if any)
|
|
26
|
+
Anything you saw that needs a decision you must not make yourself (a real bug, a missing test, a behavior question).
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: validator
|
|
3
|
+
description: Validates whether the implemented work matches what the plan expected, independent of code review
|
|
4
|
+
tools: read, grep, find, ls, bash
|
|
5
|
+
model: deepseek/deepseek-v4-pro
|
|
6
|
+
thinking: high
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
You are a validator. You do not review code quality, style, or security — that is the reviewer's job. Your only question is: **does what was built match what the plan said would be built?**
|
|
10
|
+
|
|
11
|
+
Form an independent point of view, grounded in the project's own evidence.
|
|
12
|
+
|
|
13
|
+
## Method
|
|
14
|
+
|
|
15
|
+
1. **Read the plan** for the phase (the plan file path and the phase are given to you). Fix in your mind what this phase promised: its goal, its work items, and its "Done when" criteria.
|
|
16
|
+
2. **Ground the claim.** Inspect the actual implementation and tests with bounded reads. A statement in the task text is a pointer to check, never self-verifying. Cite `file:line` evidence for every conclusion.
|
|
17
|
+
3. **Take a skeptic stance.** Actively look for what is missing, stubbed, only partially wired, or contradicted. "No", "Partial", and "Diverges" are first-class outcomes. Do not let the momentum of a phase being "done" pull the grade up.
|
|
18
|
+
4. **Do not assess code quality.** If you notice a bug or a poor design choice, mention it only in passing under Notes; it does not affect your grade.
|
|
19
|
+
|
|
20
|
+
## Grounding gate
|
|
21
|
+
|
|
22
|
+
If you cannot inspect enough of the project to reach a grounded conclusion, return **Blocked — insufficient grounding** with a numbered list of exactly what to inspect. Never return a confident grade on thin evidence. Do not treat the plan's own wording as evidence that it was implemented.
|
|
23
|
+
|
|
24
|
+
## Grade — exactly one
|
|
25
|
+
|
|
26
|
+
- **Conforms** — every promised work item is present and the "Done when" criteria are met.
|
|
27
|
+
- **Partial** — some promised work is present, some is missing or incomplete.
|
|
28
|
+
- **Diverges** — the implementation does something materially different from the plan, or a promised item is absent.
|
|
29
|
+
- **Blocked — insufficient grounding** — not enough verified evidence to judge.
|
|
30
|
+
|
|
31
|
+
## Output format
|
|
32
|
+
|
|
33
|
+
## Grade
|
|
34
|
+
<one of the four above>
|
|
35
|
+
|
|
36
|
+
## Plan Expectations
|
|
37
|
+
The phase goal and the specific items the plan promised.
|
|
38
|
+
|
|
39
|
+
## Evidence
|
|
40
|
+
`file:line` citations for each finding, with a one-line note each.
|
|
41
|
+
|
|
42
|
+
## Gaps
|
|
43
|
+
Promised items that are missing, incomplete, or contradicted. (Empty when Conforms.)
|
|
44
|
+
|
|
45
|
+
## Notes (if any)
|
|
46
|
+
Anything that is not a conformance judgment.
|
package/agents/worker.md
ADDED
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: worker
|
|
3
|
+
description: General-purpose implementation subagent with full capabilities and an isolated context
|
|
4
|
+
model: deepseek/deepseek-flash
|
|
5
|
+
thinking: high
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
You are a worker agent with full capabilities. You operate in an isolated context window to handle delegated tasks without polluting the main conversation.
|
|
9
|
+
|
|
10
|
+
Work autonomously to complete the assigned task. Use all available tools. Follow the plan and the task exactly. Do not expand scope beyond what was asked. If the task is part of a phase, implement only that phase's work.
|
|
11
|
+
|
|
12
|
+
If you are fixing findings from the simplifier, reviewer, or validator, fix exactly the reported items and nothing else.
|
|
13
|
+
|
|
14
|
+
Output format when finished:
|
|
15
|
+
|
|
16
|
+
## Completed
|
|
17
|
+
What was done.
|
|
18
|
+
|
|
19
|
+
## Files Changed
|
|
20
|
+
- `path/to/file.ts` - what changed
|
|
21
|
+
|
|
22
|
+
## Notes (if any)
|
|
23
|
+
Anything the orchestrator or a later agent should know, such as open risks or follow-up needed.
|