Source profileQuality 55/100

affaan-m/ECC/docs/zh-CN/skills/project-flow-ops/SKILL.md

project-flow-ops

Review project-flow-ops's use cases, installation, workflow, and original source instructions.

Source repository stars
234,327
Declared platforms
0
Static risk flags
0
Last source update
2026-07-27
Source checked
2026-07-28

Decision brief

What it does—and where it fits

此技能将分散的 GitHub Issue、PR 和 Linear 任务整合为一条执行流程。

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/affaan-m/ECC --skill "docs/zh-CN/skills/project-flow-ops"
    Safe inspection promptEditorial

    Inspect the Agent Skill "project-flow-ops" from https://github.com/affaan-m/ECC/blob/4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38/docs/zh-CN/skills/project-flow-ops/SKILL.md at commit 4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      使用时机

      梳理开放的 PR 或 Issue 积压 决定哪些应放入 Linear,哪些应保留在 GitHub 中 将活跃的 GitHub 工作与内部执行通道关联 将 PR 分类为:合并、移植/重建、关闭或搁置 审查评论、CI 失败或过时 Issue 是否阻碍执行

      梳理开放的 PR 或 Issue 积压决定哪些应放入 Linear,哪些应保留在 GitHub 中将活跃的 GitHub 工作与内部执行通道关联
    2. 02

      运营模式

      GitHub 是公开和社区的真实来源 Linear 是内部执行的真实来源,用于活跃的已排期工作 并非每个 GitHub Issue 都需要创建 Linear Issue 仅当工作满足以下条件时,才创建或更新 Linear: 活跃 已委派 已排期 跨职能 重要到需要内部跟踪

      GitHub 是公开和社区的真实来源Linear 是内部执行的真实来源,用于活跃的已排期工作并非每个 GitHub Issue 都需要创建 Linear Issue
    3. 03

      核心工作流

      GitHub Issue 或 PR 状态 作者和分支状态 审查评论 CI 状态 关联的 Issue

      GitHub Issue 或 PR 状态作者和分支状态审查评论

    Permission review

    Static risk signals and limitations

    No configured static risk pattern was detected

    This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score55/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars234,327SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guidecatalog recordEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    affaan-m/ECC
    Skill path
    docs/zh-CN/skills/project-flow-ops/SKILL.md
    Commit
    4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38
    License
    MIT
    Collected
    2026-07-28
    Default branch
    main
    View the original SKILL.md

    项目流程运营

    此技能将分散的 GitHub Issue、PR 和 Linear 任务整合为一条执行流程。

    当问题在于协调而非编码时使用。

    使用时机

    • 梳理开放的 PR 或 Issue 积压
    • 决定哪些应放入 Linear,哪些应保留在 GitHub 中
    • 将活跃的 GitHub 工作与内部执行通道关联
    • 将 PR 分类为:合并、移植/重建、关闭或搁置
    • 审查评论、CI 失败或过时 Issue 是否阻碍执行

    运营模式

    • GitHub 是公开和社区的真实来源
    • Linear 是内部执行的真实来源,用于活跃的已排期工作
    • 并非每个 GitHub Issue 都需要创建 Linear Issue
    • 仅当工作满足以下条件时,才创建或更新 Linear:
      • 活跃
      • 已委派
      • 已排期
      • 跨职能
      • 重要到需要内部跟踪

    核心工作流

    1. 首先阅读公开信息

    收集:

    • GitHub Issue 或 PR 状态
    • 作者和分支状态
    • 审查评论
    • CI 状态
    • 关联的 Issue

    2. 对工作进行分类

    每个项目应归入以下状态之一:

    状态含义
    合并独立完整、符合策略、准备就绪
    移植/重建有用的想法,但应在 ECC 内部手动重新落地
    关闭方向错误、过时、不安全或重复
    搁置可能有用,但当前未排期

    3. 判断是否需要 Linear

    仅在以下情况下创建或更新 Linear:

    • 执行正在积极规划中
    • 涉及多个仓库或工作流
    • 工作需要内部所有权或排序
    • 该 Issue 是更大项目通道的一部分

    不要机械地镜像所有内容。

    4. 保持两个系统一致

    当工作活跃时:

    • GitHub Issue/PR 应说明公开进展
    • Linear 应在内部跟踪负责人、优先级和执行通道

    当工作完成或被拒绝时:

    • 将公开解决方案发布回 GitHub
    • 相应地标记 Linear 任务

    审查规则

    • 切勿仅凭标题、摘要或信任进行合并;需使用完整差异
    • 当外部来源的功能有价值但不独立完整时,应在 ECC 内部重建
    • CI 红色表示需分类并修复或阻止;不要假装其已可合并
    • 如果真正的阻碍是产品方向,请直接说明,而非隐藏在工具背后

    输出格式

    返回:

    公开状态
    - 议题 / 拉取请求状态
    - 持续集成 / 审查状态
    
    分类
    - 合并 / 移植重建 / 关闭 / 搁置
    - 一段理由说明
    
    线性操作
    - 创建 / 更新 / 无需线性项
    - 项目 / 泳道(如适用)
    
    下一步操作者行动
    - 确切的下一个步骤
    

    良好用例

    • "审查开放的 PR 积压,告诉我哪些应合并,哪些应重建"
    • "将 GitHub Issue 映射到我们的 ECC 1.x 和 ECC 2.0 项目通道"
    • "检查这是否需要创建 Linear Issue,还是应保留在 GitHub 中"

    Alternatives

    Compare before choosing