home / skills / levnikolaevich / claude-code-skills / ln-401-task-executor

ln-401-task-executor skill

/ln-401-task-executor

This skill executes a single implementation task from Todo to To Review, following KISS/YAGNI and updating kanban and docs.

npx playbooks add skill levnikolaevich/claude-code-skills --skill ln-401-task-executor

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
6.1 KB
---
name: ln-401-task-executor
description: Executes implementation tasks (Todo -> In Progress -> To Review). Follows KISS/YAGNI, guides, quality checks. Not for test tasks.
---

# Implementation Task Executor

Executes a single implementation (or refactor) task from Todo to To Review using the task description and linked guides.

## Purpose & Scope
- Handle one selected task only; never touch other tasks.
- Follow task Technical Approach/plan/AC; apply KISS/YAGNI and guide patterns.
- Update Linear/kanban for this task: Todo -> In Progress -> To Review.
- Run typecheck/lint; update docs/tests/config per task instructions.
- Not for test tasks (label "tests" goes to ln-404-test-executor).

## Task Storage Mode

| Aspect | Linear Mode | File Mode |
|--------|-------------|-----------|
| **Load task** | `get_issue(task_id)` | `Read("docs/tasks/epics/.../tasks/T{NNN}-*.md")` |
| **Update status** | `update_issue(id, state)` | `Edit` the `**Status:**` line in file |
| **Kanban** | Updated by Linear sync | Must update `kanban_board.md` manually |

**File Mode status format:**
```markdown
## Status
**Status:** In Progress | **Priority:** High | **Estimate:** 4h
```

## Mode Detection

Detect operating mode at startup:

**Plan Mode Active:**
- Steps 1-2: Load task context (read-only, OK in plan mode)
- Generate EXECUTION PLAN (files to create/modify, approach) → write to plan file
- Call ExitPlanMode → STOP. Do NOT implement.
- Steps 3-6: After approval → execute implementation

**Normal Mode:**
- Steps 1-6: Standard workflow without stopping

## Progress Tracking with TodoWrite

When operating in any mode, skill MUST create detailed todo checklist tracking ALL steps.

**Rules:**
1. Create todos IMMEDIATELY before Step 1
2. Each workflow step = separate todo item; implementation step gets sub-items
3. Mark `in_progress` before starting step, `completed` after finishing

**Todo Template (10 items):**

```
Step 1: Load Context
  - Fetch full task description + linked guides/manuals/ADRs

Step 2: Receive Task
  - Get task ID from orchestrator, load full description

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
  - 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)
```

## Workflow (concise)
1) **Load context:** Fetch full task description (Linear: get_issue; File: Read task file); read linked guides/manuals/ADRs/research; auto-discover team/config if needed.
2) **Receive task:** Get task ID from orchestrator (ln-400); load full task description.
3) **Start work:** Update this task to In Progress (Linear: update_issue; File: Edit status line); move it in kanban (keep Epic/Story indent).
4) **Implement (with verification loop):** **Before writing new utilities/handlers**, Grep `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; add Task ID comment (`// See PROJ-123`) to new code blocks; update docs noted in Affected Components; update existing tests if impacted (no new tests here). After implementation, execute `verify:` 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.
5) **Quality:** Run typecheck and lint (or project equivalents); ensure instructions in Existing Code Impact are addressed.
6) **Finish:** Mark task To Review (Linear: update_issue; File: Edit status line); update kanban to To Review; add summary comment (what changed, tests run, docs touched).

## Pre-Submission Checklist

**Context:** Self-assessment before To Review reduces review round-trips and catches obvious issues early.

Before setting To Review, verify all 6 items:

| # | Check | Verify |
|---|-------|--------|
| 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 |

**If any check fails:** Fix before setting To Review. Do not rely on reviewer to catch preventable issues.

## Critical Rules
- Single-task updates only; no bulk status changes.
- Keep language of the task (EN/RU) in edits/comments.
- No code snippets in the description; code lives in repo, not in Linear.
- No new test creation; only update existing tests if required.
- Preserve Foundation-First ordering from orchestrator; do not reorder tasks.
- Add Task ID comments to new code blocks for traceability (`// See PROJ-123` or `# See PROJ-123`).
- **Do NOT commit.** Leave all changes uncommitted — ln-402 reviews and commits with task ID reference.

## Definition of Done
- Task selected and set to In Progress; kanban updated accordingly.
- Guides/manuals/ADRs/research read; approach aligned with task Technical Approach.
- Implementation completed per plan/AC; each AC `verify:` method executed with pass evidence.
- Docs and impacted tests updated.
- Typecheck and lint passed (or project quality commands) with evidence in comment.
- Task set to To Review; kanban moved to To Review; summary comment added.

## Reference Files
- Guides/manuals/ADRs/research: `docs/guides/`, `docs/manuals/`, `docs/adrs/`, `docs/research/`
- Kanban format: `docs/tasks/kanban_board.md`

---
**Version:** 3.0.0
**Last Updated:** 2025-12-23

Overview

This skill executes a single implementation or refactor task from Todo to To Review, following the task technical approach and acceptance criteria. It enforces KISS/YAGNI, reuses existing patterns when possible, runs quality checks, updates task status and kanban, and produces a detailed todo checklist for traceability. It does not handle test-only tasks or commit changes; commits are left for the reviewer/committer step.

How this skill works

On start it detects operating mode (Plan or Normal). It loads the task context from Linear or task files, generates a step-by-step execution plan in Plan Mode, or proceeds to implement in Normal Mode. The skill updates task status to In Progress, performs pattern reuse checks in src/, implements changes per AC, runs verify methods, executes typecheck/lint, updates docs/tests as needed, and sets the task to To Review while leaving changes uncommitted.

When to use it

  • When a single implementation or refactor task is selected for execution (not test tasks).
  • When you need a KISS/YAGNI-driven implementation consistent with existing code patterns.
  • When Linear or file-mode tasks require status updates and kanban movement.
  • When acceptance criteria include automated verify steps (test/command/inspect).
  • When you want automated progress tracking using a TodoWrite checklist.

Best practices

  • Operate on one task only; never modify other tasks or reorder work.
  • Always search src/ for existing patterns before adding utilities; document reuse decisions.
  • Create the full TodoWrite checklist before starting and mark items in_progress/completed.
  • Execute all AC verify methods with pass evidence before setting To Review.
  • Run project typecheck/lint and fix issues; update docs and existing tests if impacted.
  • Do not commit changes; leave uncommitted edits for the reviewer/committer step.

Example use cases

  • Implement a small API handler change described in a Linear task and update its status to In Progress/To Review.
  • Refactor a utility while ensuring no duplicate patterns are introduced and documenting rationale.
  • Follow a Story Technical Approach to add a configuration flag and update affected docs.
  • Execute verify commands from AC (run specified script and confirm output) and include pass evidence in the summary.
  • Run lint/typecheck after code edits and record results before marking the task To Review.

FAQ

What happens in Plan Mode?

The skill performs steps 1–2 to load context and writes an execution plan file, then exits without implementing changes.

Can this skill create new tests?

No. It must not create new tests; only existing tests may be updated if the task requires it.