Task body: <body> Review the git changes (run `git diff HEAD~1 HEAD` to see them) against the original plan and coding standards. Check for correctness, security issues, and code quality. Report all issues found, each annotated with a severity (critical/major/minor) and a confidence level. Do not filter by severity in this report — filtering, if needed, is the responsibility of the caller reading this review, not this step. ## Effort / Thoroughness Thoroughness/effort level: <REVIEW_EFFORT> - low: Quick pass. Focus on obvious correctness and security issues. - medium: Standard review. Check correctness, security, and code quality. - high: Deep review. Additionally examine edge cases, test coverage, and architectural fit. - xhigh: Recommended default for coding/agentic work; maximize correctness and edge-case coverage. - max: Reserve for the highest-stakes or most complex tasks. """ ) ``` If the code reviewer identifies critical issues, fix them and commit the fixes before proceeding. ### 8. Update task to done Only execute this step if implementation succeeded — specifically, if ALL of the following conditions are met: > **Scope note**: The interruption guard below applies **only to this status > transition decision** — not to Steps 3–6. If a confirmation or interruption > occurred during implementation and has since been resolved, complete Steps 3–6 > before evaluating the guard below. **Implementation succeeded** means ALL of the following: - At least one `git commit` was executed in this session (verify with `git log --oneline -1`) - Actual code/file changes were committed (not just task management operations) - `git push` completed without errors **The following do NOT count as implementation:** - `agkan task comment add` (comment additions only) - `agkan task update --body` / `--file` (body/metadata updates only) - Discussion or planning without code changes **Before updating to done, verify a commit was made:** ```bash git log --oneline -1 ``` If no commits were made in this session (output is empty or only shows pre-existing commits), do NOT update the status to done. **Surface the failure** by appending an error line to the task body, then leave the task as `in_progress`: ```bash # Surface silent failure: no commit was made agkan task get <id> --json # Write body to tmp file and update using --file to preserve newlines cat > /tmp/agkan_body_$$.md << 'BODY' <existing body> Error: Skill reached end without a commit. Implementation was not completed — files may remain uncommitted in the working tree. Manual intervention required. BODY agkan task update <id> --file /tmp/agkan_body_$$.md # Do NOT run: agkan task update <id> status done ``` **If a critical error occurred** (e.g., git push failed, permission denied, commit failed), do NOT update the status to done. Leave the task as `in_progress` and record the error details in the task body: ```bash # On error: record what went wrong in the task body (optional but recommended) agkan task get <id> --json # Write body to tmp file and update using --file to preserve newlines cat > /tmp/agkan_body_$$.md << 'BODY' <existing body> Error: <error description> BODY agkan task update <id> --file /tmp/agkan_body_$$.md # Do NOT run: agkan task update <id> status done ``` **If only task management operations were performed** (comments, body updates, no commits), do NOT update the status to done. Leave the task as `in_progress`. **If implementation succeeded** (commits were made and pushed), update to done: ```bash agkan task update <id> status done ``` --- ## Important Notes - Branch creation: check out an existing branch if `.task.branch` is non-null; otherwise auto-generate a name and create the branch, then persist it via `agkan task update <id> --branch <name>` - Do not create a PR - The condition for moving a task to `done` (commit made, no critical error) is defined in full in Step 8 above — see that step for the exact rule; it is not repeated here - This skill is used after task selection (task selection is done with the `agkan-run-direct` skill)

# Agkan Subtask Direct > Use when a task has been selected and you need to implement it directly without PR/branch creation - handles in_progress update, implementation, and marking done. - Skill: `gendosu/agkan-subtask-direct` (Agent Skill) - Install (CLI): `npx skillmds@latest add gendosu/agkan-subtask-direct` - Raw SKILL.md: https://api.skillmd.com/api/skills/gendosu/agkan-subtask-direct/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: gendosu (https://skillmd.com/u/gendosu) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/gendosu/agkan-subtask-direct --- # agkan-subtask-direct ## Overview A workflow to directly implement a selected task without creating a branch or PR and mark it as complete. --- ## Workflow ### 0. Fetch Config ```bash CONFIG=$(agkan config get --json 2>/dev/null || echo '{}') REVIEW_MODEL=$(echo "$CONFIG" | jq -r '.config.models.review.model // "opus"') REVIEW_EFFORT=$(echo "$CONFIG" | jq -r '.config.models.review.effort // "high"') ``` ### 1. Update Task to In Progress ```bash agkan task update status in_progress ``` ### 2. Check for Existing Branch Read the branch from the task's first-class `branch` column: ```bash BRANCH=$(agkan task get --json | jq -r '.task.branch // empty') ``` **Case A — Branch is non-null:** Check out the existing branch: ```bash git fetch origin git checkout "$BRANCH" ``` All subsequent commits and pushes must target this branch. **Case B — Branch is null:** Generate a branch name from the task ID and title. Use the following naming convention: - If the task has a `bug` or `security` tag → prefix `fix/` - Otherwise → prefix `feat/` - Format: `/-` (e.g., `feat/42-add-login-page`) ```bash DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@') git fetch origin git checkout -b origin/$DEFAULT_BRANCH ``` Persist the generated branch name to the task: ```bash agkan task update --branch ``` ### 3. Implementation Implement according to the task requirements. Refer to /key-guidelines during implementation to maintain code quality. ### 4. Static Analysis / Lint Check (if applicable) If the project has a static analysis or lint tool configured, run it before committing: - TypeScript: `npx tsc --noEmit` - ESLint: `npx eslint .` - RuboCop: `bundle exec rubocop` - Ruff (Python): `ruff check .` - Other: run the appropriate tool for the project language Fix any errors before proceeding. ### 5. Commit > Committing and pushing the implementation is required and must not be skipped. > This step must complete before advancing to Steps 7 and 8. Do not skip the commit > for any reason, including approaching context limits or after running tests/lint. Stage files by specifying them explicitly. Do not use `git add -A` as it risks including unintended files such as `.env` or credentials. ```bash git add ... git commit -m "" # If a branch was checked out from the task's branch column, push to it; otherwise push to current branch git push -u origin ``` > **Note**: Do not use `git add -A` or `git add .`. Files containing `.env`, `credentials.*`, or secrets may be committed unintentionally. **After push, verify it succeeded before proceeding to Step 7:** ```bash git ls-remote --heads origin ``` If push failed (empty output or non-zero exit code), record the error in the task body and do NOT proceed to Step 7. Leave the task as `in_progress`. **Recovery: If interrupted during Steps 3–5** If an error, permission denial, or user interruption occurs during implementation (Step 3), lint check (Step 4), or commit/push (Step 5): 1. Do NOT update the task status to `done` 2. Record what happened in the task body 3. Leave the task as `in_progress` — complete the remaining steps before re-evaluating ### 6. Update Checkboxes If the task body contains `- [ ]` checklist items, update items completed during this implementation. 1. Retrieve the current body: ```bash TASK_JSON=$(agkan task get --json) CURRENT_BODY=$(echo "$TASK_JSON" | jq -r '.task.body // empty') ``` 2. Check whether the body contains unchecked items. If none found, **skip this step**: ```bash echo "$CURRENT_BODY" | grep -q -- '- \[ \]' || echo "No unchecked items — skipping" ``` 3. For each item completed in this implementation, replace its `- [ ]` with `- [x]`. Write the updated body to a temp file and apply: ```bash cat > /tmp/agkan_checkbox_$$.md << 'BODY' BODY agkan task update --file /tmp/agkan_checkbox_$$.md ``` > Only mark items that were actually completed in this session. Leave pending items as `- [ ]`. ### 7. Self-Review > **Model differences:** Opus 5 / Sonnet 5 = self-verification is the default behavior, so this > step can be skipped (explicit instructions invite over-verification). Fable 5 = run this step > using an independent-context verification subagent (more effective than self-critique). Before updating the task status, perform a self-review of the implementation using a general-purpose sub-agent. Substitute `` and `` with the values fetched in Step 0: ``` Agent( subagent_type="general-purpose", model="", description="Self-review task # implementation", prompt="""Review the implementation of the following task. Task #: Task body: <body> Review the git changes (run `git diff HEAD~1 HEAD` to see them) against the original plan and coding standards. Check for correctness, security issues, and code quality. Report all issues found, each annotated with a severity (critical/major/minor) and a confidence level. Do not filter by severity in this report — filtering, if needed, is the responsibility of the caller reading this review, not this step. ## Effort / Thoroughness Thoroughness/effort level: <REVIEW_EFFORT> - low: Quick pass. Focus on obvious correctness and security issues. - medium: Standard review. Check correctness, security, and code quality. - high: Deep review. Additionally examine edge cases, test coverage, and architectural fit. - xhigh: Recommended default for coding/agentic work; maximize correctness and edge-case coverage. - max: Reserve for the highest-stakes or most complex tasks. """ ) ``` If the code reviewer identifies critical issues, fix them and commit the fixes before proceeding. ### 8. Update task to done Only execute this step if implementation succeeded — specifically, if ALL of the following conditions are met: > **Scope note**: The interruption guard below applies **only to this status > transition decision** — not to Steps 3–6. If a confirmation or interruption > occurred during implementation and has since been resolved, complete Steps 3–6 > before evaluating the guard below. **Implementation succeeded** means ALL of the following: - At least one `git commit` was executed in this session (verify with `git log --oneline -1`) - Actual code/file changes were committed (not just task management operations) - `git push` completed without errors **The following do NOT count as implementation:** - `agkan task comment add` (comment additions only) - `agkan task update --body` / `--file` (body/metadata updates only) - Discussion or planning without code changes **Before updating to done, verify a commit was made:** ```bash git log --oneline -1 ``` If no commits were made in this session (output is empty or only shows pre-existing commits), do NOT update the status to done. **Surface the failure** by appending an error line to the task body, then leave the task as `in_progress`: ```bash # Surface silent failure: no commit was made agkan task get <id> --json # Write body to tmp file and update using --file to preserve newlines cat > /tmp/agkan_body_$$.md << 'BODY' <existing body> Error: Skill reached end without a commit. Implementation was not completed — files may remain uncommitted in the working tree. Manual intervention required. BODY agkan task update <id> --file /tmp/agkan_body_$$.md # Do NOT run: agkan task update <id> status done ``` **If a critical error occurred** (e.g., git push failed, permission denied, commit failed), do NOT update the status to done. Leave the task as `in_progress` and record the error details in the task body: ```bash # On error: record what went wrong in the task body (optional but recommended) agkan task get <id> --json # Write body to tmp file and update using --file to preserve newlines cat > /tmp/agkan_body_$$.md << 'BODY' <existing body> Error: <error description> BODY agkan task update <id> --file /tmp/agkan_body_$$.md # Do NOT run: agkan task update <id> status done ``` **If only task management operations were performed** (comments, body updates, no commits), do NOT update the status to done. Leave the task as `in_progress`. **If implementation succeeded** (commits were made and pushed), update to done: ```bash agkan task update <id> status done ``` --- ## Important Notes - Branch creation: check out an existing branch if `.task.branch` is non-null; otherwise auto-generate a name and create the branch, then persist it via `agkan task update <id> --branch <name>` - Do not create a PR - The condition for moving a task to `done` (commit made, no critical error) is defined in full in Step 8 above — see that step for the exact rule; it is not repeated here - This skill is used after task selection (task selection is done with the `agkan-run-direct` skill)