at

Plugin at from marketplace auto-task in patforna/auto-task. Commands read from the repo's manifest — 1 month ago.

Skills (13)

• auto-task

  Use to drive a well-defined task end-to-end with minimal human input: plan, implement, review, ship.

• clarify-task

  Use this skill to resolve ambiguities, clarify vague criteria and make implicit assumptions explicit. Invoked at the end of /at:create-task and the start of /at:plan-task. Typical workflow: create-task → clarify-task → plan-task → impl-task → review-code → review-task → ship-task.

• config

  Use this skill to resolve auto-task settings. It owns the procedure that merges the shipped defaults file with project and local config, per-leaf, plus the resolved-block contract consumers read. Run it standalone to inspect the resolved settings and where each value came from.

• create-task

  Use this skill to crystallise and scope an ongoing conversation into a well-defined task, capturing user intent at a high level. Typical workflow: create-task → clarify-task → plan-task → impl-task → review-code → review-task → ship-task.

• impl-task

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

• panel

  Use to get independent perspectives on a topic from multiple models (a strong Claude model + Codex by default). Use with /at:synthesize to merge.

• plan-task

  Use to write an implementation plan for a well-defined task. Typical workflow: create-task → clarify-task → plan-task → impl-task → review-code → review-task → ship-task.

• review-code

  Use to review a diff for correctness, design, security, and convention conformance. High-signal, read-only, severity-gated, with an autofix lane for mechanically-certain trivia. Default review step in /at:auto-task.

• review-design

  Use to review a design / UI change against its specification. Read-only; produces findings, applies no fixes.

• review-task

  Use to verify that a task has been completed according to its intent and criteria. Typical workflow: create-task → clarify-task → plan-task → impl-task → review-code → review-task → ship-task.

• ship-task

  Use to wrap up a finished task - set status to done, merge, clean up.

• synthesize

  use to combine N independent perspectives on a prompt into a single synthesis without forcing consensus.

• tdd

  Strict test-driven development (Beck-style). Use when writing new code, adding features, or fixing bugs with TDD discipline. TRIGGER when: user asks to use TDD, write tests first, or red/green/refactor. DO NOT TRIGGER when: writing tests after the fact, or user explicitly opts out of TDD.