Claude Skills by patforna

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

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.

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.

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.

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

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

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.

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.

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

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.

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

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

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.