ln-401-task-executor by levnikolaevich/claude-code-skills
npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-401-task-executorPaths: 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. Ifshared/is missing, fetch files via WebFetch fromhttps://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}.
使用任务描述和链接的指南,执行单个从“待办”到“待评审”的实现(或重构)任务。
| 输入 |
|---|
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 必需 |
|---|
| 来源 |
|---|
| 描述 |
|---|
taskId | 是 | 参数、父级用户故事、看板、用户 | 要执行的任务 |
解析方式: 任务解析链。状态筛选: 待办
必须阅读: 加载 shared/references/tools_config_guide.md、shared/references/storage_mode_detection.md 和 shared/references/input_resolution_pattern.md
提取:task_provider = 任务管理 -> 提供方 (linear | file)。
| 方面 | Linear 模式 | 文件模式 |
|---|---|---|
| 加载任务 | get_issue(task_id) | Read("docs/tasks/epics/.../tasks/T{NNN}-*.md") |
| 更新状态 | save_issue(id, state) | Edit 文件中的 **Status:** 行 |
| 看板 | 通过 Linear 同步更新 | 必须手动更新 kanban_board.md |
文件模式状态格式:
## Status
**Status:** In Progress | **Priority:** High | **Estimate:** 4h
必须阅读: 加载 shared/references/mcp_tool_preferences.md — 只要 hex-line MCP 可用,就始终将其用于代码文件。除非 hex-line 不可用,否则不要回退到标准的 Read/Edit 工具。
在启动时检测操作模式:
计划模式激活:
正常模式:
在任何模式下操作时,技能必须创建详细的待办事项清单来跟踪所有步骤。
规则:
in_progress,完成后标记为 completed待办事项模板(10 项):
Step 1: Resolve taskId
- Resolve via args / Story context / kanban / AskUserQuestion (Todo filter)
Step 2: Load Context
- Fetch full task description + linked guides/manuals/ADRs
Step 2b: Goal Articulation Gate
- Complete 4 questions from shared/references/goal_articulation_gate.md (<=25 tokens each)
Step 2c: Implementation Blueprint
- From task "Affected Components": extract file paths (Glob/Grep to find actual paths)
- Read each file (or key sections) to understand current structure
- Output:
## Implementation Blueprint: {taskId}
**Files to create:** [list with brief purpose]
**Files to modify:** [list with what changes]
**Change order (dependencies first):**
1. {file} — {what and why first}
2. {file} — {depends on step 1}
**Risks:** {shared files with parallel tasks, if any}
- Scope: ONLY files of this task. Do not analyze other tasks.
Step 3: Start Work
- Set task to In Progress, update kanban
Step 4: Implement
- 4a Pattern Reuse: IF creating new file/utility, Grep src/ for existing similar patterns
(error handlers, validators, HTTP wrappers, config loaders). Reuse if found.
- 4b Follow task plan/AC, apply KISS/YAGNI
- 4c Architecture Guard: IF creating service function: (1) 3+ side-effect categories in **leaf** function → split (EXCEPT orchestrator functions that delegate sequentially — these are expected to have 3+ categories);
(2) get_*/find_*/check_* naming → verify no hidden writes; (3) 3+ service imports in **leaf** function → flatten (orchestrator imports are expected)
(4) **Frontend Guard (conditional):** IF affected files include `.tsx/.vue/.svelte/.html/.css` → **MANDATORY READ:** `shared/references/frontend_design_guide.md`. Load project's design_guidelines.md if exists (design tokens source of truth). Verify: one composition per viewport; max 2 typefaces + 1 accent color; cards only when interaction requires; motion max 2-3 purposeful; WCAG 2.1 AA contrast (4.5:1 text, 3:1 UI elements)
- Update docs and existing tests if impacted
- Execute verify: methods from task AC (test/command/inspect)
Step 5: Quality
- Run typecheck and lint (or project equivalents)
Step 6: Finish
- Set task to To Review, update kanban
- Add summary comment (changes, tests, docs)
shared/references/goal_articulation_gate.md — 完成 4 个问题的关卡(每个 <=25 个词元)。陈述真实目标(可交付成果作为主语)、完成的样子、不是目标、不变量和隐藏约束。2c) 实现蓝图: 根据任务“受影响组件”,通过 Glob/Grep 查找实际文件路径。读取每个文件的关键部分。输出结构化计划:要创建/修改的文件、更改顺序(依赖项优先)、风险(与并行任务共享的文件)。范围:仅限此任务。src/ 中 Grep 查找现有模式(错误处理、验证、配置访问)。如果找到则复用;如果不可复用,在代码注释中记录理由。遵循复选框/计划;保持简单;避免硬编码值;复用现有组件;更新“受影响组件”中注明的文档;如果受影响则更新现有测试(此处不创建新测试)。在创建服务函数之前,应用架构守卫(级联深度、接口诚实性、扁平编排;对于前端文件:必须阅读 shared/references/frontend_design_guide.md,如果存在则加载 design_guidelines.md,验证组合/排版/WCAG 规则)。实现后,执行任务验收标准中的 verify: 方法:test -> 运行指定测试;command -> 执行并检查输出;inspect -> 验证文件/内容是否存在。如果任何验证失败 -> 在继续之前修复。上下文: 在设置为“待评审”前进行自我评估,可以减少评审往返次数并及早发现明显问题。
必须阅读: 加载 shared/references/code_efficiency_criterion.md — 提交前进行自检。
在设置为“待评审”之前,验证所有项目:
---|---|---
0 | 验收标准已验证 | 每个验收标准的 verify: 方法已执行,并提供通过证据
1 | 方案一致性 | 实现与用户故事技术方案匹配
2 | 代码整洁 | 无死代码,无向后兼容垫片,未使用的导入已移除
3 | 配置卫生 | 无硬编码凭据/URL/魔法数字
4 | 文档已更新 | 受影响组件的文档反映了更改
5 | 测试通过 | 现有测试在更改后仍然通过
6 | 模式复用 | 新工具已对照现有代码库检查;未引入重复模式
7 | 架构守卫 | 级联深度 <= 2(叶子函数);以读取命名的函数中没有隐藏的写入操作;叶子函数中的服务链不超过 3 个(编排器导入豁免)。前端文件:组合、排版、WCAG 符合 shared/references/frontend_design_guide.md
8 | 破坏性操作安全性 | 如果任务包含“破坏性操作安全性”部分:(1) 在破坏性代码之前执行/计划了备份步骤,(2) 代码中存在回滚机制,(3) 存在环境守卫,(4) 预览/试运行证据已附加或引用
9 | 代码效率 | 没有不必要的中间变量,冗长的模式已替换为语言惯用法,没有样板框架处理程序(根据 shared/references/code_efficiency_criterion.md)
必须阅读: 加载 shared/references/destructive_operation_safety.md 以了解严重性分类和安全要求。
人工介入关卡: 如果任务严重性 = 严重(根据上面加载的 destructive_operation_safety.md):使用 AskUserQuestion 在标记为“待评审”前进行确认:“任务包含严重的破坏性操作:{operation}。备份计划:{plan}。是否继续?” 在用户确认之前,不要标记为“待评审”。
如果任何检查失败: 在设置为“待评审”之前修复。不要依赖评审员来发现可预防的问题。
verify: 方法已执行,并提供通过证据。shared/references/tools_config_guide.mdshared/references/storage_mode_detection.mddocs/guides/、docs/manuals/、docs/adrs/、docs/research/docs/tasks/kanban_board.md版本: 3.0.0 最后更新: 2025-12-23
每周安装次数
153
仓库
GitHub 星标数
245
首次出现
2026年1月24日
安全审计
安装于
claude-code138
gemini-cli135
codex135
opencode135
cursor134
github-copilot130
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. Ifshared/is missing, fetch files via WebFetch fromhttps://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}.
Executes a single implementation (or refactor) task from Todo to To Review using the task description and linked guides.
| Input | Required | Source | Description |
|---|---|---|---|
taskId | Yes | args, parent Story, kanban, user | Task to execute |
Resolution: Task Resolution Chain. Status filter: Todo
MANDATORY READ: Load shared/references/tools_config_guide.md, shared/references/storage_mode_detection.md, and shared/references/input_resolution_pattern.md
Extract: task_provider = Task Management → Provider (linear | file).
| Aspect | Linear Mode | File Mode |
|---|---|---|
| Load task | get_issue(task_id) | Read("docs/tasks/epics/.../tasks/T{NNN}-*.md") |
| Update status | save_issue(id, state) | Edit the **Status:** line in file |
| Kanban | Updated by Linear sync | Must update kanban_board.md manually |
File Mode status format:
## Status
**Status:** In Progress | **Priority:** High | **Estimate:** 4h
MANDATORY READ: Load shared/references/mcp_tool_preferences.md — ALWAYS use hex-line MCP for code files when available. No fallback to standard Read/Edit unless hex-line is down.
Detect operating mode at startup:
Plan Mode Active:
Normal Mode:
When operating in any mode, skill MUST create detailed todo checklist tracking ALL steps.
Rules:
in_progress before starting step, completed after finishingTodo Template (10 items):
Step 1: Resolve taskId
- Resolve via args / Story context / kanban / AskUserQuestion (Todo filter)
Step 2: Load Context
- Fetch full task description + linked guides/manuals/ADRs
Step 2b: Goal Articulation Gate
- Complete 4 questions from shared/references/goal_articulation_gate.md (<=25 tokens each)
Step 2c: Implementation Blueprint
- From task "Affected Components": extract file paths (Glob/Grep to find actual paths)
- Read each file (or key sections) to understand current structure
- Output:
## Implementation Blueprint: {taskId}
**Files to create:** [list with brief purpose]
**Files to modify:** [list with what changes]
**Change order (dependencies first):**
1. {file} — {what and why first}
2. {file} — {depends on step 1}
**Risks:** {shared files with parallel tasks, if any}
- Scope: ONLY files of this task. Do not analyze other tasks.
Step 3: Start Work
- Set task to In Progress, update kanban
Step 4: Implement
- 4a Pattern Reuse: IF creating new file/utility, Grep src/ for existing similar patterns
(error handlers, validators, HTTP wrappers, config loaders). Reuse if found.
- 4b Follow task plan/AC, apply KISS/YAGNI
- 4c Architecture Guard: IF creating service function: (1) 3+ side-effect categories in **leaf** function → split (EXCEPT orchestrator functions that delegate sequentially — these are expected to have 3+ categories);
(2) get_*/find_*/check_* naming → verify no hidden writes; (3) 3+ service imports in **leaf** function → flatten (orchestrator imports are expected)
(4) **Frontend Guard (conditional):** IF affected files include `.tsx/.vue/.svelte/.html/.css` → **MANDATORY READ:** `shared/references/frontend_design_guide.md`. Load project's design_guidelines.md if exists (design tokens source of truth). Verify: one composition per viewport; max 2 typefaces + 1 accent color; cards only when interaction requires; motion max 2-3 purposeful; WCAG 2.1 AA contrast (4.5:1 text, 3:1 UI elements)
- Update docs and existing tests if impacted
- Execute verify: methods from task AC (test/command/inspect)
Step 5: Quality
- Run typecheck and lint (or project equivalents)
Step 6: Finish
- Set task to To Review, update kanban
- Add summary comment (changes, tests, docs)
shared/references/goal_articulation_gate.md — Complete the 4-question gate (<=25 tokens each). State REAL GOAL (deliverable as subject), DONE LOOKS LIKE, NOT THE GOAL, INVARIANTS & HIDDEN CONSTRAINTS. 2c) Implementation Blueprint: From task "Affected Components", find actual file paths via Glob/Grep. Read key sections of each file. Output structured plan: files to create/modify, change order (dependencies first), risks (shared files with parallel tasks). Scope: this task only.src/ for existing patterns (error handling, validation, config access). Reuse if found; if not reusable, document rationale in code comment. Follow checkboxes/plan; keep it simple; avoid hardcoded values; reuse existing components; update docs noted in Affected Components; update existing tests if impacted (no new tests here). Before creating service functions, apply Architecture Guard (cascade depth, interface honesty, flat orchestration; for frontend files: MANDATORY READ shared/references/frontend_design_guide.md, load design_guidelines.md if exists, verify composition/typography/WCAG rules). After implementation, execute methods from task AC: test → run specified test; command → execute and check output; inspect → verify file/content exists. If any verify fails → fix before proceeding.Context: Self-assessment before To Review reduces review round-trips and catches obvious issues early.
MANDATORY READ: Load shared/references/code_efficiency_criterion.md — self-check before submission.
Before setting To Review, verify all items:
---|---|---
0 | AC verified | Each AC verify: method executed with pass evidence
1 | Approach alignment | Implementation matches Story Technical Approach
2 | Clean code | No dead code, no backward-compat shims, unused imports removed
3 | Config hygiene | No hardcoded creds/URLs/magic numbers
4 | Docs updated | Affected Components docs reflect changes
5 | Tests pass | Existing tests still pass after changes
6 | Pattern reuse | New utilities checked against existing codebase; no duplicate patterns introduced
7 | Architecture guard | Cascade depth <= 2 (leaf functions); no hidden writes in read-named functions; no service chains >= 3 in leaf functions (orchestrator imports exempt). Frontend files: composition, typography, WCAG per shared/references/frontend_design_guide.md
8 | Destructive op safety | If task has "Destructive Operation Safety" section: (1) backup step executed/planned before destructive code, (2) rollback mechanism exists in code, (3) environment guard present, (4) preview/dry-run evidence attached or referenced
9 | Code efficiency | No unnecessary intermediates, verbose patterns replaced by language idioms, no boilerplate framework handles (per shared/references/code_efficiency_criterion.md)
MANDATORY READ: Load shared/references/destructive_operation_safety.md for severity classification and safety requirements.
HITL Gate: IF task severity = CRITICAL (per destructive_operation_safety.md loaded above): Use AskUserQuestion to confirm before marking To Review: "Task contains CRITICAL destructive operation: {operation}. Backup plan: {plan}. Proceed?" Do NOT mark To Review until user confirms.
If any check fails: Fix before setting To Review. Do not rely on reviewer to catch preventable issues.
verify: method executed with pass evidence.shared/references/tools_config_guide.mdshared/references/storage_mode_detection.mddocs/guides/, docs/manuals/, docs/adrs/, docs/research/docs/tasks/kanban_board.mdVersion: 3.0.0 Last Updated: 2025-12-23
Weekly Installs
153
Repository
GitHub Stars
245
First Seen
Jan 24, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykWarn
Installed on
claude-code138
gemini-cli135
codex135
opencode135
cursor134
github-copilot130
通过 LiteLLM 代理让 Claude Code 对接 GitHub Copilot 运行 | 高级变通方案指南
36,300 周安装
数据质量框架实战:Great Expectations、dbt测试与数据契约确保可靠数据管道
3,900 周安装
charting图表绘制技能:TradingView风格K线图,支持技术指标与资产比较
3,800 周安装
React Email:使用React组件构建HTML电子邮件模板的现代解决方案
3,900 周安装
Kubernetes清单生成器 - 生产就绪K8s YAML配置文件生成指南
3,800 周安装
事件存储设计指南:EventStoreDB、PostgreSQL、Kafka等技术选择与实现
3,900 周安装
Temporal Python 测试策略:使用 pytest 进行工作流单元、集成与重放测试
3,900 周安装
verify: