ln-301-task-creator：基于AI的自动化任务创建器，支持Linear集成与DRY代码检查

ln-301-task-creator by levnikolaevich/claude-code-skills

153 周安装量

245 GitHub Stars

安装命令

npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-301-task-creator

🇨🇳中文介绍

路径说明： 文件路径（shared/、references/、../ln-*）是相对于技能仓库根目录的。如果在当前工作目录下未找到，请定位此 SKILL.md 文件所在的目录，然后向上返回一级以找到仓库根目录。如果缺少 shared/ 目录，请通过 WebFetch 从 https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path} 获取文件。

通用任务创建器

一个根据协调器指令生成任务文档并为实现、重构或测试任务创建 Linear 问题的工作器。

目的与范围

拥有所有任务模板和创建逻辑（Linear + 看板更新）
根据类型（实现/重构/测试）生成完整的任务文档
强制执行特定类型的硬性规则（实现中不创建新测试，重构需要回归策略，测试需要风险矩阵和限制）
如果提供了非功能性需求要点则忽略；只有功能范围会变成任务
从不自行决定范围；使用协调器的输入（计划/结果）

任务存储模式

必读： 加载 shared/references/tools_config_guide.md 和

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

调用（由谁/何时）

ln-300-task-coordinator: 为实施任务执行 CREATE（无任务）或 ADD（追加模式）。
协调器（其他组）： 根据需要创建重构或测试任务。
用户从不直接调用。

通用：taskType、teamId、Story 数据（包含 AC、技术说明、上下文的 id/标题/描述）。
实现 CREATE：idealPlan（1-8 个任务）、guideLinks。
实现 ADD：appendMode=true、newTaskDescription、guideLinks。
重构：codeQualityIssues、refactoringPlan、affectedComponents。
测试：manualTestResults、testPlan（优先级 ≥15，有用性标准）、基础设施/文档/清理项。

必读： 加载 shared/references/creation_quality_checklist.md §任务创建检查清单，以获取 ln-310 将强制执行的有效性标准。加载 shared/references/destructive_operation_safety.md 以获取破坏性操作关键词和严重性分类。

工作流程（简明）

DRY 检查（代码库扫描）： 对计划中的每个任务：
- 从任务描述中提取关键词：函数类型、组件名称、领域
- 扫描代码库：Grep(pattern="[keyword]", path="src/", output_mode="files_with_matches") 以查找类似功能
- 如果找到类似代码（关键词匹配度 ≥70%）：
  - 在任务描述的"实施计划"部分之前添加 ⚠️ DRY 警告 部分：
```
          > [!WARNING]
```
    DRY 检查： 在代码库中检测到类似功能
    - 现有代码：src/services/auth/validateToken.ts:15-42
    - 相似度：85%（函数名、领域匹配）
    - 建议： 在创建新代码前审查现有实现
      
      选项 1：重用现有函数（导入并调用）
      
      选项 2：使用新参数扩展现有函数
      
      选项 3：论证为何需要重新实现（在技术方案中记录）
- 如果没有重复 → 继续执行，不添加警告
- 原理：在实施开始前防止代码重复
模板选择： 根据 taskType 加载模板（参见"模板加载"部分）。
生成文档： 使用提供的数据、指导链接和 DRY 警告，为计划/请求中的每个任务填充各个部分。
- 继承的假设： 从父级 Story 的假设表中提取相关假设，添加到"上下文 > 继承的假设"中。仅列出影响此任务的假设。使用 A{N} ({CATEGORY}) 格式。
- 破坏性操作检测： 对于每个任务，扫描"实施计划"中是否包含来自 destructive_operation_safety.md（上面已加载）的关键词。如果检测到 → 包含来自共享参考模板的"破坏性操作安全"部分（必填）。创建者填写所有 5 个字段 + 严重性。如果未检测到 → 省略该部分。
验证类型规则： 如果违反规则则停止并报错（参见下表）。
预览： 显示标题/目标/估算/AC/组件、DRY 警告数量以及总计。
需要确认： 仅在获得明确确认后继续。
创建问题： 调用 Linear create_issue，设置 parentId=Story，state=Backlog；捕获 URL。
更新看板： 在 Story 下的 Backlog 列中添加，使用正确的 Epic/缩进。
返回摘要： URL、数量、工时、指导链接数量、DRY 警告数量；后续步骤（验证器/执行器）。

类型规则（必须通过）

taskType	硬性规则	需要验证的内容
implementation	不创建新测试	扫描文本中是否有"编写/创建/添加测试"等字样；仅允许更新现有测试
refactoring	需要回归策略	列出问题及其严重性；分 3 个阶段的计划；回归策略（基线/验证/失败）；保留功能
test	需要基于风险的计划	覆盖优先级 ≥15 的场景；每个测试都通过有用性标准；不进行框架/库/数据库测试

必填： 调用 create_issue 时始终传递 state: "Backlog"。如果未指定，Linear 默认使用团队的默认状态（通常是"Postponed"）。
DRY 检查： 在生成前为每个任务扫描代码库。如果找到类似代码（关键词匹配度 ≥70%）→ 添加带有 3 个选项（重用/扩展/论证）的 ⚠️ DRY 警告 部分。对测试任务跳过扫描（无实施代码）。
破坏性操作检测： 使用来自 destructive_operation_safety.md（上面已加载）的关键词列表。如果在任务计划中找到 → 包含"破坏性操作安全"部分作为必填项。
实现任务的"基础优先"顺序由协调器保留；不要重新排序。
不包含代码片段；仅保留方案、API 和伪代码。
文档更新必须包含在"受影响组件/文档"部分。
语言保留：在生成的任务中保持 Story 的语言（英文/俄文）。

DRY 警告示例：

Example 1: Email validation (HIGH similarity - 90%)
> [!WARNING]
> **DRY 检查：** 检测到类似功能
> - 现有代码：src/utils/validators/email.ts:validateEmail()
> - 相似度：90%（完全相同的函数名 + 领域匹配）
> - **建议：** 重用现有函数（选项 1）

Example 2: User authentication (MEDIUM similarity - 75%)
> [!WARNING]
> **DRY 检查：** 存在部分功能
> - 现有代码：src/services/auth/login.ts:authenticateUser()
> - 相似度：75%（领域匹配，范围不同）
> - **建议：** 审查现有代码，考虑扩展（选项 2）或论证新实现（选项 3）

Example 3: No duplication (skip warning)
- 未找到类似代码 → 继续执行，不添加 DRY 警告

DRY 检查完成： 已为每个任务扫描代码库；检测到类似代码（Grep）；如果相似度 ≥70%，已将 DRY 警告添加到任务描述中。
上下文检查完成（已审查现有组件/架构/依赖项/文档；已标记冲突）。
已使用正确的模板、完整的部分和 DRY 警告（如适用）生成文档。
类型验证通过（实现中不创建测试；重构有回归策略；测试有风险矩阵/限制）。
已显示包含 DRY 警告数量的预览，并且用户已确认。
已创建 Linear 问题，捕获了 parentId 和 URL；state=Backlog。
已更新 kanban_board.md，在正确的 Epic/Story 下使用缩进。
已返回包含 URL、总计、DRY 警告数量和后续步骤的摘要。

必读： 加载 shared/references/template_loading_pattern.md 以了解模板复制工作流程。

根据 taskType 选择模板：

implementation → task_template_implementation.md
refactoring → refactoring_task_template.md
test → test_task_template.md

本地副本： docs/templates/*.md（在目标项目中）

工具配置： shared/references/tools_config_guide.md
存储模式操作： shared/references/storage_mode_detection.md
看板更新算法： shared/references/kanban_update_algorithm.md
模板加载： shared/references/template_loading_pattern.md
Linear 创建工作流程： shared/references/linear_creation_workflow.md
模板（集中式）：shared/templates/task_template_implementation.md、shared/templates/refactoring_task_template.md、shared/templates/test_task_template.md
本地副本：docs/templates/*.md（在目标项目中）
看板格式：docs/tasks/kanban_board.md

版本： 3.0.0 最后更新： 2025-12-23

🇺🇸English

Paths: File paths (shared/, references/, ../ln-*) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root. If shared/ is missing, fetch files via WebFetch from https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}.

Universal Task Creator

Worker that generates task documents and creates Linear issues for implementation, refactoring, or test tasks as instructed by orchestrators.

Purpose & Scope

Owns all task templates and creation logic (Linear + kanban updates)
Generates full task documents per type (implementation/refactoring/test)
Enforces type-specific hard rules (no new tests in impl, regression strategy for refactoring, risk matrix and limits for test)
Drops NFR bullets if supplied; only functional scope becomes tasks
Never decides scope itself; uses orchestrator input (plans/results)

Task Storage Mode

MANDATORY READ: Load shared/references/tools_config_guide.md and shared/references/storage_mode_detection.md

Extract: task_provider = Task Management → Provider (linear | file).

Invocation (who/when)

ln-300-task-coordinator: CREATE (no tasks) or ADD (appendMode) for implementation tasks.
Orchestrators (other groups): Create refactoring or test tasks as needed.
Never called directly by users.

Inputs

Common: taskType, teamId, Story data (id/title/description with AC, Technical Notes, Context).
Implementation CREATE: idealPlan (1-8 tasks), guideLinks.
Implementation ADD: appendMode=true, newTaskDescription, guideLinks.
Refactoring: codeQualityIssues, refactoringPlan, affectedComponents.
Test: manualTestResults, testPlan (Priority ≥15, Usefulness Criteria), infra/doc/cleanup items.

Quality Criteria

MANDATORY READ: Load shared/references/creation_quality_checklist.md §Task Creation Checklist for validation criteria that ln-310 will enforce. Load shared/references/destructive_operation_safety.md for destructive operation keywords and severity classification.

Workflow (concise)

DRY Check (Codebase Scan): For EACH Task in plan:
- Extract keywords: function type, component name, domain from Task description
- Scan codebase: Grep(pattern="[keyword]", path="src/", output_mode="files_with_matches") for similar functionality
- IF similar code found (≥70% keyword match):
  - Add ⚠️ DRY Warning section to Task description BEFORE Implementation Plan:
```
           > [!WARNING]
```
    DRY Check: Similar functionality detected in codebase
    - Existing: src/services/auth/validateToken.ts:15-42
    - Similarity: 85% (function name, domain match)
    - Recommendation: Review existing implementation before creating new code
      
      Option 1: Reuse existing function (import and call)
      
      Option 2: Extend existing function with new parameters
      
      Option 3: Justify why reimplementation needed (document in Technical Approach)
- → Proceed without warning

Type Rules (must pass)

taskType	Hard rule	What to verify
implementation	No new test creation	Scan text for "write/create/add tests" etc.; allow only updating existing tests
refactoring	Regression strategy required	Issues listed with severity; plan in 3 phases; regression strategy (Baseline/Verify/Failure); preserve functionality
test	Risk-based plan required	Priority ≥15 scenarios covered; each test passes Usefulness Criteria; no framework/library/DB tests

Critical Notes

MANDATORY: Always pass state: "Backlog" when calling create_issue. Linear defaults to team's default status (often "Postponed") if not specified.
DRY Check: Scan codebase for EACH Task before generation. If similar code found (≥70% keyword match) → add ⚠️ DRY Warning section with 3 options (reuse/extend/justify). Skip scan for test tasks (no implementation code).
Destructive Op Detection: Use keyword list from destructive_operation_safety.md (loaded above). If found in task plan → include Destructive Operation Safety section as MANDATORY.
Foundation-First order for implementation is preserved from orchestrator; do not reorder.
No code snippets; keep to approach, APIs, and pseudocode only.
Documentation updates must be included in Affected Components/Docs sections.
Language preservation: keep Story language (EN/RU) in generated tasks.

DRY Warning Examples:

Example 1: Email validation (HIGH similarity - 90%)
> [!WARNING]
> **DRY Check:** Similar functionality detected
> - Existing: src/utils/validators/email.ts:validateEmail()
> - Similarity: 90% (exact function name + domain match)
> - **Recommendation:** REUSE existing function (Option 1)

Example 2: User authentication (MEDIUM similarity - 75%)
> [!WARNING]
> **DRY Check:** Partial functionality exists
> - Existing: src/services/auth/login.ts:authenticateUser()
> - Similarity: 75% (domain match, different scope)
> - **Recommendation:** Review existing code, consider EXTEND (Option 2) or JUSTIFY new implementation (Option 3)

Example 3: No duplication (skip warning)
- No similar code found → Proceed without DRY warning

Definition of Done

DRY Check complete: Codebase scanned for EACH Task; similar code detected (Grep); DRY warnings added to Task descriptions if ≥70% similarity found.
Context check complete (existing components/schema/deps/docs reviewed; conflicts flagged).
Documents generated with correct template, full sections, and DRY warnings (if applicable).
Type validation passed (no test creation for impl; regression strategy for refactor; risk matrix/limits for test).
Preview shown with DRY warnings count and user confirmed.
Linear issues created with parentId and URLs captured; state=Backlog.
kanban_board.md updated under correct Epic/Story with indentation.
Summary returned with URLs, totals, DRY warnings count, and next steps.

Template Loading

MANDATORY READ: Load shared/references/template_loading_pattern.md for template copy workflow.

Template Selection by taskType:

implementation → task_template_implementation.md
refactoring → refactoring_task_template.md
test → test_task_template.md

Local copies: docs/templates/*.md (in target project)

Reference Files

Tools config: shared/references/tools_config_guide.md
Storage mode operations: shared/references/storage_mode_detection.md
Kanban update algorithm: shared/references/kanban_update_algorithm.md
Template loading: shared/references/template_loading_pattern.md
Linear creation workflow: shared/references/linear_creation_workflow.md
Templates (centralized): shared/templates/task_template_implementation.md, shared/templates/refactoring_task_template.md, shared/templates/test_task_template.md

Version: 3.0.0 Last Updated: 2025-12-23

Weekly Installs

153

Repository

levnikolaevich/…e-skills

GitHub Stars

245

First Seen

Jan 24, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykWarn

Installed on

claude-code140

codex138

gemini-cli138

opencode138

cursor136

github-copilot133

通过 LiteLLM 代理让 Claude Code 对接 GitHub Copilot 运行 | 高级变通方案指南

36,300 周安装

IF no duplication

Rationale: Prevents code duplication BEFORE implementation starts

Template select: Load template based on taskType (see "Template Loading" section).

Generate docs: Fill sections for each task in plan/request using provided data, guide links, and DRY warnings.

Inherited Assumptions: Extract relevant assumptions from parent Story Assumptions table, add to Context > Inherited Assumptions. Only list assumptions affecting THIS task. Use A{N} ({CATEGORY}) format.
Destructive Op Detection: For EACH task, scan Implementation Plan for keywords from destructive_operation_safety.md (loaded above). IF detected → include "Destructive Operation Safety" section from shared reference template (MANDATORY). Creator fills all 5 fields + severity. IF NOT detected → omit section.

Validate type rules: Stop with error if violation (see table below).

Preview: Show titles/goals/estimates/AC/components, DRY warnings count, and totals.

Confirmation required: Proceed only after explicit confirm.

Create issues: Call Linear create_issue with parentId=Story, state=Backlog; capture URLs.

Update kanban: Add under Story in Backlog with correct Epic/indent.

Return summary: URLs, counts, hours, guide link count, DRY warnings count; next steps (validator/executor).

Local copies: docs/templates/*.md (in target project)

Kanban format: docs/tasks/kanban_board.md