hermes - 💡(How to fix) Fix ddalggak plan/review should withhold agreement until evidence checks

Summary

ddalggak plan과 ddalggak review가 사용자 제안·구현 결과·이전 승인에 자동 동의하지 않고, 먼저 취약한 가정과 반대 근거를 찾도록 워크플로우/프롬프트를 강화한다.

핵심은 톤이 아니라 검증 순서다. 단순히 “비판적으로 답하라” 한 줄을 넣으면 쉽게 무시된다. plan과 review 각각에 기계적 체크포인트와 출력 규칙을 넣어야 한다.

Source of truth

• 사용자 요구: ddalggak의 plan/review 응답은 기본적으로 동의 금지, 첫 반응은 취약점 검토, 빈 칭찬 금지, 직설·간결, 답이 아니면 첫 문장에서 아니라고 말하기.
• 현재 로컬 skill: /Users/pjw/.hermes/skills/software-development/ddalggak/SKILL.md
• 관련 기존 원칙:
  • Global Invariants 8, 13: 전략/리뷰는 코드베이스 방향성과 복잡도 방어 우선.
  • Review Principles: 칭찬/요약 모드 금지, gatekeeper 역할.
  • Common Pitfalls 15: confirmation-bias-resistant review/troubleshooting by default.

Weaknesses / counterarguments first

1. “기본적으로 동의하지 말라”를 문자 그대로 적용하면, 이미 검증된 사실에도 불필요한 반론을 만들 수 있다.
   • 구현에서는 항상 반대가 아니라 검증 전 동의 금지로 정의해야 한다.
2. “첫 반응은 약점”만 강제하면, 라우팅/상태 보고까지 과도하게 부정적으로 변할 수 있다.
   • 실행 라우팅 한 줄은 유지하고, 판단이 필요한 plan/review 본문 첫 섹션에만 강하게 적용한다.
3. review에는 이미 gatekeeper 문구가 많다.
   • 중복 문구만 추가하지 말고 reviewer brief 출력 구조와 approval/comment gate에 반확증편향 체크를 넣는다.

Scope

In scope

• ddalggak 공통 원칙에 “검증 전 동의 금지” 계약 추가
• plan 출력 템플릿에 Weaknesses / Counterarguments First 필수화
• review reviewer brief에 Adversarial Opening Gate 추가
• APPROVE/CHANGES_REQUESTED 결론 comment에서 빈 칭찬 금지, current head/checks/evidence 중심 문구 사용

Out of scope

• 일반 Hermes persona 전체 변경
• 공격적/무례한 말투 강제
• prompt/check까지의 확장 적용은 후속 범위로 분리 가능

Proposed implementation

Unit A — ddalggak 공통 원칙 추가

File ownership

• /Users/pjw/.hermes/skills/software-development/ddalggak/SKILL.md

Change

• Global Invariants 또는 별도 Adversarial Response Contract 섹션 추가.
• 요구사항:
  • 사용자의 아이디어/전략/의견을 먼저 인정하지 않는다.
  • 첫 판단은 가장 취약한 가정, 반대 입장, 틀릴 경우의 피해 중 하나로 시작한다.
  • 동의는 근거 확인 후에만 한다.
  • 빈 칭찬과 사용자 표현 반복을 금지한다.
  • 답이 “아니오/작동 안 함”이면 첫 문장에 말한다.

Unit B — plan 템플릿 강화

File ownership

• /Users/pjw/.hermes/skills/software-development/ddalggak/SKILL.md

Change

• plan — Issue-Ready / Refactoring Plan 섹션의 출력 템플릿에 ### Weaknesses / Counterarguments First를 Goal 앞 또는 직후에 추가한다.
• 내용 요구:
  • 사용자의 제안에서 가장 약한 가정 1~3개
  • 반대 의견이 맞을 가능성
  • 계획을 진행하면 안 되는 조건/중단 조건
• 저장되는 plan 파일에도 이 섹션이 들어가야 한다.

Unit C — review reviewer brief 강화

File ownership

• /Users/pjw/.hermes/skills/software-development/ddalggak/SKILL.md

Change

• REVIEW_BRIEF Quality Gate Template 상단에 필수 섹션 추가:
  • Do not begin with praise or agreement.
  • 첫 섹션은 Most likely blocker / weakest assumption.
  • PR이 맞다고 가정하지 말고, 틀렸을 때 어디서 터지는지 먼저 찾는다.
  • 기존 구현자·이전 승인·CI 성공을 신뢰하지 않고 current head + diff + base evidence로 재검증한다.

Unit D — final review/comment 문구 규칙 추가

File ownership

• /Users/pjw/.hermes/skills/software-development/ddalggak/SKILL.md

Change

• APPROVE 결론 comment도 “좋습니다/훌륭합니다” 대신 증거 중심으로 시작한다.
• 허용 예시:
  • Current head <sha> 기준 Critical/High 없음. 확인 근거: ...
• 금지 예시:
  • 좋은 PR입니다, 훌륭합니다, 맞습니다
• CHANGES_REQUESTED는 첫 문장에 blocker를 직접 쓴다.

Existing backlog conflict check

• 변경 범위는 로컬 Hermes skill 파일 1개로 제한된다.
• 현재 열린 upstream PR/issue 다수는 agent/, gateway/, plugins/, tools/, web/ 등 제품 코드 변경 중심이다.
• 이 이슈는 로컬 workflow skill 문서 변경이며, upstream NousResearch/hermes-agent 제품 코드와 직접 충돌하지 않는다.
• 구현 시 원격 repo 코드 PR로 만들지 말고, 로컬 skill 수정 작업으로 처리하는 것이 안전하다.

Acceptance criteria

• ddalggak plan 산출물에 사용자 주장 검토용 약점/반대근거 섹션이 필수로 들어간다.
• ddalggak review subagent brief가 칭찬/요약 시작을 금지하고 blocker 후보를 먼저 찾게 한다.
• GitHub review/approval comment는 칭찬이 아니라 current head/checks/evidence로 시작한다.
• “항상 반대”가 아니라 “검증 전 동의 금지”로 정확히 표현되어 불필요한 반대 놀이를 막는다.
• 기존 ddalggak 라우팅/상태보고/verification checklist 동작은 깨지지 않는다.

Validation

python - <<'PY'
from pathlib import Path
p = Path('/Users/pjw/.hermes/skills/software-development/ddalggak/SKILL.md')
text = p.read_text()
required = [
    'Adversarial',
    'Weaknesses',
    'Do not begin with praise or agreement',
    'Current head',
]
missing = [s for s in required if s not in text]
if missing:
    raise SystemExit(f'missing anchors: {missing}')
print('anchors ok')
PY

Manual validation prompts:

1. ddalggak plan <사용자 주장 포함>
   • 응답/저장 plan이 칭찬이 아니라 약점 검토로 시작하는지 확인.
2. ddalggak review <PR>
   • reviewer brief가 Most likely blocker / weakest assumption를 요구하는지 확인.
3. APPROVE comment dry-run 문구 확인.
   • 빈 칭찬 없이 head/checks/evidence 중심인지 확인.

Notes

• 이 이슈는 /Users/pjw/.hermes/hermes-agent/.hermes/plans/2026-05-18_003135-ddalggak-adversarial-plan-review-errors.md 계획에서 생성됨.
• 구현은 로컬 skill 패치 중심이다. upstream repo의 제품 코드 변경 PR로 오인하지 말 것.