Put spare quota to good use

Reviewing work you have already done gives you findings you can act on right away.

A good fit when

You have uncommitted changes ready to submit or hand over.

What you get

Evidence-backed findings with code locations, trigger conditions and suggested fixes.

Review the uncommitted changes in this repository, including staged and unstaged changes, without modifying files.
Read the project instructions and relevant context first. Focus on logic errors, edge cases, permissions, concurrency, state consistency and regressions.
Report at most 5 evidence-backed issues. For each, include severity, file and line, trigger conditions, impact, the smallest suggested fix and how to verify it.
Do not report naming, formatting or personal style preferences as bugs. If there are no high-confidence findings, say so.
Do not edit files. If there are no changes to review, explain and stop; do not expand to the whole repository.

Done whenEvery finding points to a specific change and trigger condition. Finding no issues is also a valid result.

A repeatable test keeps helping with future changes.

A good fit when

You maintain a code project with a working test environment.

What you get

One critical test, its results and the risks still not covered.

Read the project instructions, code and existing tests. Choose one important, narrowly scoped user workflow and identify a real gap in its tests.
Run the relevant existing tests first and record the baseline. If the environment is unavailable or the baseline fails, explain the blocker; do not attribute existing failures to new changes.
Choose the single most valuable missing test by business impact and implement it with the existing framework. Test observable behavior, not a copy of implementation details; do not chase coverage numbers.
Run the new test and relevant regression tests. Report the failure it detects, the results and remaining risks.
Do not change correct business logic just to pass a test, introduce another test framework, commit or deploy. Stop after this one improvement.

Done whenThe test runs successfully and you can explain the real failure it guards against.

Save yourself and others from rediscovering the same setup steps in every new task.

A good fit when

The project works, but its documentation is outdated or often needs explaining.

What you get

Verified setup steps, directory responsibilities and troubleshooting notes.

Verify this project’s setup and handoff documentation without changing business code.
Read project instructions, existing documentation, package manifests and configuration. Update existing documentation first, follow the repository’s document-location rules and avoid duplicate files.
Document installation, startup, build and test commands, the main directory responsibilities, required environment variable names and common troubleshooting steps. Never include secrets or real credentials.
Verify safe local commands where the environment allows. Do not deploy, migrate data or perform external writes. Distinguish verified steps, unverified steps and items needing human confirmation; cite files or command evidence.
Keep the notes concise and useful for maintenance. Do not mass-generate comments, refactor or upgrade dependencies.

Done whenSomeone else can follow the notes to start working and tell which steps have been verified.

Do the setup once and reuse it whenever you organize files or process data.

A good fit when

You repeatedly clean CSV files, organize logs, convert files or create fixed-format reports.

What you get

A minimal script, usage notes and validation with a real example.

Help me turn one repetitive manual operation into a minimal working script.
Before implementing, ask me together for the current steps, the location of one real input and the expected output. Wait for this information; do not guess which files I want processed.
Follow project instructions and prefer existing dependencies. Support dry-run by default, write actual output to a new directory and make repeated runs safe. Do not delete or overwrite original files.
Provide clear errors for invalid inputs and useful logs. Validate one real input/output example, and include the command to run the script and short usage notes.
Do not upload data, call paid services or perform external writes. Stop once this workflow works; do not expand it into a general-purpose platform.

Done whenThe same example can be run repeatedly, with correct output and intact originals.

Real interactions can uncover unresponsive controls, poor error messages and mobile layout issues.

A good fit when

You have an accessible website or local project and one flow you want checked.

What you get

Reproducible findings, screenshots and steps for checking again.

Check one user workflow on my website using a real browser.
First confirm the URL, the workflow and the available test environment. If browser tools are unavailable, say so and provide manual checks; do not claim to have performed them.
Check normal, empty and invalid input, loading and failure states, mobile layout, keyboard interaction, console errors and failed requests.
Before sending messages, paying, publishing or changing real data, stop before submission and use a test environment or ask for confirmation.
Report at most 3 important issues with reproduction steps, expected and actual behavior, and screenshots. If nothing is found, state the scope checked.
Check only this flow and do not change business code. Leave repeatable recheck steps.

Done whenEach issue has reproduction steps and screenshots that match the actual checks performed.

Clarifying scope, affected code and acceptance criteria makes the next implementation easier to start.

A good fit when

You have a feature idea but have not settled on an implementation.

What you get

An implementation plan grounded in the current project, with acceptance criteria.

Create an actionable implementation plan for my next feature without changing business code this time.
First ask what problem I want to solve and what users should be able to do. Then read the project instructions and relevant implementation; do not invent systems that do not exist.
Describe current and intended behavior, scope and non-goals, affected modules, key tradeoffs, compatibility risks and verification methods.
Break the work into small independently verifiable steps, each with user-observable acceptance criteria. Mark unknowns explicitly; do not present assumptions as facts.
Save a short plan according to the project’s rules for internal documents. Stop after planning; do not code or deploy.

Done whenEach step has a clear stopping point, and important unknowns are explicit.

Even without code to write, your existing information can become a reusable resource.

A good fit when

You have meeting notes, drafts, project records or scattered instructions.

What you get

A structured document, open questions and an action list.

Organize a set of existing materials. First confirm their location and the intended use; do not read unrelated directories.
Keep the originals and write the result to a new document, following workspace documentation rules.
Merge duplicate information, organize by topic and distinguish facts, opinions, decisions and open questions. Cite the source file or passage for important conclusions.
Flag contradictions and missing information. Do not invent facts, dates or numbers. Extract only existing action items; do not invent owners or deadlines.
Provide the organized text, open questions and a short index. Check that key conclusions trace back to the originals. Do not upload the materials.

Done whenImportant conclusions are traceable, and contradictions or gaps have not been silently removed.

Replace manual row-by-row checking with an evidence-backed data quality report.

A good fit when

You have a CSV or spreadsheet to check before summarizing, importing or analyzing it.

What you get

An anomaly report, its reasoning and optional cleaning recommendations.

Check data quality in the CSV or spreadsheet I specify.
First confirm the file location, field meanings and key business rules. Without those rules, start with descriptive checks; do not assume an outlier is an error.
Check duplicate records, missing values, inconsistent types, date formats and values outside known rules.
For each finding type, report counts, row numbers or record identifiers, reasoning and possible impact. Avoid exposing unnecessary personal information in the report.
Do not delete, overwrite or upload originals, or fill in missing data on your own. Produce an anomaly report and proposed cleaning rules, and reconcile the total record count.
Only inspect this time. Wait for approval of the cleaning rules before processing further.

Done whenEach anomaly has a location and rationale, and the original data remains unchanged.