dep-bump issue lifecycle uses a title marker, not a label

Open
  • Is something wrong?
#7 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
30/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
github, shell
Domain
tooling

Research direction

Start in skills/dep-bump-scanner/scripts/dep-bump-scanner.sh around line 480 (the gh issue create call) and line 504 (the lifecycle search), then check the matching search at skills/dep-bump-fixer/scripts/dep-bump-fixer.sh line 163. Compare with the link-health skill's labels and the Requirements blocks in both SKILL.md files. The issue needs a maintainer decision between option 1 (add a label) and option 2 (document the title marker) before any edit, so confirm that decision first.

Written by the indexing model from the issue text.

Description

Re-filed from rossoctl/agent-skills#45 (originally opened by @rubambiza) after RepoMan was cloned into this repo. Original discussion/history lives there.

Still applies in repoman: skills/dep-bump-fixer/scripts/dep-bump-fixer.sh:163 and skills/dep-bump-scanner/scripts/dep-bump-scanner.sh:504 still use [dep-bump] in:title. Needs a decision between option 1 and 2.

Summary

Follow-up from the Requirements-blocks review (#41). The dep-bump scanner and fixer track their issues by a title-string convention rather than a label, which leaves labels_applied: [] accurate but out of step with how link-health works and unusable by the Phase 3 capability check.

What the code does today

  • The scanner creates tracking issues with no label: 
    skills/dep-bump-scanner/scripts/dep-bump-scanner.sh:480
  gh issue create --repo ... --title "$issue_title" --body "$issue_body"
  • The lifecycle (find-to-close, dedupe) is driven by a title marker, not a label: 
    dep-bump-fixer.sh:163    gh issue list ... --search "[dep-bump] in:title"
dep-bump-scanner.sh:504  gh issue list ... --search "[dep-bump] in:title #$fix_pr_number in:body"

So labels_required: [] and labels_applied: [] in both SKILL.md files are literally correct, but only because the design routes around labels entirely.

Why it matters

  • Inconsistent with the link-health pair, which emits labels (kind/bug, broken-link/*) and declares them in labels_applied. A reader comparing the two skills cannot tell that dep-bump's empty block is a design choice rather than an omission.
  • The Phase 3 capability check (rossoctl/automation#74/#91) gates on declared labels. Because dep-bump declares none, there is nothing for the check to verify, and the title-marker convention is invisible to it.
  • Title-string search is more fragile than a label filter (title edits, i18n, marker collisions).

Options

  1. Apply a dep-bump (or dependency) label on gh issue create, declare it in the scanner's labels_applied and the fixer's labels_required, and switch the gh issue list lifecycle queries from [dep-bump] in:title to --label dep-bump. Matches link-health.
  2. Keep the title marker and add a short note to both SKILL.md Requirements blocks explaining that the empty labels_applied/labels_required is deliberate (title-driven lifecycle), so the empty block is not read as an oversight.

Option 1 is the more consistent long-term fix; option 2 is the cheap documentation-only reconciliation. Flagging for a decision.

Assisted-By: Claude Code

Dominant language
Shell
Stars
7
Forks
1
Avg merge
5d 10h
Merged PRs (30d)
2

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rossoctl/repoman

All issues in rossoctl/repoman

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.