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.
npx skills add nextstage-brasil/skills --skill ns-gitlab-board-sync -a claude-codeWhat 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.mdwith their existing GitLab records. - Before coding, move the linked issue from
status_backlogtostatus_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-code2Manually: put the files in place
~/.claude/skills/ns-gitlab-board-sync/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/ns-gitlab-board-sync/
1Skills CLI (Vercel)
npx skills add nextstage-brasil/skills --skill ns-gitlab-board-sync -a codex2Manually: put the files in place
.agents/skills/ns-gitlab-board-sync/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add nextstage-brasil/skills --skill ns-gitlab-board-sync -a cursor2Manually: put the files in place
.cursor/skills/ns-gitlab-board-sync/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install nextstage-brasil/skills ns-gitlab-board-sync2Manually: put the files in place
.github/skills/ns-gitlab-board-sync/SKILL.md1Skills CLI (Vercel)
npx skills add nextstage-brasil/skills --skill ns-gitlab-board-sync -a gemini-cli2Platform CLI
gemini skills install https://github.com/nextstage-brasil/skills --path skills/ns-gitlab-board-syncManually: put the files in place
.devin/skills/ns-gitlab-board-sync/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add nextstage-brasil/skills --skill ns-gitlab-board-sync -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
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