원클릭으로 Manus에서 모든 스킬 실행

$pwd:

captain-v2

Name: Captain V2
Author: mongodb

// Batch workflow for completing small DOCSP Jira tickets via sage-bot-beta. Selects tickets, hands them off to sage-bot-beta for implementation, polls for the resulting draft PRs, and adds staging links. Use this skill whenever the user wants to work through multiple small DOCSP Jira tickets or pick up batch work. Trigger phrases: "start tickets", "captain tickets", "do some tickets", "work on backlog", "bug tickets", "bug bash".

Manus에서 실행

$ git log --oneline --stat

stars:773

forks:1,705

updated:2026년 5월 19일 13:45

파일 탐색기

3 개 파일

SKILL.md

readonly

name

captain-v2

description

Batch workflow for completing small DOCSP Jira tickets via sage-bot-beta. Selects tickets, hands them off to sage-bot-beta for implementation, polls for the resulting draft PRs, and adds staging links. Use this skill whenever the user wants to work through multiple small DOCSP Jira tickets or pick up batch work. Trigger phrases: "start tickets", "captain tickets", "do some tickets", "work on backlog", "bug tickets", "bug bash".

Jira Ticket Workflow (sage-bot-beta orchestration)

This skill batches DOCSP tickets through sage-bot-beta. Captain-v2 selects tickets and adds staging links; sage-bot-beta does the research, edits, and draft PR.

What is sage-bot-beta? It's an internal MongoDB tool that takes a Jira ticket, spins up an AI agent in Argo (MongoDB's workflow infrastructure), and automatically opens a draft GitHub PR with the documentation changes. You trigger it by adding two labels to a Jira ticket; it typically produces a PR within 10–20 minutes.

Prerequisites

/jira skill — all Jira operations are delegated to it. Do not call jira-cli or mcp-atlassian directly; invoke /jira and describe the operation needed.
gh CLI authenticated against 10gen/docs-mongodb-internal. If not authenticated, or if gh CLI cannot perform a required operation, fall back to the GitHub MCP server.

Phase 1: Ticket Selection

Ask the user how many tickets (1–10) they want to start. More is fine — each runs in its own sage-bot-beta job, so they progress in parallel.

Use /jira to search for candidate tickets:

project=DOCSP AND status in (Backlog,"Ready for Work") AND (assignee is EMPTY OR assignee = currentUser()) AND ("Story Points Estimate" is EMPTY OR "Story Points Estimate" <= 2)

Return the top N results ordered by most recently updated.

Present the top N tickets as a numbered list with key, summary, and story points.
Ask the user to approve the list or swap out specific tickets.
Remind the user to refine any ticket's description that needs more direct, specific guidance on what changes to make. The more explicit the description (exact wording, target file, intended outcome), the more efficiently sage-bot-beta can complete the work without ambiguity.

Do NOT proceed to Phase 2 until the user confirms.

Phase 2: Hand off to sage-bot-beta

For each approved ticket:

Assign and transition. Use /jira to perform these operations on the ticket:
- Assignee: current user — the /jira skill resolves this automatically; no extra lookup needed
- Story Points Estimate: existing value, or 1 if unset
- Transition: In Progress — pass this exact string. Do NOT use "Start Progress" or any other variant.
Add labels. Use /jira to add labels in two steps. Order matters — sage-bot-beta validates repo:... at trigger time:
- Step 1 — add label: repo:10gen/docs-mongodb-internal
- Pause 2 seconds
- Step 2 — add label: sage-bot-beta (keep repo:10gen/docs-mongodb-internal present)
Tell the user which tickets were dispatched. Don't spawn anything; the bot runs in Argo.

Phase 3: Wait for PRs

sage-bot-beta typically creates PRs within 10–20 minutes of being triggered. Wait 7 minutes, check once, and immediately start adding staging links to whatever PRs are ready.

Step 3a: Tell the user they have a break

After dispatching, tell the user they have 7 minutes while sage-bot-beta runs in Argo, and suggest using the time to read through the dispatched tickets and form expectations for the fix before the PRs land.

Step 3b: Wait and check

Run .claude/skills/captain-v2/assets/check-prs.sh passing each dispatched ticket key as arguments:

.claude/skills/captain-v2/assets/check-prs.sh DOCSP-AAAAA DOCSP-BBBBB ...

The script emits one line per ticket:

PR_FOUND DOCSP-AAAAA: {"number":20170,"url":"https://github.com/10gen/docs-mongodb-internal/pull/20170","createdAt":"..."}
PR_MISSING DOCSP-BBBBB

Step 3c: Handle results

Result	Action
`PR_FOUND` for all tickets	Collect PR URLs and proceed to Phase 4.
`PR_FOUND` for some, `PR_MISSING` for others	Start Phase 4 immediately for ready PRs. After Phase 4, do one final check for missing tickets. If still missing at 65 min from dispatch, treat as timeout.
Timeout for a ticket	Use `/jira` to show the most recent comment on that ticket — sage-bot-beta posts an error comment on failure. Surface it verbatim and move on; do not retry the label.

Do NOT inspect PR diffs — the user reviews the draft PRs themselves.

Phase 4: Staging links

For each found PR:

Get the links — invoke /staging-preview for PR #<PR_NUMBER> on 10gen/docs-mongodb-internal. The skill returns a markdown list of staging URLs.
Write links to the PR body — use python3 + gh api to replace the ## STAGING or [STAGING] section in the PR body. Do NOT use gh pr edit (triggers a GraphQL deprecation error).

The /staging-preview skill returns a markdown list — one - [Label](url) item per changed page. Assign that output verbatim to the links variable in the script below. For example, if /staging-preview returned:
```
- [compact (database command)](https://deploy-preview-20169--mongodb-manual.netlify.app/docs/manual/reference/command/compact/)
```
then set links to that exact string in the script below.
```
python3 .claude/skills/captain-v2/assets/update-staging-links.py <PR_NUMBER> '<output from /staging-preview goes here>'
```
If the ## STAGING or [STAGING] section is absent from the PR body, append the links at the end instead of using the regex substitution.

If the procedure fails for a given PR, note it in the final summary and continue — don't block the rest of the batch.

Phase 5: Summary

For each ticket, show:

Ticket key + summary
PR link (or the failure comment from Jira if the bot errored out)
Whether staging links were added

Before signing off, remind the user:

⚠️ Before you review: These PRs were written by sage-bot-beta, an AI agent — they will look polished and professional. That's exactly what makes them risky — a wrong fact, a missed scope requirement, or a subtly incorrect procedure can be hard to spot when the formatting and prose are clean. Compare each PR against the original ticket and your own expectations, not just against itself. You are responsible for everything that merges under your name.

This is the end of the workflow.

Notes

Branch naming is sage-bot-beta's responsibility — captain-v2 does not specify a branch ref in the repo:... label.
Captain-v2 does not run git commands locally in this flow. There is no worktree, no fetch, no branch creation — sage-bot-beta handles all of it in Argo.

related-skills.json

같은 저장소

drivers-release-notes.md

from "mongodb/docs"

Draft MongoDB drivers release notes for a new version by fetching the corresponding release from the driver source code and adding them to the documentation. Use when asked to create release notes or What's New sections for the drivers and frameworks listed in the Workflow section.

2026-05-27773

local-build-check.md

from "mongodb/docs"

Run local docs build checks on pending content/ changes before opening a PR. Catches broken directives, bad refs, missing includes, invalid substitutions, and indentation errors using the Snooty RST parser. Applies unambiguous fixes from a learned per-repo knowledge base, surfaces ambiguous ones, and appends new errors to a local log. Use when the user is about to commit or open a PR and the pending changes include: edits to .txt or .rst files, changes to YAML extract files in source/includes/, any file renamed/moved/ deleted in content/ (could break :ref:, literalinclude, or include paths), or snooty.toml changes. Also use when the user asks to "check the build", "test before PR", "lint the build", or wants to validate edits work. Do NOT trigger for image-only changes, code-example file edits that don't touch RST, or non-RST config files with no path impact.

2026-05-22773

drivers-ticket-assistant.md

from "mongodb/docs"

Help the user understand and complete their assigned DOCSP tickets for drivers. Provides a prioritized overview of all assigned tickets and suggests next steps. Use only when the user explicitly uses the slash command.

2026-05-15773

jira.md

from "mongodb/docs"

Use this skill for any Jira operation in the DOCSP project — creating, viewing, searching, updating, transitioning, commenting on, or linking tickets. Also handles follow-up ticket creation to manage scope creep. TRIGGER when: user mentions a DOCSP-XXXXX ticket number or any Jira ticket URL; user asks to view, open, check, update, transition, close, comment on, link, or search tickets; user references "the ticket", "the Jira", or "open a ticket". SKIP: GitHub issues; non-Jira platforms; questions unrelated to ticket operations.

2026-05-11773

open-pr.md

from "mongodb/docs"

Opens a GitHub Pull Request with the standard PR template: Description, Staging Links, and JIRA ticket. Infers the ticket from the branch name and generates staging preview URLs from changed files after the PR is created. TRIGGER when: user asks to open, create, submit, make, update, or edit a PR or pull request, or wants to refresh staging links on an existing PR.

2026-05-07773

staging-preview.md

from "mongodb/docs"

Generate staging preview links for a MongoDB docs PR. Polls for the builder-bot deploy preview comment, then constructs page-specific URLs for changed .txt files, includes, YAML extracts, images, and TOC files. Use when you need to generate or refresh staging links for a pull request.

2026-05-07773

package.json

"author": "mongodb"

"repository": "mongodb/docs"

GitHub 저장소 열기 Creator 저장소 보기

$ install --global

$ download --local

Manus에서 실행

$ useful --forSOC

프로젝트 관리 전문가비즈니스 및 금융 운영직13-1082L4

name

captain-v2

description

Jira Ticket Workflow (sage-bot-beta orchestration)

This skill batches DOCSP tickets through sage-bot-beta. Captain-v2 selects tickets and adds staging links; sage-bot-beta does the research, edits, and draft PR.

Prerequisites

/jira skill — all Jira operations are delegated to it. Do not call jira-cli or mcp-atlassian directly; invoke /jira and describe the operation needed.
gh CLI authenticated against 10gen/docs-mongodb-internal. If not authenticated, or if gh CLI cannot perform a required operation, fall back to the GitHub MCP server.

Phase 1: Ticket Selection

Ask the user how many tickets (1–10) they want to start. More is fine — each runs in its own sage-bot-beta job, so they progress in parallel.

Use /jira to search for candidate tickets:

project=DOCSP AND status in (Backlog,"Ready for Work") AND (assignee is EMPTY OR assignee = currentUser()) AND ("Story Points Estimate" is EMPTY OR "Story Points Estimate" <= 2)

Return the top N results ordered by most recently updated.

Present the top N tickets as a numbered list with key, summary, and story points.
Ask the user to approve the list or swap out specific tickets.
Remind the user to refine any ticket's description that needs more direct, specific guidance on what changes to make. The more explicit the description (exact wording, target file, intended outcome), the more efficiently sage-bot-beta can complete the work without ambiguity.

Do NOT proceed to Phase 2 until the user confirms.

Phase 2: Hand off to sage-bot-beta

For each approved ticket:

Assign and transition. Use /jira to perform these operations on the ticket:
- Assignee: current user — the /jira skill resolves this automatically; no extra lookup needed
- Story Points Estimate: existing value, or 1 if unset
- Transition: In Progress — pass this exact string. Do NOT use "Start Progress" or any other variant.
Add labels. Use /jira to add labels in two steps. Order matters — sage-bot-beta validates repo:... at trigger time:
- Step 1 — add label: repo:10gen/docs-mongodb-internal
- Pause 2 seconds
- Step 2 — add label: sage-bot-beta (keep repo:10gen/docs-mongodb-internal present)
Tell the user which tickets were dispatched. Don't spawn anything; the bot runs in Argo.

Phase 3: Wait for PRs

sage-bot-beta typically creates PRs within 10–20 minutes of being triggered. Wait 7 minutes, check once, and immediately start adding staging links to whatever PRs are ready.

Step 3a: Tell the user they have a break

Step 3b: Wait and check

Run .claude/skills/captain-v2/assets/check-prs.sh passing each dispatched ticket key as arguments:

.claude/skills/captain-v2/assets/check-prs.sh DOCSP-AAAAA DOCSP-BBBBB ...

The script emits one line per ticket:

PR_FOUND DOCSP-AAAAA: {"number":20170,"url":"https://github.com/10gen/docs-mongodb-internal/pull/20170","createdAt":"..."}
PR_MISSING DOCSP-BBBBB

Step 3c: Handle results

Result	Action
`PR_FOUND` for all tickets	Collect PR URLs and proceed to Phase 4.
`PR_FOUND` for some, `PR_MISSING` for others	Start Phase 4 immediately for ready PRs. After Phase 4, do one final check for missing tickets. If still missing at 65 min from dispatch, treat as timeout.
Timeout for a ticket	Use `/jira` to show the most recent comment on that ticket — sage-bot-beta posts an error comment on failure. Surface it verbatim and move on; do not retry the label.

Do NOT inspect PR diffs — the user reviews the draft PRs themselves.

Phase 4: Staging links

For each found PR:

Get the links — invoke /staging-preview for PR #<PR_NUMBER> on 10gen/docs-mongodb-internal. The skill returns a markdown list of staging URLs.
Write links to the PR body — use python3 + gh api to replace the ## STAGING or [STAGING] section in the PR body. Do NOT use gh pr edit (triggers a GraphQL deprecation error).

The /staging-preview skill returns a markdown list — one - [Label](url) item per changed page. Assign that output verbatim to the links variable in the script below. For example, if /staging-preview returned:
```
- [compact (database command)](https://deploy-preview-20169--mongodb-manual.netlify.app/docs/manual/reference/command/compact/)
```
then set links to that exact string in the script below.
```
python3 .claude/skills/captain-v2/assets/update-staging-links.py <PR_NUMBER> '<output from /staging-preview goes here>'
```
If the ## STAGING or [STAGING] section is absent from the PR body, append the links at the end instead of using the regex substitution.

If the procedure fails for a given PR, note it in the final summary and continue — don't block the rest of the batch.

Phase 5: Summary

For each ticket, show:

Ticket key + summary
PR link (or the failure comment from Jira if the bot errored out)
Whether staging links were added

Before signing off, remind the user:

⚠️ Before you review: These PRs were written by sage-bot-beta, an AI agent — they will look polished and professional. That's exactly what makes them risky — a wrong fact, a missed scope requirement, or a subtly incorrect procedure can be hard to spot when the formatting and prose are clean. Compare each PR against the original ticket and your own expectations, not just against itself. You are responsible for everything that merges under your name.

This is the end of the workflow.

Notes

Branch naming is sage-bot-beta's responsibility — captain-v2 does not specify a branch ref in the repo:... label.
Captain-v2 does not run git commands locally in this flow. There is no worktree, no fetch, no branch creation — sage-bot-beta handles all of it in Argo.

captain-v2

Jira Ticket Workflow (sage-bot-beta orchestration)

Prerequisites

Phase 1: Ticket Selection

Phase 2: Hand off to sage-bot-beta

Phase 3: Wait for PRs

Step 3a: Tell the user they have a break

Step 3b: Wait and check

Step 3c: Handle results

Phase 4: Staging links

Phase 5: Summary

Notes

이 저장소의 다른 Skills

이 저장소의 다른 Skills

Jira Ticket Workflow (sage-bot-beta orchestration)

Prerequisites

Phase 1: Ticket Selection

Phase 2: Hand off to sage-bot-beta

Phase 3: Wait for PRs

Step 3a: Tell the user they have a break

Step 3b: Wait and check

Step 3c: Handle results

Phase 4: Staging links

Phase 5: Summary

Notes