|
| 1 | +# Repository Guidelines |
| 2 | + |
| 3 | +## Project Structure & Module Organization |
| 4 | + |
| 5 | +- `src/` contains the TypeScript CLI implementation, with tool handlers in `src/tools/`, MCP integration in `src/mcp/`, UI components in `src/ui/`, and shared helpers in `src/common/`. |
| 6 | +- `src/tests/` contains Node test files named `*.test.ts`. |
| 7 | +- `templates/` contains runtime prompt assets: `templates/prompts/` for EJS prompt templates and `templates/tools/` for tool instruction Markdown loaded into the system prompt. |
| 8 | +- `docs/` is reserved for user-facing documentation such as configuration and MCP guides. |
| 9 | +- `resources/` stores static images used by the documentation or UI. |
| 10 | + |
| 11 | +## Build, Test, and Development Commands |
| 12 | + |
| 13 | +- `npm test` runs all test files with `tsx --test`. |
| 14 | +- `npm run test:single -- src/tests/<name>.test.ts` runs one test file. |
| 15 | +- `npm run typecheck` verifies TypeScript types without emitting files. |
| 16 | +- `npm run lint` checks ESLint rules for `src/`. |
| 17 | +- `npm run build` runs checks, bundles `src/cli.tsx` to `dist/cli.js`, and marks the bundle executable. |
| 18 | + |
| 19 | +## Coding Style & Naming Conventions |
| 20 | + |
| 21 | +- Use TypeScript ES modules and keep imports explicit. |
| 22 | +- Prefer small, focused functions; keep filesystem path construction centralized when a path is reused. |
| 23 | +- Use two-space indentation and Prettier-compatible formatting. |
| 24 | +- Respond in standard technical English. Avoid nonstandard phrasing and corporate jargon. |
| 25 | + |
| 26 | +## Testing Guidelines |
| 27 | + |
| 28 | +- Add or update tests in `src/tests/` when changing command behavior, prompt rendering, session flow, tools, or settings. |
| 29 | +- Prefer Node's built-in `node:test` and `node:assert/strict` APIs, matching the existing tests. |
| 30 | +- Keep tests deterministic by using temporary directories and mocked network calls where needed. |
| 31 | + |
| 32 | +## Commit & Pull Request Guidelines |
| 33 | + |
| 34 | +- Keep commits focused on a single change and use concise, imperative commit messages. |
| 35 | +- In pull requests, describe the behavior change, list verification commands, and note any packaging or template path changes. |
0 commit comments