Skip to content

Commit 7166f30

Browse files
serithemageclaude
andcommitted
Fix bold markdown spacing in AGENTS.md blog post
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1 parent 284dec9 commit 7166f30

1 file changed

Lines changed: 3 additions & 3 deletions

File tree

content/posts/openclaw-agents-md-productivity-secrets.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,7 @@ tags:
2020

2121
OpenClaw(구 Clawdbot)는 GitHub 31만+ 스타를 받은 오픈소스 프로젝트로, 한 명의 개발자가 여러 AI 코딩 에이전트를 병렬로 운용해 구축한 대표적인 바이브 코딩 사례다. 이전 글[^1]에서 OpenClaw의 9가지 모범 사례를 다뤘다면, 이번에는 그 모범 사례의 원천인 `AGENTS.md` 파일 자체를 해부한다.
2222

23-
`AGENTS.md`는 단순한 README가 아니다. 이 문서는 AI 에이전트가 코드베이스에서 작업할 때 따라야 할 **운영 계약(operational contract)**이다. Peter Steinberger는 이를 "조직의 상처가 축적된 흔적(organizational scar tissue)"이라고 불렀다. 무언가 잘못될 때마다 에이전트가 스스로 규칙을 추가해 왔기 때문이다. 지금부터 이 215줄짜리 문서에서 읽어낼 수 있는 생산성의 원칙들을 하나씩 풀어본다.
23+
`AGENTS.md`는 단순한 README가 아니다. 이 문서는 AI 에이전트가 코드베이스에서 작업할 때 따라야 할 **운영 계약(operational contract)** 이다. Peter Steinberger는 이를 "조직의 상처가 축적된 흔적(organizational scar tissue)"이라고 불렀다. 무언가 잘못될 때마다 에이전트가 스스로 규칙을 추가해 왔기 때문이다. 지금부터 이 215줄짜리 문서에서 읽어낼 수 있는 생산성의 원칙들을 하나씩 풀어본다.
2424

2525
---
2626

@@ -62,7 +62,7 @@ OpenClaw AGENTS.md에서 가장 인상적인 부분은 **임포트 경계(import
6262

6363
## 3. 빌드 게이트를 절대 규칙으로 만들어라
6464

65-
AGENTS.md의 빌드/테스트 섹션은 에이전트가 코드를 변경한 후 무엇을 해야 하는지를 매우 명확하게 정의한다. 핵심은 **하드 게이트(hard gate)****소프트 게이트**의 구분이다.
65+
AGENTS.md의 빌드/테스트 섹션은 에이전트가 코드를 변경한 후 무엇을 해야 하는지를 매우 명확하게 정의한다. 핵심은 **하드 게이트(hard gate)** **소프트 게이트** 의 구분이다.
6666

6767
**하드 게이트(절대 규칙)**:
6868
- 빌드 산출물, 패키징, 모듈 경계, 퍼블리시 표면에 영향을 줄 수 있는 변경은 반드시 `pnpm build`를 실행하고 통과해야 `main`에 푸시할 수 있다
@@ -72,7 +72,7 @@ AGENTS.md의 빌드/테스트 섹션은 에이전트가 코드를 변경한 후
7272
- 좁은 범위의 변경에는 해당 동작을 직접 검증하는 좁은 범위의 테스트를 선호한다
7373
- `main`에 푸시할 때의 기본 기준은 `pnpm check``pnpm test`
7474

75-
특히 눈에 띄는 것은 **기존 실패와의 구분**이다. 변경과 무관한 실패가 이미 `origin/main`에 존재한다면, 그 사실을 명시하고 자신이 실행한 범위 테스트를 보고하라고 한다. 하지만 "관련 없는 실패니까 무시해도 된다"는 식의 면죄부를 주지는 않는다. 이 미묘한 균형이 중요하다.
75+
특히 눈에 띄는 것은 **기존 실패와의 구분** 이다. 변경과 무관한 실패가 이미 `origin/main`에 존재한다면, 그 사실을 명시하고 자신이 실행한 범위 테스트를 보고하라고 한다. 하지만 "관련 없는 실패니까 무시해도 된다"는 식의 면죄부를 주지는 않는다. 이 미묘한 균형이 중요하다.
7676

7777
또 하나 인상적인 규칙이 있다. 의존성이 누락된 경우(예: `vitest not found`) 패키지 매니저 설치를 한 번 실행한 뒤 명령을 재시도하되, 재시도도 실패하면 명령어와 첫 번째 오류 메시지를 보고하라는 것이다. 에이전트에게 자가 복구 능력을 주되, 무한 루프에 빠지지 않게 한 번으로 제한한다.
7878

0 commit comments

Comments
 (0)