with one click
warpx-answer-user-question
// Draft a response to a WarpX user question (from a GitHub issue, discussion, or email).
// Draft a response to a WarpX user question (from a GitHub issue, discussion, or email).
| name | warpx-answer-user-question |
| description | Draft a response to a WarpX user question (from a GitHub issue, discussion, or email). |
| disable-model-invocation | true |
Draft a helpful, accurate response to a WarpX user question, in the style of an experienced WarpX developer.
If a plain-text question was pasted, use it directly. If a GitHub issue or discussion URL was provided, fetch it with gh and read the full thread (all comments and replies), not just the opening post — the answer or key context is often in subsequent comments.
Identify:
Assign the question to one or more of these categories:
| Category | Typical signals |
|---|---|
| A. Installation / Build | CMake errors, missing libraries, conda/spack, CUDA compilation, module conflicts |
| B. Input File / Parameters | Wrong parameter name or value, PICMI vs native syntax, laser setup, particle injection, boundary conditions |
| C. Diagnostics & Output | Output format, reduced diagnostics syntax, checkpoint/restart, post-processing |
| D. Physics / Numerical | Numerical heating, energy non-conservation, CFL, boosted frame artifacts, resolution |
| E. Feature Availability | "Does WarpX support X?" |
| F. Performance & HPC | Slow I/O, OOM, multi-node MPI, GPU choice |
| G. Python / PICMI | pywarpx API, callbacks, add_particles, PICMI vs native mapping |
| H. Bug Report | Reproducible unexpected behavior, wrong results, crashes |
Before drafting any answer, actively search. The answer must be grounded in WarpX code, docs, and prior issues — not generated from general knowledge.
Search these sources as relevant to the category:
Documentation (Docs/source/):
usage/parameters.rst — all input parameters (the primary reference)usage/python.rst — PICMI/Python interfaceinstall/cmake.rst — build optionsdataanalysis/ — output formats, openPMD, post-processing toolsSource code — key directories:
Source/Laser/, Source/Particles/, Source/FieldSolver/, Source/Diagnostics/, Source/BoundaryConditions/, Source/Python/query/queryWithParser/add/addarr/queryAdd with the parameter nameSource/Diagnostics/ReducedDiags/Examples (Examples/Tests/, Examples/Physics_applications/):
Past GitHub issues and discussions:
Decide: do you have enough information to give a complete, accurate answer?
If not, identify the 1-3 most important missing pieces. Common things to ask for:
If information is missing, proceed directly to Step 6 and draft a "Missing info" reply — do not attempt the Step 5 escalation check, since you cannot yet assess the complexity of the issue.
Before drafting, check whether the question is within the agent's ability to answer reliably. Stop and report to the skill invoker (the WarpX developer running this skill) instead of drafting a GitHub reply if the issue falls into either of these categories:
In these cases, report to the skill invoker:
This issue appears to require deeper investigation (or domain expertise) that goes beyond what I can reliably provide. I recommend that a WarpX developer look into this directly.
Then briefly summarize what is known, what makes the question hard, and what a developer would need to look at.
Tone — match the style of experienced WarpX developers:
Structure by situation:
Answerable question: (1) Direct answer upfront, (2) explanation if needed, (3) corrected snippet or example, (4) link to relevant docs page on warpx.readthedocs.io or example file in repo
Bug report: (1) Confirm the bug with explanation, (2) workaround if one exists, (3) state if a fix PR is already open, (4) ask user to verify once merged.
Missing info: (1) Explain what's needed and why, (2) provide partial answer if possible.
Feature not available: (1) Confirm clearly, (2) explain workarounds (Python callbacks, post-processing, etc.), (3) link to tracking issue/PR if one exists, (4) invite contribution.
Show the draft and ask:
Does this response look good? Would you like me to adjust anything before you post it?
Only post the reply to GitHub if asked explicitly. Always show the draft first.