docs: add agent contributor guidance and a security-audit skill

[KernelClint]

Description

Four documentation changes for contributors using coding agents. They are one pull request because they cross-reference each other.

AGENTS.md (new, 87 lines) — an operational companion to CONTRIBUTING.md for anyone pointing an agent at this repository: where code goes, the UTScapy campaign format, the exact lint and test commands, which generated files must not be hand-edited. It opens by naming CONTRIBUTING.md as the contribution guide and links to it rather than restating it. Every statement in it is traceable to something already in the tree.

.github/skills/scapy-security-audit/SKILL.md (new, 198 lines) — a sibling to the existing scapy-packet-fields skill, carrying an audit methodology: how to build a coverage inventory from the code, keep a primitive registry, hold several hypotheses at once, falsify a candidate before promoting it, and what does not count as a finding. It deliberately contains no map of Scapy's current module layout, so it should not rot as the code moves. It points at SECURITY.md for scope rather than duplicating it.

CONTRIBUTING.md (+4 lines) — the practical checks the existing AI-assisted section already implies, plus a pointer to AGENTS.md. It does not change the position already stated there, and does not turn any existing suggestion into a requirement. One thing worth flagging: tox.ini does not set basepython for the flake8 environment, so tox -e flake8 uses whichever interpreter invokes it, and the pinned flake8<6.0.0 fails on Python 3.14. The added text says python3.12 -m tox -e flake8 for that reason.

SECURITY.md (4 lines changed) — two changes, described below.

On the SECURITY.md changes

The second is a clarification. The first is a policy proposal, and I would rather say so than have it read as one.

1. Proposal. A sentence asking a report to include a minimal working example and a negative control — the same exchange without the triggering packet. The policy currently says what counts as a vulnerability but not what shows it, and a trigger with no control does not distinguish a defect from a path that never worked. Please drop this line if you would rather not have it.

2. Clarification. The parenthetical in "a DoS that is triggered when crafting a packet (and that is not a response to a stimulus, e.g. answering machines, automatons, etc.)" reads on a quick pass as excluding automatons, when it restores them to scope. Reworded so the carve-in is unambiguous. No change in meaning intended.

Two questions rather than changes

Two other places in SECURITY.md are genuinely ambiguous in practice, and settling either would be choosing policy rather than clarifying it, so nothing was changed:

1. What "stops the dissection process entirely" covers when dissection succeeded. A wire-valid packet can dissect cleanly — not replaced with Raw — and then fail inside an answering machine's reply callback, at which point sniff() closes its reader and returns early, so later packets are never processed. The Raw exclusion plainly does not reach that, but the text does not say whether a failure after dissection counts. Both readings are available.

2. Where "anything that requires changing Scapy's configuration" stops. Read literally it removes every opt-in feature from scope, since using such a feature at all means setting configuration — WEP decryption needs conf.wepkey, for instance. That cannot be the intent, given the policy elsewhere invites reports about answering machines, which are also opt-in. There may be a distinction worth drawing between configuration that enables the feature under test and configuration that weakens a default.

Happy to send either as a follow-up if you tell me which way you want it.

Tests

No tests. These are documentation changes and the repository has no test coverage for Markdown. Every command that appears in the new files was run on this checkout, including under more than one Python version where the result depends on it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.63%. Comparing base (ca465f1) to head (f3378cb).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #5121   +/-   ##
=======================================
  Coverage   80.63%   80.63%           
=======================================
  Files         390      390           
  Lines       96903    96903           
=======================================
+ Hits        78136    78138    +2     
+ Misses      18767    18765    -2     

see 7 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.