How do you structure how you do a pull request or code contribution

[abdo210xl]

So, I haven't contributed to open source projects before, most of my work was college projects and some team projects, and i wanted to close the barrier of being afraid of doing changes to tools that i use day to day and have something that bothers me without creating my own tool from scratch, so generally how the process goes when trying to do so, generally and specially to netexec, what are their criteria for code contribution what do they focus on the most, etc. Any help regarding this would appreciated

[alexliluz]

A good first contribution is usually not “find some code to change”; it is
“pick one concrete problem, agree on the expected behavior, then make the
smallest verifiable change.”

For NetExec specifically, I would use this workflow:

1. Confirm the problem before coding. Search Issues and Discussions, then
   describe the current behavior, desired behavior, and how you can reproduce
   it. For a feature or a security-sensitive change, wait for a maintainer to
   agree with the direction. This is especially important if AI will be used:
   NetExec's AI policy
   says an AI-assisted PR must reference an accepted issue, disclose the
   tool/model and extent of assistance, and be manually tested in an
   environment you actually control.

2. Fork and branch from the current main. The
   contribution guide
   still says master, but the repository's current default branch and recent
   PR base are main. A clean setup is:

   git remote add upstream https://github.com/Pennyw0rth/NetExec.git
   git fetch upstream
   git switch -c fix/short-description upstream/main
   poetry install --with dev

3. Keep the PR about one behavior. Add a focused regression test before
   the fix when possible. Run at least:

   poetry run pytest
   poetry run ruff check . --preview

   For a new module or feature, the
   PR checklist
   requires updating tests/e2e_commands.txt when applicable. Run relevant
   end-to-end checks only against a lab/target you are authorized to test, and
   record the OS, Python version, target software version, exact command, and
   result.

4. Make the PR easy to review. Keep the template sections (Description,
   Type of change, Setup guide for the review, and Checklist); a workflow
   checks for them. Link the issue, explain the root cause rather than only the
   symptom, list files/behavior changed, include before/after evidence, and
   give the reviewer exact reproduction and verification steps. Link upstream
   dependency PRs or technique sources if relevant.

5. Respond to review as part of the contribution. Re-run the focused tests
   after changes and state what changed. NetExec's lint/test workflows are
   normally run after an approving review, so good local evidence in the PR is
   particularly valuable.

For a first PR, I would choose a small accepted bug with a reproduction you can
run yourself, or a test/documentation gap discovered while using NetExec. That
shows the things maintainers need most: a real user problem, narrow scope,
reproducibility, safe testing, and low review burden.

AI disclosure: I used OpenAI Codex (GPT-5) to inspect the current NetExec
contribution guide, AI policy, PR template, tests, and workflows and to draft
this response. The repository-specific links and commands above were checked
against current main at dee28e3473250ca154759e6020b365b409a52643.

[Dfte]

That's a really good answer! Thanks!! You mentionned the "fix an issue" as a first PR, I'd also add the "add a new module that answers one thing that you'd love as well". Playing with modules is the easier to get in touch with the NXC tool I believe :P

[NeffIsBack]

Indeed an amazing answer :)

[abdo210xl]

You are actually amazing sir, thank you for taking that time to answer such structured answer, i will try to follow your instructions, and yeah what triggered me to ask such question was an issue of transferring a large sam database file(system file specifically) in the backup_operator module while solving the latest htb machine, and i really couldn't find any other tool to do so, so someone made a simple script to just get the root flag using some sort of chunking the smb response so that it doesn't break, i haven't got deep enough to understand what exacly is the problem, but that made me to think why not try to fix it and help the community out, not that i just want to add code to say "hey i contributed to that look at me" not like that. Anyways, sorry for talking too much, but you encouraged me to give time to what i want to do, thank you again sir.

[NeffIsBack]

Hi and no worries about long answers :D

Actually there was a bug report and attempt to fix that bug, but so far only with some hot fix patch. If you want to take a look at it and check if you can find the root cause of the bug that would actually be a really good contribution.

Feel free to check out this PR: #1253