|
| 1 | +# AGENTS.md |
| 2 | + |
| 3 | +Guidance for coding agents working in this repository. |
| 4 | + |
| 5 | +## Purpose |
| 6 | + |
| 7 | +This repo contains small, self-contained [glance.sh](https://glance.sh) integrations for different coding agents. Each plugin should be easy to read, easy to install, and easy to test locally. |
| 8 | + |
| 9 | +## Repository shape |
| 10 | + |
| 11 | +- Each agent integration lives in its own top-level directory such as `pi/` or `opencode/`. |
| 12 | +- Each plugin directory should contain: |
| 13 | + - `glance.ts`: the plugin implementation |
| 14 | + - `glance.test.ts`: the Vitest suite for that plugin |
| 15 | + - `README.md`: install and usage instructions for that plugin |
| 16 | +- Shared test-only helpers and runtime stubs belong under `test/`. |
| 17 | + |
| 18 | +## Plugin expectations |
| 19 | + |
| 20 | +- Keep plugins self-contained inside their own directory. |
| 21 | +- Prefer platform-native APIs such as `fetch`, `AbortController`, and `ReadableStream` over adding new dependencies. |
| 22 | +- Preserve the style already used in the plugin you are editing instead of forcing a repo-wide formatting style. |
| 23 | +- Match the repo's writing style: concise, direct, and low on filler in code comments, README copy, and PR text. |
| 24 | +- Keep runtime-specific code minimal and explicit. Document runtime assumptions in the plugin `README.md`. |
| 25 | +- Update the plugin `README.md` whenever install steps, behavior, supported commands/tools, or runtime requirements change. |
| 26 | +- If a plugin has internal async/session logic that is hard to verify from the public API alone, expose a small `__testing` surface rather than making production code more coupled. |
| 27 | + |
| 28 | +## Behavior requirements |
| 29 | + |
| 30 | +Every plugin should cover the same core lifecycle: |
| 31 | + |
| 32 | +- create a glance session |
| 33 | +- surface the session URL to the agent or user |
| 34 | +- listen for image events over SSE |
| 35 | +- handle reconnects, timeouts, expiry, and cancellation |
| 36 | +- return or inject the received image URL in the host agent's expected format |
| 37 | + |
| 38 | +If you fix a behavior bug in one plugin, check the other plugins for the same pattern before stopping. |
| 39 | + |
| 40 | +## Testing requirements |
| 41 | + |
| 42 | +- Every plugin must have a Vitest suite in the same directory as the plugin file. |
| 43 | +- Tests should cover both the happy path and failure modes, not just basic registration. |
| 44 | +- At minimum, cover: |
| 45 | + - session creation |
| 46 | + - reuse or refresh of persistent sessions |
| 47 | + - SSE image delivery |
| 48 | + - timeout or expiry handling |
| 49 | + - cancellation or shutdown behavior |
| 50 | + - user-facing command/tool responses |
| 51 | +- Prefer deterministic tests with mocked `fetch`, streams, timers, and runtime APIs. |
| 52 | +- Keep tests local to the plugin. Put only reusable stubs or fixtures in `test/`. |
| 53 | + |
| 54 | +## Tooling and config |
| 55 | + |
| 56 | +When adding a new plugin directory or new test-only runtime stub, update the root tooling so it stays in sync: |
| 57 | + |
| 58 | +- `vitest.config.ts` |
| 59 | +- `tsconfig.json` |
| 60 | +- `package.json` if new scripts are genuinely needed |
| 61 | +- `.github/workflows/test.yml` if CI inputs change |
| 62 | + |
| 63 | +Do not add a build step unless the repository actually needs one. |
| 64 | + |
| 65 | +## Validation |
| 66 | + |
| 67 | +Before opening or updating a PR, run: |
| 68 | + |
| 69 | +```bash |
| 70 | +npm test |
| 71 | +npm run test:coverage |
| 72 | +npm exec -- tsc --noEmit |
| 73 | +``` |
| 74 | + |
| 75 | +If a command cannot be run, say so explicitly and explain why. |
| 76 | + |
| 77 | +## PR checklist |
| 78 | + |
| 79 | +- The plugin implementation, tests, and README are all updated together. |
| 80 | +- New behavior is covered by tests. |
| 81 | +- Root test/typecheck config includes any new plugin or stub paths. |
| 82 | +- CI still runs the repo validation commands on pull requests. |
| 83 | +- The PR description calls out user-visible behavior changes and any runtime-specific caveats in concise language. |
0 commit comments