The setting

Harborlight Software sells marina management tools, and its Moorings API lets marinas take slip reservations through their own websites. You are the company's first technical writer, hired after the docs outgrew one engineer's notes file.

Every mission on this path happens at the same company, so context carries over the way it does in a real job: the data you cleaned in mission two is the data the finance lead questions in mission four.

The missions

1. doc outlinestarter

Outline the Moorings API docs site from the support queue backward

Harborlight's docs are currently one long page an engineer pastes into as features ship, and support is drowning in questions the docs should answer. Your first assignment is the information architecture for a real docs site, and your manager wants the outline argued from evidence, not taste.

You deliver: An annotated docs site outline with page purposes, a first-integration reader path, and a support-question mapping.

Scored on: Covers every product area, Support questions mapped, Reader path is quickstart first, Honest about the SDK gap.

Working from: feature_notes.md, support_questions.md.

2. API explanationstarter

Turn Petra's Slack notes into the reservations reference page

The reservations endpoints are the most-used part of the Moorings API and their only documentation is a note dump Petra, the backend lead, pasted from Slack. Agencies keep guessing at field names and support pays for every guess.

You deliver: A reservations reference page covering create, fetch, and list, with examples, errors, and an open questions list for Petra.

Scored on: Fields match the notes, Ambiguities flagged not guessed, Complete endpoint coverage, Usable examples.

Working from: engineer_notes.md.

3. release notecore

Write the v1.8 release notes without burying the breaking changes

Moorings API v1.8 ships Thursday and the raw changelog is a pile of commit messages, three of which will break or surprise integrations. Last release, a silent behavior change cost a marina a weekend of failed bookings, so this time the notes have to lead with what hurts.

You deliver: Customer-facing v1.8 release notes with a breaking changes section first, migration steps, and internal noise removed.

Scored on: Breaking changes surfaced, Internal noise removed, Accurate grouping, Plain integrator language.

Working from: changelog_raw.md, support_context.md.

4. KB articlecore

Write the webhook troubleshooting article support keeps asking for

Webhook problems are Harborlight's third biggest ticket theme at 19 last quarter, and every ticket gets a hand-written answer because there is no article to link. Support pulled their best threads into one notes file and asked you to turn it into the canonical troubleshooting page.

You deliver: A knowledge base article on webhook delivery failures with symptom, cause, and fix for each of the three failure modes.

Scored on: All three causes covered, Retry mechanics exact, Self-serve diagnosis order, Idempotency shown concretely.

Working from: support_thread_notes.md.

5. review passstretch

Audit the published slips page against what the API really does

An agency built against the published slips and reservations page and burned two days on errors the docs caused. Petra fact-checked the API behavior into a truth file and your job is a full review pass: find every place the published page is wrong, and say how to fix it.

You deliver: A review report listing every factual error on the page with location, correction, and severity, plus clarity suggestions.

Scored on: Finds the factual errors, Corrections are exact, Sensible severity ranking, Clarity improvements separated.

Working from: current_docs_page.md, api_truth.md.

How the scoring works

Each deliverable is graded against the rubric written for that mission. Separately, every mission on every path is graded on how you used AI, against the same four criteria:

  • Understood the task. The learner framed the goal for the assistant clearly instead of pasting the brief and hoping.
  • Grounded in the material. The learner directed the assistant into the provided files and based the work on them, not on invented facts.
  • Verified the output. The learner checked claims, numbers, or coverage against the source material before submitting.
  • Iterated with judgment. The learner refined weak parts of the draft with specific follow-ups rather than accepting the first answer.

Both scores, with the work behind them, go on your proof profile. That is what makes a claim like "I can use AI for technical writing" something an employer can check.