Token导航 LogoToken导航TokenDH.com
开发操作浏览器github未标认证来源可访问clear审计异常

build-engineer建造工程师

Agent Skill

build-engineer 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

2,446

周安装

104

GitHub Stars

76

下载量

857
CodexClaudeCursorGemini CLI

安装说明

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

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

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

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

命令行安装

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

skills.shnpx skills
npx skills add https://github.com/404kidwiz/claude-supercode-skills --skill build-engineer

简介

专注提升构建性能与 CI/CD 效率的专项优化技能。

  • 擅长 monorepo 工具链(Turborepo/Nx/Bazel)与 bundler 调优。
  • 提供增量构建、远程缓存与依赖图分析等高级配置建议。
  • 修改前应评估对现有架构的影响,避免引入不可逆变更。
  • build-engineer 属于开发类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Build Engineer

Purpose

Provides build systems and CI/CD optimization expertise specializing in monorepo tooling (Turborepo, Nx, Bazel), bundler optimization (Webpack/Vite/Rspack), and incremental builds. Focuses on optimizing development velocity through caching, parallelization, and build performance.

When to Use

  • Setting up a Monorepo (pnpm workspaces + Turborepo/Nx)
  • Optimizing slow CI builds (Remote Caching, Sharding)
  • Migrating from Webpack to Vite/Rspack for performance
  • Configuring advanced Bazel build rules (Starlark)
  • Debugging complex dependency graphs or circular dependencies
  • Implementing "Affected" builds (only test what changed)


2. Decision Framework

Monorepo Tool Selection

ToolBest ForProsCons
TurborepoJS/TS EcosystemZero config, simple, Vercel native.JS only (mostly), less granular than Bazel.
NxEnterprise JS/TSPowerful plugins, code generation, graph visualization.heavier configuration, opinionated.
BazelPolyglot (Go/Java/JS)Hermetic builds, infinite scale (Google style).Massive learning curve, complex setup.
Pnpm WorkspacesSimple ProjectsNative to Node.js, fast installation.No task orchestration (needs Turbo/Nx).

Bundler Selection

What is the priority?
│
├─ **Development Speed (HMR)**
│  ├─ Web App? → **Vite** (ESModules based, instant start)
│  └─ Legacy App? → **Rspack** (Webpack compatible, Rust speed)
│
├─ **Production Optimization**
│  ├─ Max Compression? → **Webpack** (Mature ecosystem of plugins)
│  └─ Speed? → **Rspack / Esbuild**
│
└─ **Library Authoring**
   └─ Dual Emit (CJS/ESM)? → **Rollup** (Tree-shaking standard)

Red Flags → Escalate to devops-engineer:

  • CI Pipeline takes > 20 minutes
  • node_modules size > 1GB (Phantom dependencies)
  • "It works on my machine" but fails in CI (Environment drift)
  • Secret keys found in build artifacts (Source maps)


4. Core Workflows

Workflow 1: Turborepo Setup (Remote Caching)

Goal: Reduce CI time by 80% by reusing cache artifacts.

Steps:

  1. Configuration (turbo.json) {"$schema": "https://turbo.build/schema.json", "pipeline": {"build": {"dependsOn": ["^build"], "outputs": ["dist/**", ".next/**"]}, "test": {"dependsOn": ["build"], "inputs": ["src/**/*.tsx", "test/**/*.ts"]}, "lint": {}}}
  2. Remote Cache

- Link to Vercel Remote Cache: npx turbo link. - In CI (GitHub Actions): env: TURBO_TOKEN: ${{secrets.TURBO_TOKEN}} TURBO_TEAM: ${{secrets.TURBO_TEAM}}

  1. Execution

- turbo run build test lint - First run: 5 mins. Second run: 100ms (FULL TURBO).



Workflow 3: Nx Affected Commands

Goal: Only run tests for changed projects in a monorepo.

Steps:

  1. Analyze Graph

- nx graph (Visualizes dependencies: App A depends on Lib B).

  1. CI Pipeline # Only test projects affected by PR npx nx affected -t test --base=origin/main --head=HEAD # Only lint affected npx nx affected -t lint --base=origin/main


Workflow 5: Bazel Concepts for JS Developers

Goal: Understand BUILD files vs package.json.

Mapping:

NPM ConceptBazel Concept
package.jsonWORKSPACE / MODULE.bazel
script: buildjs_library(name = "build")
dependenciesdeps = ["//libs/utils"]
node_modulesnpm_link_all_packages

Code Example (BUILD.bazel):

load("@aspect_rules_js//js:defs.bzl", "js_library")

js_library(
    name = "pkg",
    srcs = ["index.js"],
    deps = [
        "//:node_modules/lodash",
        "//libs/utils"
    ],
)


5. Anti-Patterns & Gotchas

❌ Anti-Pattern 1: Phantom Dependencies

What it looks like:

  • import foo from 'foo' works locally but fails in CI.

Why it fails:

  • 'foo' is hoisted by the package manager but not listed in package.json.

Correct approach:

  • Use pnpm (Strict mode). It prevents accessing undeclared dependencies via symlinks.

❌ Anti-Pattern 2: Circular Dependencies

What it looks like:

  • Lib A imports Lib B. Lib B imports Lib A.
  • Build fails with "Maximum call stack exceeded" or "Undefined symbol".

Why it fails:

  • Logic error in architecture.

Correct approach:

  • Extract Shared Code: Move common logic to Lib C.
  • A → C, B → C.
  • Use madge tool to detect circular deps: npx madge --circular.

❌ Anti-Pattern 3: Committing node_modules

What it looks like:

  • Git repo size is 2GB.

Why it fails:

  • Slow clones. Platform specific binaries break.

Correct approach:

  • .gitignore must include node_modules/, dist/, .turbo/, .next/.


7. Quality Checklist

Performance:

  • Cache: Remote caching enabled and verified (Hit rate > 80%).
  • Parallelism: Tasks run in parallel where possible (Topology aware).
  • Size: Production artifacts minified and tree-shaken.

Reliability:

  • Lockfile: pnpm-lock.yaml / package-lock.json is consistent.
  • CI: Builds pass on clean runner (no cache).
  • Determinism: Same inputs = Same hash.

Maintainability:

  • Scripts: package.json scripts standardized (dev, build, test, lint).
  • Graph: Dependency graph is acyclic (DAG).
  • Scaffolding: Generators set up for new libraries/apps.

Examples

Example 1: Enterprise Monorepo Migration

Scenario: A 500-developer company with 4 React applications and 15 shared libraries wants to migrate from separate repos to a monorepo to improve code sharing and CI efficiency.

Migration Approach:

  1. Tool Selection: Chose Nx for enterprise features and graph visualization
  2. Dependency Mapping: Used madge to visualize current dependencies between projects
  3. Module Boundaries: Defined clear layers (ui, utils, data-access, features)
  4. Build Optimization: Configured remote caching with Nx Cloud

Migration Results:

  • CI build time reduced from 45 minutes to 8 minutes (82% improvement)
  • Code duplication reduced by 60% through shared libraries
  • Affected builds only test changed projects (often under 1 minute)
  • Clear architectural boundaries enforced by Nx project inference

Example 2: Webpack to Rspack Migration

Scenario: A large e-commerce platform has slow production builds (12 minutes) due to complex Webpack configuration and wants to improve developer experience.

Migration Strategy:

  1. Incremental Migration: Started with development builds, kept Webpack for production temporarily
  2. Config Translation: Mapped Webpack loaders to Rspack equivalents
  3. Plugin Compatibility: Used rspack-plugins for webpack-compatible plugins
  4. Verification: Ran parallel builds to verify output equivalence

Performance Comparison:

MetricWebpackRspackImprovement
Dev server start45s2s96%
HMR update8s0.5s94%
Production build12m2m83%
Bundle size2.4MB2.3MB4%

Example 3: Distributed CI Pipeline with Sharding

Scenario: A gaming company with 5,000 E2E tests needs to reduce CI time from 90 minutes to under 15 minutes for fast feedback.

Pipeline Design:

  1. Test Analysis: Categorized tests by duration and parallelism potential
  2. Shard Strategy: Split tests into 20 shards, each running ~250 tests
  3. Smart Scheduling: Used Nx affected to only run tests for changed features
  4. Resource Optimization: Configured auto-scaling runners for parallel execution

CI Pipeline Configuration:

# GitHub Actions with Playwright sharding
- name: Run E2E Tests
  run: |
    npx playwright test --shard=${{ matrix.shard }}/${{ matrix.total }} \
      --config=playwright.config.ts
  strategy:
    matrix:
      shard: [1, 2, ..., 20]
    max-parallel: 10

Results:

  • E2E test time: 90m → 12m (87% improvement)
  • Developer feedback loop under 15 minutes
  • Reduced cloud CI costs by 30% through better parallelism

Best Practices

Monorepo Architecture

  • Define Clear Boundaries: Establish and enforce project boundaries from day one
  • Use Strict Dependency Rules: Prevent circular dependencies and enforce directionality
  • Automate Project Creation: Use generators for consistent new project setup
  • Version Packages Together: Use Changesets or Lerna for coordinated releases
  • Document Dependencies: Maintain architecture decision records for changes

Build Performance

  • Profile Before Optimizing: Use tools like speed-measure-webpack-plugin to identify bottlenecks
  • Incremental Builds: Configure build tools to only rebuild what's necessary
  • Parallel Execution: Use available CPU cores for parallel task execution
  • Caching Strategies: Implement aggressive caching at every layer
  • Dependency Optimization: Prune unused dependencies regularly (bundlephobia)

CI/CD Excellence

  • Fail Fast: Order tests to run fast tests first, catch failures quickly
  • Sharding Strategy: Distribute tests across multiple runners intelligently
  • Cache Everything: Dependencies, build outputs, test results
  • Conditional Execution: Only run jobs that are affected by the change
  • Pipeline as Code: Version control CI configuration alongside code

Tool Selection

  • Match Tool to Ecosystem: Don't force tools that don't fit your stack
  • Evaluate Migration Cost: Consider total cost, not just performance gains
  • Community Health: Choose tools with active maintenance and community support
  • Plugin Ecosystem: Ensure required integrations are available
  • Team Familiarity: Consider learning curve and team adoption

Security and Compliance

  • Secret Scanning: Never commit secrets; use automated scanning
  • Dependency Auditing: Regular vulnerability scans with automated fixes
  • Access Control: Limit CI credentials to minimum required permissions
  • Build Reproducibility: Ensure builds can be reproduced from source
  • Audit Logging: Maintain logs of all build and deployment activities

适合场景

01

用户想查找某类 Agent Skill 时

02

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

03

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

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

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

能力 4

补充不同宿主或平台的使用分布数据

能力 5

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

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

平台分布

Claude Code

29.29%
按下载量换算251

OpenCode

24.57%
按下载量换算211

Codex

18.78%
按下载量换算161

Cursor

11.69%
按下载量换算100

Gemini CLI

8.56%
按下载量换算73

windsurf

3.15%
按下载量换算27

安全审计

Gen Agent Trust Hub

未通过

Socket

可疑

Snyk

通过

权限和风险

操作浏览器

该 Skill 可能涉及浏览器控制能力,使用时可能读取或操作网页内容,需要在受控环境中确认权限边界。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。

来源信息

继续浏览同类 Skills