Token导航 LogoToken导航TokenDH.com
研究检索敏感数据github未标认证来源可访问clear审计未展示

ralph-tui-create-linearralph TUI create Linear 搜索

Agent Skill

用于处理 Linear 项目、Issue、团队、周期和产品开发任务流。它适合让 Agent 辅助查询任务状态、整理需求队列、创建缺陷或汇总迭代进展。使用时需要确认 workspace、team、label、assignee 和状态流转规则;涉及批量创建或修改任务时,应先核对字段和目标团队,避免把草稿需求直接写入正式项目。

总安装

552

周安装

23

GitHub Stars

公开资料未说明

下载量

184
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:ralph-tui-create-linear(ralph TUI create Linear 搜索)
来源仓库:https://github.com/teknologist/ralph-tui
仓库路径:skills/ralph-tui-create-linear
安装命令:
npx skills add teknologist/ralph-tui --skill "ralph-tui-create-linear"
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

AgentSkills.tonpx skills
npx skills add teknologist/ralph-tui --skill "ralph-tui-create-linear"

简介

Ralph TUI Create Linear 技能处理 Linear 项目管理平台的 Issue 与任务流转。

  • 适用于 Codex、Claude、Cursor、Gemini CLI 中自动化创建或更新开发工单。
  • 通过 GitHub 安装,使用 npx 命令添加 teknologist/ralph-tui 仓库中的 Linear 集成模块。
  • 操作前务必确认 workspace 和 team 配置正确,防止任务错发至错误项目空间。
  • ralph-tui-create-linear 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Ralph TUI - Create Linear Issues

Converts PRDs to Linear issues (epic + child issues) for ralph-tui autonomous execution using the built-in Linear tracker.

Note: This skill uses ralph-tui's built-in convert command. No external plugins required.

Prerequisites


The Job

Take a PRD (markdown file or text) and create Linear issues:

  1. Extract Quality Gates from the PRD's "Quality Gates" section
  2. Create a master issue (epic) in Linear
  3. Create sub-issues for each user story as children of the epic
  4. Set up blocking relations based on story dependencies
  5. Output epic ID ready for ralph-tui run --tracker linear --epic TEAM-123

Step 1: Extract Quality Gates

Look for the "Quality Gates" section in the PRD:

## Quality Gates

These commands must pass for every user story:
- `pnpm typecheck` - Type checking
- `pnpm lint` - Linting

For UI stories, also include:
- Verify in browser using dev-browser skill

Extract:

  • Universal gates: Commands that apply to ALL stories (e.g., pnpm typecheck)
  • UI gates: Commands that apply only to UI stories (e.g., browser verification)

If no Quality Gates section exists: Ask the user what commands should pass, or use a sensible default like npm run typecheck.


Creating Issues

Use ralph-tui's built-in convert command:

# Convert PRD to Linear issues (prompts for team ID if not provided)
ralph-tui convert --to linear ./tasks/prd-feature.md

# Specify team ID directly
ralph-tui convert --to linear ./tasks/prd-feature.md --team-id "<team-uuid>"

# Verbose output to see issue details
ralph-tui convert --to linear ./tasks/prd-feature.md --team-id "<team-uuid>" --verbose

The convert command will:

  1. Parse the PRD markdown
  2. Create a master issue (epic) in Linear
  3. Create sub-issues for each user story as children
  4. Set up blocking relations based on dependsOn in the PRD
  5. Output the epic ID for use with ralph-tui

Story Size: The #1 Rule

Each story must be completable in ONE ralph-tui iteration (~one agent context window).

ralph-tui spawns a fresh agent instance per iteration with no memory of previous work. If a story is too big, the agent runs out of context before finishing.

Right-sized stories:

  • Add a database column + migration
  • Add a UI component to an existing page
  • Update a server action with new logic
  • Add a filter dropdown to a list

Too big (split these):

  • "Build the entire dashboard" → Split into: schema, queries, UI components, filters
  • "Add authentication" → Split into: schema, middleware, login UI, session handling
  • "Refactor the API" → Split into one story per endpoint or pattern

Rule of thumb: If you can't describe the change in 2-3 sentences, it's too big.


Story Ordering: Dependencies First

Stories execute in dependency order. Earlier stories must not depend on later ones.

Correct order:

  1. Schema/database changes (migrations)
  2. Server actions / backend logic
  3. UI components that use the backend
  4. Dashboard/summary views that aggregate data

Wrong order:

  1. ❌ UI component (depends on schema that doesn't exist yet)
  2. ❌ Schema change

Dependencies

Dependencies are handled automatically by the convert command:

  1. Parent-child relationships: All user story issues are created as children of the epic
  2. Blocking relations: The dependsOn array in your PRD creates "blocks" relations in Linear

Example PRD with dependencies:

### US-001: Add schema
**Depends on:** (none)

### US-002: Create API
**Depends on:** US-001

### US-003: Build UI
**Depends on:** US-002

This creates:

  • US-001 has no blockers
  • US-002 is blocked by US-001
  • US-003 is blocked by US-002

ralph-tui will:

  • Show blocked issues as unavailable until dependencies complete
  • Never select an issue for execution while its dependencies are open
  • Include dependency context in the prompt when working on an issue

Priority Mapping

ralph-tui maps PRD priorities to Linear's priority scale:

PRD PriorityTaskPriorityLinear PriorityLinear Display
P00 (critical)1Urgent
P11 (high)2High
P22 (medium)3Normal
P33 (low)4Low
P44 (backlog)0No Priority

Note: Linear's priority 0 means "no priority set" (backlog), while 1 is the highest (urgent).

To set priority in your PRD:

### US-001: Critical security fix
**Priority:** P0

### US-002: Regular feature
**Priority:** P2

Acceptance Criteria: Quality Gates + Story-Specific

Each issue's description should include acceptance criteria with:

  1. Story-specific criteria from the PRD (what this story accomplishes)
  2. Quality gates from the PRD's Quality Gates section (appended at the end)

Good criteria (verifiable):

  • "Add investorType column to investor table with default 'cold'"
  • "Filter dropdown has options: All, Cold, Friend"
  • "Clicking toggle shows confirmation dialog"

Bad criteria (vague):

  • ❌ "Works correctly"
  • ❌ "User can do X easily"
  • ❌ "Good UX"
  • ❌ "Handles edge cases"

Linear Anti-Patterns (Avoid These)

❌ Not specifying --team-id

# BAD: Will prompt interactively (blocks automation)
ralph-tui convert --to linear ./prd.md

# GOOD: Specify team ID
ralph-tui convert --to linear ./prd.md --team-id "<team-uuid>"

❌ Creating issues directly in Linear

Don't create issues manually in Linear's UI - use ralph-tui convert to ensure:

  • Proper parent-child relationships
  • Blocking relations match PRD dependencies
  • Consistent formatting for ralph-tui parsing

❌ Using Linear's native sub-issues incorrectly

ralph-tui uses Linear's parent-child relationships for epic→story hierarchy. Don't:

  • Create nested sub-sub-issues (keep it one level deep)
  • Mix manually created sub-issues with ralph-tui managed ones

❌ Manually editing issue hierarchy after creation

If you need to restructure:

  1. Delete the epic and all children in Linear
  2. Update your PRD
  3. Re-run ralph-tui convert --to linear

❌ Using duplicate story IDs

Each story ID must be unique within the PRD:

### US-001: First story   ✅
### US-002: Second story  ✅
### US-001: Third story   ❌ Duplicate!

Example

Input PRD (./tasks/friends-outreach-prd.md):

# PRD: Friends Outreach

Add ability to mark investors as "friends" for warm outreach.

## Quality Gates

These commands must pass for every user story:
- `pnpm typecheck` - Type checking
- `pnpm lint` - Linting

For UI stories, also include:
- Verify in browser using dev-browser skill

## User Stories

### US-001: Add investorType field to investor table
**Priority:** P1
**Description:** As a developer, I need to categorize investors as 'cold' or 'friend'.

**Acceptance Criteria:**
- [ ] Add investorType column: 'cold' | 'friend' (default 'cold')
- [ ] Generate and run migration successfully

### US-002: Add type toggle to investor list rows
**Priority:** P2
**Depends on:** US-001
**Description:** As Ryan, I want to toggle investor type directly from the list.

**Acceptance Criteria:**
- [ ] Each row has Cold | Friend toggle
- [ ] Switching shows confirmation dialog
- [ ] On confirm: updates type in database

### US-003: Filter investors by type
**Priority:** P3
**Depends on:** US-002
**Description:** As Ryan, I want to filter the list to see just friends or cold.

**Acceptance Criteria:**
- [ ] Filter dropdown: All | Cold | Friend
- [ ] Filter persists in URL params

Command:

ralph-tui convert --to linear ./tasks/friends-outreach-prd.md --team-id "<team-uuid>" --verbose

Output:

Parsing PRD: ./tasks/friends-outreach-prd.md
Creating epic: Friends Outreach
  Created: TEAM-456

Creating user stories:
  US-001: Add investorType field to investor table
    Created: TEAM-457 (priority: High)
  US-002: Add type toggle to investor list rows
    Created: TEAM-458 (priority: Normal)
    Added blocking relation: blocked by TEAM-457
  US-003: Filter investors by type
    Created: TEAM-459 (priority: Low)
    Added blocking relation: blocked by TEAM-458

Epic ID: TEAM-456
Run with: ralph-tui run --tracker linear --epic TEAM-456

Running with ralph-tui

After creating issues, run ralph-tui with the Linear tracker:

# Option 1: Specify epic directly
ralph-tui run --tracker linear --epic TEAM-456

# Option 2: Initialize first, then run
ralph-tui init --tracker linear --epicId TEAM-456
ralph-tui run

# Option 3: Use project ID instead of epic
ralph-tui init --tracker linear --projectId "project-uuid"
ralph-tui run

ralph-tui will:

  1. Fetch issues from the specified epic/project
  2. Select the highest-priority unblocked issue
  3. Generate a prompt with issue details + acceptance criteria
  4. Run the agent to implement the story
  5. Update the issue status to "Done" in Linear when completed
  6. Repeat until all stories are done
  7. Output <promise>COMPLETE</promise> when the epic is finished
Note: ralph-tui automatically updates Linear issue status. No manual status changes or workflow skills needed.

Conversion Rules

  1. Extract Quality Gates from PRD first
  2. Each user story → one Linear issue
  3. First story: No blocking relations (creates foundation)
  4. Subsequent stories: Blocked by their dependencies
  5. Priority: Mapped from PRD priority (see Priority Mapping table)
  6. All stories: Created with "unstarted" workflow state
  7. Acceptance criteria: Story criteria + quality gates appended
  8. UI stories: Also append UI-specific gates (browser verification)

Checklist Before Converting

  • Extracted Quality Gates from PRD (or asked user if missing)
  • Each story is completable in one iteration (small enough)
  • Stories are ordered by dependency (schema → backend → UI)
  • Quality gates included in PRD for all stories
  • UI stories have browser verification (if specified in Quality Gates)
  • Acceptance criteria are verifiable (not vague)
  • No story depends on a later story (dependencies flow forward)
  • No circular dependencies
  • --team-id ready for the convert command
  • LINEAR_API_KEY environment variable is set

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude Code

29%
按下载量换算53

windsurf

20.07%
按下载量换算37

OpenCode

17.05%
按下载量换算31

Codex

11.37%
按下载量换算21

Gemini CLI

7.82%
按下载量换算14

Cursor

3.17%
按下载量换算6

安全审计

暂无安全审计结果可展示。

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills