New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Trade Off

by ReviewStage in ReviewStage/stage-cli

Use at any stage — planning, before implementing, or reviewing code that's already written — to surface high-level trade-offs that could significantly simplify the work.

MITAuto-check passedBackend & APIs

Install Trade Off

skills CLI
$ npx skills add ReviewStage/stage-cli --skill trade-off -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install ReviewStage/stage-cli trade-off --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/ReviewStage/stage-cli.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/trade-off .claude/skills/trade-off && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
trade-off
GitHub stars
274
Token cost
~3k tokens
SKILL.md length
1,670 words
Files
1
Skills in repo
10
Repo updated
First seen
Licence
MIT

At a glance

Use at any stage — planning, before implementing, or reviewing code that's already written — to surface high-level trade-offs that could significantly simplify the work.

  • Works in 3 steps: Planning — sketching what the feature… → Before implementing — a plan exists,… → After implementing — reviewing a diff…
  • Tasks that involve Background jobs
  • SKILL.md covers When to use, Two layers: behavior first,…, What a trade-off looks like and How to surface them, plus 2 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Trade Off is an agent skill from ReviewStage/stage-cli. Use at any stage — planning, before implementing, or reviewing code that's already written — to surface high-level trade-offs that could significantly simplify the work. Scans two layers in strict priority order. First, user-facing behavior (features, flows, states, settings, notifications, undo, real-time, bulk ops) — cutting a behavior removes the architecture and code behind it. Second, architectural design (queues, caches, background jobs, new packages, new tables, new services, streaming, real-time infra) —…

Its SKILL.md is about 3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Backend & APIs, covering Background jobs. The repository describes itself as: A viewer for reviewing local code changes in small individual chapters. Works with any AI agent. The licence is MIT.

When your agent uses it

  • Tasks that involve Background jobs

Example prompts

  • “/trade-off”

Workflow steps

3 steps, taken from the first numbered list in SKILL.md.

  1. Planning — sketching what the feature should do. Trade-offs are cheapest here because nothing is built yet; the cut is just "don't design…
  2. Before implementing — a plan exists, you're about to write code. Last chance to cut before the work starts.
  3. After implementing — reviewing a diff you or another agent just produced. The cut now means deleting code, which is more expensive than…

What it can do on your machine

Read from SKILL.md and the folder at commit 59b977b. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Trade Off loads about 3k tokens when it runs. Until then it costs about 239 tokens; SKILL.md has 1,670 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~239
When it runs · the whole SKILL.md, loaded when a task matches
~3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from ReviewStage/stage-cli at commit 59b977b, republished under its MIT licence (© ReviewStage). 1,670 words, ~3,004 tokens.

Download SKILL.mdSave it as .claude/skills/trade-off/SKILL.md (or your agent's skills folder).
name
trade-off
description
Use at any stage — planning, before implementing, or reviewing code that's already written — to surface high-level trade-offs that could significantly simplify the work. Scans two layers in strict priority order. First, user-facing behavior (features, flows, states, settings, notifications, undo, real-time, bulk ops) — cutting a behavior removes the architecture and code behind it. Second, architectural design (queues, caches, background jobs, new packages, new tables, new services, streaming, real-time infra) — cutting an architectural piece removes whole categories of implementation. Stops there; code-level simplification is outside scope. Proactively invoke whenever the scope of a task looks like it could grow, whenever you catch yourself about to add a queue, cache, new package, new table, new service, or behavior that wasn't explicitly requested, or when looking back at a recent diff that feels larger than the task warranted.
metadata.internal
true

Trade-off

Agents over-build by default. They add product behaviors, flows, and UI states that weren't asked for, and they reach for queues, caches, new packages, new tables, and real-time infra when nothing in the task demanded them. The cost is paid forever: more surface area for users to get confused by, more infra to operate, and more code to read, maintain, and change later.

This skill is a forcing function. At any point in the lifecycle of a task — planning, before implementation, or looking back at a diff — identify what could be cut by accepting a reasonable trade-off, and surface those cuts to the user as explicit decisions.

When to use

Invoke this any time complexity is visible. There are three natural moments:

  1. Planning — sketching what the feature should do. Trade-offs are cheapest here because nothing is built yet; the cut is just "don't design it in."
  2. Before implementing — a plan exists, you're about to write code. Last chance to cut before the work starts.
  3. After implementing — reviewing a diff you or another agent just produced. The cut now means deleting code, which is more expensive than not writing it, but still usually worth it.

Signals any of the three applies:

  • The task spans multiple UI states, screens, or flows
  • There's notification, history, undo, real-time, or bulk behavior on the surface area
  • A new behavior is being added that isn't the core ask but felt "natural to include"
  • The plan introduces a queue, worker, cache layer, or background job
  • The plan adds a new package in the monorepo, a new database table, or a new external service
  • The plan uses streaming, websockets, SSE, or other real-time infra
  • A migration or backfill is being designed
  • A new admin surface or auth surface is being added
  • The user's request is short but the scope feels long
  • The diff touches multiple files across packages when the ask named one

If the task is genuinely small and concrete and the plan/diff reflects that, skip this skill.

Two layers: behavior first, then architecture

Simplification happens at two levels, and the order matters: always scan user-facing behavior first, then architecture. A behavior-level cut deletes the feature and the architecture and the code behind it. An architecture-level cut removes whole categories of implementation without touching what the user sees. If you jump past either and go straight to code, you silently lock in scope and infra decisions the user never got to make.

Code-level simplification (validation, retries, abstractions, loop shapes) is out of scope for this skill — those cuts are narrow and land through normal code review. This skill is for the decisions above that.

Layer 1: User-facing behavior (scan first)

What the user sees and can do. These are the biggest wins. Ask: does this behavior need to exist at all, or in this shape?

  • A whole feature, page, or flow that isn't load-bearing for the core job
  • A step in a wizard or form that could be merged into another or removed
  • A setting or preference the user rarely changes (hardcode the sensible default)
  • A permission tier, role, or visibility level that duplicates another with minor variation
  • Undo / redo (accept the action is permanent, or reversed manually)
  • Real-time updates (require a refresh)
  • Notifications, emails, or alerts (the user sees it next time they visit)
  • Bulk operations (one-at-a-time is tedious but shippable)
  • Mobile support (desktop-only until demand is proven)
  • A bespoke empty state with illustration and copy (show the same UI with zero items + one button)
  • Multi-language / localization
  • Keyboard shortcuts, drag-and-drop, animation polish, and similar affordances on top of the baseline interaction
  • Admin UIs for things that can be set via a script or the database for now
  • Progress indicators, history/audit logs, activity feeds on actions the user already knows they did
  • Confirmation modals on reversible actions
Layer 2: Architectural design (scan second, only after behavior)

The shape of the system around the remaining behavior. Ask: does this piece of infra or structure need to exist, or can the behavior be served by something already in place?

  • A background job / queue / worker (run it inline on the request if it's fast enough)
  • A cache layer (skip it if the underlying query is fast and traffic is low)
  • A new package in the monorepo (fold it into an existing one; extract later if it earns its own boundary)
  • A new database table (add columns to an existing one, or use a JSON column, if the shape is simple)
  • A new external service or integration (use one you already have, or do without)
  • Real-time infra — websockets, SSE (poll on an interval, or require a refresh)
  • A streaming response (return the final payload once if latency is acceptable)
  • A separate admin app or surface (add a gated route to the existing app)
  • An event bus / pub-sub (call the downstream functions directly when there are only one or two)
  • A cron / scheduled job (trigger on the next relevant user action)
  • A migration or backfill (change the code and let new data use the new shape; leave old data as-is)
  • A new auth surface (reuse the existing session / token setup)

Most tasks have 1–3 real opportunities, usually weighted toward Layer 1. List only those — don't pad.

Show full SKILL.md (802 more words)Show less

What a trade-off looks like

A trade-off is a specific thing to cut paired with what the user accepts in exchange. Vague ("keep it simple") doesn't count. The format is:

Cut X. In exchange, Y. This is fine because Z.

Behavior-layer examples (the highest-leverage kind — scan these first):

  • Cut the "draft" state for reviews. Users either publish immediately or abandon. Fine because every user interview skips the draft step, and drafts add a state machine, a separate list view, and cleanup logic.
  • Cut the email notification on review completion. The user sees it next time they open the app. Fine because we don't have email infra wired up and the in-app indicator already exists.
  • Cut the bespoke empty state for "no chapters yet". Show the same list UI with zero rows plus a single "Generate your first chapter" button. Fine because this state is brief (first-run only) and custom illustration work isn't where the value is.
  • Cut the admin UI for toggling org features. Flip flags via a DB query or a small script for now. Fine because there are 3 orgs and none of them self-serve this.
  • Cut bulk delete. Users delete one at a time. Fine because deletion is rare and selection UI + batched mutation + partial-failure handling is a chunk of work for something that may never get used.
  • Cut the confirmation modal on archive. Archived items are restorable from the archive tab. Fine because the action is already reversible and modals interrupt flow.

Architecture-layer examples (scan after behavior has been settled):

  • Cut the background job for chapter generation. Run it inline on the request. Fine because generation is <30s and we're well under Vercel Function's 300s timeout; revisit when we hit real scale.
  • Cut the Redis cache on the repo list endpoint. Hit Postgres directly on every request. Fine because the query is <50ms and we're at hundreds of requests/day; a cache here is speculative infra.
  • Cut the new @stage/notifications package. Put the one function in @stage/api for now. Fine because there's one caller and extracting a package before there's a second caller is premature.
  • Cut the new review_drafts table. Store the two fields as a JSON column on the existing reviews row. Fine because we never query into them, and a full table brings migrations, joins, and a schema boundary for no payoff.
  • Cut websockets for live review status. Poll every 10s from the client. Fine because status changes are user-triggered and infrequent; websockets add connection management and infra we don't need yet.
  • Cut the separate admin app. Add a /admin route to the existing web app gated by role. Fine because there are 3 admins and building a parallel auth surface is premature.
  • Cut the event bus. Call the two downstream functions directly. Fine because there are only two and a bus before the third caller exists is speculative indirection.

Each names a concrete thing being removed, what the user experiences instead, and why that's acceptable in this specific context. "Fine because" is the load-bearing part — it's what lets the user judge whether you're right.

How to surface them

Stop and ask before acting. Don't bundle trade-offs into a plan and barrel ahead, and don't silently leave them out after reviewing code. The user's judgment is the whole point — you want them to push back on cuts that matter and confirm ones that don't.

Adapt the framing to the stage:

Planning or pre-implementation:

Before I start, here are trade-offs I'd propose to keep this small:

1. Cut [specific thing]. In exchange, [what user accepts]. Fine because [reason].
2. Cut [specific thing]. In exchange, [what user accepts]. Fine because [reason].

Tell me which to drop from the cut list and I'll build those in.

Post-implementation review:

Looking at what's here, a few things I'd propose cutting to simplify:

1. Cut [specific thing, with file reference if applicable]. In exchange, [what user
   accepts]. Fine because [reason].
2. …

Want me to remove any of these?

Three rules for the surfacing:

  1. Be specific. Not "I'll keep it minimal" — name the behavior, state, feature, or code path being removed. If post-implementation, cite the file.
  2. Lead with the cut, not the preservation. The default is to build (or keep) everything; the news is what's not there.
  3. Don't editorialize. No "I recommend..." — let the trade-offs stand on their merits. The user knows their product.

What not to cut

Some things aren't trade-offs, they're correctness. Don't propose cutting:

  • Security boundaries (auth checks, authorization, injection safety)
  • Data integrity (transactions where needed, unique constraints, referential integrity)
  • Loud failure at system boundaries (error messages users see, logs for ops)
  • Things the user explicitly asked for in the original request

If you catch yourself proposing to cut one of these, reframe: it's not a trade-off, it's a bug.

Why this works

The goal isn't minimalism as an aesthetic. It's preserving the user's decision-making authority over complexity. Silent over-implementation denies them that authority — they can't push back on behavior or code they never saw being considered. Making trade-offs visible turns "complexity creep" from a drift into a deliberate choice, either way.

It also front-loads disagreement. Better to hear "no, we actually do need offline support" at minute zero than after the simpler version ships, or to hear "yeah, rip that out" at review time than after the code has accreted dependencies for a month.

© ReviewStage, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/trade-off of ReviewStage/stage-cli.

Open the folder on GitHubat commit 59b977b

Compare with similar skills

Trade Off next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Trade Off compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Trade Off this skillReviewStage/stage-cli274—~3kAutomated safety check: PassMIT
Trigger.dev Configurationpapermark/papermark9.2k—~1.2kAutomated safety check: PassCustom licence
FoundatioFoundatioFx/Foundatio2.1k—~3.9kAutomated safety check: PassApache-2.0
Laravel SpecialistJeffallan/claude-skills12k1 repos~2.1kAutomated safety check: PassMIT
Trigger.dev Realtimepapermark/papermark9.2k—~1.7kAutomated safety check: PassCustom licence
NubaseOtterMind/Nubase622—~2.2kAutomated safety check: NotesApache-2.0

Similar skills

  • Trigger.dev Configuration

    papermark/papermark

    Configures Trigger.dev projects through trigger.config.ts, with build extensions for Prisma, Playwright, Puppeteer, FFmpeg, Python and system packages.

    9.2k GitHub stars~1.2k tokensUpdated 1 mo ago
    Backend & APIsAuto-check passed

  • Foundatio

    FoundatioFx/Foundatio

    A skill your agent uses when working with Foundatio infrastructure abstractions for .NET -- caching, queuing, messaging, file storage, distributed locking, or background jobs.

    2.1k GitHub stars~3.9k tokensUpdated 2 days ago
    Backend & APIsAuto-check passed

  • Laravel Specialist

    Jeffallan/claude-skills

    Builds Laravel 10+ applications with Eloquent models, Sanctum authentication, Horizon queues, API resources and Livewire components, tested with Pest or PHPUnit.

    12k GitHub starsUsed in 1 repo~2.1k tokens
    Backend & APIsAuto-check passed

  • Trigger.dev Realtime

    papermark/papermark

    Shows how to subscribe to Trigger.dev task runs from the backend and from React for progress indicators, live dashboards, AI response streams and approval waits.

    9.2k GitHub stars~1.7k tokensUpdated 1 mo ago
    Backend & APIsAuto-check passed

  • Nubase

    OtterMind/Nubase

    A skill your agent uses when the user mentions Nubase broadly, wants a backend for an AI-generated app, or needs to deploy/publish generated code online — across Database, Auth, Storage, Assets…

    622 GitHub stars~2.2k tokensUpdated 13 days ago
    Backend & APIsAuto-check: notes

  • Trigger.dev Background Tasks

    papermark/papermark

    Guides building durable background tasks, scheduled jobs and queues with Trigger.dev, including retries, waits, idempotency and concurrency limits.

    9.2k GitHub stars~2.1k tokensUpdated 1 mo ago
    Backend & APIsAuto-check passed

More from ReviewStage/stage-cli

All 10 skills in this repo

  • Fixing CI

    ReviewStage/stage-cli

    A skill your agent uses when CI is failing on a branch and you need to diagnose failures from GitHub, fix them locally with iterative verification, and re-push clean commits.

    274 GitHub stars~977 tokensUpdated 1 mo ago
    Auto-check passed

  • Fixing PR Comments

    ReviewStage/stage-cli

    A skill your agent uses when a pull request has unresolved review comments that need to be addressed, or when asked to fix PR feedback

    274 GitHub stars~953 tokensUpdated 1 mo ago
    Auto-check passed

  • Iterate PR

    ReviewStage/stage-cli

    A skill your agent uses when a PR is open and the user wants to autonomously monitor and fix PR review comments, CI failures, and rebase conflicts on a recurring loop, or when asked to…

    274 GitHub stars~1.1k tokensUpdated 1 mo ago
    Auto-check passed

  • Linear Issue

    ReviewStage/stage-cli

    A skill your agent uses when creating a Linear issue from the current coding context, or when the user invokes /linear-issue.

    274 GitHub stars~2k tokensUpdated 1 mo ago
    Auto-check passed

  • Quality Review

    ReviewStage/stage-cli

    A skill your agent uses when reviewing code changes against AGENTS.md implementation quality standards, or when asked to do an implementation quality review

    274 GitHub stars~1.3k tokensUpdated 1 mo ago
    Auto-check passed

  • Rebase Origin Main

    ReviewStage/stage-cli

    A skill your agent uses when rebasing the current branch onto origin/main, including resolving merge conflicts along the way

    274 GitHub stars~927 tokensUpdated 1 mo ago
    Auto-check passed

Categories

Questions about Trade Off

What does Trade Off do?

Use at any stage — planning, before implementing, or reviewing code that's already written — to surface high-level trade-offs that could significantly simplify the work. Trade Off is an agent skill from ReviewStage/stage-cli. Use at any stage — planning, before implementing, or reviewing code that's already written — to surface high-level trade-offs that could significantly simplify the work.

When should I use Trade Off?

Trade Off fits situations like: tasks that involve Background jobs.

How do I install Trade Off in Claude Code?

Run `npx skills add ReviewStage/stage-cli --skill trade-off -a claude-code`. Or copy the skill folder (.agents/skills/trade-off in ReviewStage/stage-cli) into .claude/skills/trade-off in your project. Claude Code loads it when a task matches its description.

How do I install Trade Off in Codex?

Run `npx skills add ReviewStage/stage-cli --skill trade-off -a codex`. Or copy the skill folder (.agents/skills/trade-off in ReviewStage/stage-cli) into .agents/skills/trade-off in your project. Codex loads it when a task matches its description.

Can I use Trade Off in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ReviewStage/stage-cli --skill trade-off -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/trade-off, .gemini/skills/trade-off, .github/skills/trade-off and .opencode/skills/trade-off in your project.

What does Trade Off need to run?

SKILL.md names no scripts, command-line tools or credentials: Trade Off is instructions for the agent only.

Does Trade Off access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Trade Off safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Trade Off use?

Trade Off is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Trade Off use?

About 3k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Trade Off?

Skills that share tags, products or a category with Trade Off: Trigger.dev Configuration (papermark/papermark, 9.2k stars), Foundatio (FoundatioFx/Foundatio, 2.1k stars), Laravel Specialist (Jeffallan/claude-skills, 12k stars) and Trigger.dev Realtime (papermark/papermark, 9.2k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Trade Off?

ReviewStage (a GitHub organization) maintains it in ReviewStage/stage-cli, which has 274 GitHub stars. The repository holds 10 skills in this directory. The repository was last updated on September 7, 2026.

Source: ReviewStage/stage-cli on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.