메뉴
Add or edit a lerd service preset (database, cache, search engine, admin dashboard) as YAML in the lerd-services store. Use whenever the task is to add a new service, a new version of a service, or wire a service into projects — never add services in Go.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Add or extend a lerd framework definition (a new PHP framework or a new major version) as versioned YAML in the lerd-frameworks store. Use whenever the task involves framework detection, per-framework workers, env wiring, doctor checks, custom commands, or scaffolding — never branch on a framework name in Go.
Draft and open a pull request the lerd way — issue-first, correct issue linking, human prose, none of the banned sections. Use when asked to open, prepare, or draft a PR for lerd. Never creates anything on GitHub without explicit per-action approval.
Run the full local verification gate for lerd before committing — build, test, vet, gofmt, UI tests, installer tests, then install the local build and smoke-test. Use before every commit or PR, and whenever asked to "verify", "check CI locally", or "make sure it's green".
SOC 직업 분류 기준
| name | lerd-add-service |
| description | Add or edit a lerd service preset (database, cache, search engine, admin dashboard) as YAML in the lerd-services store. Use whenever the task is to add a new service, a new version of a service, or wire a service into projects — never add services in Go. |
Services are submitted to the lerd-env/services repo
(https://github.com/lerd-env/services) as services/<name>.yaml,
one file per service. They are data, not Go. lerd ships only the default stack
(mysql, postgres, redis, meilisearch, rustfs, mailpit); everything else is a preset
there and reaches every install within ~24h with no binary release.
The lerd-services/ directory in the lerd repo is a local checkout you can edit
and test against, but the pull request goes to lerd-env/services.
Find the closest existing preset and copy it. The existing YAML is the
schema of record — do not invent fields. For a Redis-alike copy valkey.yaml;
for a database copy mariadb.yaml or mongo.yaml; for an admin dashboard
copy phpmyadmin.yaml / pgadmin.yaml.
Fill the core fields (see valkey.yaml for the minimal shape):
name, description, family (family groups alternates + admin UIs)image (pin a specific tag), ports ("host:container")data_dir for the persistent volumeenv_vars — the host/port/credentials injected into a linked site's .envconnection_url where applicableAvoid host-port collisions. If the service shares a protocol/port with a default (e.g. Valkey vs Redis on 6379), publish it on a shifted host port so both can coexist, and note why in a short comment. lerd also auto-shifts collisions, but pick a sane default.
Declare dependencies and mounted config if the preset needs them (an admin dashboard depends on its database family; some presets mount a generated config file for auto-login). Copy the pattern from the matching existing preset.
Update the store README table in the lerd-env/services README.md so the
new service is listed.
Validate end-to-end with a real lerd install:
lerd service search <name>
lerd service preset <name>
Confirm the container starts, the port is reachable, and a linked site's .env
gets the expected vars.
latest.description one line; it shows in lerd service search.