/check

name: check
context: fork
description: |
  This skill should be used when the user wants to verify their changes
  before pushing, or update the project's rule checklists.
  Phase 1: validate changed files against .hoyeon/rules/ checklists and report
  PASS/WARN. Phase 2 (conditional): propose rule additions when unmatched
  patterns are detected. Essential before git push.
  Trigger phrases: "check", "checklist", "verify changes", "what did I miss",
  "pre-push check", "cascading changes", "any more changes needed",
  "update checklist", "update rules", "rules update",
  "체크", "체크리스트", "변경 확인", "빠뜨린 거 없나", "push 전 확인",
  "뭐 더 건드려야 해?", "연쇄 변경 확인", "규칙 갱신".

Check — Change Verification + Rule Evolution

> Analyze git diff against `.hoyeon/rules/` to catch missed cascading changes, then propose rule updates when new unmatched patterns are detected.

**Prerequisite**: The project must have a `.hoyeon/rules/` directory containing rule files with YAML frontmatter. If `.hoyeon/rules/` does not exist, guide the user to create it: `mkdir -p .hoyeon/rules`, then help them write their first rule file following `${baseDir}/references/rules-authoring.md`.

**Two-phase structure:**

• **Phase 1** (always): Validate changes — produce PASS/WARN results
• **Phase 2** (conditional): Propose rule updates — only when unmatched patterns exist

---

Phase 1: Change Validation

1. Collect Changed Files

# Gather committed + uncommitted changes
git diff --name-only HEAD~1..HEAD
git diff --name-only --cached
git diff --name-only

Deduplicate and store as `CHANGED_FILES`.

2. Build Rule Graph and Match

Read YAML frontmatter from all `.hoyeon/rules/*.md` files to construct the rule graph. Refer to `references/rules-authoring.md` ("Structure" section) for the frontmatter schema.

**Matching order:** 1. Glob-match each file in `CHANGED_FILES` against every rule's `triggers` patterns 2. Follow `depends_on` edges from matched rules to pull in related rules (1-depth only) 3. Finalize the active rule set 4. **Store unmatched files separately as `UNMATCHED_FILES`** (used in Phase 2)

**Note:** Meta documents (e.g., RULES.md) are excluded from matching.

3. Parallel Subagent Verification

Spawn one subagent per active rule using the **Agent tool (`subagent_type="general-purpose"`)** and run them in parallel.

Pass each subagent:

• The `CHANGED_FILES` list
• The rule file's body (checklist content)
• The actual diff of changed files (`git diff`)

Each subagent: 1. Applies checklist items against CHANGED_FILES 2. Identifies cases where a file was changed but related files were not 3. Reads the actual diff for WARN items to determine if the omission is genuine 4. Returns results classified as PASS / WARN / Not Applicable

4. Aggregate and Output Results

Collect all subagent results and output them **grouped by category**: domain rules first, then concern rules, then pipeline rules.

## Phase 1: Verification Results

### PASS (N items)
#### domain
- [billing] schema.ts changed -> migration file created
#### concern
- [infra] .env changed -> terraform synced
#### pipeline
- [api-codegen] swagger changed -> types regenerated

### WARN (N items)
#### concern
- [ux] en.json changed -> ko.json not updated

### Not Applicable (N items)
- [docs] no docs/ changes

5. Execute agents/commands

If active rules have `agents` or `commands` fields:

• **agents**: Run automatically via the Agent tool for additional verification. Merge any WARNs from agent results into the Phase 1 WARN list.
• **commands**: Present the commands to the user for manual execution (e.g., `pnpm generate:api`).

6. Process WARNs

For each WARN item: 1. Read the changed code to determine whether a change is actually needed 2. Distinguish between intentional omissions and accidental misses 3. For genuine misses, specify exactly which file and section needs modification

---

Phase 2: Rule Update Proposals (Conditional)

> **Phase 2 trigger conditions** — Execute Phase 2 if ANY of the following is true: > 1. `UNMATCHED_FILES` contains at least one meaningful source file (`.ts`, `.tsx`, `.json`, `.yaml`, `.tf`, etc.) — exclude meta files (`.md`, lock files, etc.) > 2. Any WARN from Phase 1 indicates a **rule gap** (not a rule violation) > > **Skip condition**: If `UNMATCHED_FILES` is empty AND no WARNs indicate rule gaps, skip Phase 2 and proceed directly to follow-up actions (step 9). > > **Distinguishing rule gaps from rule violations**: If a WARN was caused by violating an existing checklist item, it is a rule violation (handled in Phase 1). If no checklist item exists anywhere that could have caught the WARN in advance, it is a rule gap — this triggers Phase 2.

7. Analyze Patterns and Cross-Reference Rules

Analyze `UNMATCHED_FILES` and Phase 1 WARN results to identify:

• **Uncovered change patterns** — file changes not matched by any rule's `triggers`
• **Near-miss cascading changes** — duplicate logic across multiple locations where only some were updated
• **Newly discovered sync points** — relationships where changing one location requires updating another

Read `references/rules-authoring.md` for authoring guidelines, then classify findings:

• **Existing rule needs new items** — propose the rule file and specific items to add
• **New rule file needed** — entirely new pattern not covered by any existing rule; include the `category` field (domain | concern | pipeline)

8. Output Rule Update Proposals

## Phase 2: Rule Update Proposals

1. [subscriptions.md] Add sync check for URL detection functions across 3 apps
   - Reason: isSubstackUrl() duplicated in 3 locations, only 2 updated
2. [New file: webhook.md] Add sync check for webhook event changes
   - category: domain
   - Reason: new domain with no existing rule coverage

**Confirm each proposal with AskUserQuestion:**

• **"Add"** — Apply the item to the rule file
• **"Edit & Add"** — Adjust the content before adding
• **"Skip"*