Skip to main content
skill CX Codex

ns-gitlab-board-sync — Claude Code skill

Syncs local planning and execution state with existing GitLab issues. Use it to keep milestones, labels, assignees, estimates, and spent time aligned.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add nextstage-brasil/skills --skill ns-gitlab-board-sync -a claude-code
Open on GitHub

What ns-gitlab-board-sync does

This skill mirrors local task state onto existing GitLab issues. It can update a milestone, replace RF and status labels, assign an issue, set an estimate when none exists, and post wall-clock time after work. It does not create issues.

GitLab MCP must be available for the tool calls. If several GitLab MCP servers are configured, the agent asks which one to use. The skill checks docs/context/gitlab-sync-config.md; batch syncing also needs gitlab-issue-feature-map.md. Label changes use one atomic set_issue_labels call, and status moves through backlog, in_progress, then done. Without GitLab MCP, issue synchronization cannot run.

What it helps with

  • sync local plans with existing GitLab issues
  • move an issue through backlog, in progress, and done
  • set an issue milestone and assignee
  • replace RF and status labels atomically
  • record wall-clock time spent on an issue

Example prompts for the agent

  • Sync the issues linked in gitlab-issue-feature-map.md with their existing GitLab records.
  • Before coding, move the linked issue from status_backlog to status_in_progress.
  • After validation, update the issue with its RF label and post spent time calculated from START_EPOCH.

How to install ns-gitlab-board-sync

1Skills CLI (Vercel)

npx skills add nextstage-brasil/skills --skill ns-gitlab-board-sync -a claude-code

2Manually: put the files in place

~/.claude/skills/ns-gitlab-board-sync/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/ns-gitlab-board-sync/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about ns-gitlab-board-sync

How do I install ns-gitlab-board-sync in Claude Code?

Run npx skills add nextstage-brasil/skills --skill ns-gitlab-board-sync -a claude-code. The skill file will be available at ~/.claude/skills/ns-gitlab-board-sync/SKILL.md.

What does ns-gitlab-board-sync do?

It mirrors local planning and execution state onto existing GitLab issues. The skill handles milestones, labels, status changes, assignees, estimates, and spent time.

Can ns-gitlab-board-sync create new GitLab issues?

No. It only updates existing issues; the description points to mcp-gitlab-usage for creating new ones.

Source text

SKILL.md · Apache-2.0
---
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."
license: Apache-2.0
metadata:
  author: nextstage-brasil
  version: "1.2"
---

# GitLab Board Sync

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

## Prerequisites

1. GitLab MCP available — follow `mcp-gitlab-usage` for all tool calls
2. If multiple GitLab MCP servers: ask human which to use
3. `docs/context/gitlab-sync-config.md` validated
4. 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:

1. `read_issue` for description + recent comments
2. Non-blocking if inaccessible — log warning, continue
3. **Do not mutate** issue in this flow

## Flow A — Post-planning batch

Per issue in map (excluding `exclude_issues`):

1. Validate milestone (project + group)
2. `update_issue` with `milestone_id`
3. **One** `set_issue_labels` — `remove_labels` + `add_labels` atomically (RF, Status, Equipe)
4. `assign_issue`
5. `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) |

© nextstage-brasil · Apache-2.0 · nextstage-brasil/skills

Similar skills

All skills for Agent setup: memory, context, orchestration →

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor