/spec skill and outerlayer spec file create issues in GitHub, Linear and Jira. For GitHub they need an admin to approve the OuterLayer App’s Issues write permission first. See Spec commands. The repository connection is still needed: pull requests, checks and policy come from GitHub whatever tracker the issue is in.
Before you start
On the factory, you need the Connect a tracker permission. Theowner, admin and write roles have it.
You also need these rights in the tracker:
- Linear: you are an admin of the workspace, so you can authorize an application on it.
- Jira: you can create credentials for a service account in Atlassian Administration, and you hold the Administer Jira permission that creating a webhook needs.
Settings → Issue tracker, with GitHub built in and Linear and Jira ready to connect.
- Linear
- Jira
1
Authorize the workspace
Choose Connect Linear. Linear asks you to authorize OuterLayer on a workspace with write access, which includes read. Authorize a workspace that has at least one team.OuterLayer only creates issues and replaces their descriptions. It does not comment, change status, assign or close issues. People close issues themselves in Linear.
2
Pick the teams to read
Back in OuterLayer, the Teams to read dialog lists the workspace’s teams. Only issues in the teams you tick are listed. Change the set later with Change on the connection’s card.
3
Done
Linear registers its own webhook, so issue changes reach the Work page as they happen. There is nothing to paste.
What a tracker item looks like
OuterLayer reads each issue’s labels from GitHub, Linear and Jira, and keeps them current. You can filter by label on the Work page, and in the Add work dialog. It never writes labels back to the tracker. See The Work list.
A work item from any tracker gets a number on the factory, and that number is what a session is launched with. See Launch a session.
A build reads the issue from OuterLayer’s copy, not from Linear or Jira. The build needs no tracker credential of its own.
outerlayer work status --item <number> --json shows the copy under issue: its description, URL, state and labels, and when it was last read.
On a pull request in a private repository, the OuterLayer comment shows the issue’s title, its link and its “Validation required” asks. On a public repository it shows neither the title nor the text of the asks, so the contents of a private issue never become public. The asks still count toward the evaluation.
From the terminal
outerlayer work build also takes a Linear or Jira key, not only a GitHub issue number:
--repo <owner/name> to say which repository the work goes into. A Linear or Jira key never takes the checkout’s remote, unlike a plain issue number. Without --repo, the item names no repository. A build still works in the factory’s connected repositories, and starts in the first one by name. A runner whose repos.include lists repositories skips such an item, because the item names none for the filter to match.
outerlayer work status, work remove and work claim also take the key: outerlayer work status --issue ENG-142.
Pass --tracker linear or --tracker jira when the factory has connected both trackers. A key like ENG-142 does not say which tracker it belongs to. See the CLI reference for every flag work build takes.