Agent skill

Cl Find Related Tickets

by closedloop-ai in closedloop-ai/claude-plugins

Inspect the relevant code first to map the implementation blast area, then find ClosedLoop issue tickets related to a product area, behavior, requirement, incident, ticket, or pull request and give…

Apache-2.0Auto-check passedDevelopment

Install Cl Find Related Tickets

skills CLI
$ npx skills add closedloop-ai/claude-plugins --skill cl-find-related-tickets -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install closedloop-ai/claude-plugins cl-find-related-tickets --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/closedloop-ai/claude-plugins.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/vibe/skills/cl-find-related-tickets .claude/skills/cl-find-related-tickets && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
cl-find-related-tickets
GitHub stars
122
Token cost
~3.1k tokens
SKILL.md length
1,418 words
Files
2
Skills in repo
44
Repo updated
First seen
Licence
Apache-2.0

At a glance

Inspect the relevant code first to map the implementation blast area, then find ClosedLoop issue tickets related to a product area, behavior, requirement, incident, ticket, or pull request and give…

  • Works in 6 steps: Resolve the implementation context → Inspect code and map the blast area → Build the concern map → …
  • Finding potentially conflicting
  • SKILL.md covers Inputs, Safety, Search Workflow and Output, plus 1 more section
  • Calls codex and rg

What it does

Cl Find Related Tickets is an agent skill from closedloop-ai/claude-plugins. Inspect the relevant code first to map the implementation blast area, then find ClosedLoop issue tickets related to a product area, behavior, requirement, incident, ticket, or pull request and give a brief evidence-based reason for each match. Use when auditing scope, finding potentially conflicting or missing work across projects and assignees, checking whether a freeze covers every relevant ticket, comparing discoveries with an approved ticket set, or looking for direct changes, dependencies, shared contracts…

Its SKILL.md is about 3.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files (for example `agents/openai.yaml`).

It sits in Development, covering Pull requests. The repository describes itself as: Open-source Claude Code plugins for multi-agent software delivery. Plan-first SDLC workflow, code review, LLM quality judges, and self-learning — grounded in your codebase… The licence is Apache-2.0.

When your agent uses it

  • Finding potentially conflicting
  • Missing work across projects and assignees
  • Checking whether a freeze covers every relevant ticket
  • Comparing discoveries with an approved ticket set

Example prompts

  • “/cl-find-related-tickets”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Resolve the implementation context
  2. Inspect code and map the blast area
  3. Build the concern map
  4. Collect candidates broadly
  5. Verify each plausible candidate
  6. Check coverage

What it can do on your machine

Read from SKILL.md and the folder at commit 76594a3. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • codex
    • rg

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Cl Find Related Tickets loads about 3.1k tokens when it runs. Until then it costs about 172 tokens; SKILL.md has 1,418 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~172
When it runs · the whole SKILL.md, loaded when a task matches
~3.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from closedloop-ai/claude-plugins at commit 76594a3, republished under its Apache-2.0 licence (© closedloop-ai). 1,418 words, ~3,062 tokens.

Download SKILL.mdSave it as .claude/skills/cl-find-related-tickets/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
cl-find-related-tickets
description
Inspect the relevant code first to map the implementation blast area, then find ClosedLoop issue tickets related to a product area, behavior, requirement, incident, ticket, or pull request and give a brief evidence-based reason for each match. Use when auditing scope, finding potentially conflicting or missing work across projects and assignees, checking whether a freeze covers every relevant ticket, comparing discoveries with an approved ticket set, or looking for direct changes, dependencies, shared contracts, tests, and open-PR collisions. This is a read-only discovery skill and does not update tickets, comments, statuses, loops, code, or pull requests.

Understand the code blast area before searching ClosedLoop. Then find relevant work without treating project, assignee, title, or age as a reliable scope boundary. Search broadly, verify narrowly, and return a concise report.

Inputs

Extract these from the request when present:

  • Area of concern: required. Accept product behavior, page, route, component, service, schema, API, workflow, ticket, PR, or incident.
  • Repository or local checkout: optional input, but required to claim a code-grounded exhaustive result for an implementation concern. Resolve it from anchor metadata when omitted.
  • Anchor artifacts: optional ticket, PRD, plan, PR, branch, file, or route.
  • Known ticket set: optional. When supplied, report only newly discovered tickets unless the user requests the full inventory.
  • Cutoff: optional. Use it to distinguish tickets that existed before and after a freeze or decision.
  • Assignee or project filters: optional. Treat them as requested restrictions only; otherwise search all assignees and projects.
  • Terminal-status inclusion: optional. Exclude completed and canceled issues by default.

Ask one concise clarification when the implementation repository or area cannot be resolved from the request, anchor metadata, or available checkouts. Do not replace the required code pass with guessed search terms.

Safety

Remain read-only.

  • Do not create or update documents, comments, relationships, statuses, goals, loops, branches, code, or PRs.
  • Do not invoke execution, split, or blocker-routing workflows.
  • Do not write workflow repo memory unless the user separately requests persistence.
  • Never hardcode a ClosedLoop MCP tool prefix. The prefix depends on the user's local MCP connection name.
  • Follow cl-policy host-capability rules when discovering ClosedLoop tools. Use tool_search only when the current host explicitly supports dynamic calls. In Codex CLI TUI, use already exposed MCP tools or the documented codex mcp, CLI/source, or authenticated API fallback. The TUI must not call tool_search merely to satisfy the graph requirement.
  • Discover and use the read-only closedloop-graph MCP as the primary indexed discovery surface for ticket/PRD/plan lineage, dependencies, semantic matches, duplicates, PR overlap, and codebase intelligence including symbols, files, ownership boundaries, dependencies, call/data paths, co-change history, tests, and blast radius. Treat graph results as candidates only; re-fetch every reported ticket and material relationship from live ClosedLoop and verify code/PR claims against current repository and GitHub state. Use graph code intelligence to establish the implementation blast area, not only to search the ticket corpus. Never emit a dynamic graph tool call from Codex CLI TUI.
  • If the available connection cannot support an organization-wide search, state the uncovered boundary and do not call the result exhaustive.

Search Workflow

1. Resolve the implementation context

Before searching for related tickets:

  1. Read anchor ticket or PR metadata only far enough to establish the intended behavior, repository, branch, and likely entry point.
  2. Locate the current repository checkout. Read applicable AGENTS.md files and current repository documentation for the surface.
  3. If the repository cannot be accessed, ask for its identity or path. If the user wants a partial search anyway, label it not code-grounded and do not call it exhaustive.
  4. If the concern genuinely has no implementation surface, record Code blast-area pass: not applicable with the reason.
2. Inspect code and map the blast area

Complete this read-only code pass before running ClosedLoop candidate searches:

  1. Find entry points with rg --files and rg: routes, page registrations, exported symbols, UI labels, handlers, jobs, events, schemas, and API names.
  2. Read the implementation, not just filenames. Trace imports, callers, consumers, adapters, persistence, serialization, and transport boundaries in both directions.
  3. Inspect tests, fixtures, migrations, feature flags, and guardrails that encode the current behavior.
  4. Use targeted Git history and active PR metadata when they reveal renamed surfaces, recent ownership changes, or concurrent implementation.
  5. Separate the result into:
    • Direct mutation surfaces likely to change.
    • Upstream and downstream dependency surfaces that could enable, block, or break the change.
    • Tests and guardrails that could preserve conflicting behavior.
    • Legacy names and product vocabulary useful for ticket search.
  6. Record concrete path, symbol, route, contract, and behavior evidence. Do not infer a blast area from directory proximity or shared vocabulary alone.

Continue until the relevant control and data flow is understood well enough to explain why a change in each included surface can affect the concern.

3. Build the concern map

Derive a compact query set from the verified code blast area, the request, and anchor artifacts:

  1. Literal product names, labels, slugs, and quoted phrases.
  2. Verified routes, symbols, components, packages, files, services, tables, schemas, events, and API names.
  3. Synonyms, former names, abbreviations, and neighboring product terminology.
  4. Verified upstream inputs and downstream consumers.
  5. Behavioral contracts, tests, guardrails, migrations, and feature flags identified during the code pass.

Do not rely on an anchor title or product vocabulary alone. Every technical query group should trace back to code evidence.

Show full SKILL.md (630 more words)Show less
4. Collect candidates broadly

Default to organization-wide, all-project, all-assignee issue discovery.

Begin with closedloop-graph searches and bounded expansions from anchors and verified code identifiers. Continue until one expansion over material candidate nodes yields no new relevant ticket, dependency, duplicate, or PR collision, then use live ClosedLoop inventory/search to verify coverage and current state. When a caller supplies a locked manifest or explicit bounded scope, honor that boundary instead of reopening organization-wide inventory.

  1. Paginate the issue inventory when list tooling permits. Keep TRIAGE, BACKLOG, TODO, IN_PROGRESS, IN_REVIEW, and BLOCKED; exclude DONE and CANCELED.
  2. Run multiple full-text searches over the concern map. Search documents and, when useful, comments and pull requests.
  3. Search exact identifiers and quoted phrases separately from broader conceptual terms.
  4. Expand from anchor artifacts through PRODUCES, BLOCKS, and RELATES_TO relationships in both directions.
  5. Search old and current projects. A weekly project boundary or a different assignee is not evidence of irrelevance.
  6. Deduplicate candidates by issue slug.

Use PRDs and plans as evidence sources and expansion nodes. Report them as results only when the user explicitly asks for non-ticket artifacts.

5. Verify each plausible candidate

Fetch full details only for plausible candidates. Inspect:

  • Current title, body, acceptance criteria, status, assignee, project, repository snapshot, and update time.
  • Comments that add, narrow, supersede, or unblock scope.
  • Parent, child, blocking, and related artifact links.
  • Linked or mentioned PR state and implementation surface when available.
  • The previously mapped code blast area, plus targeted Git history or GitHub evidence when the ticket language is insufficient to prove a collision.

Resolve each result's project to its user-facing PRO-* slug. When ticket metadata supplies only a project UUID, use the project read capability to obtain the slug. Never substitute a project UUID or project name for the slug.

Resolve and report each ticket's current assignee display name. When no assignee exists, use Unassigned. Never display an internal user UUID in place of the assignee's name.

Classify a ticket with one primary relation:

  • DIRECT_SURFACE: changes the area itself.
  • SHARED_CONTRACT: changes data, schema, API, or behavior consumed by the area.
  • DEPENDENCY: explicitly or functionally blocks, enables, or sequences the area.
  • TEST_GUARDRAIL: tests or guardrails preserve behavior that the concern would change.
  • OPEN_PR_COLLISION: active implementation overlaps the same code or product surface.
  • DUPLICATE_OR_SUPERSEDED: describes substantially the same outcome or obsolete competing scope.

A title keyword is not evidence. For an indirect match, identify the concrete causal path. Reject generic vocabulary matches, unrelated repositories, contextual mentions without implementation impact, and stale historical work unless terminal tickets were requested.

If evidence is suggestive but incomplete, place the ticket under Needs verification; do not present it as confirmed.

6. Check coverage

Before reporting:

  1. Confirm the code pass covered direct mutation, upstream/downstream dependency, and test/guardrail surfaces.
  2. Confirm pagination or continuation cursors were exhausted for every inventory/search path used.
  3. Confirm all concern-map query groups were searched.
  4. Confirm direct links from every anchor and confirmed candidate were inspected when link tooling is available.
  5. Compare against the known ticket set exactly. Do not repeat known tickets in a new-findings report.
  6. Confirm every reported ticket is grouped under a resolved PRO-* project slug.
  7. Confirm every reported ticket includes its current assignee display name or Unassigned.
  8. Note any inaccessible code, comments, documents, repositories, or PR data that limit confidence.

Output

Keep explanations brief and self-contained. Use returned webUrl values; never construct ClosedLoop URLs.

markdown
**Coverage**
Searched <scope>; statuses <statuses>; repository <repo or all>; cutoff <date or none>. <Any limitation.>

**Code blast area**
Direct: <concise paths/symbols/behaviors>. Dependencies: <concise upstream/downstream surfaces>. Guardrails: <concise tests/flags/contracts>.

**New related tickets**

### PRO-123
| Ticket | Status | Assignee | Relation | Why it is related |
|---|---|---|---|---|
| [FEA-123](webUrl) | TODO | Name | DIRECT_SURFACE | Changes the branch-detail comments rail whose state-preservation behavior is in scope. |

Needs verification:

| Ticket | Status | Assignee | Why uncertain |
|---|---|---|---|
| [FEA-456](webUrl) | TRIAGE | Name | Mentions the same API, but the ticket does not identify which consumer is changing. |

### PRO-456
| Ticket | Status | Assignee | Relation | Why it is related |
|---|---|---|---|---|
| [FEA-789](webUrl) | BLOCKED | Name | DEPENDENCY | Owns the shared branch-event contract consumed by the affected page. |

Group both confirmed and uncertain tickets beneath their respective project slug. Include the current assignee for every ticket, including uncertain matches; use Unassigned when applicable. Omit empty project subsections and empty report sections. If a known set was supplied and no additional matches are verified, say No new related tickets found. Do not include the previously approved list merely for completeness.

Invocation Examples

text
$cl-find-related-tickets Branches list and branch details work in symphony-alpha. Known set: FEA-100, FEA-101. Report only newly found nonterminal tickets.
text
$cl-find-related-tickets Find all active tickets related to unanchored comments created through MCP or API, across every project and assignee.

© closedloop-ai, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file in plugins/vibe/skills/cl-find-related-tickets of closedloop-ai/claude-plugins.

  • SKILL.md
  • agents/openai.yaml

Open the folder on GitHubat commit 76594a3

Compare with similar skills

Cl Find Related Tickets next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Cl Find Related Tickets compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Cl Find Related Tickets this skillclosedloop-ai/claude-plugins122—~3.1kAutomated safety check: PassApache-2.0
Finishing a Development Branchobra/superpowers297k5 repos~1.9kAutomated safety check: PassMIT
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Check PRonyx-dot-app/onyx32k2 repos~2.3kAutomated safety check: PassMIT
PR Design DocOpenHands/OpenHands91k—~2.4kAutomated safety check: PassMIT
WooCommerce Code Reviewwoocommerce/woocommerce11k3 repos~1.1kAutomated safety check: PassCustom licence

Similar skills

  • Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.

    297k GitHub starsUsed in 5 repos~1.9k tokens
    DevelopmentAuto-check passed
  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed
  • Check PR

    onyx-dot-app/onyx

    Checks a GitHub, GitLab, or Perforce (p4) pull request (or merge request, or shelved changelist) for unresolved review comments, failing status checks, and incomplete PR descriptions.

    32k GitHub starsUsed in 2 repos~2.3k tokens
    DevelopmentAuto-check passed
  • PR Design Doc

    OpenHands/OpenHands

    For a non-trivial pull request, write a self-contained HTML design doc under the temporary .pr/ directory and link a visibility-appropriate preview in the PR description, so maintainers grasp the…

    91k GitHub stars~2.4k tokensUpdated today
    DevelopmentAuto-check passed
  • WooCommerce Code Review

    woocommerce/woocommerce

    Reviews WooCommerce code changes against the project's standards, flagging backend PHP architecture, naming, documentation, data integrity and testing violations.

    11k GitHub starsUsed in 3 repos~1.1k tokens
    DevelopmentAuto-check passed
  • Record PR Demo

    payloadcms/payload

    A skill your agent uses when a Payload pull request needs a concise visual walkthrough for reviewers.

    45k GitHub stars~1k tokensUpdated yesterday
    DevelopmentAuto-check passed

More from closedloop-ai/claude-plugins

All 44 skills in this repo
  • Codex Review

    closedloop-ai/claude-plugins

    Run Codex to review a plan file and return structured feedback with a verdict.

    122 GitHub stars~1.4k tokensUpdated today
    Auto-check: notes
  • Critic Cache

    closedloop-ai/claude-plugins

    Check if critic reviews are still valid before re-running Phase 2.5 critics.

    122 GitHub stars~528 tokensUpdated today
    Auto-check: notes
  • Cross Repo Cache

    closedloop-ai/claude-plugins

    Check if cross-repo coordinator results can be reused, avoiding redundant Sonnet agent launches.

    122 GitHub stars~683 tokensUpdated today
    Auto-check: notes
  • Eval Cache

    closedloop-ai/claude-plugins

    Check for a cached plan-evaluation.json result before launching the plan-evaluator agent.

    122 GitHub stars~516 tokensUpdated today
    Auto-check: notes
  • Find Plugin File

    closedloop-ai/claude-plugins

    This skill should be used when needing to locate files within the Claude Code plugins cache directory (~/.claude/plugins/cache).

    122 GitHub stars~812 tokensUpdated today
    Auto-check passed
  • Plan Validate

    closedloop-ai/claude-plugins

    Deterministic plan.json validation via Python script, replacing most plan-validator agent calls.

    122 GitHub stars~1.2k tokensUpdated today
    Auto-check: notes

Categories

Questions about Cl Find Related Tickets

What does Cl Find Related Tickets do?

Inspect the relevant code first to map the implementation blast area, then find ClosedLoop issue tickets related to a product area, behavior, requirement, incident, ticket, or pull request and give…. Cl Find Related Tickets is an agent skill from closedloop-ai/claude-plugins. Inspect the relevant code first to map the implementation blast area, then find ClosedLoop issue tickets related to a product area, behavior, requirement, incident, ticket, or pull request and give a brief evidence-based reason for each match.

When should I use Cl Find Related Tickets?

Cl Find Related Tickets fits situations like: finding potentially conflicting; missing work across projects and assignees; checking whether a freeze covers every relevant ticket; comparing discoveries with an approved ticket set.

How do I install Cl Find Related Tickets in Claude Code?

Run `npx skills add closedloop-ai/claude-plugins --skill cl-find-related-tickets -a claude-code`. Or copy the skill folder (plugins/vibe/skills/cl-find-related-tickets in closedloop-ai/claude-plugins) into .claude/skills/cl-find-related-tickets in your project. Claude Code loads it when a task matches its description.

How do I install Cl Find Related Tickets in Codex?

Run `npx skills add closedloop-ai/claude-plugins --skill cl-find-related-tickets -a codex`. Or copy the skill folder (plugins/vibe/skills/cl-find-related-tickets in closedloop-ai/claude-plugins) into .agents/skills/cl-find-related-tickets in your project. Codex loads it when a task matches its description.

Can I use Cl Find Related Tickets in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add closedloop-ai/claude-plugins --skill cl-find-related-tickets -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/cl-find-related-tickets, .gemini/skills/cl-find-related-tickets, .github/skills/cl-find-related-tickets and .opencode/skills/cl-find-related-tickets in your project.

What does Cl Find Related Tickets need to run?

Going by SKILL.md and its folder, Cl Find Related Tickets needs the command-line tools its instructions call (codex and rg).

Does Cl Find Related Tickets access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Cl Find Related Tickets safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Cl Find Related Tickets use?

Cl Find Related Tickets is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Cl Find Related Tickets use?

About 3.1k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Cl Find Related Tickets?

Skills that share tags, products or a category with Cl Find Related Tickets: Finishing a Development Branch (obra/superpowers, 297k stars), PR Babysitter (openinterpreter/openinterpreter, 69k stars), Check PR (onyx-dot-app/onyx, 32k stars) and PR Design Doc (OpenHands/OpenHands, 91k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Cl Find Related Tickets?

closedloop-ai (a GitHub organization) maintains it in closedloop-ai/claude-plugins, which has 122 GitHub stars. The repository holds 44 skills in this directory. The repository was last updated on October 10, 2026.

Source: closedloop-ai/claude-plugins on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.