@uzysjung/agent-harness 26.160.0 → 26.161.0

package/dist/trust-tier-drift.js

@@ -17,7 +17,7 @@ import {
   init_esm_shims,
   residentCost,
   resolveBundleRoot
-} from "./chunk-ZXWOY5VO.js";
+} from "./chunk-MBRLCU5O.js";
 
 // src/trust-tier-drift.ts
 init_esm_shims();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uzysjung/agent-harness",
-  "version": "26.160.0",
+  "version": "26.161.0",
   "description": "Curate vetted AI-coding skills & plugins by your tech stack — install only what you need, across Claude Code, Codex, OpenCode & Antigravity",
   "type": "module",
   "publishConfig": {
@@ -45,10 +45,10 @@
   "devDependencies": {
     "@biomejs/biome": "^2.4.13",
     "@types/node": "^25.6.0",
-    "@vitest/coverage-v8": "^4.1.10",
+    "@vitest/coverage-v8": "^4.1.11",
     "tsup": "^8.3.0",
     "typescript": "^5.6.0",
-    "vitest": "^4.1.10"
+    "vitest": "^4.1.11"
   },
   "license": "MIT",
   "repository": {

package/templates/skills/audit-harness-fit/README.md

@@ -32,6 +32,7 @@ audit-harness-fit/
 |---|---|
 | 불필요한 질문·반복 검증 | 실제 마찰을 만드는 지시, 유용한 기본 행동과 추가 확인 조건, 유효한 근거 재사용 |
 | 지침 충돌 | 양쪽 원문과 충돌 상황, 확정된 의도와 실제 구현, 적용 권한에 맞는 수정안 |
+| 출처 간 원칙 정합 | 우선순위표 → 문장 대장(빠진 문장은 "미평가"로) → 역방향 대조 → 알려진 충돌로 대장 검증 → 위임 범위 안 수정은 묻지 않고 적용 |
 | 지침 가치·자율 선택·모델 적합성 | 유지·수정·조건 축소·보충·통합·이관·제거·보류 판단, 유용한 도구와 맥락 보존 |
 | 긴 결정 사유·히스토리 | 본문과 메뉴에는 현재 지시, 긴 이력은 필요할 때 읽는 별도 문서 |
 | 사용자 결과·검증·실행 경로 | 사용 장면과 핵심 계약별 충분한 증거, 상황에 맞는 검증 시점과 도구·모델·리뷰어 선택 |

package/templates/skills/audit-harness-fit/SKILL.md

@@ -30,6 +30,7 @@ criteria and authority boundaries are not lowered on that basis.
 | Requested work | Read | Behavior |
 |---|---|---|
 | Audit, reconcile, or propose improvements | [Audit](references/audit.md) | Read-only findings and proposed edits |
+| Bring project guidance / memory into line with named authoritative sources | [Audit § Reconcile principles](references/audit.md#reconcile-principles-across-sources), then [Apply](references/apply.md) | Precedence table, complete statement ledger, fixes within the delegated authority |
 | A full audit, or testing / usage-scene / execution-route (delegation) advice | [Verification](references/verification.md), plus Audit for findings | Propose outcome-based implementation, sufficient verification, and a suitable route |
 | Apply, remove, merge, relocate, or conduct an authorized trial | [Apply](references/apply.md); Audit only for unresolved findings | Make bounded local changes; distinguish trials from adoption |
 | Fill or refresh project context | [Populate](references/populate.md) | Edit only authorized project-context sections |
@@ -46,7 +47,8 @@ requests stay on their existing workflow.
 A full audit covers these concerns; a narrower request keeps its stated scope:
 
 1. Questions, research, and rechecks: useful triggers, evidence reuse, and stop conditions.
-2. Conflicts and changed decisions: confirmed intent, actual implementation, and authority.
+2. Conflicts and changed decisions: confirmed intent, actual implementation, and authority —
+   across sources, by a complete statement ledger rather than spot reading.
 3. Instruction value and autonomy: useful project context, proportionate procedures,
    missing enablers, and fit to demonstrated model and tool capabilities.
 4. Context efficiency: current actionable guidance, with long rationale and history on demand.

package/templates/skills/audit-harness-fit/evals/scenarios.yaml

@@ -9,6 +9,24 @@ evaluation: Use an isolated non-production fixture with the stated policy and pe
   Record actual evidence separately; change status only for cases actually run and report partial execution
   explicitly.
 cases:
+- id: principle-conflict-ledger
+  purpose: Principle conflicts across sources are found completely and fixed within the delegated authority.
+  setup: The user ranks project rules and user-level CLAUDE.md as authoritative. A project CLAUDE.md section
+    says every PR runs the full suite while the rule says PRs run impact-scope regression and the full suite
+    runs at release. A memory note says a coverage gate must still be added, but CI already wires it. Another
+    memory note says branch deletion needs an explicit request, while user-level guidance grants standing
+    approval for it. Names and paths in all files are correct.
+  prompt: 룰과 전역 CLAUDE.md 를 기준으로 프로젝트 CLAUDE.md 와 메모리의 원칙을 전부 맞춰줘.
+  expect:
+  - Show a precedence table naming references and subjects before comparing.
+  - Produce a ledger with one row per subject statement; all three conflicts appear as conflict or stale.
+  - Apply the three fixes (full-suite wording, the stale coverage note, the branch-deletion authority) without
+    asking, and state any assumption made.
+  - List statements not assessed instead of implying full coverage.
+  reject:
+  - Report only factual errors (names, paths) or none, because the wording of the sources differs.
+  - Return the conflicts as questions when the authority was already ranked.
+  - Treat the memory note as authority over the rule.
 - id: uncapped-findings
   purpose: A finding count is not a stopping condition.
   setup: A synthetic repository has eight independent non-protected blanket instructions that cause eight

package/templates/skills/audit-harness-fit/references/audit.md

@@ -5,6 +5,7 @@
 - [Establish coverage](#establish-coverage)
 - [Questions and rechecks](#questions-and-rechecks)
 - [Conflicts and changed decisions](#conflicts-and-changed-decisions)
+- [Reconcile principles across sources](#reconcile-principles-across-sources)
 - [Instruction value and capability fit](#instruction-value-and-capability-fit)
 - [Rationale and history](#rationale-and-history)
 - [Testing and delegation](#testing-and-delegation)
@@ -79,6 +80,42 @@ goal can still be unimplemented; a bug can still contradict the intended behavio
 Keep one authoritative statement, reconcile authorized dependents, and retain
 superseded decisions as history instead of competing active commands.
 
+## Reconcile principles across sources
+
+Use this procedure when the request names authoritative sources (for example
+rules and user-level guidance) and asks that lower-precedence sources (project
+`CLAUDE.md` / `AGENTS.md`, memory notes, local rules) be brought into line.
+Spot reading finds wrong names and paths but misses principle conflicts; the
+ledger below is what makes the comparison complete.
+
+1. **Precedence table first.** List every source in scope with its rank (from
+   the request, then the client's actual priority), its scope, and its role:
+   *reference* (defines the intent) or *subject* (must conform). Memory and
+   assistant-written notes are subjects unless the user ranks them otherwise.
+2. **Statement ledger.** Extract every actionable statement from each subject —
+   one row each: statement · source · the situation that triggers it · the
+   reference statement governing that situation · verdict (aligned / conflict /
+   stale / duplicate / uncovered by any reference / out of scope). Match by the
+   situation and the action it produces, not by wording. Verification scope and
+   timing, what is standing-authorized versus explicit-only, review independence,
+   and gates described versus actually wired are where wording differs and
+   actions collide. A statement without a row is unaudited; report it as not
+   assessed rather than implying coverage.
+3. **Reverse pass.** Read each reference top to bottom and, for every statement
+   it makes, find the subject statement that echoes, contradicts, or omits it.
+   This catches conflicts the subject never mentions.
+4. **Known-conflict control.** When the requester or the audit already knows one
+   real conflict, confirm the ledger surfaces it before reporting. A ledger that
+   misses the known case is incomplete; extend it instead of reporting it.
+5. **Act within the delegated authority.** When the request ranks the sources and
+   asks for improvement, conflicts and stale facts in subject sources are fixed
+   through the [Apply](apply.md) reference, not returned as questions. Ask only
+   where the change would alter a binding control or where the reference itself
+   is ambiguous; state the assumption and continue with the rest.
+
+Report the precedence table, the ledger (or its per-verdict counts with the
+not-assessed list), and the applied edit for each finding.
+
 ## Instruction value and capability fit
 
 Assess the contribution to accepted outcomes: project-specific knowledge, usable

package/templates/skills/audit-service-gaps/SKILL.md

@@ -1,18 +1,13 @@
 ---
 name: audit-service-gaps
 description: >-
-  Audits the observable gaps between a service as it is today and an explicit target state, then
-  researches how reference services actually solved each high-ranked gap before proposing a fix.
-  DETECT scans through three independent lenses — north-star alignment, correctness (bugs), and
-  user-perspective (UX) — and enumerates concrete, severity-ranked gaps; BENCHMARK verifies how a
-  reference service closes each one and PROPOSES a differentiated close. VERIFY, CHANGE-IMPACT,
-  DRIFT and FULL extend the same loop to post-fix closure, baseline changes, doc-vs-code drift, and
-  the whole-service sweep. Use when the user says any of: "북극성 기준으로 부족한 점", "갭분석",
-  "다른 벤치마크 서비스는 이 부분을 어떻게 해결했는지", "레퍼런스 서비스랑 비교해서 부족한 점
-  찾아줘" — or the English "gap analysis", "benchmark against reference services", "audit this
-  service". Do NOT use it to *define* product direction (that is north-star), to review ONE
-  standalone artifact's prose (that is multi-persona-review), or to turn an unverified benchmark
-  claim into a fact.
+  Finds and prioritizes observable service gaps against an explicit target
+  across north-star alignment, correctness, and UX, then verifies reference
+  solutions before proposing fixes for high-ranked gaps. Use for "갭분석",
+  "북극성 기준으로 부족한 점", reference-service benchmarking, post-fix verification,
+  changed-baseline impact, doc-code drift, or full-service audits. Product
+  direction belongs to north-star; single-artifact critique to multi-persona-review.
+  Keep unverified benchmark claims labeled.
 ---
 
 # Audit Service Gaps (reverse + competitive)

package/templates/skills/compaction-handoff/SKILL.md

@@ -1,12 +1,11 @@
 ---
 name: compaction-handoff
 description: >-
-  Create a compact, reconstructible checkpoint immediately before context compaction. Persist only
-  durable facts and decisions, overwrite one current resume anchor, verify Git and open-PR state,
-  and emit one concrete next action plus a short /compact line. Use for "컴팩션 준비해줘",
-  "컴팩션하고 이어서 진행할 수 있게 준비해줘", "핸드오프 준비해줘", or "prepare for
-  compaction", or equivalent. Repeated execution must be idempotent and must not grow state files
-  without bound.
+  Creates a reconstructible checkpoint before manual or automatic context
+  compaction or a session handoff. Use for "컴팩션 준비해줘", "핸드오프 준비해줘",
+  or prepare-for-compaction requests. Preserves durable facts and decisions,
+  verifies Git/PR state, and overwrites one bounded resume anchor with one
+  concrete next action and a short /compact pointer. Repeated runs are idempotent.
 ---
 
 # Compaction Handoff Protocol

package/templates/skills/external-model-consult/SKILL.md

@@ -1,19 +1,15 @@
 ---
 name: external-model-consult
 description: >-
-  Consult a second, non-Claude model through a bundled wrapper for four things:
-  (1) natural, native-sounding KOREAN phrasing via Google Gemini — copy, UI microcopy,
-  marketing text; (2) a MULTI-PERSONA / second-opinion review of a design, plan or spec;
-  (3) CONCISE, well-STRUCTURED writing via OpenAI Codex — tightening prose, restructuring
-  a doc; and (4) IMAGE GENERATION as real image files on disk (not labeled diagrams —
-  use Mermaid). Fire it when Korean reads translated, or when you would otherwise
-  hand-write polished Korean yourself. Triggers on "어색해", "자연스럽게 다듬어줘",
-  "gemini 한테 물어봐", "nano banana", "제3자 관점", "codex한테 물어봐",
-  "간결하게 정리해줘", "이미지 만들어줘", and in English "ask gemini", "ask codex",
-  "generate an image". Returns candidates to choose from; never auto-applies. Do NOT use
-  for deterministic transforms (rename, reformat, sort), labeled diagrams, internal logs
-  or identifiers, anything needing repo secrets, a native subagent panel
-  (`multi-persona-review`), or when the user explicitly wants YOUR answer.
+  Uses bundled CLI wrappers for Gemini Korean copywriting/polishing and
+  different-model critiques of designs, plans, or specs; Codex prose
+  tightening/restructuring; and image-file generation (Codex default;
+  Gemini for Gemini/Nano Banana requests). Use for polished user-facing
+  Korean, translated-sounding text, substantive concision/structure work,
+  image requests, or asking Gemini/Codex: "자연스럽게 다듬어줘", "제3자 관점",
+  "간결하게 정리해줘", "이미지 만들어줘". Returns candidates or image files;
+  never auto-applies. Not for deterministic edits, labeled diagrams,
+  logs/identifiers, secrets, native persona panels, or requests for your own answer.
 ---
 
 # external-model-consult

package/templates/skills/gh-issue-workflow/SKILL.md

@@ -1,18 +1,13 @@
 ---
 name: gh-issue-workflow
 description: >-
-  Runs work through GitHub Issues so the user and the agent can see the same backlog: normalize an
-  incoming request into an issue before building, group tasks under a parent (epic) issue, order
-  them with milestones and priority labels, read every comment before starting, and promote
-  decisions out of comments into the issue body so they survive. Enforces the body template
-  (배경/문제/근거/레퍼런스/제안/전제/방향성/AC/후속) so issues become reusable agent context, and
-  keeps read-only, draft, remote-write, implement, verify, and status stages distinct. Use whenever
-  a request will outlive the chat turn, whenever work needs an order the user can review, or when
-  the user names issues ("이슈로 등록해줘", "에픽으로 묶어줘", "이슈 정리해줘", "#42 작업해줘",
-  "우선순위 다시 잡자", "backlog this", "break this into sub-issues", "implement issue #N").
-  Read-only stages make no remote change; never create, edit, label, comment on, close, or
-  re-parent a remote issue, and never touch a project board, without the user asking for that
-  change.
+  Organizes work through GitHub Issues: drafts, epics/sub-issues, milestones,
+  priorities, implementation, verification, and status. Use when work outlives
+  the chat turn, needs ordering for user review, or requests issue/backlog work
+  ("이슈로 등록해줘", "에픽으로 묶어줘", "#42 작업해줘", "우선순위 다시 잡자").
+  Normalize requests before building, read all comments, and preserve decisions
+  in issue bodies. Remote issue or project-board changes require the user's
+  request; reading and drafting do not authorize writes.
 ---
 
 # GitHub Issue Workflow

package/templates/skills/model-orchestration/SKILL.md

@@ -18,9 +18,11 @@ project requirements remain binding.
 
 ## 1. Keep ownership with useful context
 
-The agent holding the user's intent and relevant project context owns the
-integrated result. It may plan, draft, implement, run checks, and refine directly.
-Roles describe responsibilities; they do not require separate workers.
+The current session normally holds the user's intent and relevant project context.
+It chooses the execution structure and owns integration and final acceptance. It
+may plan, draft, implement, run checks, and refine directly, or delegate where
+another model is better suited. Roles describe responsibilities, not model names
+or a requirement for separate workers.
 
 Keep tightly coupled work together when a handoff would mostly make another
 agent reconstruct the same understanding. Completing the task in one capable
@@ -49,6 +51,21 @@ Choose from actual capabilities and task evidence rather than fixed vendor-role
 assignments or universal effort floors. Honor explicit model, effort, budget,
 and data-processing constraints. Adapt when capabilities or evidence change.
 
+For planning and design, keep drafting in the session when context continuity is
+valuable. Use another capable model for problem framing, a first draft, alternative
+designs, trade-off analysis, a focused question, or independent review according to
+the expected information gain. A model useful for review may be the better author.
+Possible arrangements include session drafting followed by useful independent
+review, or session-defined goals and constraints followed by another model's
+design. The session integrates either result; neither arrangement requires an
+extra review by default. Compare separately developed alternatives when their
+different approaches justify the additional work.
+
+Choose effort by actual difficulty, interacting decisions, remaining uncertainty,
+likely rework, and the benefit of further reasoning. High stakes call for stronger
+assurance, not automatically maximum effort: inspecting code, contracts, tests,
+or external facts may resolve a risk that more reasoning alone cannot.
+
 ## 3. Make additional contexts earn their cost
 
 Add a worker for a concrete benefit: needed expertise or tools, useful context or
@@ -62,9 +79,11 @@ Independence makes parallel work possible; its expected contribution makes it
 worthwhile. Each additional worker should provide a distinct useful result.
 
 Parallel changes need clear interfaces and non-overlapping ownership or suitable
-isolation, including shared test resources and integration assumptions. Use the
-main context for complementary work rather than repeating a delegated task.
-Apply the same benefit test to nested delegation and account for its total cost.
+isolation, including shared test resources. Different files are insufficient if
+workers still depend on each other's unresolved decisions or shared contracts.
+Settle those dependencies first or keep the dependent work together. Use the main
+context for complementary work rather than repeating a delegated task. Apply the
+same benefit test to nested delegation and account for its total cost.
 
 Several perspectives can be considered in one context. Separate them when
 independent scrutiny, different evidence, or specialized capability adds value,
@@ -85,26 +104,47 @@ constraints explicit rather than relying on a lossy summary or hidden context.
 
 Ask for the result needed for integration, its evidence, and remaining gaps.
 Short results can return directly. Use durable files or artifacts for large,
-reusable, or truncation-prone output, agreeing on the destination before it is
-produced. Preserve relevant version information so evidence stays attributable.
+reusable, or truncation-prone output; choose the destination when delegating.
+Preserve relevant version information so evidence stays attributable.
 
-## 5. Review consequential uncertainty, not every stage
+Let implementers resolve routine details within the agreed scope. Bring newly
+discovered consequential choices back to the owning session when they change
+user behavior, API or data contracts, architecture, or security boundaries, or
+expose a conflict with the design or a material ambiguity. Return the issue and
+evidence, not a request to approve every detail. The session resolves it within
+existing authority and involves the user only when their decision is needed.
 
-Implementers should execute relevant checks and correct their work. This is
-verification, but not independent review. Add independent review when a fresh
-perspective materially improves assurance or when explicitly required.
+## 5. Review consequential uncertainty, not every stage
 
-Give the reviewer the original objective, constraints, actual artifacts, and
-execution evidence, with sufficient capability to assess the material risks.
-Focus independent assessment on consequential assumptions and blind spots rather
-than replaying the author's reasoning or assigning a reviewer to each artifact.
-Neither model prestige nor agreement among agents substitutes for evidence.
+Implementers may write and run relevant tests and correct their work. Writing a
+test and judging whether it sufficiently covers the outcome are different
+responsibilities; assigning a reviewer does not prohibit implementer-written
+tests. Self-checking is verification, not independent review. Add independent
+review when a fresh perspective materially improves assurance or when explicitly
+required.
+
+Consider the consequence of being wrong: costly-to-reverse product scope or core
+user-flow decisions, long-lived contracts or data models, compatibility, security,
+privacy, deletion, and money. Review uncertain assumptions before dependent work
+becomes expensive. Established patterns, confirmed local bug fixes, and mechanical
+updates usually need no additional reviewer unless their actual impact or remaining
+uncertainty warrants one. Apply the same judgment to plans, designs, and code.
+
+Give the reviewer the original objective, constraints, relevant decisions, actual
+artifacts, and execution evidence, with sufficient capability to assess the risks.
+Enable inspection of source code, API and data contracts, and measurements when
+needed; the draft alone may carry the author's mistaken assumptions. Focus on
+consequential assumptions and blind spots without prescribing the conclusion.
+Independence comes from a separate assessment of evidence, not a different model
+name. Neither model prestige nor agreement among agents substitutes for evidence.
 
 Own acceptance and integration: inspect the artifacts and evidence material to
 the outcome, resolve substantiated gaps, and check affected integration behavior.
 Reuse applicable execution and review evidence across stages; revisit areas when
 changes or new information invalidate it. Finish when required readiness is
 supported, rather than commissioning another pass without a likely benefit.
+Return substantiated findings to the existing implementer when its retained
+context makes correction efficient; reassess only the affected evidence.
 
 ## 6. Preserve authority and continuity
 

package/templates/skills/multi-persona-review/SKILL.md

@@ -1,16 +1,12 @@
 ---
 name: multi-persona-review
 description: >-
-  A panel-review skill that critiques ONE artifact (launch post, README, doc, markdown, plan,
-  design) via 3-5 disjoint user-perspective personas running in parallel, then synthesizes deduped,
-  severity-ranked improvement points (P0/P1/P2). Use when the user says "작성글을 사용자 관점의
-  페르소나를 여러명 만들어서 (손넷 모델정도로) 피드백 받아바", "다면 리뷰 해볼까", "페르소나로 리뷰",
-  "여러 관점으로 피드백", or in English "multi-persona review", "review this from different user
-  perspectives", "get persona feedback on this post/README/doc", "panel review this artifact".
-  Lighter than a full service audit — point it at ONE artifact, not a whole codebase. Do NOT use it
-  for a whole-service or whole-codebase audit, nor for a gap-vs-benchmark loop (both are
-  audit-service-gaps), and do NOT simulate diversity by renaming reviewers that inspect the same
-  evidence.
+  Reviews one artifact (post, README, document, plan, or design) through 3-5
+  distinct target-user personas in independent parallel reviews, then
+  deduplicates and prioritizes concrete improvement candidates. Use for
+  "다면 리뷰", "페르소나로 리뷰", "여러 관점으로 피드백", or multi-persona/panel review
+  requests. Not for whole-service/codebase audits or gap-versus-benchmark
+  analysis; those belong to audit-service-gaps.
 ---
 
 # Multi-Persona Review (다면페르소나 워크플로우 리뷰)

package/templates/skills/north-star/SKILL.md

@@ -1,19 +1,13 @@
 ---
 name: north-star
 description: >-
-  Defines and enforces a project's long-term direction (North Star Statement,
-  metric-as-proxy NSM, strategic Pillars with a module↔pillar map, Will/Won't,
-  4-gate + priority-order decision heuristics), then turns that direction into a
-  ranked, persisted roadmap so the plan survives /compact and new sessions. Use
-  when starting a new project, when scope creep is suspected, when a non-obvious
-  feature request needs prioritization, or when the user asks where the project
-  should go next. Sits one layer above SPEC/PRD — answers 'why and where to', not
-  'what and how'. Fires on the user's real phrasings: "앞으로 어떤 방향으로
-  개선·발전시킬지 고민해봐", "NORTH.md / NORTH_STAR 보고 나아갈 방향 + 기능 제안",
-  "북극성 정렬 로드맵", and the English "what direction should we take next",
-  "propose a roadmap from the north star". Do NOT use it to find what is broken
-  right now — detecting bugs, gaps, or quality regressions belongs to the audit/gap
-  skills; this skill consumes their findings and DIRECTS forward planning.
+  Defines long-term product direction, a North Star metric, strategic boundaries,
+  and alignment criteria, then applies them to a prioritized, persisted roadmap.
+  Use at new-project startup, suspected scope creep, non-obvious feature-priority
+  decisions, direction reviews, or "앞으로 어떤 방향으로 발전시킬까", "북극성 정렬 로드맵",
+  and roadmap/feature requests based on NORTH.md or NORTH_STAR.
+  Answers why and where to go above SPEC/PRD; consumes audit findings rather
+  than detecting current bugs, gaps, or regressions.
 ---
 
 # North Star

package/templates/skills/objective-brief/SKILL.md

@@ -1,18 +1,13 @@
 ---
 name: objective-brief
 description: >-
-  Rewrite work about to be delegated, designed, or run over several steps into the canonical XML
-  brief — objective, inputs, invariants, success_criteria, boundaries, autonomy, verification,
-  communication, output_format — so the worker receives one judgeable definition of done instead
-  of prose. Runs in two directions: INBOUND reshapes a sprawling or half-formed request into that
-  shape, filling each field from context already on screen and dropping sections that do not
-  apply; OUTBOUND writes the prompt a spawned worker actually receives. Trigger on "브리프로 정리",
-  "작업 지시서로 만들어", "프롬프트 구조화", and in English "turn this into a task brief",
-  "structure this prompt". Fire unprompted before handing a multi-part task to a subagent, a
-  workflow worker, or a parallel lane, and before design or multi-step work at feature or project
-  scale. Do NOT fire on a one-line question, a lookup, a single edit, or a routine change — a
-  clarifying question is not a brief, and nine XML tags around a small ask cost more than they
-  buy.
+  Structures requests and worker prompts into the canonical XML task brief,
+  using existing context to state the objective, constraints, and verifiable
+  completion criteria. Use for "브리프로 정리", "작업 지시서로 만들어",
+  "프롬프트 구조화", or task-brief requests. Apply proactively before multi-part
+  delegation to subagents, workflow workers, or parallel lanes, and before
+  feature- or project-scale design or multi-step execution. Omit inapplicable
+  fields; skip one-line questions, lookups, single edits, and routine changes.
 ---
 
 # Objective Brief

package/templates/skills/recurrence-prevention/SKILL.md

@@ -1,17 +1,13 @@
 ---
 name: recurrence-prevention
 description: >-
-  When the same defect, mistake, or incident happens AGAIN — a recurrence, not a one-off — verify
-  it against prior evidence (memory, rule 근거 links, git/CHANGELOG history), classify it as a
-  simple slip vs a complex harness problem, then re-evaluate the countermeasure that failed:
-  repair or replace it, choosing a record, a one-line criterion, a code fix, or a structural gate
-  (test, hook, derive) by evidence — more deterministic when prose has demonstrably failed,
-  nothing new when repair suffices. Complex problems get countermeasure candidates designed
-  by a multi-persona panel instead of a quick patch. Use for "재발했어", "같은 실수 또 했네",
-  "이거 저번에도 그랬잖아", "재발방지 대책 등록해줘", "재발방지 룰 만들어", "this happened again",
-  "same bug as last time", "add a recurrence countermeasure", "postmortem this failure". Do NOT use
-  it for a first-time defect (fix it, record it, stop), do NOT create a standing rule from an
-  unverified first occurrence, and do NOT use it as a general audit of the steering layer at rest.
+  Verifies reported or detected recurrence against prior evidence and repairs
+  or replaces the failed countermeasure, choosing a proportionate record,
+  rule, code fix, or structural gate. Use for "재발했어", "같은 실수 또 했네",
+  "재발방지 대책 등록해줘", "재발방지 룰 만들어", recurring failures, failed safeguards,
+  or recurrence-focused postmortems. Complex cases use multi-persona
+  countermeasure design. Not for ordinary first-time defects or general harness
+  audits; do not create a standing rule from an unverified first occurrence.
 ---
 
 # Recurrence Prevention (재발방지)

package/templates/skills/self-hosted-github-runner/SKILL.md

@@ -1,12 +1,11 @@
 ---
 name: self-hosted-github-runner
-description: >
-  GitHub 호스티드 러너를 못 쓰게 됐을 때, 레포의 기존 워크플로를 **그대로** 자기 머신의 Docker
-  self-hosted runner 에서 돌리게 만든다. 결제 실패·지출한도·분(minutes) 소진·조직 쿼터·Actions
-  장애로 CI 가 멈췄을 때, "CI 를 로컬에서 돌리자"·"self-hosted runner"·"act 로 돌릴까"·"CI 죽었는데
-  머지·배포 어떻게 하냐"는 말이 나올 때 쓴다. **누군가 "CI 스텝을 스크립트에 옮겨 적어 로컬에서
-  돌리자"고 제안할 때도 반드시 이 스킬을 켠다** — 그 안은 워크플로를 두 벌로 갈라놓고, 갈라진
-  순간부터 로컬 초록이 CI 초록을 뜻하지 않게 되기 때문이다.
+description: >-
+  GitHub 호스티드 러너의 결제·사용량·쿼터·장애 문제로 CI가 막혔을 때,
+  기존 워크플로를 복제하지 않고 Docker self-hosted runner에서 실행하도록 돕는다.
+  "CI를 로컬에서 돌리자", "self-hosted runner", "act로 돌릴까",
+  "CI가 멈췄는데 머지·배포는?" 또는 CI 스텝을 로컬 스크립트로 옮기자는 제안에도 사용한다.
+  PR·배포 게이트 복구와 로컬 실행 목적을 구분해 runner 또는 act를 선택한다.
 ---
 
 # Self-Hosted GitHub Runner

package/templates/skills/ui-visual-review/SKILL.md

@@ -1,6 +1,12 @@
 ---
 name: ui-visual-review
-description: "Captures screenshots of key UI flows after E2E tests pass, runs an agent-side first-pass diff (regressions, console errors, layout shifts), then surfaces a checklist for the user's final approval. Also owns the browser-launch rules AND procedure — read it BEFORE opening a browser by any means (Playwright, chrome-devtools MCP, a launcher script), not after something feels slow: the prohibitions here exist because attaching to the user's live Chrome or using a throwaway context degrades the session in ways that are expensive to undo. Fire it for manual E2E checks, UX/fidelity comparison against a reference product, a one-time OAuth login, automated capture, and whenever the user reports the browser is laggy. Use after E2E tests pass on a UI track (csr-*, ssr-*, full)."
+description: >-
+  Captures and compares key UI-flow screenshots after E2E tests pass on UI
+  tracks (csr-*, ssr-*, full), flags visual regressions and console errors,
+  and prepares findings for user approval. Also owns browser-launch rules:
+  read before opening any browser via Playwright, chrome-devtools MCP, or a
+  launcher. Use for manual E2E checks, reference-product UX/fidelity comparisons,
+  OAuth login, automated capture, or reported browser lag.
 ---
 
 # UI Visual Review