@polygraph/codex-plugin 0.4.28 → 0.4.29
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.
|
@@ -11,7 +11,7 @@ These tools are available via MCP and CLI. Use whichever is available in your en
|
|
|
11
11
|
|
|
12
12
|
| MCP Tool | CLI Equivalent | Description |
|
|
13
13
|
| --- | --- | --- |
|
|
14
|
-
| `list_repos` | `polygraph repo list` | Discover candidate repositories
|
|
14
|
+
| `list_repos` | `polygraph repo list` | Discover candidate repositories. |
|
|
15
15
|
| `start_session` | `polygraph session start --repo <ids>` | Initialize a NEW session with selected repositories. Only use when no `sessionId` was provided. |
|
|
16
16
|
| `add_repo` | — | Attach repositories to an EXISTING session. Use when `sessionId` was provided and the session has no repos yet, or when the user wants to add more. |
|
|
17
17
|
| `show_session` | `polygraph session show <id> [--details]` | Get full session details including URL, and use details when session summary, repo IDs, PR URLs, and PR descriptions are needed |
|
|
@@ -54,16 +54,22 @@ Call `list_repos` to discover available candidate repositories:
|
|
|
54
54
|
list_repos()
|
|
55
55
|
```
|
|
56
56
|
|
|
57
|
+
`list_repos` accepts these optional parameters; set whichever apply. Refer to the tool schema for each parameter.
|
|
58
|
+
|
|
59
|
+
- `connectedTo`: repo ID, name, or full name (e.g. `nrwl/ocean`); pair with `connectionType`
|
|
60
|
+
- `connectionType`: `directly-upstream` | `directly-downstream` | `directly-both` (default) | `upstream` | `downstream` | `both`
|
|
61
|
+
- `publishedPackages`, `consumedPackages`, `publishedApis`, `consumedApis`: arrays of package names / API paths
|
|
62
|
+
- `nameFilter`: array of repo name patterns (e.g. `nrwl/*`)
|
|
63
|
+
- `semanticQuery`: free-text description of the repositories you want
|
|
64
|
+
|
|
57
65
|
This returns:
|
|
58
66
|
|
|
59
|
-
- **`
|
|
60
|
-
- **`candidates`**: Candidate account repositories, each with:
|
|
67
|
+
- **`repos`**: Candidate account repositories, each with:
|
|
61
68
|
- `id`: Repository ID
|
|
62
69
|
- `name`: Repository name
|
|
70
|
+
- `repository`: Full repo name (e.g., `org/repo`)
|
|
71
|
+
- `provider`: VCS provider (e.g., `GITHUB`)
|
|
63
72
|
- `description`: AI-generated description of what the repository does (may be null)
|
|
64
|
-
- `vcsConfiguration.repositoryFullName`: Full repo name (e.g., `org/repo`)
|
|
65
|
-
- `graphRelationship`: How this repository relates to the initiator (`distance`, `direction`, `path`), or `null` if the repository is not in the dependency graph. When `initiator` is null, `graphRelationship` will be null for all candidates.
|
|
66
|
-
- **`dependencyGraph`**: Graph of repository dependency `edges` (always available, independent of initiator)
|
|
67
73
|
|
|
68
74
|
### Step 2: Select Relevant Repos
|
|
69
75
|
|
|
@@ -73,14 +79,11 @@ If `selectedRepoIds` or exact repo refs were provided by the main agent, use tho
|
|
|
73
79
|
|
|
74
80
|
Otherwise, analyze the candidates using the `userContext` to determine which repos are relevant:
|
|
75
81
|
|
|
76
|
-
1. Read each
|
|
77
|
-
2. Match against the `userContext`
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
- Direction (upstream/downstream based on the nature of the change)
|
|
82
|
-
3. Select only the repos that are clearly relevant to the task
|
|
83
|
-
4. If uncertain which repos are relevant, include all candidates (safe default)
|
|
82
|
+
1. Read each repo's `description`
|
|
83
|
+
2. Match repo descriptions against the `userContext` to identify relevant repos
|
|
84
|
+
3. Select the repos that are relevant to the task
|
|
85
|
+
4. When uncertain, include all candidates
|
|
86
|
+
5. When the user described the task in natural language and the result is large, re-query with `semanticQuery` set to that description
|
|
84
87
|
|
|
85
88
|
### Step 3: Initialize Polygraph Session or Attach Repos
|
|
86
89
|
|
|
@@ -136,11 +139,6 @@ Return a structured summary in this format:
|
|
|
136
139
|
| Repo | Repository ID | Description | Selected |
|
|
137
140
|
| --- | --- | --- | --- |
|
|
138
141
|
| REPO_FULL_NAME | REPOSITORY_ID | DESCRIPTION | Yes/No |
|
|
139
|
-
|
|
140
|
-
### Initiator
|
|
141
|
-
(Only include this section if `list_repos` was called and `initiator` is non-null)
|
|
142
|
-
- **Name:** <initiator name>
|
|
143
|
-
- **Repo:** <initiator repo full name>
|
|
144
142
|
```
|
|
145
143
|
|
|
146
144
|
## Important Notes
|
package/package.json
CHANGED
|
@@ -29,7 +29,7 @@ Polygraph functionality is available via both MCP tools and CLI commands. Use wh
|
|
|
29
29
|
|
|
30
30
|
| MCP Tool | CLI Equivalent | Description |
|
|
31
31
|
| --- | --- | --- |
|
|
32
|
-
| `list_repos` | `polygraph repo list` | Discover candidate repositories
|
|
32
|
+
| `list_repos` | `polygraph repo list` | Discover candidate repositories. |
|
|
33
33
|
| `start_session` | `polygraph session start --repo <ids>` | Initialize a Polygraph session with selected repositories |
|
|
34
34
|
| `spawn_agent` | — | Start a new child task or send a follow-up to an active task in another repository. Input: `{ sessionId, repo, instruction, context? }`. Output: `{ taskId, message, status: 'delegated' }`. Follow-up routing is automatic: if the repo already has an active child task, the instruction is delivered to it as a follow-up message; otherwise a new child run starts. A repo has at most one active child at a time. A session resume or reconstruction is read-only context restoration; after resuming, do not use `spawn_agent` to continue changes unless the user explicitly asks for changes. |
|
|
35
35
|
| `show_agent` | — | Poll flat per-child status for the session. Output: `{ children: PolygraphChildStatusItem[] }` where each item exposes `repositoryId`, `repoFullName`, `status`, `lastOutputLines`, `durationMs`, `instruction`, `agentType?`, `inputRequiredQuestion?`. `status` is an AcpRunStatus: `'created' \| 'in-progress' \| 'input-required' \| 'permission-required' \| 'completed' \| 'failed' \| 'cancelled'` (British double-L on `'cancelled'`). `inputRequiredQuestion` is populated only when `status === 'input-required'`. |
|