From tehik-task-board
Processes a folder-based task queue — completes tasks and moves them to the output folder together with artifact directories
How this skill is triggered — by the user, by Claude, or both
Slash command
/tehik-task-board:process-task-boardThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The user provides an **input folder** (pending tasks) and an **output folder** (completed work awaiting review or final completion). The agent completes tasks one at a time or in batches (if the user specifies), creates **artifact directories** when needed, and moves the task file(s) to the output location.
The user provides an input folder (pending tasks) and an output folder (completed work awaiting review or final completion). The agent completes tasks one at a time or in batches (if the user specifies), creates artifact directories when needed, and moves the task file(s) to the output location.
User guide (board flow vs
implement-feature, execution order): docs/task-board.md
Prerequisite: Paths and filenames are in English (code and structure). Task content or artifacts may be in Estonian only if the user explicitly requests it.
Default layout (names may vary by project — the user may supply their own paths):
<project-root>/
└── Agent_reports/
└── Tasks/
├── To-Do/ # input — unprocessed tasks
├── To-Validate/ # first pass complete; awaiting **`/validate-task-board`** review
└── Done/ # finally approved (after validation or if skipped)
To-Do → To-Validate: preferred output after completing a task when you want a second pass (stronger model) before Done.To-Do → Done: allowed for simple or low-risk tasks — state this clearly in the summary.Agent_reports/Tasks/.working/ (gitignore recommended) if you do not want to mix in_progress files with the To-Do indicator.The user may supply arbitrary paths, e.g. only .../To-Do and .../To-Validate. Adjust steps accordingly.
To avoid a long prompt on every run, support a config file alongside the project:
Agent_reports/Tasks/board-config.yaml (preferred)Example:
paths:
# may also be absolute paths outside the git repo
todo: /Users/your-user/Agent_reports/Tasks/To-Do
to_validate: /Users/your-user/Agent_reports/Tasks/To-Validate
done: /Users/your-user/Agent_reports/Tasks/Done
repos:
include:
- id: backend
path: services/backend
- id: frontend
path: apps/frontend
discover:
enabled: false
roots: [services, apps]
max_depth: 4
ignore_paths: [Agent_reports, node_modules, .git]
execution:
single_task_at_a_time: true
create_branch_before_changes: true
move_completed_to: to_validate # to_validate | done
run_validation_pass: true
git:
strategy: ask # ask | mr | auto_merge_target
merge_target_branch: develop
checkout_target_after_merge: true
If the user prompt and config conflict, the user prompt wins.
Each task is preferably a Markdown file (.md); .txt is also acceptable.
Recommended YAML frontmatter:
---
id: PROJ-1842
type: code # code | analysis | validation | breakdown | epic
code_workflow: implement-feature # optional: implement-feature | fix-bug | refactor
title: Short title
source: jira
jira_id: "" # optional: Jira key (e.g. VAHE-3174), set by business-brief-to-tasks
epic_of: "" # optional: parent epic id, set by business-brief-to-tasks
status: open # open | in_progress | pending_validation | done | blocked | needs_revision
depends_on: [] # optional: list of blocking task ids
follow_up_tasks: [] # optional: ids of follow-up tasks created during processing
---
Fields added automatically during the validation pass (/validate-task-board), not set at creation: validation_status, validated_at, reviewer.
type drives behavior:
type | Action |
|---|---|
code | Do not limit yourself to “writing code only”. Follow type: code — chaining below; select and execute fully one primary workflow (implement-feature, fix-bug, or refactor) together with the sub-workflows described there (slash commands). |
analysis | Produce structured analysis (goals, constraints, options, recommendation). Add diagrams (mermaid), data model sketches, API patterns as needed — keep them in the same artifact directory. If the analysis requires deep codebase understanding, start with /analyze-codebase. |
validation | Follow the /validate-external-proposal workflow (or its checklist). |
breakdown | Follow /business-brief-to-tasks — create smaller tasks in the To-Do folder (or the queue the user specified); mark this task complete only after subtasks are created, then move per output rules (To-Validate or Done). |
epic | Like breakdown, but allow EPIC-level items (large bundles) + subtasks in subfolders; do not cram large work into one overly small file. |
If frontmatter is missing: infer type from the task text and ask the user for confirmation if uncertain.
type: code — chaining with existing workflowsThis file (/process-task-board) only sequences tasks and folders. For code-changing tasks, the main work is always in the corresponding command/workflow — the agent must run the right command (e.g. /implement-feature) and complete every phase in order, not a shortened “patch only” version.
| Situation | Primary workflow | Note |
|---|---|---|
| New functionality, extension | /implement-feature | Default when the task does not describe a bugfix |
| Bugfix, regression | /fix-bug | Use code_workflow: fix-bug or a clear bug description in the task |
| Structural change, same behavior | /refactor | If behavior changes → that is a feat or fix, not a refactor |
If the task has code_workflow in frontmatter, follow it. If missing, choose using the table.
These are embedded in the chosen primary workflow file; the agent must not skip them if that workflow requires them:
| Primary workflow | Typical internal references (read and follow in full) |
|---|---|
implement-feature | /analyze-codebase → /create-branch (feature) → implement → /update-docs → /run-tests → /conventional-commit → MR draft |
fix-bug | /analyze-codebase → /create-branch (fix) → fix + regression test → /run-tests → /update-docs → /conventional-commit → MR draft |
refactor | /analyze-codebase → /run-tests (before change) → /create-branch → refactor → /run-tests → /update-docs → /conventional-commit |
Each referenced slash command points to the canonical workflow with the same ID; run it in full when you need more detailed steps.
/update-docs./update-dependencies (when the task is specifically about dependencies)./release (when the task requires it).If the task explicitly says “do not branch / do not commit” (e.g. spike), note an exception in the task file and summary and stay within what the user allowed.
skills/)For use with this board (full list):
| Workflow | Use |
|---|---|
implement-feature | New functionality cycle |
fix-bug | Bugfix |
refactor | Structure without behavior change |
analyze-codebase | Base exploration, AGENTS.md context |
create-branch | Branch creation |
run-tests | Tests + lint + coverage |
update-docs | CHANGELOG, README, OpenAPI, diagrams |
conventional-commit | Commit message |
update-dependencies | Dependency updates |
release | Release cycle |
business-brief-to-tasks | Breaking down business requirements |
validate-external-proposal | External proposal review |
validate-task-board | To-Validate review |
process-task-board | This file — queue and folders |
Load project config if present: Agent_reports/Tasks/board-config.yaml.
If the user does not supply paths, use config paths.*; if config is missing, assume from project root: input Agent_reports/Tasks/To-Do/, output Agent_reports/Tasks/To-Validate/ (create folders as needed).
If config has repos.include, use those paths for tests and changes.
If repos.discover.enabled: true, discover repos only under roots and skip ignore_paths.
Set execution mode:
single_task_at_a_time: true);Ensure input and output folders exist (create output if needed).
List tasks in the input folder; order:
depends_on or with satisfied dependencies;blocked unless the user says otherwise.If the user asks to go straight to Done without To-Validate, set output to Agent_reports/Tasks/Done/ (or the path they gave).
If the queue has type: code tasks, set Git strategy:
git.strategy is mr or auto_merge_target, use it without extra questions;git.strategy is ask (or missing), ask once before the first code task:
git.merge_target_branch and check out git.merge_target_branch again
Save the choice for the run and apply to all type: code tasks in the same run unless the user says otherwise.If execution.create_branch_before_changes: true, apply a strict branch rule for each type: code task:
feature/*, fix/*, hotfix/*), not the target branch;git.merge_target_branch (or main/develop), run /create-branch first, then start changes;blocked and do not make code changes on the target branch.Agent_reports/Tasks/.working/ (create under Tasks if the user agrees) or set status: in_progress in frontmatter and leave under To-Do for now.type:
type: code: run the chosen primary command/workflow (/implement-feature, etc.) and complete all phases; each slash command in a phase means full application of the workflow with that name, not just the title.type: follow the corresponding row and referenced workflow.To-Validate): <id>-<slug>/ (slug derived from title).README.md in that folder: what was done, where the main artifact is.done):
status: pending_validationstatus: donestatus: needs_revision or blocked<id>/ folder with artifacts).id, clear title, type, rationale);follow_up_tasks: [NEW-ID] or link/id in the summary section);status: pending_validation or done per output rules), not “done by default”;git.merge_target_branch (default develop), then switch back to git.merge_target_branch in the same repo.After a batch or all tasks: table / list — which files went where, what stayed blocked, what needs a human decision.
blocked with a reason or create subtasks (breakdown)./implement-feature, /fix-bug, /refactor (including /analyze-codebase, /create-branch, /run-tests, /update-docs, /conventional-commit, etc. inside them)/business-brief-to-tasks/validate-external-proposalTo-Validate → Done or To-Do: /validate-task-boardGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub tehik-ee/ai-generic-skills --plugin tehik-task-board