원클릭으로
fix-issue
// End-to-end workflow for fixing a GitHub issue. Use when asked to fix, investigate, or resolve a GitHub issue in sccn/eegprep.
// End-to-end workflow for fixing a GitHub issue. Use when asked to fix, investigate, or resolve a GitHub issue in sccn/eegprep.
Develop new EEGPrep features end to end with EEGLAB parity, AGENTS.md compliance, planning, implementation, tests, GUI visual parity, GUI user-flow QA, review, and PR creation. Use when a user asks Codex to build or port an EEGPrep feature, especially pop_* functions, GUI components, or EEGLAB-parity workflows.
Build, port, or iterate on EEGPrep GUI features so they visually and behaviorally match EEGLAB MATLAB UI. Use when implementing a pop_ function GUI, adding an EEGPrep Qt dialog/window, creating or updating visual parity cases under tools/visual_parity, comparing EEGLAB and EEGPrep screenshots, debugging MATLAB GUI capture under X11, or tuning layout/style from an end-user screenshot feedback loop.
Exhaustive user-flow QA workflow using the Computer/GUI agent plus terminal for current PR or branch features. Use only when the user explicitly invokes `$gui-agent-flow-qa`, explicitly mentions `gui-agent-flow-qa`, or explicitly asks to use the Computer/GUI agent to simulate all user flows and produce a QA report. Do not use for ordinary testing, code review, implementation, or GUI parity work unless the user explicitly requests this workflow.
Authoring pull requests in sccn/eegprep. Use when creating or updating a PR, and whenever changing a branch that is already associated with a PR.
Review a pull request for correctness, EEGLAB parity, and behavioral regressions in sccn/eegprep.
| name | fix-issue |
| description | End-to-end workflow for fixing a GitHub issue. Use when asked to fix, investigate, or resolve a GitHub issue in sccn/eegprep. |
You are to fix the Github issue indicated by the user.
Read first:
@AGENTS.md
You may not proceed to a new task until you have completed all prior tasks. If you cannot complete a task, write a Github comment with your last status and why you failed. A task list is at the end of this document.
Be terse. Every sentence must convey information that the reader does not already have. Follow these rules in all comments you post:
src/eegprep/functions/eegobj/eegobj.py#L65-L71 - key/value arg validation.Use gh to fetch the issue. Read the codebase to find all relevant source
files. Post a single comment combining your research and proposed fix.
Before you write code, run a duplicate-work preflight:
gh pr list --state open --search "<issue-id or keyword>").gh issue list --state open --search "<keyword>").The comment has two sections: Research and Proposed Fix.
Title: # Research
**Relevant code** list: max 5 links, each with a short (<10 word) annotation.Example:
EEGobj.__init__()routes path strings throughpop_loadset(). Whenscipy.io.loadmat()fails,pop_loadset()falls back topop_loadset_h5(), which opens the HDF5 file without a context manager, so repeated loads can leak file handles. Root cause:h5py.File(...)is never closed.Relevant code
src/eegprep/functions/eegobj/eegobj.py#L17-L29- path to pop_loadsetsrc/eegprep/functions/popfunc/pop_loadset.py#L80-L88- loadmat fallbacksrc/eegprep/functions/popfunc/pop_loadset_h5.py#L20-L26- h5py file open
Title: # Proposed Fix
There are 2 cases:
Bug fix: Show the call chain that triggers the error, then state the fix in one sentence. Include a code snippet only if the fix is non-obvious.
env.run()returns a tuple;foo()assumes an object and calls.abc(). Fix: unwrap the tuple inRolloutWorker._step()before passing tofoo().
Design change: The design doc replaces the # Proposed Fix section.
Write it directly in the issue comment (agents cannot commit files before the PR). The 3-4 sentence prose cap applies to # Research; the design doc can be around a thousand words. As required, Use an Explore subagent to gather relevant files/lines, related issues/PRs, and reusable utilities. Summarize findings, note gaps, and save a research note. Ask 3–6 targeted questions: scope boundaries, tests, tradeoffs, open questions. Avoid questions answered by code search. Then draft the design doc as a spec. Keep it concise, cite real files/lines, include non-empty Open Questions, and avoid backward-compat unless needed. Iterate until settled. Send design + spec to a reviewer subagent. Incorporate clear improvements, and ask the user only about ambiguous decisions. Keep everything in one comment.
In both cases: find the minimally disruptive fix. Do not over-engineer.
Once you have researched and prepared your design or planned fix, you may
proceed to implementation. You MUST implement your changes in a branch with the
following format agent/{YYYYMMDD}-fix-{issue-id}. You are allowed to create
branches on github as well as submit PRs from those branches.
You will implement a test which demonstrates your changed behavior before beginning work. Your tests will be minimal and refrain from using mocks.
tests/ if appropriate../pre-commit.py --fix and resolve all reported issues before uploading.uv run pytest before uploading.When all tests pass, you may proceed to upload your branch.
Open a pull request following .agents/skills/pull-request/SKILL.md exactly.
Read that file and use the plain-text format it specifies — no markdown headers,
no bullet lists, no ## Summary sections. Violations will be rejected.
Attach it to the Github issue with a comment summarizing the fix.
After opening the pull request, you must verify that CI checks pass:
gh pr view <number> --json statusCheckRollupKey checks to monitor:
The tasks for this skill:
./pre-commit.py --fix and resolve all issuesIf at any point you are unable to proceed, you must add a comment to the Github issue with your last status.