workspace-manager/.workspace-ops/skills/build-management/SKILL.md

2.1 KiB

name version description
build-management 1.0.0 workspace-level build-management guidance skill for Jenkins and OTO-backed build/deploy flows. Use when adding or reviewing common build guidance, artifact/evidence conventions, or project starter build docs.

Build Management

Purpose

Keep Jenkins and OTO build/deploy guidance consistent across the workspace while preserving each project's own build entrypoints.

When To Use

  • The user asks about Jenkins build guidance.
  • The user asks about OTO build/deploy responsibility.
  • A project needs a starter build-management guide.
  • A build flow needs shared evidence, artifact, remote runner, or credential handling guidance.

Required Reads

  • .workspace-ops/rules/common/rules.md
  • .workspace-ops/rules/domains/build/rules.md
  • .workspace-ops/docs/build-jenkins-oto.md
  • .workspace-ops/templates/build-jenkins-oto.md when creating a project starter guide
  • .workspace-ops/docs/remote-test-environments.md when remote runner behavior matters

Procedure

  1. Identify the project-owned build entrypoints before discussing Jenkins or OTO.
  2. Separate responsibilities: project commands, Jenkins orchestration, OTO build/deploy agent behavior, remote runner, artifact storage, and evidence.
  3. Link credential handling back to the SOPS/secret guidance instead of repeating secret values.
  4. If adding a starter guide for a project, use the workspace template and fill only confirmed project paths and commands.
  5. Note unknown Jenkins job names, OTO commands, or artifact paths as "확인 필요" instead of inventing them.

Output

  • State the build owner and orchestration owner.
  • List project commands, Jenkins/OTO responsibilities, artifact/evidence outputs, and credential injection boundaries.
  • Include verification commands or smoke paths where known.

Do Not

  • Do not make Jenkins or OTO the source of truth for project build behavior when the project already has local entrypoints.
  • Do not store credentials or private job URLs in tracked docs.
  • Do not add project-local build files unless the user asked for implementation.