Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

yagni-review

Estrelas2

Forks0

Atualizado23 de junho de 2026 às 12:29

Review diffs for over-engineering only. Finds what to delete: reinvented standard library, unneeded dependencies, speculative abstractions, dead flexibility. One line per finding with tag and replacement. Use when the user says "review for over-engineering", "what can we delete", "is this over-engineered", "simplify review", "yagni review", or invokes /yagni-review. Complements correctness-focused /review — this one only hunts complexity.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

FranciscoJRSantos

FranciscoJRSantos/personal-agents

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·SOC 15-1253

SKILL.md

readonly

name

yagni-review

description

YAGNI Review

Review the current branch's diff against main for unnecessary complexity. One line per finding: location, what to cut, what replaces it. The diff's best outcome is getting shorter.

Scope

Over-engineering and complexity only. Correctness bugs, security holes, and performance are explicitly out of scope — route them to /review.

Step 1: Get the Diff

git diff main...HEAD

If main doesn't exist locally, try origin/main, then master.

Step 2: Classify Findings

For each finding, assign one tag:

Tag	What to cut	Replacement
`delete:`	Dead code, unused flexibility, speculative feature	Nothing — remove it
`stdlib:`	Hand-rolled thing the standard library ships	Name the function/class
`native:`	Dependency or code doing what the platform already does	Name the native feature
`yagni:`	Abstraction with one implementation, config nobody sets, layer with one caller	Inline until a second use exists
`shrink:`	Same logic, fewer lines	Show the shorter form

Step 3: Format Output

One line per finding:

L<line>: <tag> <what>. <replacement>.

For multi-file diffs: <file>:L<line>: <tag> <what>. <replacement>.

Examples

L12-38: stdlib: 27-line email validator class. "@" check + confirmation email, 1 line.
L4: native: moment.js imported for one format call. Intl.DateTimeFormat, 0 deps.
repo.py:L88: yagni: AbstractRepository with one implementation. Inline it.
L52-71: delete: retry wrapper around an idempotent local call. Nothing replaces it.
L30-44: shrink: manual loop builds dict. dict(zip(keys, values)), 1 line.

Step 4: Score

End with the only metric that matters:

net: -<N> lines possible.

If there is nothing to cut, say Lean already. Ship. and stop.

Boundaries

Scope: over-engineering and complexity only.
Correctness bugs, security holes, performance are out of scope — route to /review.
A single smoke test or assert-based self-check is the minimum, not bloat — never flag it.
Does not apply the fixes, only lists them.

Optional: Persist Findings

If the user wants to track deferred findings, mark them with deferred: comments in the code (format: # deferred: <ceiling>, <upgrade path>). Then run /debt-ledger to harvest them into a ledger.

Mais deste repositório

mesmo repositório

debt-ledger

FranciscoJRSantos/personal-agents

Harvest every `deferred:` comment in the codebase into a debt ledger, so deliberate shortcuts and deferrals get tracked instead of rotting into "later means never". Use when the user says "debt ledger", "/debt-ledger", "what did we defer", "list the shortcuts", "ponytail ledger", or "what did we mark to do later". One-shot report, changes nothing.

2026-06-232

implement

FranciscoJRSantos/personal-agents

Vertical-slice implementation with TDD inside each slice. Reads the plan and kanban-board artifacts to determine which slice to implement. Each slice crosses all layers (data → pure → edge → UI → integration) and follows Red-Green-Refactor. Clear context between slices. Use this skill whenever the user says "implement", "start coding", "proceed with implementation", "/implement", or wants to begin implementation after a plan exists. Entry point: /implement

2026-06-232

grill-me

FranciscoJRSantos/personal-agents

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Produces a decision log artifact consumable by /plan. Invoke with "/grill-me [topic]".

2026-06-072

plan

FranciscoJRSantos/personal-agents

Fetches a Jira ticket, detects its type, and generates a type-aware implementation plan with Kanban/DAG vertical slices. Presents the plan for approval before writing it back to Jira as a comment. Produces both a plan artifact and a kanban-board artifact. Use this skill whenever the user invokes /plan PROJ-123 or asks to generate an implementation plan for a Jira ticket. Entry point: /plan PROJ-123

2026-06-072

ship

FranciscoJRSantos/personal-agents

Run the full verification suite (lint, type check, tests), gate on the review artifact, commit, push, and create a merge request. Use this skill whenever the user says "ship it", "commit and push", "create MR", "open a merge request", "push my branch", or wants to finalize and submit their work.

2026-06-072

learn

FranciscoJRSantos/personal-agents

Codify a correction or convention from the current session into AGENTS.md (global) or .agents/conventions.md (project-specific) in "Always/Never [action] BECAUSE [reason]" format. Use this skill whenever the user says "remember this", "add a rule", "don't do that again", "learn this", "/learn", or wants to capture a lesson from the session before the conversation ends. Entry point: /learn [optional rule text]

2026-05-232

name

yagni-review

description

YAGNI Review

Review the current branch's diff against main for unnecessary complexity. One line per finding: location, what to cut, what replaces it. The diff's best outcome is getting shorter.

Scope

Over-engineering and complexity only. Correctness bugs, security holes, and performance are explicitly out of scope — route them to /review.

Step 1: Get the Diff

git diff main...HEAD

If main doesn't exist locally, try origin/main, then master.

Step 2: Classify Findings

For each finding, assign one tag:

Tag	What to cut	Replacement
`delete:`	Dead code, unused flexibility, speculative feature	Nothing — remove it
`stdlib:`	Hand-rolled thing the standard library ships	Name the function/class
`native:`	Dependency or code doing what the platform already does	Name the native feature
`yagni:`	Abstraction with one implementation, config nobody sets, layer with one caller	Inline until a second use exists
`shrink:`	Same logic, fewer lines	Show the shorter form

Step 3: Format Output

One line per finding:

L<line>: <tag> <what>. <replacement>.

For multi-file diffs: <file>:L<line>: <tag> <what>. <replacement>.

Examples

L12-38: stdlib: 27-line email validator class. "@" check + confirmation email, 1 line.
L4: native: moment.js imported for one format call. Intl.DateTimeFormat, 0 deps.
repo.py:L88: yagni: AbstractRepository with one implementation. Inline it.
L52-71: delete: retry wrapper around an idempotent local call. Nothing replaces it.
L30-44: shrink: manual loop builds dict. dict(zip(keys, values)), 1 line.

Step 4: Score

End with the only metric that matters:

net: -<N> lines possible.

If there is nothing to cut, say Lean already. Ship. and stop.

Boundaries

Scope: over-engineering and complexity only.
Correctness bugs, security holes, performance are out of scope — route to /review.
A single smoke test or assert-based self-check is the minimum, not bloat — never flag it.
Does not apply the fixes, only lists them.

Optional: Persist Findings

If the user wants to track deferred findings, mark them with deferred: comments in the code (format: # deferred: <ceiling>, <upgrade path>). Then run /debt-ledger to harvest them into a ledger.