Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
aws-samples avatar

Gitlab Docs Publishing

  • 20 installs
  • 41 repo stars
  • Updated July 6, 2026
  • aws-samples/sample-agent-skills-for-builders

gitlab-docs-publishing is a Claude skill that publishes HTML design docs on GitLab Pages and injects a text-selection bubble that opens prefilled GitLab Issues for in-context review.

About

This skill publishes HTML or Markdown design documents on GitLab Pages and adds an in-context comment workflow. Reviewers select any text in the published doc, and a floating bubble opens a prefilled GitLab Issue with a title, anchor link, selection quote, and label. It relies only on free GitLab features and the reviewer's existing session, so there is no OAuth, PAT, or in-page API call.

  • Publishes HTML/Markdown design docs on GitLab Pages
  • Adds a selection-driven bubble that opens a prefilled GitLab Issue
  • Uses free GitLab features with no OAuth, PAT, or API calls

Gitlab Docs Publishing by the numbers

  • 20 all-time installs (skills.sh)
  • Ranked #1,005 of 1,879 Documentation skills by installs in the Skillselion catalog
  • Data as of Jul 30, 2026 (Skillselion catalog sync)
At a glance

gitlab-docs-publishing capabilities & compatibility

Uses only free GitLab features (Pages, Issues); no external services.

Capabilities
quip to gitlab wiki · documentation
Works with
gitlab
Use cases
documentation
Pricing
Free
From the docs

What gitlab-docs-publishing says it does

Publish HTML/Markdown design documents on GitLab Pages with selection-driven discussion.
SKILL.md
GitLab handles auth via the user's existing session — no OAuth, no PAT, no API calls.
SKILL.md
npx skills add https://github.com/aws-samples/sample-agent-skills-for-builders --skill gitlab-docs-publishing

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs20
repo stars41
Last updatedJuly 6, 2026
Repositoryaws-samples/sample-agent-skills-for-builders

What it does

Publish design docs on GitLab Pages with a selection-driven bubble that files prefilled GitLab Issues as in-context review comments.

Who is it for?

Teams reviewing design docs on GitLab who want in-context feedback without external services or OAuth.

Skip if: External or public audiences who do not have GitLab accounts.

When should I use this skill?

When publishing design docs on GitLab Pages and enabling selection-driven in-context review comments.

What you get

Design docs are served at a public GitLab Pages URL where selecting text opens a prefilled, labelled GitLab Issue with a working anchor link.

  • public/<v>/index.html on GitLab Pages
  • comment-widget.js and .css assets
  • comments-issue.json config

By the numbers

  • 4-step inject-comments pipeline
  • deployment checklist with 6 checks

Files

SKILL.mdMarkdownGitHub ↗

GitLab Docs Publishing

Publish styled HTML design docs on GitLab Pages and let reviewers file in-context feedback by selecting any text and clicking a floating 💬 bubble — which opens a pre-filled GitLab Issue in a new tab. Zero external services, zero in-page API calls.

Standalone HTML design docs are great for reading but miss two things GitLab does not provide out of the box: a public URL (GitLab renders .html blobs as source code, not as a page) and an in-context comment thread tied to the exact piece of prose a reviewer wants to discuss. This skill bolts both on using only free GitLab features:

  • GitLab Pages auto-publishes HTML on every merge to main.
  • Selection-driven 💬 bubble — a small JS widget watches text selection.

On click, it navigates the browser to GitLab's "New issue" page with title + description + label prefilled. GitLab authenticates the user with their existing session cookie.

When to Apply

  • Publishing a technical design doc (HTML or Markdown) for team review.
  • Teammates complain they have to git clone to see the styled HTML version.
  • Meeting feedback gets lost because there's no place to write it against

specific sentences.

  • An HTML visual doc has been generated from source Markdown and now needs

a distribution channel with feedback affordances.

Not for:

  • Documents that belong in GitLab Wiki (Wiki renders Markdown natively and

has built-in comments).

  • Single-reviewer review — use MR line comments instead.
  • External/public audiences who do not have GitLab accounts.

How It Works

docs/<v>/foo.html
   │
   │ inject-comments.py:
   │   1. Strip any pre-existing in-page widgets
   │   2. Add ids to headings/figures/tables
   │   3. Inject <link>+<script> for the selection-bubble widget
   │   4. Copy comment-widget.{js,css} into <assets-dir>
   ↓
public/<v>/index.html  ──▶  GitLab Pages CI publishes public/
                              ↓
                     Reviewer opens published URL
                     Selects any text → 💬 bubble appears
                     Clicks → new tab on GitLab issues/new
                     with title + description + label prefilled
                     GitLab uses existing session cookie
                     Reviewer types → submits → labelled Issue created

Usage

Step 1 — Add the Pages CI job

Copy `templates/gitlab-ci-pages.yml` into your project's .gitlab-ci.yml and replace <VERSION> / <MAIN_HTML>. The template already runs the inject step (Step 2 explains its config). After merge to main, the doc is served at the project's Pages URL — check Settings → Pages for the exact host.

Step 2 — Configure the per-page Issue settings

Commit a small per-page config:

// docs/v1.0.0/comments-issue.json
{
  "gitlabHost": "https://gitlab.example.com",
  "projectPath": "group/subgroup/project",
  "pageUrl": "https://<pages-url>/v1.0.0/",
  "titlePrefix": "[v1.0.0-tech-design]",
  "issueLabels": "doc-comments"
}

The CI template invokes the injector with this config. The injector:

  • Adds id attributes to every <h1><h6> (slug from heading text),

<div class="diagram-frame"> (figure-N), and <div class="aws-table-wrap"> (table-N) so anchor URLs resolve.

  • Injects <link rel="stylesheet"> and <script defer> referencing the

bundled widget assets.

  • Copies comment-widget.{js,css} into --assets-dir.
  • Is idempotent — re-running on the same HTML doesn't double up.

Step 3 — Validate before publishing

python3 scripts/validate-html.py docs/v1.0.0/tech-design.html

Confirms tag balance and that anchor IDs are present.

What the reviewer sees

  • The published doc renders normally — no extra buttons or chrome anywhere.
  • Selecting any text shows a small orange "💬 添加评论" / "💬 Add comment"

bubble above the selection.

  • Clicking opens a new tab on GitLab's New Issue page. Title is

[<prefix>] §<heading-text> · "<first 30 chars of selection>…". Description contains an anchor link (back to the section) plus the selection quote, plus a hidden anchor JSON block for forward-compat tooling.

  • The reviewer types their comment under "Your comment:" and submits.

Deployment Checklist

  • [ ] HTML generated; tag balance and anchors validated.
  • [ ] .gitlab-ci.yml includes the pages job and the inject step.
  • [ ] comments-issue.json is committed and has the right gitlabHost,

projectPath, and pageUrl.

  • [ ] Selecting text on the published page shows the bubble.
  • [ ] Clicking the bubble opens GitLab's New Issue page with prefilled

title, description, and label.

  • [ ] After submitting, the resulting Issue has a working anchor link in

its description that scrolls back to the right section.

References

Related skills

FAQ

Does this need OAuth or a personal access token?

No. GitLab handles auth via the user's existing session, so there is no OAuth, no PAT, and no in-page API calls.

How do reviewers leave feedback?

They select any text in the published doc; a floating bubble opens a prefilled GitLab Issue in a new tab with title, anchor link, selection quote, and label.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.