{"owner":"omnigent-ai","repo":"omnigent","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".github/copilot-instructions.md"],"skills":{"AGENTS.md":"# Agent guidance\n\nGuidance for AI agents (Claude Code, Copilot, Cursor, etc.) working in this\nrepository. See `CONTRIBUTING.md` for the full contributor workflow.\n\n## Committing\n\nRun the `pre-commit` hook before committing (`pre-commit run --all-files`, or\nlet it run on staged files via `git commit`). Fix any issues it reports so the\ncommit lands clean — CI runs the same checks.\n\n## Local development shortcuts\n\nUse `just` for common tasks; run `just --list` for grouped recipes.\n\n- `just ensure` — install/check prerequisites\n- `just run-ios` / `just run-android` — build/run mobile apps\n- `just dev` / `just dev-mobile` — start the omnigent dev pod\n- `just electron-dev` / `just electron-build` — Electron desktop shell\n- `just lint` / `just lint-all` — run pre-commit\n- `just normalize-locks` — rewrite lockfile registries to PyPI/npmjs.org\n\n## Pull requests\n\nWhen you open a pull request, fill in the repo's PR template at\n`.github/pull_request_template.md` (case-sensitive on Linux — note the lowercase\nfilename). Keep every section and checkbox row so reviewers can skim them.\n\n- **Summary** — what changed and why.\n- **Test Plan** — how you verified it.\n- **Demo** — a **video or images** showing the change. Expected on contributor\n  PRs for UI / frontend changes (check the \"UI / frontend change\" box under\n  *Type of change*) so reviewers can see the new behaviour without checking out\n  the branch. Use `N/A` for non-visual changes.\n- **Type of change** / **Test coverage** — check all that apply (at least one\n  each).\n- **Coverage notes** — required if you checked \"Manual verification completed\"\n  or \"Not applicable\".\n\nGenerate the description from the actual diff and this session's context — lead\nwith the motivation, then the change. Don't pass a `--body` that skips these\nsections.\n\n## Finishing a task\n\nWhen you finish a task, print instructions to the user on how to test it: the\ncommands to run, the inputs to provide, or the steps to reproduce so they can\nverify the result themselves. Prefer verification that is best performed by a\nhuman, such as concrete manual behavior checks, rather than only listing unit\ntest commands. Don't leave the user guessing how to confirm the work — tell\nthem exactly what to do.\n\n## Deprecating features\n\nWhen deprecating a feature, note the version in which it is expected to be\nremoved so we can clean it up when that version ships. Call out the deprecation\nversion in code (e.g. a `@deprecated` tag or comment naming the target release)\nand in the PR/commit description, so there's a clear marker to act on later.\n\n## Code comments\n\nKeep comments short and focused on the code, not on the change history.\n\n- **Keep them brief** — prefer one or two lines. Avoid comments longer than\n  three lines; if you need more, the code likely needs refactoring or a doc\n  string, not a wall of inline commentary.\n- **Describe the scenario, not the PR** — explain *what* the code handles or\n  *why* it exists, in terms a future reader needs. Don't reference PR numbers,\n  issue numbers, or ticket IDs (e.g. `#1646`, `fixes JIRA-123`); the scenario\n  should be clear without chasing external links.\n\n## Database query names\n\nApplication stores use `make_named_managed_session_maker` and give every\nsession a stable semantic operation name. The session-level name must describe\nthe caller's intent rather than repeat SQL syntax; use a nested\n`query_name_scope` only when one transaction needs distinct names for important\nsubqueries. Because the named session covers implicit flush and commit, don't\nadd an explicit `flush()` only to make a query name observable.\n\n## Framework-owned instructions\n\nKeep runtime lifecycle and metadata instructions separate from portable agent\ninstructions:\n\n- Agent-spec and per-request instructions are user-authored. Framework-owned\n  instructions are additive runtime behavior and are appended after them in\n  `omnigent/runtime/prompt.py`.\n- Keep the canonical instruction text and lifecycle gate in the owning framework\n  module. Harness adapters should only transport the composed instructions; do\n  not duplicate policy across adapters or add lifecycle metadata to `AgentSpec`.\n- If framework instructions grow beyond a small ordered list, introduce a\n  structured `FrameworkInstructions` value at the prompt-composition boundary.\n",".github/copilot-instructions.md":"# Copilot Code Review Instructions\n\n## E2E Test Requirement\n\nEvery pull request that introduces a new feature **must** include at least one\nend-to-end (e2e) test covering the happy-path behaviour of that feature.\n\n- E2E tests live under `tests/e2e/`.\n- If a PR adds new user-facing functionality and does not add or update an e2e\n  test, flag it as a required change.\n- Bug-fix or refactor PRs that do not change observable behaviour are exempt.\n\n## Backend Test Coverage\n\nA pull request that changes behaviour under `omnigent/` should add or update a\ntest in the suite matching the area it touches. If a behaviour change ships\nwithout a covering test, flag it and name the suite the test belongs in.\n\nPrefer a fast, focused **unit test** in the area suite — that is what most\nchanges need. Only expect an `integration` or `e2e` test when the change\ngenuinely spans components or full-stack flows; do not push for a heavier test\nwhere a unit test would suffice.\n\nMost backend areas mirror their source directory under `tests/`:\n\n| Area changed (`omnigent/…`) | Expected test suite (`tests/…`) |\n| --- | --- |\n| `server/` | `server/` |\n| `runner/` | `runner/` |\n| `runtime/` | `runtime/` |\n| `tools/` | `tools/` |\n| `inner/` | `inner/` |\n| `llms/` | `llms/` |\n| `db/` | `db/` (flag schema migrations especially) |\n| `policies/` | `policies/` |\n| `repl/` | `repl/` |\n| `entities/` | `entities/` |\n| `stores/` | `stores/` |\n| `host/` | `host/` |\n| `spec/` | `spec/` |\n\n- A test under `tests/integration/` or `tests/e2e/` that exercises the change\n  also satisfies the requirement — don't insist on the exact area suite.\n- Do not ask for a test for pure refactors, renames, type-only changes,\n  dependency bumps, comment/docstring/logging edits, or anything with no\n  observable behaviour change.\n- A trivial, empty, or unrelated test does not count as coverage.\n- When in doubt about whether a change needs a test, raise it as a question\n  rather than a required change.\n\n## Frontend Test Coverage\n\nA pull request that changes behaviour under `web/` should add or update a\n**colocated Vitest unit test** — a `*.test.ts` or `*.test.tsx` file beside the\ncomponent or module it touches. If a behaviour change ships without one, flag it.\n\n- A change to user-facing UI behaviour additionally needs a Playwright test\n  under `tests/e2e_ui/`. That requirement is already enforced by the\n  `E2E UI Required` status check, so do not re-flag it here — focus the review\n  on the colocated unit test.\n- A UI / frontend PR should also include a **video or images** in the `Demo`\n  section of the PR description (with the \"UI / frontend change\" box checked).\n  If a UI PR has an empty Demo section, flag it as a request for a screenshot\n  or recording.\n- Do not ask for a test for styling/formatting-only changes, copy tweaks with\n  no flow change, type-only changes, dependency bumps, or refactors with no\n  observable behaviour change.\n- A trivial, empty, or unrelated test does not count as coverage.\n"},"files":{"AGENTS.md":"# Agent guidance\n\nGuidance for AI agents (Claude Code, Copilot, Cursor, etc.) working in this\nrepository. See `CONTRIBUTING.md` for the full contributor workflow.\n\n## Committing\n\nRun the `pre-commit` hook before committing (`pre-commit run --all-files`, or\nlet it run on staged files via `git commit`). Fix any issues it reports so the\ncommit lands clean — CI runs the same checks.\n\n## Local development shortcuts\n\nUse `just` for common tasks; run `just --list` for grouped recipes.\n\n- `just ensure` — install/check prerequisites\n- `just run-ios` / `just run-android` — build/run mobile apps\n- `just dev` / `just dev-mobile` — start the omnigent dev pod\n- `just electron-dev` / `just electron-build` — Electron desktop shell\n- `just lint` / `just lint-all` — run pre-commit\n- `just normalize-locks` — rewrite lockfile registries to PyPI/npmjs.org\n\n## Pull requests\n\nWhen you open a pull request, fill in the repo's PR template at\n`.github/pull_request_template.md` (case-sensitive on Linux — note the lowercase\nfilename). Keep every section and checkbox row so reviewers can skim them.\n\n- **Summary** — what changed and why.\n- **Test Plan** — how you verified it.\n- **Demo** — a **video or images** showing the change. Expected on contributor\n  PRs for UI / frontend changes (check the \"UI / frontend change\" box under\n  *Type of change*) so reviewers can see the new behaviour without checking out\n  the branch. Use `N/A` for non-visual changes.\n- **Type of change** / **Test coverage** — check all that apply (at least one\n  each).\n- **Coverage notes** — required if you checked \"Manual verification completed\"\n  or \"Not applicable\".\n\nGenerate the description from the actual diff and this session's context — lead\nwith the motivation, then the change. Don't pass a `--body` that skips these\nsections.\n\n## Finishing a task\n\nWhen you finish a task, print instructions to the user on how to test it: the\ncommands to run, the inputs to provide, or the steps to reproduce so they can\nverify the result themselves. Prefer verification that is best performed by a\nhuman, such as concrete manual behavior checks, rather than only listing unit\ntest commands. Don't leave the user guessing how to confirm the work — tell\nthem exactly what to do.\n\n## Deprecating features\n\nWhen deprecating a feature, note the version in which it is expected to be\nremoved so we can clean it up when that version ships. Call out the deprecation\nversion in code (e.g. a `@deprecated` tag or comment naming the target release)\nand in the PR/commit description, so there's a clear marker to act on later.\n\n## Code comments\n\nKeep comments short and focused on the code, not on the change history.\n\n- **Keep them brief** — prefer one or two lines. Avoid comments longer than\n  three lines; if you need more, the code likely needs refactoring or a doc\n  string, not a wall of inline commentary.\n- **Describe the scenario, not the PR** — explain *what* the code handles or\n  *why* it exists, in terms a future reader needs. Don't reference PR numbers,\n  issue numbers, or ticket IDs (e.g. `#1646`, `fixes JIRA-123`); the scenario\n  should be clear without chasing external links.\n\n## Database query names\n\nApplication stores use `make_named_managed_session_maker` and give every\nsession a stable semantic operation name. The session-level name must describe\nthe caller's intent rather than repeat SQL syntax; use a nested\n`query_name_scope` only when one transaction needs distinct names for important\nsubqueries. Because the named session covers implicit flush and commit, don't\nadd an explicit `flush()` only to make a query name observable.\n\n## Framework-owned instructions\n\nKeep runtime lifecycle and metadata instructions separate from portable agent\ninstructions:\n\n- Agent-spec and per-request instructions are user-authored. Framework-owned\n  instructions are additive runtime behavior and are appended after them in\n  `omnigent/runtime/prompt.py`.\n- Keep the canonical instruction text and lifecycle gate in the owning framework\n  module. Harness adapters should only transport the composed instructions; do\n  not duplicate policy across adapters or add lifecycle metadata to `AgentSpec`.\n- If framework instructions grow beyond a small ordered list, introduce a\n  structured `FrameworkInstructions` value at the prompt-composition boundary.\n",".github/copilot-instructions.md":"# Copilot Code Review Instructions\n\n## E2E Test Requirement\n\nEvery pull request that introduces a new feature **must** include at least one\nend-to-end (e2e) test covering the happy-path behaviour of that feature.\n\n- E2E tests live under `tests/e2e/`.\n- If a PR adds new user-facing functionality and does not add or update an e2e\n  test, flag it as a required change.\n- Bug-fix or refactor PRs that do not change observable behaviour are exempt.\n\n## Backend Test Coverage\n\nA pull request that changes behaviour under `omnigent/` should add or update a\ntest in the suite matching the area it touches. If a behaviour change ships\nwithout a covering test, flag it and name the suite the test belongs in.\n\nPrefer a fast, focused **unit test** in the area suite — that is what most\nchanges need. Only expect an `integration` or `e2e` test when the change\ngenuinely spans components or full-stack flows; do not push for a heavier test\nwhere a unit test would suffice.\n\nMost backend areas mirror their source directory under `tests/`:\n\n| Area changed (`omnigent/…`) | Expected test suite (`tests/…`) |\n| --- | --- |\n| `server/` | `server/` |\n| `runner/` | `runner/` |\n| `runtime/` | `runtime/` |\n| `tools/` | `tools/` |\n| `inner/` | `inner/` |\n| `llms/` | `llms/` |\n| `db/` | `db/` (flag schema migrations especially) |\n| `policies/` | `policies/` |\n| `repl/` | `repl/` |\n| `entities/` | `entities/` |\n| `stores/` | `stores/` |\n| `host/` | `host/` |\n| `spec/` | `spec/` |\n\n- A test under `tests/integration/` or `tests/e2e/` that exercises the change\n  also satisfies the requirement — don't insist on the exact area suite.\n- Do not ask for a test for pure refactors, renames, type-only changes,\n  dependency bumps, comment/docstring/logging edits, or anything with no\n  observable behaviour change.\n- A trivial, empty, or unrelated test does not count as coverage.\n- When in doubt about whether a change needs a test, raise it as a question\n  rather than a required change.\n\n## Frontend Test Coverage\n\nA pull request that changes behaviour under `web/` should add or update a\n**colocated Vitest unit test** — a `*.test.ts` or `*.test.tsx` file beside the\ncomponent or module it touches. If a behaviour change ships without one, flag it.\n\n- A change to user-facing UI behaviour additionally needs a Playwright test\n  under `tests/e2e_ui/`. That requirement is already enforced by the\n  `E2E UI Required` status check, so do not re-flag it here — focus the review\n  on the colocated unit test.\n- A UI / frontend PR should also include a **video or images** in the `Demo`\n  section of the PR description (with the \"UI / frontend change\" box checked).\n  If a UI PR has an empty Demo section, flag it as a request for a screenshot\n  or recording.\n- Do not ask for a test for styling/formatting-only changes, copy tweaks with\n  no flow change, type-only changes, dependency bumps, or refactors with no\n  observable behaviour change.\n- A trivial, empty, or unrelated test does not count as coverage.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Agent guidance\n\nGuidance for AI agents (Claude Code, Copilot, Cursor, etc.) working in this\nrepository. See `CONTRIBUTING.md` for the full contributor workflow.\n\n## Committing\n\nRun the `pre-commit` hook before committing (`pre-commit run --all-files`, or\nlet it run on staged files via `git commit`). Fix any issues it reports so the\ncommit lands clean — CI runs the same checks.\n\n## Local development shortcuts\n\nUse `just` for common tasks; run `just --list` for grouped recipes.\n\n- `just ensure` — install/check prerequisites\n- `just run-ios` / `just run-android` — build/run mobile apps\n- `just dev` / `just dev-mobile` — start the omnigent dev pod\n- `just electron-dev` / `just electron-build` — Electron desktop shell\n- `just lint` / `just lint-all` — run pre-commit\n- `just normalize-locks` — rewrite lockfile registries to PyPI/npmjs.org\n\n## Pull requests\n\nWhen you open a pull request, fill in the repo's PR template at\n`.github/pull_request_template.md` (case-sensitive on Linux — note the lowercase\nfilename). Keep every section and checkbox row so reviewers can skim them.\n\n- **Summary** — what changed and why.\n- **Test Plan** — how you verified it.\n- **Demo** — a **video or images** showing the change. Expected on contributor\n  PRs for UI / frontend changes (check the \"UI / frontend change\" box under\n  *Type of change*) so reviewers can see the new behaviour without checking out\n  the branch. Use `N/A` for non-visual changes.\n- **Type of change** / **Test coverage** — check all that apply (at least one\n  each).\n- **Coverage notes** — required if you checked \"Manual verification completed\"\n  or \"Not applicable\".\n\nGenerate the description from the actual diff and this session's context — lead\nwith the motivation, then the change. Don't pass a `--body` that skips these\nsections.\n\n## Finishing a task\n\nWhen you finish a task, print instructions to the user on how to test it: the\ncommands to run, the inputs to provide, or the steps to reproduce so they can\nverify the result themselves. Prefer verification that is best performed by a\nhuman, such as concrete manual behavior checks, rather than only listing unit\ntest commands. Don't leave the user guessing how to confirm the work — tell\nthem exactly what to do.\n\n## Deprecating features\n\nWhen deprecating a feature, note the version in which it is expected to be\nremoved so we can clean it up when that version ships. Call out the deprecation\nversion in code (e.g. a `@deprecated` tag or comment naming the target release)\nand in the PR/commit description, so there's a clear marker to act on later.\n\n## Code comments\n\nKeep comments short and focused on the code, not on the change history.\n\n- **Keep them brief** — prefer one or two lines. Avoid comments longer than\n  three lines; if you need more, the code likely needs refactoring or a doc\n  string, not a wall of inline commentary.\n- **Describe the scenario, not the PR** — explain *what* the code handles or\n  *why* it exists, in terms a future reader needs. Don't reference PR numbers,\n  issue numbers, or ticket IDs (e.g. `#1646`, `fixes JIRA-123`); the scenario\n  should be clear without chasing external links.\n\n## Database query names\n\nApplication stores use `make_named_managed_session_maker` and give every\nsession a stable semantic operation name. The session-level name must describe\nthe caller's intent rather than repeat SQL syntax; use a nested\n`query_name_scope` only when one transaction needs distinct names for important\nsubqueries. Because the named session covers implicit flush and commit, don't\nadd an explicit `flush()` only to make a query name observable.\n\n## Framework-owned instructions\n\nKeep runtime lifecycle and metadata instructions separate from portable agent\ninstructions:\n\n- Agent-spec and per-request instructions are user-authored. Framework-owned\n  instructions are additive runtime behavior and are appended after them in\n  `omnigent/runtime/prompt.py`.\n- Keep the canonical instruction text and lifecycle gate in the owning framework\n  module. Harness adapters should only transport the composed instructions; do\n  not duplicate policy across adapters or add lifecycle metadata to `AgentSpec`.\n- If framework instructions grow beyond a small ordered list, introduce a\n  structured `FrameworkInstructions` value at the prompt-composition boundary.\n","category":"root","tokens":1080},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","title":"copilot-instructions.md","content":"# Copilot Code Review Instructions\n\n## E2E Test Requirement\n\nEvery pull request that introduces a new feature **must** include at least one\nend-to-end (e2e) test covering the happy-path behaviour of that feature.\n\n- E2E tests live under `tests/e2e/`.\n- If a PR adds new user-facing functionality and does not add or update an e2e\n  test, flag it as a required change.\n- Bug-fix or refactor PRs that do not change observable behaviour are exempt.\n\n## Backend Test Coverage\n\nA pull request that changes behaviour under `omnigent/` should add or update a\ntest in the suite matching the area it touches. If a behaviour change ships\nwithout a covering test, flag it and name the suite the test belongs in.\n\nPrefer a fast, focused **unit test** in the area suite — that is what most\nchanges need. Only expect an `integration` or `e2e` test when the change\ngenuinely spans components or full-stack flows; do not push for a heavier test\nwhere a unit test would suffice.\n\nMost backend areas mirror their source directory under `tests/`:\n\n| Area changed (`omnigent/…`) | Expected test suite (`tests/…`) |\n| --- | --- |\n| `server/` | `server/` |\n| `runner/` | `runner/` |\n| `runtime/` | `runtime/` |\n| `tools/` | `tools/` |\n| `inner/` | `inner/` |\n| `llms/` | `llms/` |\n| `db/` | `db/` (flag schema migrations especially) |\n| `policies/` | `policies/` |\n| `repl/` | `repl/` |\n| `entities/` | `entities/` |\n| `stores/` | `stores/` |\n| `host/` | `host/` |\n| `spec/` | `spec/` |\n\n- A test under `tests/integration/` or `tests/e2e/` that exercises the change\n  also satisfies the requirement — don't insist on the exact area suite.\n- Do not ask for a test for pure refactors, renames, type-only changes,\n  dependency bumps, comment/docstring/logging edits, or anything with no\n  observable behaviour change.\n- A trivial, empty, or unrelated test does not count as coverage.\n- When in doubt about whether a change needs a test, raise it as a question\n  rather than a required change.\n\n## Frontend Test Coverage\n\nA pull request that changes behaviour under `web/` should add or update a\n**colocated Vitest unit test** — a `*.test.ts` or `*.test.tsx` file beside the\ncomponent or module it touches. If a behaviour change ships without one, flag it.\n\n- A change to user-facing UI behaviour additionally needs a Playwright test\n  under `tests/e2e_ui/`. That requirement is already enforced by the\n  `E2E UI Required` status check, so do not re-flag it here — focus the review\n  on the colocated unit test.\n- A UI / frontend PR should also include a **video or images** in the `Demo`\n  section of the PR description (with the \"UI / frontend change\" box checked).\n  If a UI PR has an empty Demo section, flag it as a request for a screenshot\n  or recording.\n- Do not ask for a test for styling/formatting-only changes, copy tweaks with\n  no flow change, type-only changes, dependency bumps, or refactors with no\n  observable behaviour change.\n- A trivial, empty, or unrelated test does not count as coverage.\n","category":".github","tokens":747}]}