The Developers are the people in the Scrum Team committed to creating any aspect of a usable Increment each Sprint. That is a definition by commitment rather than by craft, and it is the reason a tester, a designer, a data engineer and a technical writer are all Developers when they sit on a Scrum Team.
The four things they are accountable for
Each one closes a question the framework would otherwise leave open.
Creating a plan for the Sprint, which is the Sprint Backlog. A plan made by the people who will carry it out is the only kind that can be adapted honestly when the work turns out to be different from the guess.
Instilling quality by adhering to a Definition of Done. That places the standard inside the work as it is built rather than in an inspection bolted on at the end.
Adapting their plan each day towards the Sprint Goal, which is exactly what the Daily Scrum exists to produce.
Holding each other accountable as professionals. This is the clause that makes self-management something other than an absence of supervision, since a team with nobody outside it enforcing standards has to enforce them internally or not at all.
Skills are broad, and deliberately unlisted
The specific skills needed are broad and vary with the domain of work. Scrum names none of them, because the same framework is used for software, hardware, marketing and research, and any list would be wrong for most of those within a year.
What the framework does insist on is that the team collectively holds whatever the domain requires, so that a usable Increment can be produced without waiting on somebody outside the team. Cross-functionality is a property of the group. No individual is asked to do everything, and the group is asked to need nobody else.
No titles, no sub teams
There is no title other than Developer, and there are no sub teams or hierarchies within a Scrum Team. A lead who allocates the work, an architect who signs off designs before coding starts, or a test group that receives the build in the final days all put back the structure this accountability was written to remove.
People keep their specialisms and their standing in the wider organisation. What they do not acquire inside the Scrum Team is authority over another member's work, because an Increment cannot be a collective accountability while one person decides for everyone.
How many of them there are
A Scrum Team is typically ten or fewer people in total, so the Developers are whoever remains after one Product Owner and one Scrum Master. The Guide sets no minimum and no fixed ratio. A team that has grown past the point where it stays cohesive should consider reorganising into several Scrum Teams sharing one Product Goal, one Product Backlog and one Product Owner.
Where their authority stops
The Developers decide how the work is done and how much of it can be taken into a Sprint. They do not decide what the product should become or how the Product Backlog is ordered, which is the Product Owner's accountability.
Scenario questions probe that line from both directions. A Product Owner dictating which tasks the Developers take on has crossed it, and so have Developers who reorder the Product Backlog because they would rather build something else first.