backlog-external
Skill14 starsChanged 8 months agoMITView on GitHub
External service backlog implementation (GitHub Issues, Linear, JIRA, YouTrack). Used when stack.md has backlog external with a backlog_config section.
In this repository50 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- adr-conventionSkill
- architecture-vocabularySkill
- backlog-localSkill
- backlogSkill
- checkpointsSkill
- design-principlesSkill
- domain-glossarySkill
- git-practicesSkill
- grounded-claimsSkill
- knowledge-checkSkill
- policy-riskSkill
- positive-framingSkill
- receiving-code-reviewSkill
- skill-authoringSkill
- skill-awarenessSkill
- subagent-driven-developmentSkill
- test-driven-developmentSkill
- token-efficientSkill
- triageSkill
- verification-before-completionSkill
- workflow-bugSkill
- workflow-checkSkill
- workflow-commitSkill
- workflow-contractsSkill
- workflow-debugSkill
- workflow-decisionsSkill
- workflow-docsSkill
- workflow-doctorSkill
- workflow-epicSkill
- workflow-featureSkill
- workflow-flow-fix-pipelineSkill
- workflow-flowSkill
- workflow-grillSkill
- workflow-handoffSkill
- workflow-ideaSkill
- workflow-implementSkill
- workflow-planSkill
- workflow-proposalSkill
- workflow-prSkill
- workflow-refineSkill
- workflow-researchSkill
- workflow-reviewSkill
- workflow-startSkill
- workflow-statusSkill
- workflow-tech-reviewSkill
- workflow-update-workflowSkill
- workflow-validateSkill
- workflow-worktreeSkill
- workflow-yoloSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
23 rules. About 0 are common, 14 are distinctive, and 9 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈14
Distinctive · estimate
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 68
Local files manage: Document references (spec paths, plan paths).
- Very specific: line 81
github-issues: Use gh CLI commands (already available, no MCP needed)
- Distinctive: line 82
linear: Use the Linear MCP connector tools
- Distinctive: line 83
jira: Use the Jira MCP connector tools
- Distinctive: line 84
youtrack: Use the YouTrack MCP connector tools
- Distinctive: line 123
For Linear/Jira: Use the appropriate MCP tool to list/search issues with the matching state and labels.
- Very specific: line 125
For YouTrack: Use search_issues with a YouTrack query, e.g.
- Distinctive: line 155
Intent: Create new issues in the external service for each backlog item.
- Distinctive: line 158
Create an issue in the external service:
- Very specific: line 178
Add Plan: {plan_path} to each issue's description, next to the spec link (replace an earlier one)
- Distinctive: line 185
Add a comment: "Started"
- Very specific: line 186
Update docs/backlog-index.md status column
- Distinctive: line 193
Add comment: "Implementation complete, pending PR"
- Distinctive: line 201
Add comment with PR reference: "Completed — PR #{number}" or "Completed on main"
- Very specific: line 203
Update the parent document: if all stories for the feature are done, set the feature spec to status: done.
- Distinctive: line 214
Update the issue status in the external service.
- Distinctive: line 220
Create or update a parent issue/epic in the external service:
- Very specific: line 223
If the service supports parent-child relationships (Linear, Jira, YouTrack), set this as the parent of all story issues.
- Very specific: line 244
If the team reordered issues in Linear/Jira/YouTrack, that's the new priority
- Very specific: line 250
MCP connector not available: STOP and report: "The {service} connector is not available.
- Distinctive: line 251
Authentication failure: STOP and report: "Authentication failed for {service}.
- Distinctive: line 255
Never fall back to local silently: If the external service is unavailable, tell the user explicitly.
- Very specific: line 264
Run a one-time sync: for each item in docs/backlog.md, create an issue in the external service
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Backlog External — Generic External Service Implementation
implements: backlog
stack: externalThis skill implements the backlog interface using an external project management service (GitHub Issues, Linear, Jira, YouTrack, etc.). It reads the service type and state mappings from stack.md.
Design principle: Local is the source of truth for documents (specs, plans, contracts). The external service is the source of truth for item status and priority ordering. This skill bridges both.
Prerequisites
- An MCP connector for the configured service (Linear, Jira, YouTrack) OR the
ghCLI for GitHub Issues - The
backlog_configsection instack.mdproperly configured
Configuration in stack.md
backlog: external
backlog_config:
service: github-issues # github-issues | linear | jira | youtrack
project: my-org/my-repo # GitHub: owner/repo, Linear: project slug, Jira: project key, YouTrack: project short name (e.g. WEB)
states:
ready: "Backlog" # Service-specific state name for each workflow status
doing: "In Progress"
implemented: "In Review"
done: "Done"
labels:
feature_prefix: "feat:" # Label prefix for feature grouping (e.g., "feat:FEAT-005")
service_prefix: "svc:" # Label prefix for service tagging (e.g., "svc:be")
group_prefix: "group:" # Label prefix for story groups
issue_type: "Story" # Jira/YouTrack: issue type for stories (YouTrack: the "Type" field value)YouTrack example (states are the values of the project's State field; project is the short name that prefixes issue IDs like WEB-132):
backlog: external
backlog_config:
service: youtrack
project: WEB # YouTrack project short name — issues are WEB-1, WEB-2, ...
states:
ready: "Open"
doing: "In Progress"
implemented: "In Review"
done: "Done"
labels: # YouTrack has no "labels" — these prefixes become tags via manage_issue_tags
feature_prefix: "feat:"
service_prefix: "svc:"
group_prefix: "group:"
issue_type: "Story" # Value of the YouTrack "Type" fieldYouTrack requires a connected MCP server. JetBrains ships a built-in Remote MCP Server at
https://{your-instance}.youtrack.cloud/mcp(YouTrack 2025.3+, Cloud or Server). Add it as an MCP connector (OAuth or a permanent token,Authorization: Bearer <token>). Its predefined tools run under your account permissions.
How It Works — The Hybrid Model
External service manages: Item status, priority ordering, team comments/feedback, assignment, labels, sprint planning.
Local files manage: Document references (spec paths, plan paths).
The bridge: Each backlog item has an external issue ID AND a local story ID. The external issue links to the local spec file. Local operations update the external service after each status change.
Operation Implementations
General Approach
For every operation, the AI:
- Reads
stack.mdto get thebacklog_config - Determines which tools to use based on
service:- github-issues: Use
ghCLI commands (already available, no MCP needed) - linear: Use the Linear MCP connector tools
- jira: Use the Jira MCP connector tools
- youtrack: Use the YouTrack MCP connector tools
- github-issues: Use
- Translates the operation's intent into the appropriate tool call
- The skill describes WHAT to do, not WHICH specific tool to call — the AI maps to available tools at runtime
YouTrack tool map (JetBrains predefined MCP tools):
| Operation intent | YouTrack MCP tool |
| Search / list issues | search_issues (YouTrack query, e.g. project: WEB State: {Open} tag: feat:FEAT-005) |
| Read one issue | get_issue |
| Discover custom field values | get_issue_fields_schema |
| Create issue | create_issue (set project short name, summary, State, Type fields) |
| Update fields / change state | update_issue (set the State field to the mapped value) |
| Assign | change_issue_assignee |
| Add tags (feature/service/group) | manage_issue_tags |
| Read / add comments | get_issue_comments / add_issue_comment |
| Link epic ↔ story | link_issues (use the subtask link type) |
| Log time | log_work |
| Find project | find_projects / get_project |
YouTrack specifics to respect:
- State is a custom field, not a separate status API — change it with
update_issueby setting theStatefield to the value configured inbacklog_config.states. Callget_issue_fields_schemafirst if unsure of the exact field/value names. - YouTrack has tags, not labels — the
labels.*_prefixvalues become tag names applied viamanage_issue_tags. - The external issue ID is the readable ID (e.g.
WEB-132); use it indocs/backlog-index.md.
list(filter)
Intent: Get items from the external service matching the filter.
- Query the external service for issues in the configured project
- Filter by state mapping (e.g.,
status: ready→ query for issues in the state configured asbacklog_config.states.ready) - Filter by labels for feature, service, and group (using configured prefixes)
- Parse results into the standard item format: id, title, status, feature, group, order, service
For GitHub Issues:
gh issue list --repo {project} --state open --label "{label}" --json number,title,state,labelsFor Linear/Jira: Use the appropriate MCP tool to list/search issues with the matching state and labels.
For YouTrack: Use search_issues with a YouTrack query, e.g. project: {project} State: {states.ready} tag: {feature_prefix}{FEAT-ID}.
Priority ordering: The external service's ordering is authoritative. Items are returned in the order the service provides them.
get(id)
Intent: Get a single item with full metadata.
- Fetch the issue from the external service by ID
- Return metadata: title, status, labels, comments, spec path from labels/description
get_feature_progress(feature_id)
Intent: Count items per status for a feature.
- Query the external service for all issues with the feature label (e.g.,
feat:FEAT-005) - Count by state mapping
- Return counts
next_id()
Intent: Generate the next story ID.
- Query the external service for all issues with story ID labels (or scan issue titles for
S-NNNpattern) - Return
S-{max+1}
create(items)
Intent: Create new issues in the external service for each backlog item.
For each item:
- Create an issue in the external service:
- Title:
{id}: {title} - State: configured
readystate - Labels: feature label, service label, group label, order label
- Description/body: Link to the local spec file —
Spec: {spec_path}
- Title:
- Record the external issue ID mapping (add it as a tag in the description or use labels)
Do NOT create local docs/backlog.md entries. The external service IS the backlog. However, maintain a lightweight local index file at docs/backlog-index.md that maps story IDs to external issue IDs for quick reference:
# Backlog Index
| Story | External | Feature | Status |
|---|---|---|---|
| S-010 | #42 | FEAT-005 | ready |
| S-011 | #43 | FEAT-005 | ready |link_plan(ids, plan_path)
Intent: Record which implementation plan covers a set of items.
- Add
Plan: {plan_path}to each issue's description, next to the spec link (replace an earlier one)
start(id)
Intent: Move an item from ready to doing.
- Move the issue to the
doingstate in the external service - Add a comment: "Started"
- Update
docs/backlog-index.mdstatus column
mark_implemented(id)
Intent: Mark an item as code-complete, pending PR.
- Move the issue to the
implementedstate in the external service - Add comment: "Implementation complete, pending PR"
- Update local index
complete(id, reference)
Intent: Mark an item as done.
- Move the issue to the
donestate in the external service - Add comment with PR reference: "Completed — PR #{number}" or "Completed on main"
- Update local index
- Update the parent document: if all stories for the feature are done, set the feature spec to
status: done; for a bug item, set the bug report tostatus: fixed - Close the plan: if every item linked to the same plan is done, set that plan to
status: done(no plan link: close the spec's plan together with the spec)
Sync Operations
These are ACTIVE for external backends:
push_status(id, status, reference)
Update the issue status in the external service. Map the workflow status to the configured state name.
Already called inline by start(), complete(), etc. — this operation exists for cases where the status needs to be updated separately (e.g., fixing a stale status).
push_summary(feature_id, title, spec_link)
Create or update a parent issue/epic in the external service:
- Title:
{feature_id}: {title} - Description: Link to the local spec file
- If the service supports parent-child relationships (Linear, Jira, YouTrack), set this as the parent of all story issues. For YouTrack, create the epic with
create_issueand connect each story withlink_issuesusing thesubtasklink type.
push_stories(feature_id, items)
Same as create(items) but specifically for syncing after /virtual-team:feature creates stories.
pull_comments(id)
Retrieve comments from the external issue. Present them to the AI as context:
Team feedback on {id}:
- [{author}] ({date}): {comment text}
- [{author}] ({date}): {comment text}Called by /virtual-team:implement before starting a story — ensures the AI sees any QA feedback, PO notes, or team discussion.
pull_priorities()
Retrieve the current issue ordering from the external service. This overrides any local ordering:
- The external service's priority/position is authoritative
- If the team reordered issues in Linear/Jira/YouTrack, that's the new priority
Error Handling
- MCP connector not available: STOP and report: "The {service} connector is not available. Install it or switch to
backlog: localin stack.md." - Authentication failure: STOP and report: "Authentication failed for {service}. Re-authenticate the connector."
- Issue not found: Report and suggest creating it: "Issue {id} not found in {service}. Run
/virtual-team:contracts syncor create it manually." - Rate limit: Report and suggest waiting or switching to local temporarily.
Never fall back to local silently. If the external service is unavailable, tell the user explicitly. Using local as a silent fallback would cause the two sources to diverge.
Migration: Local → External
To migrate from backlog: local to backlog: external:
- Configure
backlog_configinstack.md - Run a one-time sync: for each item in
docs/backlog.md, create an issue in the external service - Generate
docs/backlog-index.mdfrom the sync - Optionally keep
docs/backlog.mdas a read-only archive (rename todocs/backlog-archive.md) - Change
stack.mdtobacklog: external
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

