一键导入
pull-request
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
| name | pull-request |
| description | 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. |
This skill defines the exact output format for pull requests. Follow it literally when creating or updating a PR. Also apply it whenever you make changes to a branch that already has an associated PR.
When a branch is already associated with a PR, check the current PR title and description after your code changes. Keep them aligned with the actual scope of the branch, and update them if they are no longer correct or sufficient.
The PR description becomes the squash-merge commit message. Write it as plain text — no markdown.
Title: Short imperative sentence. Optional scope tag in brackets.
Body: 1-3 sentences stating what changed and why. End with issue link if one exists.
Hard rules — violations will be rejected:
##), no bullet lists (-/*), no tables, no images, no [text](url) links.- [ ], - [x]).## Summary, ## Test plan, ## Changes.Title: [EEG] Fix pop_loadset HDF5 path handling
Body:
Ensure pop_loadset resolves HDF5 sidecar paths relative to the .set file
location. This prevents missing file errors when datasets are moved between
folders. Adds a regression test covering relative paths.
Fixes #1234
If the work originated from a GitHub issue, reference it:
Fixes #NNNN — auto-closes the issue on merge.Part of #NNNN — for partial work.Do not create an issue solely to satisfy this rule. When there is no pre-existing issue (e.g., user-directed work in a conversation), omit the issue link.
Run these before pushing. Do not skip any step.
./pre-commit.py --fix — resolve all issues. Do not substitute uv run pre-commit ....uv run pytest — relevant test files or directories.After pushing, monitor CI: gh pr view <number> --json statusCheckRollup.
Fix failures before considering the PR complete.
PRs over ~500 lines must include a specification. Put it in (preferred order):
A specification contains:
Unless the user says otherwise, and when permissions allow, push directly to a branch on the main repository and open the PR from that branch. Do not default to pushing to a fork. Use a fork only when direct push to the main repository is not available or the user explicitly asks for it.
Use gh pr create with these flags:
gh pr create \
--title "<title>" \
--body "<plain text body>"
agent-generated label only when the PR is created by a repository
automation workflow. Do not add it when a human asks an agent to create or
update the PR from an interactive session.Fixes #NNNN when addressing a pre-existing issue..agents/skills/github-pr-review/ — PR review skill (separate concern).agents/skills/fix-issue/ — end-to-end issue fix workflowAGENTS.md — coding guidelinesRun an unusually strict EEGPrep code-quality review for architecture, maintainability, abstraction quality, file sprawl, spaghetti branching, and missed simplification. Use for thermo-nuclear review, thermonuclear review, deep maintainability audit, strict architecture review, or when code technically works but may make EEGPrep harder to ship.
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.
Build EEGPrep external extension packages with SDK registration, declarative menus, pop_* console/history behavior, packaged help/data, distribution choices, tests, GUI visual parity, and catalog-readiness. Use when Codex or a researcher needs to create, port, review, package, or submit an EEGPrep extension outside the core package.
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.
Plan EEGPrep multi-phase GitHub epics, phase issues, epic branches, merge order, and agent-ready /goal prompts for EEGLAB parity or major product work. Use when the user asks to organize EEGPrep work as an epic, create phase issues, plan parallel agent streams, or set up an epic branch.
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.