Tracked work
DJINN + Linear
No untracked work. A build needs an issue first, so every pull request traces back to something a person can find months later.
How it connects
Intake before code
A free-form request is triaged into an issue before anything is built. The issue id lands in the branch, the commits and the PR title, so the trail runs both directions.
Status is read live, never recalled
Questions about what exists are answered by querying Linear at the time of asking, never from memory. That rule exists because answering from memory went wrong once.
Opening issues is autonomous; closing them is not
DJINN may create tracking issues as part of intake. Marking work done happens through the deploy train, not by the agent deciding it has finished.
Connector spec
- Auth
- oauth2 · linear_v1
- Host
- https://api.linear.app
POST graphql
Emits issue · incremental on updatedAt · cursor pagination
Declared boundary: the connecting operator only
This spec parses and validates, and it has not been run against a live Linear account. Sigil fetches and paginates today; it does not yet apply the mapping or enforce the boundary shown here. Both are declared and checked for shape, not executed.
Documents
Linear setup and reference.
Setup steps, scopes, and the policy boundaries that govern this connector. Sent by email — leave an address and we send them manually, same as the handbook.
- RunbookIssue intake and project routing
- ReferenceNaming and traceability conventions
Want Linear wired into your own company brain?