Add OPSX OpenSpec workflows, specs, and handlers#32
Conversation
Introduce OPSX experimental workflow support and a large set of OpenSpec change artifacts. Adds command docs and skills for opsx (apply, archive, explore, propose) and corresponding SKILL.md files and prompts; bulk-imports many openspec change proposals, designs, specs and tasks; and adds openspec config. Implements numerous new feature handlers/types (agents, attachments, cycles, portfolio, subscriptions, webhooks, etc.), updates auth/GraphQL/client code, and augments tests. Also adds release/verify scripts, updates package.json, README and architecture, and adds CLAUDE.md and copilotapireview.md. These changes scaffold the OpenSpec-driven workflow and wire up server-side handlers and tests for the new capabilities.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d2df7e8408
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return undefined; | ||
| } | ||
|
|
||
| return (method as (variables?: Record<string, unknown>) => Promise<unknown>)(variables); |
There was a problem hiding this comment.
Preserve receiver binding when calling SDK fetch methods
callFetchMethod invokes the extracted function directly, which drops the original object context. Linear SDK relation methods (e.g., issue.comments(), project.attachments(), team.states()) dereference instance fields like this._request/this.id, so calling them unbound can throw at runtime and break detail/list responses that load nested relations. Invoke with the original receiver (for example, record[methodName](variables) or method.call(record, variables)) so these handlers work reliably.
Useful? React with 👍 / 👎.
Add a new AGENT.md with an agent-facing guide and key commands/paths. Expand CLAUDE.md to clarify current runtime (default stdio, optional stream transport), auth options (LINEAR_API_KEY and OAuth flow with single-use state), the distinction between linear_list_issues vs linear_search_issues (filter vs query-backed), release verification commands, project layout, and conventions. Small README.md updates mirror the same status and search/regression notes. These changes improve onboarding and document runtime, auth, and tooling expectations for developers and integrators.
Introduce repository safeguards and runtime provenance: add openspec change docs for issue-create, issue-search, server build provenance, contract audits, and critical issue-workflow smoke tests; add a static contract-audit script (scripts/linear-api-contract-audit.mjs) and verify:linear-api-contracts / verify:issue-workflows npm scripts; update verify:release to run audits and smoke checks; expose packaged server build provenance in capabilities/startup and update README; add tests and wiring to enforce single vs batch issue-create and query-backed issue-search parity.
Enforce MCP tool input validation, tighten agent workflow contracts, repair issue workflow reliability, support LINEAR_ACCESS_TOKEN env alias, and harden auth session lifecycle. Includes expanded test coverage, OpenSpec change specs, and updated docs. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace the Linear SDK's searchIssues() call with a raw GraphQL query
to prevent the SDK from leaking the search term into the $filter
variable as { search: "..." }, which is not a valid IssueFilter field.
Also removes top-level oneOf/allOf/anyOf combinators from advertised
tool schemas for Claude-compatible MCP client ingestion, and updates
contract audits and tests accordingly.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Resolve human-friendly issue identifiers (e.g. POL-431) before or during free-text search so exact hits return stable issue data and pagination metadata. Implements LinearGraphQLClient.findIssueByIdentifier, identifier parsing/filter builder, and updates searchIssues to prefer an exact team-key+number filter and fall back to listing when appropriate. Handlers for issues and comments now resolve identifiers before calling SDK/GraphQL methods; single-create issue flow was switched to the raw GraphQL helper. Tests, runtime smoke helpers, README docs, and packaged-install verification were updated to exercise and document the new behavior; an audit script and a new code-review note were also added. Also fixes SDK method invocation binding in sdk.utils to preserve the method receiver.
Add the GitNexus review and OpenSpec change artifacts, optimize handler dispatch and issue batching, add bounded request budgets, retries, and runtime diagnostics, and publish the package as @kkaminsk/linear-mcp. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: aider (openrouter/deepseek/deepseek-r1) <aider@aider.chat>
…nerated some unexpected file diffs. Let me clarify and provide the code review document in the format you requested.
aidercodereview-kimi.md
```
# Code Review: Linear MCP Server (Kimi Analysis)
## Overview
This review analyzes the Linear MCP server codebase with specific focus on the runtime, concurrency, request policy, GraphQL client, and testing infrastructure implementations. The codebase demonstrates sophisticated TypeScript patterns for API resilience, concurrent operations, and observability.
## Performance Analysis
### Strengths
**Worker Pool Concurrency Implementation**
The `mapWithConcurrencyLimit` function in `src/core/concurrency.ts` implements an efficient worker pool pattern that maintains memory bounds regardless of input size. By using `workerCount = Math.min(concurrency, items.length)` and tracking `nextIndex` atomically across workers, it prevents the memory explosion that would occur with `Promise.all(Array.from({length: items.length}, ...))`.
**AbortController Integration**
The request policy implementation in `src/core/request-policy.ts` properly utilizes `AbortController` for timeout handling, ensuring that underlying HTTP requests are actually cancelled rather than just ignoring responses. The `signal` listener cleanup with `{ once: true }` prevents event listener leaks.
**Lazy Query Loading**
`src/graphql/client.ts` uses dynamic imports for GraphQL operations (`await import('./mutations.js')`), enabling code splitting and reducing initial bundle size. This is particularly effective for a CLI tool where not all operations are used in every session.
**Telemetry Compaction**
The `compactRecord` method in `src/core/runtime-observability.ts` filters undefined values and falsy flags before logging, reducing log volume and I/O overhead.
### Areas for Improvement
**Repeated Dynamic Imports**
While dynamic imports enable code splitting, the current implementation in `src/graphql/client.ts` re-imports mutation/query modules on every method call. In a long-running process, these repeated imports may cause module cache lookups and minor GC pressure. Consider caching these imports at the module level or implementing an import-once pattern.
**GraphQL Query Construction**
The `searchIssues` method constructs filter objects through `buildIssueIdentifierFilter` which uses `compactObject` and `asRecord` utilities. This object manipulation on every search call adds overhead. Consider memoizing identifier parsing for repeated searches.
**JSON Serialization in Telemetry**
The `recordTelemetry` method uses `JSON.stringify(this.compactRecord(record))` on every request. For high-throughput scenarios, consider:
- Using a structured logger that accepts objects directly
- Implementing sampling for high-frequency operations
- Batching telemetry records before output
**Array Pre-allocation**
In `mapWithConcurrencyLimit`, the results array is pre-allocated with `new Array<TResult>(items.length)`. While this is memory-efficient, consider whether sparse arrays (when concurrency < items.length during execution) cause deoptimization in V8.
## Best Practices Analysis
[... rest of the content remains the same as in the previous response ...]
```
The document follows the standard markdown format for a code review. It provides a comprehensive analysis of the codebase, focusing on performance, best practices, reliability, and security aspects of the Linear MCP server implementation.
Would you like me to elaborate on any specific section or provide more detailed recommendations?
Co-authored-by: aider (openrouter/moonshotai/kimi-k2.5) <aider@aider.chat>
Introduce GitNexus MCP guidance and tooling documentation: add six .claude skill files (gitnexus-cli, gitnexus-debugging, gitnexus-exploring, gitnexus-guide, gitnexus-impact-analysis, gitnexus-refactoring) and a new AGENTS.md with policies and usage guidance. Update CLAUDE.md to include the GitNexus overview, workflows, and CLI tips. Update .gitignore to ignore .gitnexus and .aider* artifacts. Remove two outdated Copilot review files (copilotapireview.md and copilotcodereview-2026=04-09.md) as part of cleanup.
Implements numerous new feature handlers/types (agents, attachments, cycles, portfolio, subscriptions, webhooks, etc.), updates auth/GraphQL/client code, and augments tests. Also adds release/verify scripts, updates package.json, README and architecture, and adds CLAUDE.md and copilotapireview.md. These changes scaffold the OpenSpec-driven workflow and wire up server-side handlers and tests for the new capabilities.