/options

← Back to index

Summary

Stuck between approaches? Get 2–4 genuinely different paths with honest pros/cons and a firm recommendation — grounded in your actual project, not generic assumptions.

When to use

Use /options when you have a decision to make and want the trade-offs laid out before committing. The skill reads relevant project files so the pros/cons reflect your actual stack, not a textbook answer.

Trigger phrases (from SKILL.md):

Not a research workflow. The skill reads project files and reasons from them; it does not run a multi-step investigation or save output files.

Invocation

State the decision directly as the argument:

/options [decision or concern]

Or just raise the decision in natural language — the skill picks it up from the recent conversation if no argument is given. For decisions that concern the current project, make sure you're in the project directory so the skill can read the relevant files.

Example 1 — Security trade-off

Input:

/options how should we handle auth tokens — store in localStorage vs httpOnly cookies?

Output / Result:

Decision: auth token storage

Option A — localStorage
  Pro: simple to implement; works across subdomains without configuration
  Con: accessible to any script on the page — XSS on any dependency
       exposes every token immediately
  Con: no automatic expiry enforcement without custom logic

Option B — httpOnly cookie (recommended)
  Pro: inaccessible to JavaScript — XSS cannot read the token
  Pro: expiry handled by the browser natively
  Con: requires CSRF protection (SameSite=Strict handles most cases)
  Con: cross-origin requests need CORS configuration

Recommendation: httpOnly cookie.
localStorage is exploitable via XSS in any script on your page —
one compromised dependency and every session is exposed.
The CSRF surface is smaller and better-understood than the XSS surface.

Example 2 — Project-grounded tool choice

Input:

/options pick a test framework for our new Python service

Output / Result:

[Reads pyproject.toml, existing test files, and requirements]

Decision: Python test framework

Option A — pytest (recommended)
  Pro: already used in sibling service auth-service (tests/conftest.py)
  Pro: richest plugin ecosystem (pytest-cov, pytest-asyncio for your
       FastAPI routes)
  Con: fixture magic is non-obvious to newcomers

Option B — unittest
  Pro: zero new dependencies
  Con: verbose boilerplate; no parametrize without a plugin
  Con: not used anywhere else in this repo — inconsistency cost

Recommendation: pytest — it's already in the repo, the async plugin
covers your FastAPI routes, and a single conftest.py shares fixtures
across both services.

Related tools