idle-skills

Work out the technical shape of an agreed plan — contracts, types, schemas, dependency order — and propose it as tasks and decisions. Use only where scope and complexity make those definitions necessary. Never decides how the program works; that is the plan's job.

Read-only critique of a proposed technical breakdown against the plan, before it is accepted. Checks alignment, necessary contracts, feasibility, simplicity and readability. Requested when worth challenging, never scheduled; reports blockers without scoring or rewriting.

Review accumulated retros, identify recurring evidence-backed process patterns, and propose surgical skill or workflow changes for human approval. Never applies changes automatically.

Decide consequential UX/UI behavior for an agreed task. Use when a changed user-facing surface is not already determined by an existing approved pattern and a design system is configured. Skip backend/infra and trivial pattern-following changes.

Capture, scan, or index terse, currently actionable tribal knowledge about non-obvious cross-cutting constraints, workarounds, and gotchas. Use when missing context would cause a future mistake; never use lore as history, a changelog, or a second requirements system.

Drive one or more tasks to a CI-green PR, through whatever shape each one actually needs. Runs the interviews itself, breaks the work into goals with the maintainer, and dispatches the rest. Never creates scope.

Interview the maintainer about how the program should work, and write it into the plan in plain words. Use when the approach is not obvious. Produces the how-it-works half of the plan — no contracts, types, or schemas.

Interview the maintainer about what they need from a task, and write it into the task in their words. Use when a dropped task's value, boundary, or a load-bearing noun is not already settled. Skip when it is already clear enough to build from.

Record concrete successes and friction after a task, session, or pipeline run. Observe from artifacts and trajectories without fixing, assigning work, or changing process.

Read-only review of implemented work against its task's goal or an explicit changed-file scope. Judges whether the goal is reached, applicable constraints/rules, regressions, and plausible changed risks. Produces operational findings and a verdict; never edits code.

Configure evidence-backed, maintainer-approved pipeline rule slots and design-system paths for this repository. Use during installation or when repository conventions change; do not promote generic best practices into binding policy automatically.

Turn completed work into a clean CI-green merge-ready PR. Verifies, commits, updates the PR, and waits for CI; does not merge. Review belongs to the pipeline skill.

Implement a claimed task with the smallest clear solution that reaches its goal. Use after the plan is agreed and the task is yours.

Write or review user-facing documentation when it is an explicit deliverable or when an implementation makes authoritative documentation false. Preserve project voice and factual accuracy; use reading-funnel craft proportionately to page type.

Create proportionate failing evidence for a task's goal before implementation when behavior is regressible and an automated test is appropriate. Use in the build phase; do not let tests create requirements.