Token导航 LogoToken导航

Agent Skill · 前端设计

github-multi-project(GitHub multi project 前端)

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

github-multi-project 是前端设计类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证为 MIT,暂无第三方扫描结果,按安装量在前端设计类的 10,216 个 Skill 里排第 6,674。

总安装 470周安装 20GitHub Stars 127下载 165核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

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

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

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/anton-abyzov/specweave --skill github-multi-project

这个 Skill 是做什么的

前端设计类 Skill 关注页面结构、视觉规范和组件写法,输出通常是可运行的界面代码。

用于统一管理多个 GitHub 项目的界面组件。提供项目概览卡片和快速导航功能。支持跨项目搜索和状态聚合显示。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。适合同时维护多个关联项目的情况。界面布局可自定义调整。

github-multi-project 属于前端设计类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/github-multi-project

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/anton-abyzov/specweave --skill github-multi-pr…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

github-multi-project 怎么安装?

在终端执行 npx skills add https://github.com/anton-abyzov/specweave --skill github-multi-project。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

github-multi-project 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

github-multi-project 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

github-multi-project 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

github-multi-project 用的人多吗?

公开数据是累计安装 470 次,近一周安装 20 次,下载 165 次,GitHub 127 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

github-multi-project 安全吗?

没有查到第三方扫描结果,安全性无法从公开资料判断,安装前请自行审查源码、依赖和命令行为。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 3 个目录同时收录,说明这个 Skill 流传比较广。
  • 许可证明确为 MIT,商用和分发边界好判断。

先想清楚的地方

  • 没有第三方扫描结果,安全性只能靠自己读源码判断。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理前端设计类任务、又不想每次都手写提示词的人。

不太适合

  • 要求有安全扫描结论才肯安装的团队。
  • 需要厂商级技术支持和 SLA 的生产系统。

前端设计类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
frontend-design

前端设计 · Codex、Claude

8,823,360126,072只读MIT通过
vercel-composition-patterns

Vercel 组合模式 · Codex、Claude

3,858,81625,893需要联网MIT通过
vercel-react-native-skills

Vercel React native skills 前端 · Codex、Claude

2,468,66425,878只读MIT通过
adapt

adapt 搜索 · Codex、Claude

2,027,04023,125操作浏览器未明确通过
bolder

bolder 分析 · Codex、Claude

2,004,28823,130只读未明确通过
github-multi-project

GitHub multi project 前端 · 本页

470127需要联网MIT未收录

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

GitHub Multi-Project Management Skill

Expert skill for managing SpecWeave projects across multiple GitHub repositories.

Core Capabilities

1. Spec Organization

  • Organizes specs in .specweave/docs/internal/projects/{project-id}/ structure
  • Maps increments to specific projects/repos
  • Maintains traceability across repositories
  • Handles cross-project dependencies

2. Task Splitting

When a SpecWeave increment spans multiple repositories:

  • Analyzes tasks in tasks.md
  • Identifies which tasks belong to which repo
  • Creates repo-specific task lists
  • Maintains cross-repo coordination

3. Repository Architectures

Single Repository
my-app/
├── .specweave/
│   └── docs/internal/projects/default/
└── src/
Multi-Repository (Polyrepo)
my-app-frontend/
├── .git
└── src/

my-app-backend/
├── .git
└── src/

my-app-shared/
├── .git
└── src/
Parent Repository Approach (Recommended for Multi-Repo)
my-app-parent/              # Parent repo with .specweave
├── .specweave/
│   └── docs/internal/projects/
│       ├── frontend/
│       ├── backend/
│       └── shared/
└── services/               # Implementation repos
    ├── frontend/
    ├── backend/
    └── shared/
Monorepo
my-app/
├── .specweave/
│   └── docs/internal/projects/
│       ├── frontend/
│       ├── backend/
│       └── shared/
└── packages/
    ├── frontend/
    ├── backend/
    └── shared/

Task Splitting Examples

Example 1: E-commerce Platform

Increment: Add shopping cart functionality

Tasks split by repository:

Frontend (my-app-frontend):

  • T-001: Create CartItem component
  • T-002: Implement cart state management
  • T-003: Add cart UI with add/remove buttons

Backend (my-app-backend):

  • T-004: Create cart database schema
  • T-005: Implement cart API endpoints
  • T-006: Add cart validation logic

Shared (my-app-shared):

  • T-007: Define cart TypeScript types
  • T-008: Create cart utility functions

Example 2: Microservices Architecture

Increment: Implement user notifications

Tasks split by service:

User Service:

  • T-001: Add notification preferences to user profile
  • T-002: Create preference API endpoints

Notification Service:

  • T-003: Implement notification queue
  • T-004: Create email sender
  • T-005: Create push notification sender

Gateway Service:

  • T-006: Add notification routes
  • T-007: Implement rate limiting

Commands

Analyze Task Distribution

// Analyze which tasks belong to which repository
function analyzeTaskDistribution(tasks: Task[]): Map<string, Task[]> {
  const distribution = new Map();

  for (const task of tasks) {
    const repo = detectRepository(task);
    if (!distribution.has(repo)) {
      distribution.set(repo, []);
    }
    distribution.get(repo).push(task);
  }

  return distribution;
}

Create Repository-Specific Issues

// Create GitHub issues in each repository
async function createRepoSpecificIssues(
  increment: Increment,
  distribution: Map<string, Task[]>
) {
  for (const [repo, tasks] of distribution) {
    const issue = await createGitHubIssue({
      repo,
      title: `[${increment.id}] ${increment.name} - ${repo}`,
      body: formatTasksAsChecklist(tasks),
      labels: ['specweave', 'increment', repo]
    });

    console.log(`Created issue #${issue.number} in ${repo}`);
  }
}

Best Practices

1. Parent Repository Approach

Recommended for multi-repo projects:

  • Central.specweave/ folder in parent repo
  • Living docs sync to parent (single source of truth)
  • Implementation repos stay clean
  • Better for enterprise/multi-team projects

2. Task Naming Convention

T-{repo}-{number}: {description}
T-FE-001: Create user profile component
T-BE-001: Implement user API
T-SHARED-001: Define user types

3. Cross-Repository Dependencies

Mark dependencies clearly:

T-FE-002: Consume user API
  Dependencies: T-BE-001 (must complete first)

4. Spec Organization

.specweave/docs/internal/projects/
├── frontend/
│   └── specs/
│       ├── spec-001-user-interface.md
│       └── spec-002-cart-ui.md
├── backend/
│   └── specs/
│       ├── spec-001-api-design.md
│       └── spec-002-database.md
└── shared/
    └── specs/
        └── spec-001-types.md

Integration with GitHub Projects

Multi-Repo GitHub Project

Create a GitHub Project that spans multiple repositories:

  1. Create project at organization level
  2. Add issues from all repos
  3. Use project boards for cross-repo coordination
  4. Track overall increment progress

Repository-Specific Projects

Each repository can have its own project:

  • Frontend Project: UI tasks
  • Backend Project: API tasks
  • Shared Project: Common tasks

Automation

GitHub Actions Integration

# .github/workflows/specweave-sync.yml
name: SpecWeave Multi-Repo Sync

on:
  workflow_dispatch:
  schedule:
    - cron: '0 */6 * * *' # Every 6 hours

jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Sync to repositories
        run: |
          # Sync tasks to frontend repo
          gh issue create --repo myorg/frontend ...

          # Sync tasks to backend repo
          gh issue create --repo myorg/backend ...

Error Handling

Common Issues

  1. Repository not found: Ensure repos exist and token has access
  2. Task ambiguity: Use clear naming to indicate target repo
  3. Cross-repo conflicts: Use parent repo as single source of truth
  4. Permission errors: Token needs repo scope for all repositories

Related Skills

  • github-sync: Basic GitHub synchronization
  • github-issue-tracker: Task-level tracking
  • specweave:multi-project-spec-mapper: Intelligent spec splitting

平台分布

Claude Code

30.79%
按下载量换算51

Antigravity

21.29%
按下载量换算35

Cursor

18.04%
按下载量换算30

Gemini CLI

13.58%
按下载量换算22

OpenCode

8.31%
按下载量换算14

Codex

3.33%
按下载量换算5

安全审计

暂无安全审计结果可展示。

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

继续浏览同类 Skills