My name is Manav, and I am a BTech CSE student from India.
I am interested in contributing to Swift for Google Summer of Code 2026, specifically the project:
“Improved documentation for command line tools”.
I have started exploring the swift-argument-parser repository and the GenerateDocCReference plugin. I am currently studying how documentation is generated and how commands and options are structured.
I had a few technical questions:
For generating separate pages for commands, should this be handled within the existing plugin or as an extension layer on top of it?
Regarding symbol graph generation, is there an existing structure or schema expected for representing CLI commands, flags, and subcommands?
Should the initial focus be on improving markdown output first, or designing the intermediate representation for documentation?
I would really appreciate any guidance or suggestions from mentors on how to approach this project effectively.
Looking forward to contributing and learning from the community.
I feel like this would be within the responsibilities of the current plugin.
There's not any expected structure specifically for CLI types—see this thread for more details—but the SymbolKit repo contains this spec of the general file format.
As a potential starting point for how to map the existing symbol graph elements to commands you could also look at this experiment that I did 2 years ago and how I represented a command in the symbol graph file (without representing flags or even adding relationships between subcommands).
That question is kind of up to you to decide how you want to structure the project in your proposal.
That said, specifically for this project, I would recommend that you focus on what a small collection of benefits that you want to provide (to either the reader and/or writer of the CLI documentation). Once you know the benefits that you want to provide you can work your way backwards to how to accomplish those.
Depending on what benefits you want to provide, you may find that your proposal focuses on either aspect of the initial project idea more.
I would probably recommend including at least some markdown improvements and trying to plan for them early-ish in the project because there would be fewer pieces to learn about up-front and it would enable you to learn from working in the plugin code base. Then you can use what you've learned in the later parts of the project plan.
I shared some similar advice in this message in another thread.