Interact with Linear.app for issue tracking. Use when working with Linear tickets (format ABC-123), creating issues, updating status, or downloading attachments. Triggers on ticket references, issue management, or when user mentions Linear.
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
We track tickets and projects in Linear (https://linear.app). Use the linearis CLI tool via Bash.
Run linearis usage to see all available commands and options.
| Command | Purpose |
|---|---|
linearis issues read ABC-123 | Get issue details + attachments |
linearis issues search "keyword" | Search issues |
linearis issues create "Title" --team Team | Create issue |
linearis issues update ABC-123 --status "Done" | Update issue |
linearis comments create ABC-123 --body "text" | Add comment |
linearis documents list --issue ABC-123 | List attached docs |
linearis embeds download "<url>" --output ./file --overwrite | Download attachment |
ABC-<number> (e.g., FOR-123)When the user asks to start working on a Linear issue, these steps must be included in your plan (using TodoWrite or similar planning tools):
Read the issue details:
linearis issues read ABC-123
Switch to main branch:
git checkout main
git pull origin main
Create a feature branch:
feature/ABC-123-brief-descriptionfeature/FOR-123-add-costs-projectiongit checkout -b feature/ABC-123-brief-description
Update issue status to "In Progress":
linearis issues update ABC-123 --status "In Progress"
Implement the feature:
Verify implementation and get user sign-off:
/verify-plan <PLAN-PATH> (if a plan file exists)When complete and approved, create a pull request:
git push -u origin feature/ABC-123-brief-description
gh pr create --title "ABC-123: Brief description" --body "Resolves ABC-123\n\n## Summary\n- Implemented feature...\n\n## Test plan\n- [ ] Tested scenario..."
Update issue status to "In Review":
linearis issues update ABC-123 --status "In Review"
Critical: When planning work on a Linear issue, include ALL these workflow steps in your TodoWrite plan. Don't just implement the feature - the plan must include branch creation at the start, user sign-off verification before committing, and PR creation at the end.
When the user asks to investigate/explore/look into a Linear issue (without immediately implementing):
linearis issues read ABC-123Always produce a visible summary even if the investigation is cut short. The summary is the deliverable.
Read issue with attachments:
linearis issues read ABC-123
Returns JSON including an embeds array containing uploaded files (screenshots, documents, etc.) with signed download URLs and expiration timestamps.
Download attachments to .linear-tmp/ (gitignored):
mkdir -p .linear-tmp
linearis embeds download "https://uploads.linear.app/..." --output .linear-tmp/screenshot.png --overwrite
- [ ] task → - [x] task), update the description accordinglylinearis comments create ABC-123 --body "Progress update: ..."
A project-local token file .linear_api_token exists in the project root. Always pass it explicitly when running linearis commands:
linearis --api-token "$(cat .linear_api_token)" <command>
Do NOT rely on ~/.linear_api_token or LINEAR_API_TOKEN env var — those may belong to a different team.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Create and manage Architecture Decision Records (ADRs). Use when making architectural changes (refactoring, API versioning, new domain layers, schema changes), when reviewing recent commits for documentation needs, or when the user mentions ADR, architecture decisions, or documenting technical decisions.
The English summary is being prepared. Showing the original description.
Detect documentation and architecture-model drift by comparing source-of-truth code (CLI commands, flags, env vars, GH Action inputs/outputs, package structure, pipeline stages, providers, adapters, platforms) against web docs, README, and LikeC4 architecture model (.c4 files). Use when files that define the user-facing interface or internal structure change, when the user asks to check docs, or when mentioning doc drift, architecture drift, stale docs, or documentation sync.
The English summary is being prepared. Showing the original description.
Enforce the project's documentation voice when writing or reviewing public-facing content. Triggers on edits to doc files (packages/web/src/content/docs/**/*.md) and README.md. Catches LLM prose patterns, marketing language, and messaging drift.
The English summary is being prepared. Showing the original description.
Use this skill whenever code changes introduce new imports, API calls, database connections, message queues, or service-to-service communication. Also use before any commit or push. Catches undeclared dependencies and architecture violations using Erode.
The English summary is being prepared. Showing the original description.
Generate product pitch videos for the Erode project from screenshots. Use this skill whenever the user wants to create, update, or regenerate the product demo video, landing page animation, or pitch clip for erode.dev or the GitHub repo. Also trigger when the user mentions "product video", "demo video", "pitch video", "update the video", "regenerate video", or "landing page animation" in the context of Erode.
The English summary is being prepared. Showing the original description.
Conventional commits with project conventions. Use when the user asks to commit, make a commit, or wants to follow the project's git commit standard.
The English summary is being prepared. Showing the original description.