agentsclimarketplace

Impl task

Skill patforna/auto-task/skills/impl-task

An opinionated agentic workflow to turn well-defined units of work into shippable code with minimal human input.

Install
npx -y skills add patforna/auto-task --skill impl-task

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Implement a task by executing its implementation plan. Typical workflow: create-task → clarify-task → plan-task → impl-task → review-code → review-task → ship-task.

SKILL.md

4.5 KB, as published. Nobody here has run it

Implement Task

Usage

/at:impl-task <task-path> [further user instructions]

Goal

Implement a task by executing its implementation plan.

Context

This skill is typically run as part of a larger workflow:

create-task → clarify-task → plan-task → impl-task → review-code → review-task → ship-task

As steps (e.g. clarify, plan, impl, review) typically run in new sessions, it's imperative that the task file plus repo state carry everything the next agent needs.

Task files live in the project's task store — tasks/ in the repo by default. Project config can override this and other defaults: read .claude/auto-task.config.md (project, committed) and .claude/auto-task.config.local.md (personal overrides — win on conflict) if they exist. See /at:create-task § Task Store and Project Config.

Guidance (DO NOT IGNORE!)

<!-- Curate as we go along. -->

These rules govern how to execute the implementation. Internalise and follow them throughout.

  • Commit early and often.
  • Stage files explicitly by path (git add <paths>), never -A/. — it guards against sweeping in unrelated changes (e.g. from parallel sessions sharing a checkout).
  • Run the project's formatter over your changes before the final verification run — formatting must never surface as a verification failure or a mop-up commit.
  • Follow the repo's existing commit conventions. Append the task-link suffix to subjects (default (task/NNN); config can change or drop it) so commits trace back to the task.
  • Look for and internalise existing style, patterns, conventions. Don't deviate unless the plan explicitly asks for it.
  • Maintain the testing pyramid. Test at the lowest possible level. Few, mostly happy-path tests at the top of the pyramid (e2e, component).
  • Do not use I/O, randomness, or real date/time in unit tests.
  • Take small steps when uncertain, surprised, or in unfamiliar territory; bigger steps when confident. An unexpected red means shift down to smaller steps. An unexpected green means review your test with fresh eyes — there are probably gaps.

Step 1: Task Readiness

If the task does not contain an Implementation plan section (usually set by /at:plan-task), stop, flag it to the user and ask how to proceed.

Otherwise, set the task status to in-dev — by default, edit the frontmatter status: field and commit with a (task/NNN) subject suffix; if the project config defines a task-status command, use that instead.

Step 2: Build Context

Read the task and the code the implementation plan will touch. If in doubt, err on the side of reading too much. Ensure you fully understand the task, implementation plan and current state of the codebase before proceeding.

Step 3: Implement

Work through the implementation plan step by step. Re-read the implementation plan so it's fresh in your context before proceeding to the next step.

Fully read, internalise and use /at:tdd to drive implementation. Do not write or modify production code without a failing test.

When Things Go Wrong

  • If an implementation plan step seems wrong or missing, try to resolve the issue and note it down in Implementation Notes (see below).
  • If tests keep failing after 3 implementation attempts, revert to the last green state and take a smaller step.
  • If the build fails on unrelated changes, flag it to the user. Don't fix silently — it may be someone else's work in progress.

Step 4: Self-Review

After completing all planned steps, review git diff from your first commit to HEAD:

  • Does the diff touch only what the plan requires? If not, resolve.
  • Verify that each AC is demonstrably met. If not, resolve.
  • Ensure there are no unwanted leftovers that you introduced (e.g. debug prints, TODO comments, commented-out or obsolete code, etc.).

Step 5: Wrap Up

Add an ## Implementation Notes section to the end of the task file, noting anything worth flagging or preserving — in plain English. For example:

  • Any deviations from the plan.
  • Any surprises encountered during implementation.
  • Any learnings worth codifying (incl. how).
  • Any non-obvious assumptions that were made implicitly.
  • Any non-obvious follow-up work not yet captured.
  • etc.

Commit the task update.

Step 6: Integrate Feedback

Wait for the user to provide feedback. Once provided, address it, commit, respond.

Gives 0 of the 12 instructions most code review skills give

Counted across 610 of the 674 authors here whose files we hold, read 2026-08-06

  • push back with technical reasoning if wrongin 60 of 610, across 24 files
  • ask for clarification on unclear itemsin 51 of 610, across 16 files
  • fix critical issues immediatelyin 45 of 610, across 29 files
  • implement one item at a timein 45 of 610, across 11 files
  • group findings by severityin 44 of 610, across 43 files
  • verify feedback against the codebasein 42 of 610, across 8 files
  • dispatch a code reviewer subagentin 39 of 610, across 23 files
  • fix important issues before proceedingin 37 of 610, across 22 files
  • test each fix individuallyin 35 of 610, across 7 files
  • reply in github comment threadsin 33 of 610, across 5 files
  • check for security vulnerabilitiesin 31 of 610, across 27 files
  • factualize corrections without over-explainingin 30 of 610, across 2 files

Said here and by no other author read

  • commit early and often
  • stage files explicitly by path
  • run the formatter before verifying changes
  • follow existing repository commit conventions
  • use test-driven development for implementation
  • test at the lowest possible level

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.