| name | quick-wins |
| description | Surface and triage local issues that are safe and quick for an AI to implement and easy for a human to verify. Use when the user wants to "knock out issues", asks for "quick wins", "low-hanging fruit", "what's easy to do right now", or wants a batch of small tasks to work through in one session. |
| allowed-tools | Bash, Read |
| disable-model-invocation | true |
Quick Wins — find AI-friendly issues to knock out
Use this skill when the user wants to power through a batch of small issues. The goal is to identify issues where:
- The spec is already done — root cause, file paths, or implementation hints are in the issue body
- The blast radius is small — touches one logger / one command / one screen, not architecture
- A human can verify in <2 minutes — clear "do X, see Y" check
- Failure mode is obvious — if it breaks, you'll see it immediately (not a slow data corruption)
Workflow
Step 1 — list candidate issues
Pull all 2-todo issues with their size/complexity:
obsidian base:query vault=nvALT path="Simple History issues.base" format=json \
| jq '[.[] | select(.status == "2-todo") | {name, prio, type, size, complexity}]'
Filenames also act as a length proxy (longer file = more spec written down):
ls -S "/Users/bonny/Documents/nvALT/Simple History/issues/" | head -30
wc -l "/Users/bonny/Documents/nvALT/Simple History/issues/"*.md | sort -n
Very short issues (<25 lines) are usually stubs without enough context — skip them unless the title alone is enough.
Very long issues are often well-spec'd but may have grown in scope — read carefully.
Step 2 — score each candidate
Read the body and rate against these signals. Don't invent scores; just check off what's true.
Green flags (more = better)
- 🟢 Issue body names a specific file + line for the fix (e.g. "
class-post-logger.php:654, add ...")
- 🟢 Has a
> [!agent] decision block — means the design has already been debated
- 🟢 Marked
size: 1-small or complexity: patch
- 🟢 Type is
bug with reproducible steps
- 🟢 Verification is "run X, see Y" — no test data, no special account, no third-party service
- 🟢 Single-file or single-method change
Red flags (any one is usually disqualifying)
- 🔴 Touches the database schema or runs
ALTER TABLE on existing data
- 🔴 Modifies billing, license validation, or update server logic
- 🔴 Crosses core ↔ premium boundary (without clear interface)
- 🔴 Type is
feature and the body is a stub (<25 lines, no implementation hints)
- 🔴 Verification needs WooCommerce + a real order + a real product (unless WC is set up locally)
- 🔴 Status is
4-needs-decision or 5-needs-investigation — by definition not ready
- 🔴 Networks/multisite changes without a network test environment
- 🔴 UI redesigns (subjective taste calls — save for human-led work)
Step 3 — present a tiered list
Group findings into three tiers and present to the user. Don't pick — let the user choose what to work on.
🟢 Tier 1 — Spec is done, just implement
- <Issue name> — one-line summary of fix + verification step
...
🟡 Tier 2 — Clear scope, slightly larger
- <Issue name> — ...
🔴 Skip for now (with reason)
- <Issue name> — too risky / underspecified / needs decision
Step 4 — once user picks one
Follow the normal local-issues workflow:
obsidian property:set ... status=1-in-progress- Implement the change
- Verify by running the steps in the issue
- Run linters and relevant tests
- Commit (per
git-commits skill)
obsidian property:set ... status=8-done and review=pending- Append a
> [!agent] block summarising what changed and how the user can verify
If the user says "do them all" or "knock them out", work through one at a time, marking each done before starting the next. Do not batch into a single commit — one issue, one commit, so review can happen per-issue.
Anti-patterns — DON'T
- ❌ Don't promote an issue to Tier 1 just because it's small. "Small + underspecified" still means hidden decisions.
- ❌ Don't treat
size: 1-small as the only signal — read the body.
- ❌ Don't pick issues with
status: 4-needs-decision or 5-needs-investigation — they're parked for a reason.
- ❌ Don't pick UX/redesign work without an explicit
> [!agent] decision in the body.
- ❌ Don't assume an issue is fresh — check if there's already an
agent note saying it's partly done.
Notes on common issue types in this repo
- WP-CLI bugs (e.g. things-not-logged-from-CLI) → usually a missing
WP_CLI exception alongside the REST_REQUEST/XMLRPC_REQUEST checks. Easy to verify with wp commands.
- Logger improvements (extra context fields like SKU/ID) → see the
create-logger and logger-messages skills. Verify via the populate-log skill or by doing the action and reading the event details.
- License/constant features (premium) → small, isolated changes in the licensing code. Verify by
define()-ing the constant and reloading the settings screen.
- WooCommerce features → only safe if WC is installed locally and you can hit the action. If not, mark blocked and move on.
