pyside6-engineer
Skill5 starsChanged 22 days agoMITView on GitHub
Use when PySide6-specific widget architecture, signals and slots, model-view design, threading, window behavior, or GUI testing requires Qt judgment.
In this repository47 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agents-md-fixerSkill
- arch-docsSkill
- book-to-markdownSkill
- docset-updaterSkill
- humanizerSkill
- news-release-docsSkill
- pdf-guideSkill
- readme-docsSkill
- screenshot-docsSkill
- see-also-docsSkill
- setup-install-usage-docsSkill
- bptools-writer-expertSkill
- color-accessibility-expertSkill
- css-creative-expertSkill
- game-design-expertSkill
- geometry-expertSkill
- glass-expertSkill
- hic-human-interact-expertSkill
- openscad-3d-printing-expertSkill
- podman-expertSkill
- postgresql-expertSkill
- rust-code-expertSkill
- solid-js-expertSkill
- svg-creator-expertSkill
- typescript-engineerSkill
- ui-ux-engineerSkill
- vision-expertSkill
- wasm-rust-expertSkill
- webwork-writer-expertSkill
- delegate-manager-to-subagentsSkill
- gas-town-workflowSkill
- hang-checkSkill
- html-game-parallel-builderSkill
- parallel-planSkill
- stay-busySkill
- repo-rules-readerSkill
- blueprint-plan-drafterSkill
- ideonomy-plainSkill
- ideonomy-richSkill
- make-goalSkill
- modest-plan-drafterSkill
- audit-code-reviewerSkill
- old-python-code-reviewSkill
- prune-testsSkill
- unit-test-starterSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
30 rules. About 0 are common, 14 are distinctive, and 16 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈14
Distinctive · estimate
This author's own choices. Worth a look.
16
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Use this skill to build desktop interfaces that are technically sound with PySide6.
- Very specific: line 12
Use the official Qt for Python docs as the primary source for APIs, examples, and tool behavior.
- Distinctive: line 19
If GUI code exists, follow the existing-app path: inventory the current widgets and state flow, then make targeted, layout-preserving …
- Distinctive: line 20
If no GUI code exists, follow the greenfield path: decide the window shell and primary surface first, then build the layout and hierarchy …
- Very specific: line 21
Read references/project_workflow.md for the full two-path workflow: greenfield (evidence, Qt contract, implementation choices, validation) …
- Very specific: line 24
Read references/topic_index.md as the routing front door: match the user problem to a row to find the right reference guide before writing …
- Very specific: line 26
Read references/task_selection.md to classify underspecified requests by window container, state coordination model, user goal, and …
- Very specific: line 28
Read references/official_qt_for_python_docs.md when you need the official entry points for installation, module lookup, tutorials, …
- Distinctive: line 31
Prefer a small composition tree of widgets over a giant window class.
- Distinctive: line 32
Keep business logic separate from widget layout logic.
- Distinctive: line 33
Use signals, slots, and small controller-style helpers to avoid tightly coupling every widget to every other widget.
- Very specific: line 34
Read references/pyside6_patterns.md when choosing between common widget, dialog, navigation, threading, and model/view patterns.
- Very specific: line 35
Read references/signals_slots.md when designing event flow, widget coordination, worker updates, or signal boundaries.
- Distinctive: line 38
Prefer layouts over absolute positioning.
- Distinctive: line 39
Keep forms short, labels explicit, and primary actions visually dominant.
- Very specific: line 41
Read references/model_view.md before building non-trivial tables, trees, filtering, sorting, or custom cell rendering.
- Very specific: line 42
Read references/testing_and_oracles.md to drive every UI state through pytest-qt and qtbot, validate against an oracle, and capture a …
- Distinctive: line 47
Prefer Qt Widgets for classic desktop productivity tools, forms, settings, inspectors, admin panels, and other dense business UIs.
- Distinctive: line 48
Use Qt Quick only when the product genuinely needs a more fluid, animated, or QML-centric surface and the request clearly points there.
- Very specific: line 49
Prefer QMainWindow for multi-region applications with menus, toolbars, docks, or status bars.
- Very specific: line 50
Prefer QDialog for short focused tasks that need confirmation or cancellation.
- Very specific: line 51
Prefer QStackedWidget or a router/controller pattern for multi-step flows when tabs would expose too much complexity.
- Distinctive: line 52
Prefer Qt's model/view classes for tables, trees, and large changing datasets.
- Very specific: line 53
Keep long-running work off the UI thread.
- Distinctive: line 54
Treat stylesheets as a finishing layer, not a substitute for good widget choice and layout structure.
- Very specific: line 55
Prefer official Qt tools when the task involves .ui, .qrc, or project-generation workflows instead of reinventing those steps by hand.
- Very specific: line 56
Read references/designer_ui_workflow.md when .ui files, Qt Designer, or pyside6-uic are involved.
- Very specific: line 57
Read references/deployment_and_packaging.md when the task includes packaging, shipping, or validating a distributable PySide6 app.
- Distinctive: line 63
Do not block the event loop with expensive work, sleeps, or synchronous network/file operations in click handlers.
- Distinctive: line 67
When using this skill, aim to produce:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
PySide6 Engineer
Overview
Use this skill to build desktop interfaces that are technically sound with PySide6.
Focus on widget architecture, signal-slot design, state management, and Qt best practices.
Use the official Qt for Python docs as the primary source for APIs, examples, and tool behavior.
For UI/UX review and design polish, use the ui-ux-engineer skill.
Workflow
- Detect the project shape before coding.
- Inspect the target for existing PySide6 source: window or widget classes,
.uifiles, signal-slot wiring, and any GUI tests or screenshots. - If GUI code exists, follow the existing-app path: inventory the current widgets and state flow, then make targeted, layout-preserving changes tied to a specific issue.
- If no GUI code exists, follow the greenfield path: decide the window shell and primary surface first, then build the layout and hierarchy before wiring behavior.
- Read
references/project_workflow.mdfor the full two-path workflow: greenfield (evidence, Qt contract, implementation choices, validation) and existing-repo (inspect first, identify current design, targeted changes, prove improvement).
- Classify the surface before coding.
- Read
references/topic_index.mdas the routing front door: match the user problem to a row to find the right reference guide before writing any code. - Decide whether the work belongs in Qt Widgets or Qt Quick first, then decide whether it should use a
QMainWindow,QWidget,QDialog, wizard, dock layout, or model/view surface. - Read
references/task_selection.mdto classify underspecified requests by window container, state coordination model, user goal, and required states. - Identify the primary user goal, the main workflow path, and the states that must be handled: loading, empty, valid, invalid, busy, success, and failure.
- Read
references/official_qt_for_python_docs.mdwhen you need the official entry points for installation, module lookup, tutorials, examples, or package tools.
- Choose a structure that keeps state understandable.
- Prefer a small composition tree of widgets over a giant window class.
- Keep business logic separate from widget layout logic.
- Use signals, slots, and small controller-style helpers to avoid tightly coupling every widget to every other widget.
- Read
references/pyside6_patterns.mdwhen choosing between common widget, dialog, navigation, threading, and model/view patterns. - Read
references/signals_slots.mdwhen designing event flow, widget coordination, worker updates, or signal boundaries.
- Build the UI from layout and hierarchy first.
- Prefer layouts over absolute positioning.
- Keep forms short, labels explicit, and primary actions visually dominant.
- Design for resizing from the start; do not assume one fixed window size.
- Read
references/model_view.mdbefore building non-trivial tables, trees, filtering, sorting, or custom cell rendering. - Read
references/testing_and_oracles.mdto drive every UI state through pytest-qt and qtbot, validate against an oracle, and capture a before-and-after screenshot grid as the proof artifact.
Implementation defaults
- Load the local-only design books first when present; see the survey in
references/reference_survey.mdfor the topic-to-book map, validated grep terms, and the graceful-absent fallback to official Qt docs. Seereferences/local_books.mdfor the reading order and Qt-UX lens per book. - Prefer Qt Widgets for classic desktop productivity tools, forms, settings, inspectors, admin panels, and other dense business UIs.
- Use Qt Quick only when the product genuinely needs a more fluid, animated, or QML-centric surface and the request clearly points there.
- Prefer
QMainWindowfor multi-region applications with menus, toolbars, docks, or status bars. - Prefer
QDialogfor short focused tasks that need confirmation or cancellation. - Prefer
QStackedWidgetor a router/controller pattern for multi-step flows when tabs would expose too much complexity. - Prefer Qt's model/view classes for tables, trees, and large changing datasets.
- Keep long-running work off the UI thread; use worker objects plus
QThreador other Qt-safe async patterns. - Treat stylesheets as a finishing layer, not a substitute for good widget choice and layout structure.
- Prefer official Qt tools when the task involves
.ui,.qrc, or project-generation workflows instead of reinventing those steps by hand. - Read
references/designer_ui_workflow.mdwhen.uifiles, Qt Designer, orpyside6-uicare involved. - Read
references/deployment_and_packaging.mdwhen the task includes packaging, shipping, or validating a distributable PySide6 app.
Quality bar
- Favor stable patterns over clever widget tricks.
- Favor predictable state transitions over hidden side effects.
- Do not block the event loop with expensive work, sleeps, or synchronous network/file operations in click handlers.
Output expectations
When using this skill, aim to produce:
- PySide6 code that is organized by responsibility and easy to extend.
- Explicit handling for validation, error messaging, empty states, and loading states.
- References to the relevant official Qt for Python docs when using unfamiliar APIs or package tools.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

