Skillnaija All courses →

Publish Two Polished Technical Pieces: a How-To Guide and a README or API Doc

The capstone project for Technical Writing — a free Data & Tech course. Pass it and you earn a certificate anyone can verify.

Start the course free Download the project workbook

The project unlocks once you complete the lessons. The workbook is free to download now so you can see exactly what is expected.

What you will submit

Public links to two published technical pieces — one how-to guide and one README or API doc — for a real or sample tool, formatted in Markdown, each with its one-line audience statement and a short accuracy-and-edit note.

What to do, step by step

  1. Choose ONE real or sample tool you understand and can actually open — for example a Nigerian fintech app, a developer API like Paystack or Flutterwave, a small open-source project on GitHub, or a sample command-line tool. At the top of a planning note, write a one-line audience statement for each piece using Lesson 2 (for example: 'For a first-time shop owner with a smartphone and no coding knowledge' for the how-to, and 'For a developer integrating this tool' for the README/API doc).
  2. Write a clear HOW-TO GUIDE for one specific task with that tool (for example 'How to set up a payment link' or 'How to export your data'). Follow the structure from Lesson 4: a one-line description of what it achieves, any prerequisites, numbered single-action steps that each start with a strong verb and tell the reader what they will SEE, and a short 'result' or 'next steps' line. Keep it in plain language and verify every step actually works by following your own draft (Lesson 6).
  3. Write EITHER a README for a real or sample project OR a short API doc for one endpoint. A README must include: title and one-line description, what problem it solves, installation, at least one usage example, and where to get help. An API doc must clearly show one endpoint — what you send (method, path, parameters), a sample request, and the response (including at least one error) — using proper code formatting.
  4. Format BOTH pieces in Markdown, using headings (#, ##), bold for key terms, numbered or bulleted lists where appropriate, links, and backticks for any code or commands (Lesson 5). Make sure code and prose are clearly separated and nothing is a wall of unbroken text.
  5. Run an accuracy-and-clarity edit (Lessons 3 and 6): confirm names are consistent (one name per thing), cut filler and big words, prefer the active voice, run the 'scan test' on each piece, and fix anything that fails. Add a 2-3 line note describing one thing you tightened or one gap you caught by testing the tool yourself.
  6. Publish both pieces as PUBLIC links — for example a GitHub repo or Gist, GitHub Pages, a Notion page set to 'anyone with the link can view', or a Hashnode/Dev.to post — and submit both links (with the short audience and edit notes) in a single document or message.

Files to work with

Project workbook (fill in, then submit)The whole brief, an evidence checklist, the grading rubric as a self-check and the link-sharing steps in one file. Opens in Word, Google Docs or WPS.Word · 7 KB

How it is graded

CriterionWeight
Audience is clearly defined for each piece and the writing genuinely matches that reader's knowledge level and needs (Lesson 2 applied)20%
How-to guide follows the correct structure — goal, prerequisites, numbered single-action steps with strong verbs and visible 'success' signals, and a result/next-steps line25%
README or API doc is complete and correct for its type (README: description, problem, install, usage example, help; API doc: method/path/parameters, request, and response with an error)25%
Both pieces use clean Markdown and plain language — consistent naming, active voice, code clearly separated from prose, scannable structure20%
Both pieces are published as working public links, with the audience statements and a short accuracy-and-edit note included10%

You need 65% overall to pass. A failed submission comes back with feedback and can be revised and resubmitted.

Before you submit: make your link public

If your work lives in Google Drive or Google Docs, open Share → General access and change “Restricted” to “Anyone with the link” (Viewer). Then paste the link into a private browser window: if it opens without sign-in, you are ready. A private link cannot be graded — it is the single most common reason a good project fails.

Frequently asked questions

Do I have to finish Technical Writing before submitting the project?

Yes. The submission screen opens once every lesson in Technical Writing is marked complete. The lessons are where the methods, the Nigerian context and the worked examples the project depends on are taught.

How is the project graded?

An examiner scores each rubric criterion from 0 to 100 and weights them as shown on this page; you need 65% overall to pass. Most submissions are graded within minutes and you get written feedback on what was strong and what to improve.

Can I resubmit if I fail?

Yes. A failed project comes back with feedback; revise the weak parts and resubmit. A passed project is final — the certificate is issued and cannot be re-rolled.

What do I actually submit?

A write-up of what you did (under 5,000 characters) plus a public link to your work — a Google Drive folder, Google Doc, spreadsheet, GitHub repository or video. The link must open without sign-in; a private link cannot be graded. The free project workbook on this page walks you through all 6 steps.

Is the certificate real?

Yes. Passing this project issues a certificate with a unique verification code. Anyone — an employer, a client, a school — can open the verification page and see that the certificate is genuine and which project earned it.

More Data & Tech projects

Ready to earn this certificate?

Technical Writing is free and self-paced. Finish the lessons, complete this project, and the certificate is yours to share.

Start learning free