Token导航 LogoToken导航TokenDH.com
研究检索敏感数据github未标认证来源可访问许可证需确认审计通过

escalate-issues升级问题

Agent Skill

用于围绕 GitHub 仓库、Issue、Pull Request、分支、提交和代码协作流程提供辅助能力。它适合让 Agent 查询项目状态、整理变更、辅助创建或检查协作事项,并把仓库中的信息转成可执行的下一步。使用时需要区分只读查询和写入操作;涉及创建 PR、修改 Issue、推送分支或访问私有仓库时,应确认 token 权限、目标仓库范围和用户授权。

总安装

451

周安装

19

GitHub Stars

12

下载量

158
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:escalate-issues(升级问题)
来源仓库:https://github.com/pjt222/development-guides
仓库路径:skills/escalate-issues
安装命令:
npx skills add https://github.com/pjt222/development-guides --skill escalate-issues
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/pjt222/development-guides --skill escalate-issues

简介

escalate-issues 在自动化清理遇到复杂问题时介入,提供人工决策支持。

  • 适用于不确定代码删除安全性、需领域专家判断或涉及安全漏洞的情形。
  • 输入清晰的问题描述与上下文,输出风险评估与下一步行动建议。
  • 不涉及简单修复,仅在自动清理风险高或不足时使用,避免误操作。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

escalate-issues

When to Use

Use this skill when a maintenance task encounters problems beyond automated cleanup:

  • Uncertain whether code is safe to delete
  • Configuration changes require domain expertise (security, performance, architecture)
  • Breaking changes detected during cleanup
  • Complex refactoring needed (not just cleanup)
  • Security-sensitive findings (hardcoded secrets, vulnerabilities)

Do NOT use for simple issues with clear fixes. Escalate only when automated cleanup is risky or insufficient.

Inputs

ParameterTypeRequiredDescription
issue_descriptionstringYesClear description of the problem
severityenumYescritical, high, medium, low
context_filesarrayNoPaths to relevant files
specialiststringNoTarget agent (auto-route if not specified)
blockingbooleanNoWhether issue blocks further cleanup (default: false)

Procedure

Step 1: Assess Severity

Classify the issue using standard severity levels.

CRITICAL — Blocks production functionality:

  • Broken imports in actively used code
  • Security vulnerabilities (exposed secrets, SQL injection)
  • Data loss risk from cleanup operation
  • Production service outages

HIGH — Impacts maintainability or developer productivity:

  • Significant dead code bloat (>1000 lines)
  • Broken CI/CD pipelines
  • Major configuration drift between environments
  • Unreferenced modules that might be dynamically loaded

MEDIUM — Minor hygiene issues:

  • Unused helper functions (<100 lines)
  • Stale documentation requiring updates
  • Deprecated config files (no longer used but present)
  • Lint warnings in non-critical paths

LOW — Style inconsistencies:

  • Mixed indentation (works but inconsistent)
  • Trailing whitespace
  • Inconsistent naming (camelCase vs snake_case)
  • Minor formatting differences

Severity Decision Tree:

Does it break production? → CRITICAL
Does it block development? → HIGH
Does it impact code quality? → MEDIUM
Is it purely cosmetic? → LOW

Expected: Issue classified with clear severity label

On failure: If uncertain, default to HIGH and escalate to human for re-triage

Step 2: Document Finding

Capture all relevant context for the specialist to review.

Issue Report Template:

# Issue: [Brief Title]

**Severity**: CRITICAL | HIGH | MEDIUM | LOW
**Discovered During**: [Skill name, e.g., clean-codebase]
**Date**: YYYY-MM-DD
**Blocking**: Yes | No

## Description

Clear description of the problem in 2-3 sentences.

## Context

- **File(s)**: [List of affected files with line numbers]
- **Related**: [Related issues, commits, or previous attempts to fix]
- **Impact**: [What breaks if this isn't fixed, or what's wasted if not cleaned]

## Evidence

Code snippet or log excerpt showing the problem


## Attempted Fixes

- Tried X but failed because Y
- Considered Z but uncertain due to W

## Recommendation

- **Option 1**: [Safe conservative approach]
- **Option 2**: [More aggressive fix with risks]
- **Preferred**: [Which option to pursue and why]

## Specialist Routing

**Suggested Agent**: [agent-name] **Reason**: [Why this specialist is appropriate]

## References

- [Link to related documentation]
- [Link to similar past issues]

Expected: Issue documented with full context in ESCALATION_REPORTS/issue_YYYYMMDD_HHMM.md

On failure: (N/A — always document, even if incomplete)

Step 3: Determine Routing

Match issue type to appropriate specialist agent or human reviewer.

Routing Table:

Issue TypeSpecialistReason
Security vulnerabilitysecurity-analystSecurity expertise required
GxP compliance concerngxp-validatorRegulatory knowledge needed
Architecture decisionsenior-software-developerDesign pattern expertise
Config managementdevops-engineerInfrastructure knowledge
Dependency conflictsdevops-engineerPackage management expertise
Performance bottlenecksenior-data-scientistOptimization knowledge
Code style disputecode-reviewerStyle guide authority
Dead code uncertaintyr-developer (or lang-specific)Language-specific knowledge
Broken test unclearcode-reviewerTest design expertise
Documentation accuracysenior-researcherDomain knowledge required
License compatibilityauditorLegal/compliance expertise

Automatic Routing Logic:

def route_issue(severity, issue_type):
    if severity == "CRITICAL":
        # Always escalate to human for critical issues
        return "human"

    if "security" in issue_type or "secret" in issue_type:
        return "security-analyst"

    if "gxp" in issue_type or "compliance" in issue_type:
        return "gxp-validator"

    if "architecture" in issue_type or "design" in issue_type:
        return "senior-software-developer"

    if "config" in issue_type or "deployment" in issue_type:
        return "devops-engineer"

    # Default: code-reviewer for general code issues
    return "code-reviewer"

Expected: Issue routed to appropriate specialist with justification

On failure: If no clear specialist, escalate to human for manual routing

Step 4: Create Actionable Issue Report

Generate a formatted report suitable for the target audience (agent or human).

For Specialist Agents (structured format for MCP tools):

---
type: escalation
severity: high
from_agent: janitor
to_agent: security-analyst
blocking: false
---

# Security Concern: Hardcoded API Key in Config

**File**: config/production.yml:45
**Pattern**: API_KEY="sk_live_abc123..."

**Request**: Please review if this is a valid secret or a placeholder.
If valid, recommend secure credential management strategy.

**Context**: Discovered during config cleanup sweep.

For Human Reviewers (detailed markdown):

# Escalation Report: Uncertain Dead Code Removal

**From**: Janitor Agent
**Date**: 2026-02-16
**Severity**: HIGH

## Problem

File `src/legacy_payments.js` (450 lines) appears unused but contains
complex payment processing logic. Static analysis shows zero references,
but name suggests business-critical functionality.

## Why Escalated

- Uncertain if payment code is dynamically loaded at runtime
- Potential data loss risk if deleted incorrectly
- Requires domain knowledge to assess business impact

## Evidence

- No direct imports found
- Last modified 8 months ago
- Git history shows it was part of payment refactor

## Recommendation

Request human review before deletion. If confirmed dead:
1. Archive to archive/legacy/ directory
2. Document in ARCHIVE_LOG.md
3. Create ticket to verify payment flows still work

## Next Steps

Awaiting human confirmation before proceeding with cleanup.

Expected: Report formatted appropriately for target audience

On failure: (N/A — generate report in generic markdown if uncertain)

Step 5: Track Escalation Status

Maintain a log of all escalations to prevent duplicate reports.

# Escalation Log

| ID | Date | Severity | Issue | Specialist | Status |
|----|------|----------|-------|-----------|--------|
| ESC-001 | 2026-02-16 | CRITICAL | Broken prod import | human | Resolved |
| ESC-002 | 2026-02-16 | HIGH | Dead payment code | human | Pending |
| ESC-003 | 2026-02-16 | MEDIUM | Config drift | devops-engineer | In Progress |

Expected: ESCALATION_LOG.md updated with new entry

On failure: If log doesn't exist, create it

Step 6: Notify and Block (If Required)

If issue is blocking further maintenance, notify and pause cleanup.

Blocking Logic:

  • CRITICAL issues always block
  • HIGH issues block if in critical path
  • MEDIUM/LOW issues do not block

Notification:

⚠️ MAINTENANCE BLOCKED ⚠️

Issue ESC-002 (HIGH severity) requires human review before proceeding.

**Affected Operation**: clean-codebase (Step 5: Remove Dead Code)
**Reason**: Uncertain if src/legacy_payments.js is truly dead

**Action Required**: Review ESCALATION_REPORTS/ESC-002_2026-02-16.md

Once resolved, re-run maintenance from Step 5.

Expected: Maintenance paused; clear notification generated

On failure: If notification mechanism unavailable, document in report

Validation Checklist

After escalation:

  • Issue severity correctly assessed
  • Full context documented (files, evidence, attempts)
  • Appropriate specialist identified
  • Escalation report created in ESCALATION_REPORTS/
  • ESCALATION_LOG.md updated
  • Blocking status communicated if applicable
  • No sensitive information exposed in report

Common Pitfalls

  1. Over-Escalating: Escalating simple issues wastes specialist time. Only escalate when truly uncertain or risky.
  2. Under-Escalating: Deleting code "just to see if tests pass" without escalation can cause production outages.
  3. Insufficient Context: Escalating without evidence forces specialists to re-investigate. Include file paths, line numbers, error messages.
  4. Vague Descriptions: "Something's wrong with config" is not actionable. Be specific: "Config drift: dev uses API v1, prod uses v2".
  5. Not Tracking Status: Re-escalating already-reviewed issues. Check ESCALATION_LOG.md first.
  6. Exposing Secrets: Including actual API keys or passwords in escalation reports. Redact sensitive values.

Related Skills

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

34.87%
按下载量换算55

Claude

29.75%
按下载量换算47

Cursor

21.47%
按下载量换算34

Gemini CLI

9.15%
按下载量换算14

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills