How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

ns-gitlab-board-sync - Skill

Name: ns-gitlab-board-sync
Author: nextstage-brasil

Imported from nextstage-brasil/skills (skills/ns-gitlab-board-sync/SKILL.md) via skills.sh. Install upstream with npx skills add nextstage-brasil/skills --skill ns-gitlab-board-sync. Copyright stays with the author (Apache-2.0).

GitLab Board Sync

Mirror local SDD planning/execution state onto existing GitLab issues. Does not create issues.

Prerequisites

GitLab MCP available — follow mcp-gitlab-usage for all tool calls
If multiple GitLab MCP servers: ask human which to use
docs/context/gitlab-sync-config.md validated
For post-planning batch: gitlab-issue-feature-map.md exists

Configuration

Read references/gitlab-sync-config.template.md for expected fields:

project_id, milestone_id, assignee_default
status_backlog, status_in_progress, status_done, status_blocked
rf_label_format, base_branch, work_branch, mr_target_branch

Discover unknown status labels via list_project_labels — confirm with human.

Flow C — Pre-implementation read

When task lists GitLab issue IIDs:

read_issue for description + recent comments
Non-blocking if inaccessible — log warning, continue
Do not mutate issue in this flow

Flow A — Post-planning batch

Per issue in map (excluding exclude_issues):

Validate milestone (project + group)
update_issue with milestone_id
One set_issue_labels — remove_labels + add_labels atomically (RF, Status, Equipe)
assign_issue
set_issue_estimate from linked task header (seconds) only if time_stats.time_estimate is empty — never overwrite; skip values < 60

Flow B — Per-task execution sync (legacy 1:1)

Mutual exclusion: any issue_iid in delivery-units.md → do not run Flow B. Owner = ../ns-spec-driven/references/delivery-units.md GitLab status/spent (SSoT).

When task row maps 1:1 to its own GitLab issue (no delivery units file, or unpublished units + legacy gitlab-issue-feature-map.md):

Task start (before coding)

remove: status_backlog
add: status_in_progress

Record START_TIME / START_EPOCH when coding starts (for wall-clock add_issue_spent_time — see ../ns-execution-gitlab-issue/references/time-tracking.md).

Task complete (after validation)

Only if already status_in_progress:

remove: status_in_progress
add: status_done, RF: NNN
add_issue_spent_time
add_issue_comment (internal=true)

Never backlog → done in one step.

Flow D — Per delivery unit

Run only when SSoT row is Flow D (published issue_iid + local execute, no G). When G owns lifecycle → skip entire Flow D.

Unit start (before coding unit tasks)

remove: status_backlog
add: status_in_progress

Record START_TIME / START_EPOCH when coding starts for unit (wall-clock for unit-level spent).

Unit complete (after unit validation + review approved)

Only if already status_in_progress:

remove: status_in_progress
add: status_done
add_issue_comment (internal=true)

Local-only (SSoT Flow D row): include add_issue_spent_time once per unit (wall-clock, not estimate_sum); set spent_posted = yes.

Never backlog → done in one step. Never add_issue_spent_time per task inside unit. Never Flow D when G owns the same issue.

Anti-patterns

Wrong	Right
`assignee` on `update_issue`	`assign_issue`
Two label calls for one transition	Single atomic `set_issue_labels`
Manual `Milestone:` label	`milestone_id` on `update_issue`
`set_issue_estimate` for time spent	`add_issue_spent_time` with wall-clock duration
`set_issue_estimate` when estimate already set	Skip — preserve existing
Plan/`estimate_seconds` as spent `duration`	Epoch delta only (`time-tracking.md`)
Public comment for internal notes	`internal: true`

References

File	When
`references/gitlab-sync-config.template.md`	Bootstrap config
`mcp-gitlab-usage`	Tool schemas and gates
`../ns-spec-driven/references/delivery-units.md`	GitLab status/spent (SSoT)

Install ns-gitlab-board-sync and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

{ "ocm": "1", "id": "nextstage-brasil-skills-ns-gitlab-board-sync", "kind": "skill", "name": "ns-gitlab-board-sync", "description": "(NS) Sync existing GitLab issues with local planning/execution — milestone, RF labels, status, assignee, estimates, spent time. Use during implementation when tasks link to GitLab issues or after plan-version-from-gitlab sync — not for creating new issues (use mcp-gitlab-usage). Always atomic set_issue_labels and three-step status cycle.", "publisher": "nextstage-brasil", "version": "1.0.0", "capabilities": { "domains": [ "customer_support" ], "tags": [ "skill-md", "skills-sh" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "(NS) Sync existing GitLab issues with local planning/execution — milestone, RF labels, status, assignee, estimates, spent time. Use during implementation when tasks link to GitLab issues or after plan-version-from-gitlab sync — not for creating new issues (use mcp-gitlab-usage). Always atomic set_issue_labels and three-step status cycle." ], "primary": false, "metadata": { "source": { "provider": "skills.sh", "repository": "https://github.com/nextstage-brasil/skills", "path": "skills/ns-gitlab-board-sync/SKILL.md", "ref": "HEAD", "url": "https://www.skills.sh/nextstage-brasil/skills/ns-gitlab-board-sync", "key": "nextstage-brasil/skills/skills/ns-gitlab-board-sync/SKILL.md" }, "license": "Apache-2.0" }, "instructions": "# GitLab Board Sync\n\nMirror local SDD planning/execution state onto **existing** GitLab issues. Does **not** create issues.\n\n## Prerequisites\n\n1. GitLab MCP available — follow `mcp-gitlab-usage` for all tool calls\n2. If multiple GitLab MCP servers: ask human which to use\n3. `docs/context/gitlab-sync-config.md` validated\n4. For post-planning batch: `gitlab-issue-feature-map.md` exists\n\n## Configuration\n\nRead `references/gitlab-sync-config.template.md` for expected fields:\n\n- `project_id`, `milestone_id`, `assignee_default`\n- `status_backlog`, `status_in_progress`, `status_done`, `status_blocked", "cost": { "context_tokens": 1044 } }

ns-gitlab-board-sync

About

GitLab Board Sync

Prerequisites

Configuration

Flow C — Pre-implementation read

Flow A — Post-planning batch

Flow B — Per-task execution sync (legacy 1:1)

Task start (before coding)

Task complete (after validation)

Flow D — Per delivery unit

Unit start (before coding unit tasks)

Unit complete (after unit validation + review approved)

Anti-patterns

References

Install ns-gitlab-board-sync and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews