{
  "markdown": "<p align=\"center\">\n  <img src=\"plugins/jaipilot/assets/jaipilot-logo.svg\" alt=\"JAIPilot\" width=\"112\">\n</p>\n\n# JAIPilot — **Ship better Java with your coding agent.**\n\nJAIPilot helps Codex and Claude Code research maintainer intent, clean, test, review, safely upgrade\ndependencies and JDKs, and optimize real Java repositories without drifting into unnecessary code\nor unproved changes.\n\nBy default, your agent runs Java builds, tests, analysis, profiling, and benchmarks on a ready\nremote Java machine whenever the task does not require laptop-only access or state.\n\nJAIPilot does not replace your coding agent or add another AI. It gives your agent focused Java\nworkflows, remote compute, and one rule: **show evidence, not confidence.**\n\n> **Further reading:**\n> [Preventing agent drift: A guide to shipping serious code via vibe-coding](https://jaipilot.com/blog/preventing-agent-drift-serious-code-vibe-coding)\n> explains the engineering principles behind JAIPilot's bounded, evidence-first workflows.\n\n## Install and run\n\n### Codex\n\nJAIPilot is packaged for the official OpenAI plugin directory. Once the listing is approved, install\nit there to get all eight local skills and the optional OAuth remote MCP together. The same public\nMCP remains available as a direct connection:\n\n```bash\ncodex mcp add jaipilot --url https://api.jaipilot.com/functions/v1/jaipilot/mcp\n```\n\n### Claude Code\n\n```text\n/plugin marketplace add JAIPilot/jaipilot\n/plugin install jaipilot@jaipilot\n```\n\n### Any MCP client\n\nIf your client supports remote HTTP MCP servers and OAuth, connect directly to JAIPilot without\ninstalling a plugin or running a local process:\n\n```text\nhttps://api.jaipilot.com/functions/v1/jaipilot/mcp\n```\n\nClients that use the common `mcpServers` configuration shape can add:\n\n```json\n{\n  \"mcpServers\": {\n    \"jaipilot\": {\n      \"type\": \"http\",\n      \"url\": \"https://api.jaipilot.com/functions/v1/jaipilot/mcp\"\n    }\n  }\n}\n```\n\nComplete the OAuth sign-in when the client first connects. Clients with MCP Skills support can\ndiscover the JAIPilot skills directly; tool-only clients can load the same versioned instructions\nthrough the read-only `skill_get` tool. Remote execution remains opt-in and requires approval before\nan exact committed repository revision is uploaded.\n\n### GitHub Marketplace\n\nInstall the [JAIPilot GitHub App](https://github.com/marketplace/jaipilot) to repair failed\nDependabot and Renovate pull requests for Maven and Gradle repositories.\n\n### See what JAIPilot changed\n\nJAIPilot does not hide its value behind skill routing or build logs. Every meaningful skill\nmilestone uses the same restrained, one-line grammar:\n\n`**JAIPilot · <capability>** — <completed outcome>; <strongest fresh proof>.`\n\nFor example: **JAIPilot · Test generation** — 7/7 focused tests passed; fresh line and branch\ncoverage reached 100%.\n\nThe update appears only after completed work, never for intent or routing. When completion coincides\nwith the final response, the same line becomes its outcome lead and is immediately followed by one\nconsolidated impact section. Nested skills contribute to that section instead of printing a stack\nof banners.\n\nFor example, a measured Petclinic test-generation run ends with evidence in this shape:\n\n**JAIPilot · Test generation** — 10 useful tests added; changed-method line and branch coverage\nreached 100%.\n\n**JAIPilot impact**\n- **Test generation:** 75 → 85 tests (**+10**); changed-method line and branch coverage\n  0% → 100% (**+100 percentage points**)\n- **Evidence:** `./mvnw -q clean verify` — 85/85 tests passed\n\nImpact uses fresh, same-scope before/after evidence already useful to the task. When a comparison is\nnot available, JAIPilot says `not measured`; when the value is a maintainer decision or rejected\nunsafe change, it describes that outcome without inventing hours saved, risk percentages, or a\ncounterfactual “without JAIPilot” score.\n\n### Example prompts\n\nOpen a Java repository and ask JAIPilot the same way you would ask a teammate. Each example shows\nthe skills JAIPilot selects and why that workflow helps.\n\n#### Check whether an issue is worth picking up\n\n**Prompt**\n\n```text\nCan you look into issue #184 and tell me whether I should work on it, or if someone is already\nhandling the same problem?\n```\n\n> **Skills and flow:** `jaipilot-maintainer-intent` researches the issue, related work, contribution\n> rules, and code history before recommending whether to proceed, join existing work, ask, wait, or\n> stop.\n>\n> **Why it helps:** You avoid duplicating another contributor's work or building a fix maintainers\n> are unlikely to accept.\n\n#### Get a branch ready to merge\n\n**Prompt**\n\n```text\nI've finished the changes on this branch. Can you make sure they're ready to merge?\n```\n\n> **Skills and flow:** `jaipilot-optimize-java` coordinates bounded cleanup and improvement,\n> `jaipilot-generate-tests` fills meaningful test gaps, and `jaipilot-review-diff` reviews the\n> complete result. `jaipilot-fast-execution` and `jaipilot-remote-java` accelerate substantial\n> verification when safe and useful.\n>\n> **Why it helps:** You get a smaller, reviewed change with missing tests added and the repository's\n> real checks run before handoff.\n\n#### Upgrade a framework and its dependencies\n\n**Prompt**\n\n```text\nCan you upgrade this Spring Boot service and its outdated dependencies while keeping Java 17\nsupport?\n```\n\n> **Skills and flow:** `jaipilot-maintainer-intent` first checks repository history, active or prior\n> upgrade work, maintainer direction, and established compatibility constraints. The supported\n> upgrade then uses `jaipilot-clean-java` to inventory and modernize the requested dependency and\n> build paths. `jaipilot-openrewrite` is selected only when a repeated type-aware migration justifies\n> it, followed by `jaipilot-generate-tests`, `jaipilot-review-diff`, `jaipilot-fast-execution`, and\n> `jaipilot-remote-java` as applicable.\n>\n> **Why it helps:** The upgrade follows the repository's intended direction and avoids duplicating\n> or conflicting with existing work. Accepted changes remain compatible, reversible, and verified\n> instead of becoming a broad version bump with hidden runtime or transitive-dependency breakage.\n\n#### Fix a failing dependency-bot update\n\n**Prompt**\n\n```text\nDependabot's Jackson update is failing CI. Can you figure out why and fix it?\n```\n\n> **Skills and flow:** `jaipilot-maintainer-intent` checks the bot PR, maintainer direction, related\n> attempts, and the correct delivery path. The supported fix then uses `jaipilot-clean-java` or\n> `jaipilot-openrewrite`, followed by `jaipilot-generate-tests` and `jaipilot-review-diff`.\n> Substantial commands use `jaipilot-fast-execution` and `jaipilot-remote-java` when appropriate.\n>\n> **Why it helps:** The agent fixes the actual compatibility problem on the right branch instead of\n> merely forcing the bot's version change through CI.\n\n#### Add tests for a service change\n\n**Prompt**\n\n```text\nPlease add unit tests for my changes to OrderService, especially the validation and error cases.\n```\n\n> **Skills and flow:** `jaipilot-generate-tests` maps the requested classes and useful cases, creates\n> and executes safely independent test-class work in parallel, and reports fresh configured coverage\n> or mutation evidence. `jaipilot-fast-execution` and `jaipilot-remote-java` accelerate the test and\n> verification work when applicable.\n>\n> **Why it helps:** You get behavior-focused tests across the complete requested scope, not hollow\n> tests written only to inflate a coverage number.\n\n#### Simplify a difficult module\n\n**Prompt**\n\n```text\nThis payments module has become hard to follow. Can you remove dead code and simplify it without\nchanging its behavior?\n```\n\n> **Skills and flow:** `jaipilot-clean-java` proves what can be removed or consolidated and keeps\n> uncertain candidates. `jaipilot-generate-tests` covers concrete regression gaps, and\n> `jaipilot-review-diff` checks the final patch. Verification routes through\n> `jaipilot-fast-execution` and `jaipilot-remote-java` when useful.\n>\n> **Why it helps:** The module becomes easier to maintain without speculative deletion, silent API\n> breakage, or a cleanup that only looks smaller.\n\n#### Review work before opening a pull request\n\n**Prompt**\n\n```text\nCan you review my current diff before I open a pull request?\n```\n\n> **Skills and flow:** `jaipilot-review-diff` reads the complete Java and build change, checks\n> behavior, compatibility, unnecessary code, and missing proof, then runs the applicable repository\n> checks via `jaipilot-fast-execution` and `jaipilot-remote-java` when appropriate.\n>\n> **Why it helps:** You get ranked, evidence-backed findings across the whole change rather than a\n> shallow review of the most obvious file.\n\n#### Speed up a slow endpoint\n\n**Prompt**\n\n```text\nThe /orders endpoint gets slow for large accounts. Can you find the bottleneck and improve it?\n```\n\n> **Skills and flow:** `jaipilot-optimize-java` bounds the change, `jaipilot-clean-java` profiles and\n> tests measured hypotheses, `jaipilot-generate-tests` protects behavior, and\n> `jaipilot-review-diff` checks the candidate. `jaipilot-fast-execution` and\n> `jaipilot-remote-java` provide controlled execution and comparable measurements.\n>\n> **Why it helps:** The retained optimization is tied to a real bottleneck and repeatable evidence,\n> not a plausible-looking micro-optimization or one noisy timing.\n\n#### Run a slow build faster\n\n**Prompt**\n\n```text\nOur full Gradle build takes about 20 minutes. Can you run it faster and tell me where the time goes?\n```\n\n> **Skills and flow:** `jaipilot-fast-execution` sizes safe batching and native build parallelism for\n> the available resources. `jaipilot-remote-java` offloads the work when the repository does not need\n> laptop-only services or state.\n>\n> **Why it helps:** You reduce wall time without skipping tests, weakening gates, or creating\n> misleading results through unsafe concurrency.\n\nThe Codex plugin installs all eight skills locally and configures the optional hosted MCP. A direct\nMCP connection can instead discover the same versioned skills through `skills/list`, `skills/get`,\ndigest-verified `resources/read`, and standard `mcp/skill` resources. Clients that do not yet\npromote server skills can use the read-only `skill_get` fallback. Signing in creates no upload or\ncompute; remote execution starts only after the separate exact-repository upload consent described\nbelow. Claude Code retains its plugin path.\n\nWhen remote execution is useful, your agent asks before uploading one exact committed Git revision.\nApprove the upload; if authentication is not already active, sign in when prompted. The agent uses\n`git archive` for that commit and handles integrity checking, private upload, execution, logs, and\ncleanup. You do not configure a VM, provide an AWS key, or copy files manually. Staged, unstaged,\nuntracked, ignored, and `.git` content never enters the build, and remote files never return\nautomatically.\n\nIf packaging or upload cannot be verified, JAIPilot does not start the build. Your agent must\nshow the failing step instead of silently uploading a different source tree.\n\n| **12.2–80.3% faster** | **61.3–62.5% faster** | **87.5–92.4% faster** | **8 → 2** SQL statements |\n| --------------------- | --------------------- | --------------------- | ------------------------ |\n| OTel lookup medians   | Micrometer merges     | Calcite JMH medians   | N+1 removed              |\n\n## JAIPilot vs no JAIPilot\n\nThe original [Petclinic PR](https://github.com/skrcode/spring-framework-petclinic/pull/21) already\nhad a green build. JAIPilot reviewed that exact head and produced this\n[companion change](https://github.com/skrcode/spring-framework-petclinic/pull/25):\n\n| Metric                         |       Without JAIPilot | With JAIPilot | Outcome                         |\n| ------------------------------ | ---------------------: | ------------: | ------------------------------- |\n| Tests                          |                     75 |            85 | **+10 tests (+13.3%)**          |\n| Changed-method line coverage   |              0/12 (0%) |  11/11 (100%) | **+100 percentage points**      |\n| Changed-method branch coverage |               0/8 (0%) |    8/8 (100%) | **+100 percentage points**      |\n| `Owner` class line coverage    |          22/53 (41.5%) | 33/51 (64.7%) | **+23.2 points with less code** |\n| Production change              | Unused helper remained |   +2/-9 lines | **7 net lines removed**         |\n| `Owner` methods                |                     16 |            15 | **1 unused method removed**     |\n| `Owner` complexity             |                     25 |            24 | **4% lower**                    |\n| Clean Maven verification       |           75/75 passed |  85/85 passed | **Both stayed green**           |\n\nThe important result is not simply “more tests.” Without JAIPilot, the build passed while the new\nbehavior had zero coverage and unused code remained. With JAIPilot, the same behavior stayed green,\nthe edge cases became executable tests, and production code became smaller.\n\nThe comparison uses the original PR head and JAIPilot's direct child commit, clean worktrees, the\nsame `./mvnw -q clean verify` command, and fresh JaCoCo 0.8.14 reports.\n\n## Measured performance: Apache Calcite\n\nOn `skrcode/calcite` at exact commit\n[`d3a5d8d`](https://github.com/skrcode/calcite/tree/d3a5d8d9e6713c5fd483810e1aa1f38652d2dd8d),\nJAIPilot profiled Calcite's existing\n`DefaultDirectedGraphBenchmark.removeAllVertices{10,50,90}Benchmark`. The 50% workload attributed\n31.1% of runnable samples to `Collection.removeIf`: the implementation scanned the complete global\nedge set once for every removed vertex.\n\nThe candidate changed two files (+28/-5), removed the repeated scans, and added behavior tests for\nthe majority-removal and self-loop paths. Lower JMH scores are better:\n\n| Removed vertices | Baseline median (µs/op) | JAIPilot median (µs/op) | Improvement | Baseline p95 (µs/op) | JAIPilot p95 (µs/op) | Improvement |\n| ---------------: | ----------------------: | ----------------------: | ----------: | -------------------: | -------------------: | ----------: |\n|              10% |                  26.710 |                   2.029 |   **92.4%** |               27.142 |                2.439 |   **91.0%** |\n|              50% |                  74.619 |                   9.140 |   **87.8%** |               87.245 |               14.993 |   **82.8%** |\n|              90% |                  77.423 |                   9.677 |   **87.5%** |               89.514 |               10.052 |   **88.8%** |\n\nBaseline and candidate ran on the same 4 CPU/8 GiB remote workspace with the same Temurin JDK 17,\nbuilt JMH jar, command, and workload. Each row contains 21 measured observations: seven forks with\nthree measured iterations per fork after warm-up. The identical focused command passed 15/15 tests\nbefore and after the production edit. A fresh exact-SHA `:core:clean :core:check` then completed\n16,644 tests with 0 failures and 155 skips, and the tested remote diff matched the local candidate\ndigest.\n\nThis is a controlled result for Calcite's existing graph-removal workloads, not a claim that every\nJava workload becomes faster.\n\n## Measured performance: OpenTelemetry Java\n\nOn `skrcode/opentelemetry-java` at exact commit\n[`35636ae`](https://github.com/skrcode/opentelemetry-java/tree/35636aec8d3dc6706bb483bad92383fdd6012af0),\nJAIPilot found that immutable attribute sets were sorted by key name during construction but still\nused a full linear scan for every lookup. This matters at the default span limit of 128 attributes.\n\nThe [three-file draft change](https://github.com/skrcode/opentelemetry-java/pull/3) preserves the\nsmall-set and first-four-entry fast path, then uses binary search for the rest. It also adds a\nlarge-set behavior test and a repository-native JMH benchmark. Lower values are better:\n\n| Lookup          | Baseline median (ns/op) | JAIPilot median (ns/op) | Improvement | Baseline p95 | JAIPilot p95 | Improvement |\n| --------------- | ----------------------: | ----------------------: | ----------: | -----------: | ------------: | ----------: |\n| First           |                   2.483 |                   2.179 |   **12.2%** |        2.637 |         2.272 |   **13.8%** |\n| Middle          |                 169.124 |                  85.905 |   **49.2%** |      178.250 |        88.537 |   **50.3%** |\n| Last            |                 346.195 |                  87.323 |   **74.8%** |      358.321 |        90.084 |   **74.9%** |\n| Missing         |                 141.560 |                  69.552 |   **50.9%** |      150.321 |        74.261 |   **50.6%** |\n| Last as `Value` |                 368.629 |                  72.684 |   **80.3%** |      387.467 |        78.087 |   **79.8%** |\n\nBaseline and candidate ran in the same 4 CPU/8 GiB remote workspace with Temurin JDK 21, the same\nJMH jar, command, warm-up, and workload. Each row has 21 observations. The new focused behavior test\npassed before and after the production edit; a clean `:api:all:check` passed all 147 tasks including\nAnimal Sniffer, Checkstyle, Spotless, tests, and japicmp. The tested remote Git delta matched the\nlocal candidate digest. The `Value` workload still allocates about 16 B/op; JAIPilot reports the\nlookup-time win without claiming that allocation disappeared.\n\n## Measured performance: Micrometer\n\nOn `skrcode/micrometer` at exact commit\n[`22207bf`](https://github.com/skrcode/micrometer/tree/22207bf9ccc973a1b1bc3890b33645e53fb2e475),\nJAIPilot found that adding or replacing one `Tag` or `KeyValue` went through temporary varargs and\niterable merge machinery even though the backing arrays were already sorted.\n\nThe [six-file draft change](https://github.com/skrcode/micrometer/pull/3) adds a bounded binary-search\nmerge for the single-value overloads, behavior tests, and four workloads in Micrometer's existing\nJMH module:\n\n| Replacement workload | Baseline median (ns/op) | JAIPilot median (ns/op) | Improvement | Baseline p95 | JAIPilot p95 | Improvement | Allocation |\n| -------------------- | ----------------------: | ----------------------: | ----------: | -----------: | ------------: | ----------: | ---------: |\n| `KeyValues.and`      |                  57.941 |                  22.449 |   **61.3%** |       63.554 |        23.487 |   **63.0%** | **136 → 104 B/op** |\n| `Tags.and`           |                  58.968 |                  22.101 |   **62.5%** |       63.388 |        24.425 |   **61.5%** | **136 → 104 B/op** |\n\nSingle-value insertion reduced median allocation by 17.6% and p95 allocation by 46.2%. Its median\nlatency improved by only 6.7–8.9%, below JAIPilot's 10% shared-hardware threshold, so it is not\npresented as a speed win. The same-workspace experiment used 21 observations per workload; 92\nfocused tests and the final clean scoped build passed, with 1,132 tests, zero failures, and the\nremote production diff matching the local digest.\n\n## Measured database work: Petclinic\n\nOn the current Petclinic JDBC vet listing, JAIPilot found a real N+1 query path: six vets required\neight SQL statements (`2 + N`). It kept the ordered vet query and replaced the per-vet specialty\nlookups with one joined association query.\n\n| Evidence                  | Baseline | JAIPilot candidate |\n| ------------------------- | -------: | ------------------: |\n| SQL statements, six vets |        8 |               **2** |\n| Growth with vet count     |  `2 + N` |       **constant 2** |\n| Focused JDBC tests        |    11/11 |           **15/15** |\n| Clean repository build    |    75/75 |           **79/79** |\n\nThe new tests lock vet ordering, specialty ordering, vets without specialties, duplicate links,\nshared specialty identity, empty data, and the exact two-statement ceiling. The final clean Maven\nbuild and JaCoCo report passed on a 4 CPU/8 GiB remote workspace, and the local and remote binary\ndiff digests matched. This is deterministic query-count evidence; JAIPilot does not turn it into an\ninvented latency claim.\n\n## Why teams use JAIPilot\n\n- **Less agent drift** — changes stay bounded, lean, and aligned with the repository.\n- **Better Java code** — remove proven waste, reduce complexity, improve tests, review risky diffs,\n  and optimize measured bottlenecks.\n- **Verified modernization** — upgrade the JDK, Maven or Gradle wrapper, build plugins, frameworks,\n  BOMs, and direct dependencies to stable compatible versions in isolated, reversible batches.\n- **Real verification** — use the repository's Maven or Gradle build, tests, coverage, architecture\n  rules, and performance measurements.\n- **Remote-first execution** — use disposable hardware with JDK 17, 21, and 25, Maven, and Gradle\n  ready unless private networks, local services, secrets, hardware, or state require the laptop.\n- **Remote performance lab** — profile and compare a bounded optimization on one 4 CPU/8 GiB\n  workspace, with matching patch identity, raw observations, median, p95, and correctness evidence.\n- **Keeps dirty work private** — remote execution accepts only an explicitly approved exact commit;\n  staged, unstaged, untracked, ignored, and `.git` content stays on the laptop.\n- **Your agent stays in control** — Codex or Claude Code chooses every edit and command and reports\n  exactly what JAIPilot achieved.\n\n## More proven results\n\nAdditional acceptance runs used repository-native verification:\n\n| Use case                                                                                            | Result                                                                                                                                                                                           |\n| --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| Optimize Apache Calcite graph removal                                                               | Existing JMH workload medians improved by **87.5–92.4%** across 10%, 50%, and 90% removal cases; matching behavior tests and a **16,644-test** clean check passed.                               |\n| Optimize OpenTelemetry attribute lookup                                                             | Five 128-attribute lookup workloads improved by **12.2–80.3%** at median and **13.8–79.8%** at p95; clean API compatibility and verification passed.                                           |\n| Optimize Micrometer single-value merges                                                             | Replacement merges improved by **61.3–62.5%** at median and allocated **23.5% less**; sub-threshold insertion latency was not marketed as a speed win.                                        |\n| [Cover previously untested behavior](https://github.com/skrcode/spring-framework-petclinic/pull/34) | **7** focused tests added with **no production or dependency change**; target coverage moved from **0% to 100%** for lines and branches; **82/82** tests passed independently on Java 17 and 21. |\n| Run Maven remotely                                                                                  | Spring Petclinic's exact committed SHA passed **75/75** tests; the build emitted matching source/archive identities and deleted its private source afterward.                               |\n| Retry a heavy Gradle build                                                                          | Calcite's 2 CPU/4 GiB attempt reported its real out-of-memory failure; a fresh 4 CPU/8 GiB retry passed **93/93** focused tests, and cancellation plus JFR summary output were verified.      |\n| Remove a JDBC N+1 query                                                                              | Vet listing SQL statements fell from **8 to 2** on the six-vet fixture; **15/15** focused and **79/79** clean-build tests passed, with identical local/remote diff digests.                 |\n\nThese are reproducible acceptance results, not claims that every repository will see the same\ncoverage, code reduction, or speed.\n\n## MCP Registry\n\nClients that consume the official MCP Registry can discover `io.github.JAIPilot/jaipilot`. The one\nhosted endpoint serves the eight Java engineering skills directly and forwards only\n`tools/list`/`tools/call` to the existing bounded OAuth remote-execution service. Skill discovery\nand reads do not contact remote execution; tool calls retain its authorization and safety boundary.\n\nBoth skill catalogs are paginated five skills and then three so direct clients can load all eight.\nThe direct MCP connection remains available alongside the combined Codex plugin submitted to the\nofficial OpenAI plugin directory.\n\n## Included skills\n\n| Skill                        | Outcome                                                   |\n| ---------------------------- | --------------------------------------------------------- |\n| `jaipilot-maintainer-intent` | Read repository history and choose the right next action. |\n| `jaipilot-optimize-java`     | Make one bounded Java change leaner, safer, and faster.   |\n| `jaipilot-generate-tests`    | Add meaningful tests and fresh coverage evidence.         |\n| `jaipilot-clean-java`        | Remove waste, enforce architecture, and simplify code.     |\n| `jaipilot-openrewrite`       | Apply clean, bounded, verified Java migrations.            |\n| `jaipilot-review-diff`       | Find regressions, unnecessary code, and missing proof.    |\n| `jaipilot-fast-execution`    | Run substantial Java verification efficiently.            |\n| `jaipilot-remote-java`       | Default applicable Java execution to remote hardware.     |\n\nJAIPilot can work with repository-configured tools such as JaCoCo, PIT, ArchUnit, OpenRewrite,\nCheckstyle, PMD, SpotBugs, SonarQube, JMH, and JFR. It never weakens a quality gate merely to get a\ngreen result.\n\n## Remote build beta\n\nThe beta permits one active normal AWS CodeBuild attempt. Each attempt starts from a private exact\ncommit archive, has no persistent cache or workspace, and terminates when its command exits, is\ncancelled, or reaches its hard timeout. The default profile is 2 CPU/4 GiB; 4 CPU/8 GiB is available\nfor memory-heavy builds and profiling. Builds have public outbound internet access and never commit,\npush, or receive GitHub write credentials.\n\nJAIPilot stays local when a corporate VPN, VPC-only dependency, private artifact service, internal\ndatabase, unavailable secret, raw profiler artifact, machine-specific state, or other laptop-only\nresource is required. CodeBuild startup is variable and can take several minutes on a cold compute\nclass, so this is batch-style remote execution rather than an interactive shell.\n\nSee [Security](SECURITY.md), [Privacy](PRIVACY.md), [Support](SUPPORT.md), [Terms](TERMS.md), and\nthe [Changelog](CHANGELOG.md).\n\nLicensed under the [MIT License](LICENSE).\n",
  "bytes": 27147,
  "sha": "54a13239f1de73416b01522d64508846ecd2775f4efdc1ccfe5d4e4d4a795e13",
  "repo_slug": "jaipilot/jaipilot",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_jaipilot_jaipilot_cfeea0db/readme"
}