mustflow 1.15.97

package/templates/default/locales/ko/.mustflow/skills/facade-pattern/SKILL.md

@@ -0,0 +1,210 @@
+---
+mustflow_doc: skill.facade-pattern
+locale: ko
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: facade-pattern
+description: Apply this skill when a controller, handler, command, service, or UI event needs a stable high-level entry point over a complex subsystem, repeated multi-step workflow, multiple dependencies, external services, repositories, queues, caches, file storage, transactions, idempotency, retries, logging, or normalized results, without turning that entry point into a god service or hiding domain rules.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.facade-pattern
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - test_related
+    - test
+    - lint
+    - build
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Facade Pattern
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Provide one simple, stable public entry point in front of a complex subsystem or repeated workflow.
+
+A facade is not a convenient name for a large service class. It is a thin application-level coordinator that hides internal ordering, external provider details, retries, transactions, logging, idempotency, and result normalization from callers while keeping domain decisions visible in domain objects, pure functions, policies, strategies, commands, or state machines.
+
+Use this skill to make callers say what they want done while the facade controls where the subsystem complexity lives.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- One user or system action requires three or more internal steps.
+- One operation coordinates two or more dependencies such as repositories, gateways, storage, queues, caches, validators, scanners, compressors, event publishers, or external services.
+- The same internal sequence is repeated across controllers, handlers, workers, UI event handlers, or services.
+- Callers know too much about implementation order, provider SDKs, database records, file storage, cache keys, queues, or external response shapes.
+- Failure handling, retry, timeout, logging, transactions, idempotency, cache invalidation, or event publishing differs between call sites for the same operation.
+- A controller, route, job, command handler, or UI event handler directly performs subsystem orchestration instead of delegating to a stable entry point.
+- The internal implementation is likely to change while the caller-facing operation should remain stable.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The facade would only call one method with a different name.
+- The caller is already simple and does not know internal subsystem details.
+- The intent is to hide messy code without clarifying ownership, tests, or boundaries.
+- Domain rules, pricing, permissions, eligibility, validation policy, or state transitions are the main problem; use `pure-core-imperative-shell`, `strategy-pattern`, or `state-machine-pattern` as appropriate.
+- Several interchangeable algorithms or policies are the main problem; use `strategy-pattern`.
+- A single external API or protocol needs translation into an internal shape; use `adapter-boundary`.
+- One state-changing intent needs payload, context, transaction, idempotency, audit, retry, outbox, and traceability semantics; use `command-pattern`, and place a facade below it only when there is a real subsystem workflow to simplify.
+- The proposed facade would become `AppFacade`, `SystemFacade`, `CommonService`, `Manager`, `Helper`, or another catch-all container.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The caller surface that should become simpler: controller, router, UI handler, command handler, worker, job, or service.
+- The high-level operation name and the user or system purpose it represents.
+- The current internal sequence, repeated call sites, or leaked subsystem details.
+- Dependencies involved and whether each is a domain service, pure policy, repository port, gateway port, adapter, queue, cache, transaction manager, idempotency store, logger, or event publisher.
+- Expected success response and expected failure cases.
+- Authorization, idempotency, retry, transaction, observability, security, and performance requirements.
+- Local conventions for request objects, context objects, `Result` values, ports, adapters, dependency injection, commands, events, and tests.
+- Relevant command-intent contract entries for verification.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+- The operation has enough real subsystem complexity to justify a facade.
+- The facade boundary is a feature area or workflow boundary, not a whole application boundary.
+- If preserving existing behavior, `behavior-preserving-refactor` has been applied before moving orchestration.
+- If external systems cross the boundary, `adapter-boundary` and `dependency-injection` have been applied so the facade depends on internal ports rather than SDK clients.
+- If expected failure or absence is part of the contract, `result-option` has been applied to the return shape.
+- If the operation is a traceable state-changing intent, `command-pattern` has been considered so the facade does not replace command semantics.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or update a narrow facade in an application or feature boundary.
+- Add request, response, context, and facade error types.
+- Add or update ports, injected collaborators, mapper functions, error normalizers, idempotency handling, transaction orchestration, retry policy calls, event publishing, cache invalidation, and logging directly needed by the facade.
+- Move repeated subsystem ordering out of controllers, handlers, workers, command handlers, or UI event handlers into the facade.
+- Add tests with fake dependencies for success, validation, permission, dependency failure, error normalization, idempotency, event publishing, transaction behavior, and sensitive-log protection.
+- Do not move domain rules into the facade just because the facade coordinates the operation.
+- Do not expose private subsystem steps as public facade methods.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the need.
+   - Use a facade when the caller needs one stable high-level operation but currently knows internal ordering or multiple subsystem details.
+   - Do not use a facade for a one-line wrapper, a pure policy, a provider translation, a lifecycle transition table, or a command execution unit by itself.
+2. Name the facade by feature area or workflow.
+   - Prefer names such as `FileUploadFacade`, `CheckoutFacade`, `BillingFacade`, `ReportExportFacade`, or `SignupFacade`.
+   - Avoid broad names such as `AppFacade`, `SystemFacade`, `CommonService`, `Manager`, `Helper`, and `Util`.
+3. Name public methods by caller intent.
+   - Use names such as `uploadImage`, `checkout`, `createInvoice`, `refundPayment`, `exportReport`, or `sendWelcomeNotification`.
+   - Avoid public methods named after internal steps such as `compress`, `scan`, `saveMetadata`, `publishEvent`, or `invalidateCache`.
+   - Keep public methods few. A facade with many public methods probably owns more than one workflow.
+4. Define request and context shapes.
+   - Accept one request object for operation data.
+   - Accept a separate context object for actor, request identifier, correlation identifier, tenant or account scope, idempotency key, source, and trusted server-side execution facts.
+   - Do not pass long primitive parameter lists, framework request objects, response objects, ORM entities, SDK clients, database connections, file streams, or loggers as request payload.
+5. Define normalized response and failure shapes.
+   - Return the minimum caller-needed success facts.
+   - Return expected failures as `Result` values or the local equivalent.
+   - Do not return provider SDK responses, ORM models, full database rows, internal domain entities, raw exception objects, secrets, internal file paths, or unnecessary metadata.
+6. Keep dependencies explicit and replaceable.
+   - Inject collaborators through constructors or function parameters.
+   - Depend on role interfaces or ports, not concrete SDK clients or framework objects.
+   - Wrap external SDKs in adapters before they reach the facade.
+   - Avoid facade-to-facade dependency chains. If two facades need the same lower-level behavior, extract a shared lower-level service, port, or pure function.
+7. Keep the facade stateless per request.
+   - Store injected dependencies, immutable configuration, and read-only policy objects only.
+   - Do not store current user, current request, current file, current transaction, intermediate result, last response, or mutable request-specific collections in facade fields.
+8. Delegate domain decisions.
+   - The facade may perform basic input checks, call validators, pass context, check permissions through a policy, coordinate dependencies, normalize errors, and return results.
+   - It must not become the home for pricing formulas, eligibility rules, permission policy, lifecycle transitions, state mutation rules, or complex calculations.
+   - Use pure core functions, policies, strategies, commands, or state machines for domain decisions and have the facade call them.
+9. Control transactions carefully.
+   - Use transactions for fast local persistence that must commit together.
+   - Do not hold a database transaction open while calling slow external APIs, email, webhooks, file uploads, payment providers, AI calls, or other long network work.
+   - When local state and external work must coordinate, use idempotency keys, pending states, action ledgers, outbox records, sagas, compensation commands, or worker jobs.
+10. Make harmful duplicate execution safe.
+    - Require idempotency for payments, refunds, order creation, account creation, file uploads, email sends, coupon use, point grants, external sync, and webhook handling.
+    - Scope idempotency by actor, tenant, workspace, account, owner, or other trust boundary.
+    - Store stable payload hashes rather than raw sensitive payloads.
+    - Return existing results for the same key and same payload hash, and return conflicts for the same key with different payload.
+11. Apply retry only when safe.
+    - Retry transient network, timeout, rate-limit, provider outage, and read operations when the operation is safe or idempotent.
+    - Do not retry invalid input, denied access, unsupported formats, domain-rule failures, terminal state transitions, or unsafe writes without idempotency.
+    - Return retryability in failure results when callers or workers need it.
+12. Add safe observability.
+    - Log high-level operation start, success, failure, duration, request identifier, actor identifier, resource identifier, error code, retry count, and idempotency-key presence when useful.
+    - Do not log passwords, tokens, cookies, API keys, raw card data, raw personal data, raw file content, full provider responses, full request bodies, or raw external exceptions.
+    - Use consistent event names such as `<domain>.<operation>.started`, `<domain>.<operation>.succeeded`, and `<domain>.<operation>.failed`.
+13. Keep performance visible.
+    - If the operation is expensive or long-running, name it with words such as `request`, `schedule`, `enqueue`, or `start`, then return a job identifier or queued status.
+    - Add timeouts to external calls.
+    - Avoid hidden N+1 behavior behind a simple facade method.
+    - Limit response data to what the caller needs.
+14. Document the public facade contract when the method is new or changed.
+    - Include purpose, input, output, failure codes, side effects, idempotency, transaction behavior, external dependencies, synchronous or asynchronous behavior, and security requirements.
+    - Keep comments concise and attached to public API surfaces rather than private implementation details.
+15. Test at the facade boundary.
+    - Use fake repositories, gateways, storage, scanners, event publishers, idempotency stores, transaction runners, and loggers.
+    - Cover success, validation failure, permission denial, missing resource, dependency failure, error normalization, event or outbox creation, idempotency hit, idempotency conflict, dangerous missing key, transaction rollback when relevant, and no sensitive logging.
+    - Do not call real external APIs, real payments, real email, real large uploads, or private methods directly in facade unit tests.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Callers invoke a high-level operation and no longer know internal subsystem order.
+- Public facade methods express caller intent, not internal steps.
+- Request data and execution context are separated.
+- Success responses and expected failures are normalized.
+- External SDK types, provider errors, ORM models, framework objects, and internal paths do not cross the facade boundary.
+- Dependencies are injected and test-replaceable.
+- Domain decisions remain outside the facade.
+- Transactions, idempotency, retry, logging, security, and performance behavior are explicit where the operation needs them.
+- Tests cover the facade's observable result and side effects through fake dependencies.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `test_related`
+- `test`
+- `lint`
+- `build`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Choose the narrowest configured verification that covers changed facade code, dependencies, tests, templates, docs, release metadata, and mustflow routing.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the facade is a one-method pass-through wrapper, remove it or merge it back into the caller.
+- If the facade grows into a god service, split it by workflow or feature area.
+- If the facade hides domain rules, extract those rules into pure functions, policy objects, strategies, state machines, or domain services.
+- If public methods expose internal steps, make them private or move them to lower-level collaborators.
+- If provider objects or errors leak through the facade result, add adapters and error mappers.
+- If the facade must call another facade, check for a lower-level shared dependency before accepting the coupling.
+- If idempotency or retry cannot be made safe for a harmful side effect, fail closed and report the manual or workflow gap.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Facade need and selected workflow boundary
+- Caller surface simplified
+- Request, context, response, and failure shapes
+- Dependencies injected and lower-level collaborators used
+- Domain decisions delegated out of the facade
+- Adapter, command, strategy, state-machine, or pure-core boundaries used with this skill
+- Transaction, idempotency, retry, logging, security, and performance choices
+- Tests or verification evidence
+- Skipped checks and remaining facade risk

package/templates/default/locales/ko/.mustflow/skills/failure-triage/SKILL.md

@@ -0,0 +1,119 @@
+---
+mustflow_doc: skill.failure-triage
+locale: ko
+canonical: false
+revision: 3
+authority: procedure
+lifecycle: mustflow-owned
+name: failure-triage
+description: 테스트, 빌드, 규칙 검사, 문서 검증 명령이 실패했거나 근본 원인을 분석해야 할 때 적용합니다.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.failure-triage
+  command_intents:
+    - test
+    - lint
+    - build
+    - docs_validate
+    - mustflow_check
+---
+
+# 실패 분석 (Failure Triage)
+
+<!-- mustflow-section: purpose -->
+## 목적
+
+실패를 임의로 수정하거나 은폐하지 않고, 가장 가능성 높은 근본 원인을 체계적으로 분석합니다.
+
+<!-- mustflow-section: use-when -->
+## 적용 시나리오
+
+- 설정된 명령 의도가 실패했을 때 적용합니다.
+- 테스트, 빌드, 규칙 검사, 문서 검증 실패의 원인을 좁혀야 할 때 적용합니다.
+
+<!-- mustflow-section: do-not-use-when -->
+## 적용하지 않는 경우
+
+- 실패 로그나 실행한 명령 의도를 확인할 수 없는 경우, 먼저 실행 기록을 확보하십시오.
+- 파괴적인 복구 명령이 필요하다고 판단되면, 사용자의 승인 전까지는 진행하지 마십시오.
+
+<!-- mustflow-section: required-inputs -->
+## 필요한 입력
+
+- 실패한 명령 의도 이름
+- 실제 실행된 `argv` 또는 `cmd`
+- 작업 디렉터리, 종료 코드, 핵심 오류 메시지
+- 관련 변경 파일
+- `.mustflow/docs/agent-workflow.md`의 실패 대응 정책
+- `.mustflow/config/commands.toml`의 실패한 명령 의도 계약
+
+<!-- mustflow-section: preconditions -->
+## 사전 조건
+
+- 작업이 사용 조건에 맞고 사용하지 않는 경우에는 해당하지 않습니다.
+- 필요한 입력을 확보했거나, 빠진 입력을 추측하지 않고 보고할 수 있습니다.
+- 현재 범위에 대해 더 높은 우선순위의 지침과 `.mustflow/config/commands.toml`을 확인했습니다.
+
+<!-- mustflow-section: allowed-edits -->
+## 허용 수정 범위
+
+- 이 스킬, 사용자 요청, `.mustflow/skills/INDEX.md`의 맞는 경로가 설명하는 범위 안에서만 수정합니다.
+- 명령 권한을 넓히거나, 프로젝트 사실을 지어내거나, 관련 없는 워크플로 파일을 변경하지 않습니다.
+
+<!-- mustflow-section: procedure -->
+## 절차
+
+1. 실패한 명령 의도와 작업 디렉터리를 확인합니다.
+2. 종료 코드와 핵심 오류 메시지를 분석합니다.
+3. 명령 생명주기와 제한 시간을 확인합니다.
+4. `oneshot` 의도인 경우, 한 번 더 실행하여 일시적인 오류인지 확인합니다.
+5. `server`, `watch`, `interactive`, `browser`, `background` 의도는 재실행하지 않고 장기 실행 명령으로 분류하여 보고합니다.
+6. 제한 시간 초과가 발생했다면 프로세스 정리 결과를 기록합니다.
+7. 원인을 환경, 설정, 코드, 테스트 문제로 분류합니다.
+8. 가장 작은 단위의 재현 명령이나 관련 파일을 식별합니다.
+9. 최소한의 수정을 적용한 후 실패한 명령 의도를 다시 실행하여 검증합니다.
+
+<!-- mustflow-section: postconditions -->
+## 사후 조건
+
+- 명확한 근거, 실행한 명령 의도, 건너뛴 확인, 남은 위험을 포함해 예상 출력을 작성할 수 있습니다.
+- 빠진 명령 의도, 알 수 없는 입력, 권한 충돌은 숨기지 않고 보고합니다.
+
+<!-- mustflow-section: verification -->
+## 검증
+
+공유 명령 정책은 `.mustflow/docs/agent-workflow.md#명령-실행-정책`을 따릅니다.
+
+관련 명령 의도:
+
+- 실패한 원래 명령 의도
+- 수정 범위에 따라 필요한 `test`, `lint`, `build`, `docs_validate`, `mustflow_check`
+
+각 의도는 `.mustflow/config/commands.toml`에서 확인하십시오.
+`status = "configured"`가 아니면 실행하지 않고, 상태와 건너뛴 이유를 보고하십시오.
+`lifecycle = "oneshot"`과 `run_policy = "agent_allowed"`가 아니면 검증 명령으로 실행하지 않습니다.
+`test_watch`, `dev`, `start`, 브라우저 UI, 원시 개발 서버 명령은 검증 명령으로 사용하지 않습니다.
+스킬 문서 내에 실제 셸 명령을 직접 작성하지 마십시오.
+
+<!-- mustflow-section: failure-handling -->
+## 실패 대응
+
+- 민감한 정보가 로그에 노출된 경우 즉시 중단하고 보고하십시오.
+- 파괴적인 명령이 필요하다고 판단되면 즉시 중단하고 승인 요청 사항으로 보고하십시오.
+- 장기 실행 프로세스가 필요한 실패인 경우, 개발 서버나 브라우저 UI를 직접 실행하지 말고 승인 요청 사항으로 보고하십시오.
+- 제한 시간 초과 후 정리가 실패했다면 프로세스 ID, 명령 의도, 정리 오류를 보고하십시오.
+- 원인이 외부 서비스나 권한 문제로 판단되면 현재까지 확인한 내용을 보고하십시오.
+
+<!-- mustflow-section: output-format -->
+## 출력 형식
+
+- 작업 요약
+- 실패한 명령 의도
+- 핵심 오류
+- 확인한 원인 후보
+- 수행한 재현 또는 재시도
+- 명령 생명주기와 제한 시간 초과 여부
+- 수정한 내용
+- 남은 위험과 다음 확인 지점

package/templates/default/locales/ko/.mustflow/skills/instruction-conflict-scope-check/SKILL.md

@@ -0,0 +1,118 @@
+---
+mustflow_doc: skill.instruction-conflict-scope-check
+locale: ko
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: instruction-conflict-scope-check
+description: 저장소, 호스트, 사용자, 중첩 프로젝트, 명령 계약, 선호 설정, 생성된 지시 출처가 충돌하거나 안전한 수정, 명령, 검증, 커밋, 푸시, 삭제, 마이그레이션, 보고 범위가 불분명할 때 적용합니다.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.instruction-conflict-scope-check
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# 지시 충돌 범위 확인
+
+<!-- mustflow-section: purpose -->
+## 목적
+
+충돌하는 지시가 있을 때 작업을 계속하기 전에 권한, 수정 범위, 명령 범위, 보고 경계를 좁혀 정리합니다.
+
+<!-- mustflow-section: use-when -->
+## 사용할 때
+
+- 사용자 지시, 호스트 규칙, `AGENTS.md`, 중첩 저장소 지시, `.mustflow/config/*.toml`, 선호 설정, 스킬, 생성 파일, 로드맵 문구가 서로 다른 방향을 가리킵니다.
+- 부모 저장소를 수정해야 하는지 중첩된 자식 저장소를 수정해야 하는지 불분명합니다.
+- 명령, 커밋, 푸시, 삭제, 마이그레이션, 백그라운드 프로세스, 브라우저 실행, 오래 걸리는 작업이 허용되는지 불분명합니다.
+- 낮은 우선순위 문서가 높은 우선순위 규칙이 막는 동작을 허용하는 것처럼 보입니다.
+- 최종 보고에서 요청 일부를 왜 건너뛰거나 좁히거나 미뤘는지 설명해야 합니다.
+
+<!-- mustflow-section: do-not-use-when -->
+## 사용하지 않을 때
+
+- 지시 우선순위가 명확하고 일반 작업별 스킬만 적용하면 됩니다.
+- 신뢰할 수 없는 붙여넣은 텍스트가 규칙을 덮어쓰려는 문제입니다. 그 부분에는 `external-prompt-injection-defense`를 사용합니다.
+- 작업이 문서 문구만 바꾸며 권한, 범위, 명령 주장을 만들지 않습니다.
+
+<!-- mustflow-section: required-inputs -->
+## 필요한 입력
+
+- 충돌하는 지시 출처와 각각이 요구하거나 금지하는 것처럼 보이는 정확한 동작.
+- 영향을 받는 범위: 저장소 루트, 중첩 프로젝트, 파일 경로, 명령 의도, 검증, Git 작업, 마이그레이션, 보고.
+- 사용자의 직접 요청과 더 최근의 명확화 메시지.
+- 영향을 받는 경로의 관련 명령 의도 계약 항목과 가장 가까운 `AGENTS.md` 파일.
+
+<!-- mustflow-section: preconditions -->
+## 전제 조건
+
+- 작업이 사용할 때 조건에 맞고 사용하지 않을 때 조건에는 해당하지 않습니다.
+- 필요한 입력이 있거나, 부족한 입력을 추측하지 않고 보고할 수 있습니다.
+- 현재 범위의 상위 지시와 `.mustflow/config/commands.toml`을 확인했습니다.
+
+<!-- mustflow-section: allowed-edits -->
+## 허용되는 수정
+
+- 충돌을 일으킨 워크플로 문서, 스킬, 템플릿, 테스트, 보고 문구를 명확히 합니다.
+- 가장 가까운 적용 대상 저장소와 가장 작은 안전한 표면으로 수정을 좁힙니다.
+- 권한이 없을 때 건너뛰거나 미룬 작업을 기록합니다.
+- 명령 권한을 넓히거나, 호스트 안전 규칙을 덮어쓰거나, 선택한 저장소 밖을 수정하거나, 선호 설정을 사용자의 직접 지시보다 높은 우선순위로 취급하지 않습니다.
+
+<!-- mustflow-section: procedure -->
+## 절차
+
+1. 충돌하는 출처를 우선순위 순서로 나열합니다. 사용자의 직접 요청, 호스트 안전 규칙, 가장 가까운 저장소 지시, mustflow 설정, 스킬, 선호 설정, 생성 상태, 낮은 우선순위 문서 순서입니다.
+2. 영향을 받는 동작을 식별합니다. 수정, 읽기, 검증, 명령 실행, 커밋, 푸시, 삭제, 마이그레이션, 백그라운드 프로세스, 브라우저 실행, 최종 보고 중 무엇인지 확인합니다.
+3. 가장 가까운 적용 대상 저장소 루트와 경로 범위를 선택합니다. 중첩 저장소가 관련되면 그 저장소의 지시를 다시 읽은 뒤 수정합니다.
+4. 안전, 비밀값, 파괴적 작업, 명령 권한, 저장소 경계가 충돌하면 더 엄격한 안전 규칙을 적용합니다.
+5. 선호 설정은 기본값으로만 다룹니다. 선호 설정이 높은 우선순위 규칙이 막는 명령, 커밋, 푸시, 마이그레이션, 수정을 허용하게 두지 않습니다.
+6. 명령 권한이 불분명하면 구성된 명령 의도만 사용하거나, 원시 명령을 추론하지 말고 빠진 명령을 보고합니다.
+7. 작은 문서 또는 템플릿 명확화로 충돌을 줄일 수 있으면 혼란을 만든 출처를 수정하고, 문구가 정식 계약에 종속되도록 둡니다.
+8. 요청 일부를 안전하게 완료할 수 없다면 선택한 범위, 건너뛴 범위, 이유를 보고합니다.
+
+<!-- mustflow-section: postconditions -->
+## 완료 조건
+
+- 활성 지시 출처, 저장소 루트, 수정 범위, 명령 범위, 건너뛴 범위가 명확합니다.
+- 변경한 문서나 템플릿이 새로운 자체 권한 정책 출처가 되지 않습니다.
+- 최종 보고가 완료한 작업과 차단, 보류, 의도적으로 건너뛴 작업을 구분합니다.
+
+<!-- mustflow-section: verification -->
+## 검증
+
+사용 가능한 구성된 일회성 명령 의도를 사용합니다.
+
+- `changes_status`
+- `changes_diff_summary`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+명확히 한 지시 또는 템플릿 표면을 더 잘 증명하는 좁은 테스트나 문서 의도가 있으면 그 의도를 사용합니다.
+
+<!-- mustflow-section: failure-handling -->
+## 실패 처리
+
+- 높은 우선순위 지시 두 개를 조화시킬 수 없다면 추측하지 말고 멈춰서 충돌을 보고합니다.
+- 가장 가까운 저장소 루트가 불분명하면 수정 전에 읽기 전용 상태와 지시 파일을 확인합니다.
+- 명령, Git 작업, 마이그레이션, 파괴적 작업에 권한이 없으면 실행하지 않습니다. 빠진 승인 또는 명령 계약을 보고합니다.
+- 검증에서 명령 권한이나 지시 권한 범위 이탈이 발견되면 관련 없는 동작을 추가하기 전에 그 이탈을 고칩니다.
+
+<!-- mustflow-section: output-format -->
+## 출력 형식
+
+- 충돌한 지시 출처
+- 선택한 우선순위 규칙과 저장소 범위
+- 허용, 축소, 건너뜀, 보류한 동작
+- 명확히 한 문서 또는 템플릿
+- 실행한 명령 의도
+- 건너뛴 검사와 이유
+- 남은 권한 또는 범위 위험

package/templates/default/locales/ko/.mustflow/skills/line-ending-hygiene/SKILL.md

@@ -0,0 +1,111 @@
+---
+mustflow_doc: skill.line-ending-hygiene
+locale: ko
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: line-ending-hygiene
+description: Apply this skill when Git reports CRLF/LF warnings or when tracked text files may need repository line-ending normalization.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.line-ending-hygiene
+  command_intents:
+    - line_endings_check
+    - changes_status
+    - mustflow_check
+---
+
+# Line Ending Hygiene
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Detect line-ending drift without silently rewriting a repository, and normalize only when a repository policy and explicit user request make it safe.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Git reports CRLF, LF, or line-ending replacement warnings.
+- A diff or formatter appears to rewrite files only because of line endings.
+- A user asks why line-ending warnings appear.
+- A user asks to normalize tracked files to the repository line-ending policy.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is unrelated to Git, text files, formatting, or command-output warnings.
+- The repository has no line-ending policy and the user has not asked to create one.
+- The only affected files are generated artifacts, package archives, images, databases, or other binary files.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The warning text or changed-file evidence.
+- Current `.gitattributes` or equivalent repository line-ending policy.
+- Current changed-file status.
+- The configured command intents for line-ending checks and manual normalization.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Required inputs are available, or missing inputs can be reported without guessing.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Update line-ending policy files only when the user asks for a repository policy change.
+- Normalize tracked text files only when the user explicitly requests normalization and the repository declares an LF policy.
+- Do not rewrite binary files, generated archives, dependency folders, or unrelated source files.
+- Do not change formatting, indentation, or content while handling line endings.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Inspect the changed-file status before deciding whether line endings are the actual issue.
+2. Use the `line_endings_check` intent when it is configured and agent-runnable.
+3. If no LF policy is declared, report the missing policy instead of normalizing files.
+4. If drift is found, report the affected tracked files and whether normalization was only previewed.
+5. Use normalization only after an explicit user request, and treat `line_endings_normalize` as manual-only unless the repository declares otherwise.
+6. After any normalization, re-run the line-ending check and a relevant validation intent for the touched scope.
+7. Keep the final report focused on policy, files changed, checks run, and remaining risk.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The agent has not silently rewritten the working tree.
+- Any normalization is tied to a declared repository policy.
+- Remaining CRLF, mixed line endings, missing policy, or manual-only command gaps are reported.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `line_endings_check`
+- `changes_status`
+- `mustflow_check`
+
+If normalization touched code, documentation, templates, or release surfaces, also run the narrowest configured verification that covers those changed files.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If Git is unavailable or the repository is not a Git working tree, report that tracked-file inspection is unavailable.
+- If a line-ending check fails because drift exists, do not treat it as a tool failure; report the affected files and next safe action.
+- If normalization fails, stop after the first relevant error and do not attempt broader formatting.
+- If the repository policy conflicts with user intent, ask for an explicit policy decision before editing.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Line-ending policy found
+- Files with CRLF or mixed line endings
+- Files normalized
+- Command intents run
+- Command intents skipped with reasons
+- Remaining line-ending risk