mustflow 1.15.97

package/templates/default/locales/ko/.mustflow/skills/result-option/SKILL.md

@@ -0,0 +1,186 @@
+---
+mustflow_doc: skill.result-option
+locale: ko
+canonical: false
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: result-option
+description: Apply this skill when expected failures, meaningful absence, null or undefined returns, thrown business errors, boolean success flags, raw string errors, repository lookups, validation, parsing, external adapter errors, or boundary error mapping need explicit Result and Option handling.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.result-option
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - test_related
+    - test
+    - lint
+    - build
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Result / Option
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Represent expected failures and meaningful absence as explicit values.
+
+Use `Result<T, E>` when an operation can fail and the caller must know why. Use `Option<T>` when a value may be absent and absence is normal. Use `throw` only for programmer errors, impossible states, corrupted invariants, fatal startup failures, or third-party exceptions before an adapter converts them at a boundary.
+
+Expected failure must be data. Meaningful absence must be data. Exceptions are only for truly exceptional situations.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Code throws for normal business failures such as validation failure, not found, permission denied, conflict, invalid state, expired token, insufficient balance, rate limit, timeout, payment rejection, or file validation.
+- Domain, application, or service functions return `null` or `undefined` to signal meaningful absence.
+- Code returns ambiguous success flags, optional error fields, raw string errors, or generic `Error` values.
+- A repository lookup can fail due to persistence and can also legitimately find no record.
+- External SDK, database, HTTP, payment, email, filesystem, or framework exceptions leak into business logic.
+- A controller, adapter, or command handler must convert typed failures into HTTP, UI, CLI, or queue responses.
+- Tests need stable success, failure, and absence cases without relying on thrown exceptions.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- A function is a total pure calculation that cannot fail and always returns a value; return `T` directly.
+- Absence is a bug because an invariant promises the value exists; use a stricter type or assert at the invariant boundary.
+- The task is only about separating decision logic from side effects; use `pure-core-imperative-shell`.
+- The task is only about provider mapping, timeout, retry, or protocol containment; use `adapter-boundary`.
+- Absence is an optional collaborator that can safely perform a neutral same-interface behavior without changing caller flow; use `null-object-pattern`.
+- The codebase already has a different established `Result` or `Option` shape and the task does not touch failure or absence handling.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The operation being modeled and whether it can fail, be absent, both, or neither.
+- Existing local `Result`, `Option`, error, `Either`, `Maybe`, exception, and response-mapping conventions.
+- The layer where failure originates and the layer where it should be handled.
+- Error categories, stable error codes, safe user-facing message rules, and sensitive data constraints.
+- Tests or examples that show successful, failing, and absent outcomes.
+- 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.
+- Existing local result and option helpers have been searched before adding new helpers.
+- If external libraries or providers throw, `adapter-boundary` has been considered for conversion at that boundary.
+- If core logic currently performs I/O or logs while deciding failures, `pure-core-imperative-shell` has been considered.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Replace expected-failure `throw` paths with `Result<T, E>`.
+- Replace domain-level `null` or `undefined` absence with `Option<T>`.
+- Convert `Option<T>` to `Result<T, E>` at the point where absence becomes an error.
+- Add or reuse small discriminated-union helpers such as `ok`, `err`, `some`, `none`, `fromNullable`, `isOk`, `isErr`, `isSome`, `isNone`, `map`, `mapErr`, `andThen`, `matchResult`, `matchOption`, `fromPromise`, `okOr`, and `allResults` when local style supports them.
+- Add typed error unions, stable error codes, categories, and boundary mappers.
+- Add tests for success, failure, absence, error code, and error category.
+- Do not introduce a broad functional programming library unless the codebase already uses that style.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Choose the return shape.
+   - Return `T` when the value always exists and the operation cannot fail.
+   - Return `Option<T>` when absence is normal and needs no explanation.
+   - Return `Result<T, E>` when failure is expected and the caller must know why.
+   - Return `Promise<Result<T, E>>` for asynchronous expected failures.
+   - Return `Result<Option<T>, E>` when an operation can fail and success may still have no value.
+   - Return `Result<void, E>` for commands that can fail but have no useful success value.
+   - Use `throw` or `assertNever` only for impossible states, programmer errors, corrupted invariants, fatal startup failures, or test assertions.
+   - Use a null object only when the absence is an optional dependency with honest neutral behavior and the caller should not branch on presence.
+2. Keep expected failures out of exceptions.
+   - Do not throw for invalid input, missing resource, denied access, duplicate state, invalid transition, external timeout, rate limit, persistence failure, or payment rejection.
+   - Catch third-party exceptions in adapters and convert them to typed errors before they cross inward.
+3. Keep absence explicit.
+   - Domain, application, and service functions should not use `null` or `undefined` as meaningful absence.
+   - Raw DTOs, database rows, framework objects, and external API responses may contain `null` or `undefined`, but boundary mappers must convert them before they enter core logic.
+4. Use structured errors.
+   - Avoid raw string errors, generic `"ERROR"` codes, and optional error fields.
+   - Prefer stable machine-readable codes such as `INVALID_EMAIL`, `USER_NOT_FOUND`, `ORDER_ALREADY_PAID`, or `PAYMENT_PROVIDER_TIMEOUT`.
+   - Prefer consistent categories such as `validation`, `authentication`, `permission`, `not_found`, `conflict`, `invariant`, `rate_limit`, `timeout`, `external`, `persistence`, and `internal`.
+   - Keep raw causes, secrets, tokens, stack traces, SQL, payment payloads, and private user data out of public responses.
+5. Preserve specificity inside the system.
+   - Use narrow error unions close to the rule when practical.
+   - Widen to an application error type near use cases or boundaries.
+   - Preserve the underlying cause when useful, but do not make domain logic depend on third-party error classes.
+6. Compose results deliberately.
+   - Return, transform with `mapErr`, handle explicitly, or convert to a boundary response.
+   - Do not swallow `err` by returning success.
+   - Avoid nested results such as `Result<Result<T, A>, B>`; prefer `Result<T, A | B>`.
+   - Avoid `Result<Promise<T>, E>`; use `Promise<Result<T, E>>`.
+   - Prefer `Result<Option<T>, E>` over `Option<Result<T, E>>`.
+7. Use names that match meaning.
+   - Use `find*` when absence is normal.
+   - Use `get*` when absence is an error.
+   - Use `parse*`, `validate*`, and fallible `create*` functions when invalid input should produce `Result`.
+   - Use `is*`, `has*`, and `can*` only when a boolean answer is truly enough and cannot fail.
+8. Map at boundaries.
+   - Repositories that can fail and may not find data should return `Result<Option<T>, E>`.
+   - Services may convert an `Option` into a domain error when the value is required.
+   - Controllers, CLI handlers, queue consumers, and UI boundary code should convert `Result` into protocol responses.
+   - Do not serialize internal `Result` or `Option` shapes as public API responses unless that is the explicit public contract.
+9. Log once at the outer boundary.
+   - Do not log the same error at every layer.
+   - Pure domain functions must not log.
+   - Boundary logs may include category, code, safe details, and non-serialized cause according to privacy rules.
+10. Test the branches.
+    - Every `Result`-returning function should have tests for success, at least one representative failure, error code, error category, and important details.
+    - Every `Option`-returning function should have tests for `some` and `none`.
+    - Test stable codes and categories rather than complete free-form messages unless the message is a public contract.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Expected failures are represented as typed data.
+- Meaningful absence is represented as `Option` or the local equivalent.
+- Normal business failures do not rely on thrown exceptions or rejected promises.
+- Infrastructure and provider errors are converted at boundaries before reaching business logic.
+- Public responses expose stable safe error shapes, not internal `Result`, raw causes, secrets, or stack traces.
+- Tests cover success, failure, and absence branches.
+
+<!-- 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`
+
+Prefer focused tests for the functions whose return shape or error handling changed. Use release or documentation checks when templates, public docs, package metadata, schemas, CLI behavior, or skill routing change.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If local helper shape conflicts with this skill, follow the local convention and report the difference.
+- If replacing exceptions would require a broad public API change, narrow the change to one boundary and report remaining throw paths.
+- If error categories or codes are missing, add the smallest local error union or mapper instead of inventing a global taxonomy too early.
+- If a supposedly impossible condition can happen through user or system behavior, model it as `Result` instead of throwing.
+- If adapter conversion is incomplete, keep third-party error handling in the adapter and report remaining leakage.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Failure or absence surface changed
+- Return shape chosen and why
+- Error codes and categories introduced or reused
+- Boundary conversions added
+- Throw paths preserved and why
+- Tests added or updated
+- Command intents run
+- Remaining exception, null, or error-shape risks

package/templates/default/locales/ko/.mustflow/skills/security-privacy-review/SKILL.md

@@ -0,0 +1,116 @@
+---
+mustflow_doc: skill.security-privacy-review
+locale: ko
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: security-privacy-review
+description: 코드, 설정, 문서, 템플릿, 로그, 원격 측정, 인증 정보, 데이터 흐름이 비밀값, 개인정보, 인증, 인가, 보존, 외부 공개에 영향을 줄 때 적용합니다.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.security-privacy-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# 보안과 개인정보 검토
+
+<!-- mustflow-section: purpose -->
+## 목적
+
+일반적인 코드, 문서, 템플릿, 설정, 로그, 보고 변경에서 생길 수 있는 보안, 개인정보, 공개 위험을 잡아냅니다.
+
+<!-- mustflow-section: use-when -->
+## 사용할 때
+
+- 변경이 인증, 인가, 세션, 관리자 동작, 테넌트 경계, 개인정보, 비밀값, 토큰, 인증 정보, API 키, 비공개 파일을 건드립니다.
+- 로그, 원격 측정, 진단, 실행 기록, 보고서, 캐시, 생성 상태, 보존, 가림 처리, 내보내기, 외부 전송을 추가하거나 수정합니다.
+- 문서, 템플릿, 예시, 테스트, 최종 보고가 민감한 데이터 처리, 개인정보 동작, 비밀값 처리, 사용자를 식별할 수 있는 데이터를 언급합니다.
+- 변경 내용이 파일명, 경로, 명령 출력, 스크린샷, 생성 산출물, 패키지 내용, 공개 문서를 통해 데이터를 노출할 수 있습니다.
+
+<!-- mustflow-section: do-not-use-when -->
+## 사용하지 않을 때
+
+- 구체적인 악용 사례 회귀 테스트가 필요합니다. 그 부분에는 `security-regression-tests`를 사용합니다.
+- 작업이 민감한 데이터와 무관한 의존성 사용 가능 여부, 패키지 버전 최신성, 산출물 패키징만 다룹니다.
+- 변경된 경계, 데이터 흐름, 공개 표면 없이 일반 보안 체크리스트만 요청받았습니다.
+
+<!-- mustflow-section: required-inputs -->
+## 필요한 입력
+
+- 변경 파일, diff 요약, 사용자 목표.
+- 관련된 민감 데이터, 행위자, 신뢰 경계, 저장, 로그, 보존, 내보내기, 외부 공개 표면.
+- 비밀값, 개인정보, 생성 상태, 공개 문서, 패키지 내용, 명령 출력에 대한 기존 프로젝트 규칙.
+- 상태, diff, 문서, 릴리스, mustflow 검증에 관한 명령 의도 계약 항목.
+
+<!-- mustflow-section: preconditions -->
+## 전제 조건
+
+- 작업이 사용할 때 조건에 맞고 사용하지 않을 때 조건에는 해당하지 않습니다.
+- 필요한 입력이 있거나, 부족한 입력을 추측하지 않고 보고할 수 있습니다.
+- 현재 범위의 상위 지시와 `.mustflow/config/commands.toml`을 확인했습니다.
+
+<!-- mustflow-section: allowed-edits -->
+## 허용되는 수정
+
+- 변경 표면이 뒷받침할 때 가림 처리, 생략, 보존, 공개, 문서 문구를 추가하거나 강화합니다.
+- 필요하지 않은 민감해 보이는 샘플 값을 문서, fixture, 템플릿, 로그, 보고서, 최종 출력에서 제거합니다.
+- 개인정보나 비밀값 처리 동작을 확인하지 못했다면 안전하다고 단정하지 말고 미검증 상태로 표시합니다.
+- 컴플라이언스 주장, 개인정보 보장, 비밀값 스캔 결과, 감사 범위를 지어내지 않습니다.
+
+<!-- mustflow-section: procedure -->
+## 절차
+
+1. 민감 표면을 식별합니다. 비밀값, 개인정보, 행위자, 권한, 저장 위치, 로그, 생성 산출물, 패키지 파일, 공개 문서, 외부 수신자를 확인합니다.
+2. 변경이 민감 정보를 만들거나, 저장하거나, 읽거나, 변환하거나, 기록하거나, 내보내거나, 삭제하거나, 보고하는지 판단합니다.
+3. 변경 표면이 공개, 패키징, 생성, 캐시, 보존, 사용자 노출, 저장소 밖 전송에 해당하는지 확인합니다.
+4. 예시, fixture, 스크린샷, 명령 출력, 최종 보고가 실제처럼 보이는 비밀값이나 불필요한 개인정보를 노출하지 않는지 확인합니다.
+5. 사용자가 결과를 이해하는 데 민감 값이 필요하지 않다면 가림 처리보다 생략이나 최소 메타데이터를 우선합니다.
+6. 변경이 인가나 악용 경계에 영향을 준다면 테스트 생성을 이 검토에 섞지 말고 `security-regression-tests`를 적용합니다.
+7. 변경된 문서, 템플릿, 패키지, mustflow 계약을 검증하는 가장 좁은 구성된 검증을 실행합니다.
+
+<!-- mustflow-section: postconditions -->
+## 완료 조건
+
+- 민감 데이터와 공개 표면을 식별했거나 모르는 부분을 명시했습니다.
+- 공개 표면과 패키지 표면에 불필요한 비밀값, 개인정보, 오해를 부르는 개인정보 보장이 없습니다.
+- 최종 보고는 민감 값을 드러내지 않으면서 남은 미검증 보안 또는 개인정보 위험을 밝힙니다.
+
+<!-- mustflow-section: verification -->
+## 검증
+
+사용 가능한 구성된 일회성 명령 의도를 사용합니다.
+
+- `changes_status`
+- `changes_diff_summary`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+변경한 민감 표면을 더 잘 증명하는 좁은 테스트, 빌드, 문서 의도가 있으면 그 의도를 사용합니다.
+
+<!-- mustflow-section: failure-handling -->
+## 실패 처리
+
+- 민감 값이 명령 출력에 나타나면 그 값을 복사하지 말고 값 없이 문제를 요약합니다.
+- 프로젝트 맥락이 부족해 개인정보나 비밀값 처리를 확인할 수 없다면 불확실성을 보고하고 안전하다고 주장하지 않습니다.
+- 패키지, 생성 산출물, 공개 문서에 민감 데이터가 포함되어 있으면 무관한 작업을 계속하기 전에 제거하거나 가립니다.
+- 검증에 사용할 수 없는 스캐너나 실제 운영 시스템이 필요하다면 빠진 검사와 남은 위험을 보고합니다.
+
+<!-- mustflow-section: output-format -->
+## 출력 형식
+
+- 검토한 민감 표면
+- 확인한 공개 또는 보존 경로
+- 적용한 가림, 생략, 문구 변경
+- 관련 보안 회귀 테스트 필요성
+- 실행한 명령 의도
+- 건너뛴 검사와 이유
+- 남은 보안 또는 개인정보 위험

package/templates/default/locales/ko/.mustflow/skills/security-regression-tests/SKILL.md

@@ -0,0 +1,131 @@
+---
+mustflow_doc: skill.security-regression-tests
+locale: ko
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: security-regression-tests
+description: 보안에 민감한 코드나 동작 변경에 악용 시나리오 회귀 테스트가 필요할 때 적용합니다.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.security-regression-tests
+  command_intents:
+    - test
+    - test_related
+    - test_audit
+    - lint
+    - build
+---
+
+# 보안 회귀 테스트
+
+<!-- mustflow-section: purpose -->
+## 목적
+
+보안에 민감한 동작 변경을 안전한 부정 테스트로 바꿔 방어 기대값을 유지합니다. 이 스킬은 취약점 스캔, 공격 코드 작성, 침투 테스트 자동화를 목적으로 하지 않습니다.
+
+<!-- mustflow-section: use-when -->
+## 사용 조건
+
+- 인증, 인가, 세션, CSRF, 요청 제한, 관리자 기능, 결제, 크레딧, 구독, 개인정보, 테넌트 경계 동작이 바뀔 때.
+- 입력값 검증, 출력 이스케이프, 파일 업로드, 경로 처리, 웹훅 콜백, 리다이렉트, 외부 주소 처리 동작이 바뀔 때.
+- 악용 가능성을 막는 버그 수정이 있었고, 같은 문제가 다시 생기지 않도록 회귀 테스트가 필요할 때.
+- 검토 중 실제 코드 경계에 붙일 수 있는 구체적인 보안 민감 지점이 확인될 때.
+
+<!-- mustflow-section: do-not-use-when -->
+## 사용하지 않는 경우
+
+- 작업이 일반 보안 검토, 의존성 점검, 정적 분석 요청, 정책 논의에 그칠 때.
+- 보호 대상 리소스, 행위자, 신뢰 경계, 기존 테스트 도구를 식별할 만큼 애플리케이션 맥락이 충분하지 않을 때.
+- 특정 라우트, 컴포넌트, 직렬화 코드, 데이터 흐름 없이 "XSS 방지" 같은 일반 테스트만 만들 수 있을 때.
+- 테스트에 실제 외부 서비스, 실시간 공격 트래픽, 자격 증명 추측, 파괴적 입력, 위험한 페이로드 수집이 필요할 때.
+- 사용자가 테스트 추가나 제안을 명시적으로 원하지 않을 때.
+
+<!-- mustflow-section: required-inputs -->
+## 필요한 입력
+
+- 보안 민감 경계를 만드는 변경 동작, 차이, 라우트, 컴포넌트, 핸들러, 데이터 모델, 버그 수정.
+- 관련 행위자, 소유권 규칙, 신뢰 경계, 허용되거나 거부되어야 하는 상태 조합, 기대 상태 코드나 오류 동작.
+- 기존 테스트 도구, 픽스처, 팩토리, 목, 요청 헬퍼, 이름 규칙.
+- `.mustflow/config/commands.toml`의 테스트, 점검, 린트, 빌드 관련 명령 의도.
+- 개인정보, 인가, 업로드, 콜백, 결제, 테넌트 규칙을 정의하는 프로젝트 맥락이나 공개 계약.
+
+<!-- mustflow-section: preconditions -->
+## 사전 조건
+
+- 작업이 사용 조건에 맞고 사용하지 않는 경우에는 해당하지 않습니다.
+- 필요한 입력을 확보했거나, 빠진 입력을 추측하지 않고 보고할 수 있습니다.
+- 현재 범위에 대해 더 높은 우선순위의 지침과 `.mustflow/config/commands.toml`을 확인했습니다.
+- 테스트를 공격 방법 설명이나 위험한 대상 접촉 없이 방어 기대값으로 작성할 수 있습니다.
+
+<!-- mustflow-section: allowed-edits -->
+## 허용 수정 범위
+
+- 이 스킬, 사용자 요청, `.mustflow/skills/INDEX.md`의 맞는 경로가 설명하는 범위 안에서만 수정합니다.
+- 새 테스트 구조를 만들기 전에 기존 테스트 파일, 픽스처, 팩토리, 목, 헬퍼 API를 우선 사용합니다.
+- 명령 권한을 넓히거나, 프로젝트 사실을 지어내거나, 외부 스캐너를 도입하거나, 공격용 페이로드 묶음을 추가하거나, 관련 없는 워크플로 파일을 변경하지 않습니다.
+
+<!-- mustflow-section: procedure -->
+## 절차
+
+1. 보호 경계를 식별합니다. 행위자, 리소스, 작업, 신뢰 경계, 기대 방어 결과를 확인합니다.
+2. 넓은 공격명만 쓰지 말고 프로젝트 사실에 맞춰 악용 시나리오를 분류합니다.
+   - 권한 없는 행위자 또는 테넌트 간 접근
+   - 잘못된 소유권 또는 권한 상승
+   - 안전하지 않은 입력 구조, 크기, 인코딩, 경로, MIME 불일치
+   - 안전하지 않은 출력 렌더링 또는 직렬화
+   - 안전하지 않은 외부 주소, 콜백, 리다이렉트, 서버 쪽 요청 대상
+   - 결제, 크레딧, 쿠폰, 구독, 환불, 권한 부여 악용
+   - 개인정보 또는 관리자 전용 접근 누출
+3. 같은 경계를 이미 검증하는 테스트가 있는지 찾습니다. 새 테스트보다 기존 테스트 보강이 더 명확하면 기존 테스트를 보강합니다.
+4. 가장 작은 안전한 부정 테스트 데이터를 만듭니다. 필요하면 허용되는 기준 사례 하나와, 경계가 악용 조건을 거부함을 증명하는 거부 사례 하나를 둡니다.
+5. 외부 요청, 업로드, 리다이렉트, 웹훅, 결제 제공자, 파일 시스템은 목이나 로컬 대역을 사용합니다. 의심스러운 실제 대상에는 접속하지 않습니다.
+6. `cannot_read_other_users_invoice` 또는 `rejects_private_network_callback_url`처럼 방어 기대값이 드러나는 이름을 붙입니다.
+7. 상태 코드, 반환 오류 모양, 바뀌지 않은 데이터베이스 상태, 발생하지 않은 부수 효과, 정리된 출력, 거부된 작업처럼 관찰 가능한 동작에 단언을 둡니다.
+8. 긴 공격 문자열을 테스트에 넣지 않습니다. 검증 규칙이나 경계를 증명하는 최소 대표 입력을 사용합니다.
+9. 결정적인 테스트를 작성할 만큼 프로젝트 맥락이 부족하면 픽스처나 동작을 지어내지 말고 구체적인 테스트 제안으로 남깁니다.
+
+<!-- mustflow-section: postconditions -->
+## 사후 조건
+
+- 명확한 근거, 실행한 명령 의도, 건너뛴 확인, 남은 위험을 포함해 예상 출력을 작성할 수 있습니다.
+- 빠진 명령 의도, 알 수 없는 입력, 권한 충돌은 숨기지 않고 보고합니다.
+- 새 테스트는 모든 변경에 테스트를 추가하는 습관이 아니라, 구체적인 보안 민감 동작 계약으로 정당화됩니다.
+
+<!-- mustflow-section: verification -->
+## 검증
+
+가능한 경우 설정된 일회성 명령 의도를 사용합니다.
+
+- `test_related`
+- `test`
+- `test_audit`
+- `lint`
+- `build`
+
+변경된 경계를 확인하는 가장 좁은 설정된 테스트 의도를 우선합니다. 테스트, 린트, 스캐너, 빌드 명령을 추측하지 않습니다. 관련 의도가 unknown 또는 manual-only 상태라면 그 상태와 남은 검증 위험을 보고합니다.
+
+<!-- mustflow-section: failure-handling -->
+## 실패 대응
+
+- 생성한 테스트가 방어 동작 누락 때문에 실패하면 테스트를 약하게 만들기 전에 해당 경계를 소유한 가장 가까운 실제 코드를 확인합니다.
+- 생성한 테스트가 픽스처나 가정 오류 때문에 실패하면 테스트 설정을 고치거나 빠진 프로젝트 사실을 보고합니다.
+- 테스트에 위험한 트래픽, 실제 자격 증명, 실제 외부 대상, 파괴적 데이터가 필요하면 로컬 목 기반 기대값이나 글로 된 테스트 제안으로 바꿉니다.
+- 기존 테스트가 이미 경계를 증명한다면 중복 사례를 추가하지 말고 기존 범위를 보고합니다.
+- 저장소의 테스트 정책상 테스트 추가 전에 더 많은 근거가 필요하면 테스트를 정당화하는 보안 민감 계약을 보고하거나 제안 단계에서 멈춥니다.
+
+<!-- mustflow-section: output-format -->
+## 출력 형식
+
+- 검토한 보안 민감 경계
+- 악용 시나리오 분류
+- 필요한 테스트 데이터
+- 추가하거나 보강한 테스트
+- 재사용한 기존 범위
+- 테스트 실패 시 의심할 코드 위치
+- 실행한 명령 의도
+- 건너뛴 명령 의도와 이유
+- 남은 보안 또는 검증 위험

package/templates/default/locales/ko/.mustflow/skills/skill-authoring/SKILL.md

@@ -0,0 +1,110 @@
+---
+mustflow_doc: skill.skill-authoring
+locale: ko
+canonical: false
+revision: 3
+lifecycle: mustflow-owned
+authority: procedure
+name: skill-authoring
+description: `.mustflow/skills/*/SKILL.md` 절차와 `.mustflow/skills/INDEX.md` 경로를 만들거나 유지보수할 때 적용합니다.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.skill-authoring
+  command_intents:
+    - mustflow_check
+    - docs_validate
+---
+
+# 스킬 작성
+
+<!-- mustflow-section: purpose -->
+## 목적
+
+mustflow 스킬을 좁고 반복 가능한 절차로 유지합니다. 스킬이 넓은 조언, 프로젝트 맥락, 명령 실행 권한 출처로 변하지 않게 막습니다.
+
+<!-- mustflow-section: use-when -->
+## 사용 조건
+
+- `.mustflow/skills/<name>/SKILL.md` 파일을 만들거나, 이름을 바꾸거나, 나누거나, 제거하거나, 크게 수정할 때.
+- `.mustflow/skills/INDEX.md`에 스킬 경로를 새로 넣거나 갱신해야 할 때.
+- 스킬의 사용 조건, 제외 조건, 필요한 입력, 명령 의도 참조, 검증, 실패 대응을 더 명확히 해야 할 때.
+- 넓은 프롬프트, 점검표, 외부 제안을 mustflow 스킬 형식에 맞게 흡수해야 할 때.
+
+<!-- mustflow-section: do-not-use-when -->
+## 사용하지 않는 경우
+
+- 기존 스킬을 코드, 문서, 테스트, 맥락, 자산 작업에 적용하기만 하는 경우.
+- 내용이 `AGENTS.md`, `.mustflow/docs/agent-workflow.md`, `.mustflow/context/PROJECT.md`, `.mustflow/config/commands.toml`에 들어가야 하는 경우.
+- 제안된 스킬이 반복 가능한 발동 조건과 절차 없이 "더 좋은 코드를 작성하라" 또는 "주의하라" 같은 넓은 조언에 머무는 경우.
+- 스킬이 프로젝트 도메인 맥락을 중복하거나, 명령 실행을 허가하거나, 원시 셸 명령을 정의하려는 경우.
+
+<!-- mustflow-section: required-inputs -->
+## 필요한 입력
+
+- 사용자 요청과 스킬이 다룰 반복 작업.
+- 기존 `.mustflow/skills/INDEX.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. 안정적인 폴더 이름과 일치하는 앞부분 메타데이터 `name`을 사용합니다. `mustflow_doc`은 `skill.<name>`, `metadata.mustflow_schema`는 `"1"`, `metadata.mustflow_kind`는 `procedure`, `metadata.pack_id`는 패키지 이름공간, `metadata.skill_id`는 `<pack_id>.<name>`으로 설정합니다.
+4. 표준 섹션을 작성합니다: 목적, 사용 조건, 사용하지 않는 경우, 필요한 입력, 사전 조건, 허용 수정 범위, 절차, 사후 조건, 검증, 실패 대응, 출력 형식.
+5. 절차를 구체적이고 좁게 유지합니다. 무엇을 읽고, 무엇을 바꾸며, 무엇을 피하고, 어떤 근거를 보고할지 포함합니다.
+6. 명령은 명령 의도 이름으로만 참조합니다. 원시 셸 명령 블록을 넣거나 스킬이 명령 실행을 허가한다고 쓰지 않습니다.
+7. `.mustflow/skills/INDEX.md`에는 트리거, 필요한 입력, 수정 범위, 위험, 검증 의도, 예상 출력을 포함한 간결한 라우팅 행을 추가하거나 갱신합니다.
+8. 스킬이 템플릿으로 설치된다면 템플릿 매니페스트, 현지화 메타데이터, 설치 문서, 패키지 테스트, 설치 파일 목록을 보여 주는 공개 문서를 함께 갱신합니다.
+
+<!-- mustflow-section: postconditions -->
+## 사후 조건
+
+- 명확한 근거, 실행한 명령 의도, 건너뛴 확인, 남은 위험을 포함해 예상 출력을 작성할 수 있습니다.
+- 빠진 명령 의도, 알 수 없는 입력, 권한 충돌은 숨기지 않고 보고합니다.
+
+<!-- mustflow-section: verification -->
+## 검증
+
+가능한 경우 설정된 일회성 명령 의도를 사용합니다.
+
+- `mustflow_check`
+- `docs_validate`
+
+스킬 변경이 테스트나 동작에 민감한 템플릿 출력도 바꾼다면 관련 설정 검증 의도, 테스트 의도, 빌드 의도도 사용합니다.
+
+<!-- mustflow-section: failure-handling -->
+## 실패 대응
+
+- `mustflow_check`가 누락된 섹션, 메타데이터 불일치, 알 수 없는 명령 의도, 원시 셸 명령, 명령 허가 주장 문제를 보고하면 관련 없는 파일을 바꾸기 전에 스킬 계약을 고칩니다.
+- 두 스킬이 겹치면 사용 조건과 제외 조건을 더 좁히거나 중복 절차를 합칩니다.
+- 필요한 명령 의도가 없으면 스킬 안에 명령을 새로 지어내지 말고 누락된 의도를 기록합니다.
+- 번역 확신도가 낮으면 원본 스킬을 기준으로 두고, 템플릿 메타데이터에서 번역을 검토 필요 상태로 표시합니다.
+
+<!-- mustflow-section: output-format -->
+## 출력 형식
+
+- 추가, 수정, 이름 변경, 제거한 스킬 파일
+- 바꾼 스킬 색인 경로
+- 참조한 명령 의도
+- 갱신한 템플릿 또는 현지화 메타데이터
+- 실행한 명령 의도
+- 건너뛴 명령 의도와 이유
+- 남은 중복, 번역, 검증 위험

package/templates/default/locales/ko/.mustflow/skills/source-freshness-check/SKILL.md

@@ -0,0 +1,111 @@
+---
+mustflow_doc: skill.source-freshness-check
+locale: ko
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: source-freshness-check
+description: 현재 버전, 외부 문서, 가격, 날짜, 일정, 제품 동작처럼 시간이 지나면 낡을 수 있는 정보에 작업이 의존할 때 적용합니다.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.source-freshness-check
+  command_intents:
+    - changes_status
+    - docs_validate_fast
+    - mustflow_check
+---
+
+# 출처 최신성 확인
+
+<!-- mustflow-section: purpose -->
+## 목적
+
+오래되었거나 확인되지 않은 주장이 코드, 문서, 템플릿, 릴리스 노트, 최종 보고에 들어가지 않게 합니다.
+
+<!-- mustflow-section: use-when -->
+## 사용할 때
+
+- 사용자가 최신, 현재, 가장 새것, 오늘, 어제, 내일, 특정 최근 날짜를 묻습니다.
+- 외부 제품, API, 패키지 버전, 가격, 법적 규칙, 일정, 스포츠, 시장, 공급자 문서에 주장이 의존합니다.
+- 문서나 사용자 문구가 지원 상태, 릴리스 동작, 명령 가능 여부, 호환성처럼 달라질 수 있는 내용을 말합니다.
+- 출처, 인용, 스크린샷, 생성된 요약이 현재 작업보다 오래되었을 수 있습니다.
+
+<!-- mustflow-section: do-not-use-when -->
+## 사용하지 않을 때
+
+- 사실이 저장소 내부에만 있고 현재 파일에서 확인할 수 있습니다.
+- 시간에 민감한 주장을 새로 넣거나 유지하지 않는 기계적 수정입니다.
+- 사용자가 사용할 원문을 직접 제공했고 서식 변경이나 번역만 요청했습니다.
+
+<!-- mustflow-section: required-inputs -->
+## 필요한 입력
+
+- 오래될 수 있는 주장이나 결정.
+- 그 주장을 뒷받침하는 파일, 명령 출력, 출처 페이지, 스크린샷, 사용자 제공 원문.
+- 보이는 경우 날짜나 버전 맥락.
+- 허용 출처, 공식 문서, 오프라인 작업에 관한 저장소 정책.
+
+<!-- mustflow-section: preconditions -->
+## 전제 조건
+
+- 작업이 사용할 때 조건에 맞고 사용하지 않을 때 조건에는 해당하지 않습니다.
+- 필요한 입력이 있거나, 부족한 입력을 추측하지 않고 보고할 수 있습니다.
+- 현재 범위의 상위 지시와 `.mustflow/config/commands.toml`을 확인했습니다.
+
+<!-- mustflow-section: allowed-edits -->
+## 허용되는 수정
+
+- 최신성 위험을 분명히 하는 곳에만 출처 날짜 메모를 추가하거나 갱신합니다.
+- 필요하면 "최신" 같은 불안정한 표현을 날짜나 버전이 있는 주장으로 바꿉니다.
+- 출처를 자신 있게 확인할 수 없으면 번역이나 문서를 검수 대상으로 표시합니다.
+- 인용, 릴리스 날짜, 호환 범위, 공급자 동작을 지어내지 않습니다.
+
+<!-- mustflow-section: procedure -->
+## 절차
+
+1. 시간, 외부 동작, 상위 출처에 의존하는 주장을 모두 찾습니다.
+2. 보조 요약보다 현재 저장소 파일, 공식 출처, 선언된 패키지 메타데이터, 사용자 제공 원문을 우선합니다.
+3. 최신성 경계를 기록합니다. 예: 확인 날짜, 확인 버전, 릴리스 태그, 문서 페이지, 또는 로컬이고 안정적이라고 보는 이유.
+4. 허용된 도구나 명령 계약 안에서 주장을 갱신할 수 없다면 보수적으로 표현하고 확인하지 못한 출처를 보고합니다.
+5. "latest", "current", "recent" 같은 열린 표현은 구체적인 날짜나 버전이 함께 있을 때만 사용합니다.
+6. 문서를 수정할 때는 넓은 출처 섹션을 만들기보다, 필요한 경우 주장 가까이 또는 최종 보고에 출처 맥락을 남깁니다.
+7. 변경 파일을 덮는 가장 작은 구성된 검증을 실행합니다.
+
+<!-- mustflow-section: postconditions -->
+## 완료 조건
+
+- 시간에 민감한 주장은 확인되었거나, 날짜/버전이 붙었거나, 확인하지 못했다고 보고되어 있습니다.
+- 문서는 스냅샷만 확인했는데도 실시간 최신처럼 읽히지 않습니다.
+- 최종 보고에는 건너뛴 최신성 확인과 남은 오래된 출처 위험이 적혀 있습니다.
+
+<!-- mustflow-section: verification -->
+## 검증
+
+사용 가능한 구성된 일회성 명령 의도를 사용합니다.
+
+- `changes_status`
+- `docs_validate_fast`
+- `mustflow_check`
+
+갱신한 주장이 실행 동작이나 공개 문서에 영향을 주면 관련 테스트, 빌드, 문서 검증 의도도 실행합니다.
+
+<!-- mustflow-section: failure-handling -->
+## 실패 처리
+
+- 요청한 출처에 접근할 수 없다면 접근 공백을 보고하고 그 주장을 현재 사실처럼 말하지 않습니다.
+- 출처가 충돌하면 가장 권위 있는 출처를 우선하고 충돌을 보고합니다.
+- 최신성 확인이 번역 문서의 의미를 바꾼다면 해당 번역을 검수 대상으로 표시합니다.
+- 최신성 확인에 현재 호스트 권한 밖의 네트워크 접근이나 도구가 필요하면 권한 경계에서 멈추고 남은 미확인 항목을 밝힙니다.
+
+<!-- mustflow-section: output-format -->
+## 출력 형식
+
+- 찾은 최신성 민감 주장
+- 확인한 출처 또는 버전
+- 바꾼 문구 또는 보수적으로 남긴 주장
+- 실행한 명령 의도
+- 건너뛴 출처 확인과 이유
+- 남은 오래된 출처 위험