repo-adaptation

name	repo-adaptation
description	Use when adapting or customizing this repository to meet the needs of the source code under `src/`, including language and framework needs, dependencies, runtime behavior, Docker, Makefile targets, and customization surfaces. Do not use for routine bug fixes, small refactors, pure workflow validation, GitHub-settings-only work, or release-integrity-only work.

Repo adaptation

Use this skill when adapting or customizing this repository to meet the needs of the source code under src/.

Use this skill when

• inspecting src/ to identify the project language, framework, dependency, runtime, build, test, Docker, and Makefile needs
• adapting the repository for a new Go, Node.js, SQL, or small polyglot project
• changing config/project.cfg, Dockerfile, Makefile, scripts/, or default project scaffolding
• changing the default customization surface for derived repositories

Do not use this skill when

• making a routine bug fix or small refactor within the repository
• only validating existing behavior without changing the adaptation model or workflow surface
• only updating GitHub-side settings guidance
• only changing release integrity or artifact-verification behavior
• only changing the Terraform-backed GitHub hardening workspace under config/infra

Goals

• Preserve the secure-by-default posture of the repository.
• Preserve the stable public interface unless there is a strong reason to change it.
• Keep the repository container-first, reproducible, and easy to review.
• Keep fork-specific behavior explicit and reviewable.

Method

• Treat Makefile as the primary user-facing interface.
• Treat scripts/ as implementation details.
• Treat config/project.cfg as the main customization point for project-specific commands and settings.
• Inspect inserted project code before choosing workflow changes:
  • identify the primary language and framework
  • identify package managers, lockfiles, dependency manifests, and runtime entrypoints
  • identify build, test, lint, format, smoke-test, and release commands
  • identify Docker image, port, volume, and environment-variable needs
  • identify whether root Makefile targets should call existing project commands or add thin wrappers
• Keep changes small and reviewable.
• For Terraform-backed GitHub hardening changes under config/infra, use terraform-hardening instead.
• If a change weakens security, reproducibility, or reviewability, document the reason explicitly.
• Update documentation when the customization surface, workflow, or security posture changes.

Output expectations

• State what was adapted and why.
• Call out any public-interface changes.
• Call out any security or reproducibility tradeoffs.
• List the documentation updated.