linear-issue-delivery

Solid

Keep a Linear issue aligned with implementation evidence, acceptance criteria, code review, and deployment state while avoiding premature completion claims.

Code & Development 4,373 stars 848 forks Updated today NOASSERTION

Install

View on GitHub

Quality Score: 84/100

Stars 20%

100

Recency 20%

100

Frontmatter 20%

Documentation 15%

Issue Health 10%

License 10%

100

Description 5%

100

Skill Content

# Linear Issue Delivery 1. Read the issue, linked work, acceptance criteria, and current status. 2. Inspect the local or remote implementation evidence supplied by the user. 3. Report gaps between the issue and the actual change before editing either side. 4. Add concise evidence or update status only when the requested milestone is genuinely reached. 5. Preserve links to pull requests, tests, releases, or follow-up issues when available. Do not mark work done based only on a local edit. Distinguish local implementation, pushed code, merged code, and deployed behavior.

Details

Author: Devin-AXIS
Repository: Devin-AXIS/iPolloWork
Created: 12 months ago
Last Updated: today
Language: TypeScript
License: NOASSERTION

Integrates with

GitHub · DevTools Linear · Productivity

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

linear-triage

Triage Linear issues using bounded searches, duplicate checks, explicit team and project scope, and evidence-backed priority recommendations.

4,373 Updated today

Devin-AXIS

AI & Automation Listed

linear

ArcBox's Linear workflow. Use whenever starting a task that may have or need a tracking issue, or working with Linear at all — finding, creating, or updating issues, syncing progress, moving status, triage, or branch/PR linking. Trigger on any mention of Linear, an issue/ticket, an issue ID like ABX-123, a project, the board, or sprint/standup planning.

135 Updated today

arcboxlabs

Web & Frontend Listed

meaningful-linear-issues

Create complete, analytics-ready Linear issues in ONE pass — resolve the right project (never guess it), and proactively fill the metadata that's technically optional but matters for planning/analytics: priority, estimate, labels (a Type + an Area from the team's existing taxonomy), milestone, assignee, cycle, and relations. Use when asked to 'create/file/open a Linear issue', 'log a ticket', 'add this to Linear', 'make an issue for X', or before any Linear `save_issue` that **creates** an issue or **backfills** missing metadata on a bare one — so the user doesn't have to come back and ask for the labels/estimate/project a second time, and so an issue doesn't land in the wrong project. NOT for routine field edits (status changes, reassignments) — those are also `save_issue` but don't need this.

2 Updated 4 days ago

stealth-factory