feat: skills の一律強制を縮小し内容を現行世代に更新（#116、v0.66.0）

CHANGELOG.md

@@ -4,6 +4,18 @@ All notable changes to this project will be documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/), and this project adheres to [Semantic Versioning](https://semver.org/).
 
+## [0.66.0] - 2026-06-12
+
+LLM 性能監査（#121）P3 の最終弾（#116）。skills の一律強制を縮小し内容の鮮度を更新した。
+
+### Changed
+- **tdd-workflow（#116）**: 「全作業（バグ修正・リファクタ含む）に TDD + 80% カバレッジを一律強制」を「TDD の明示要求時、またはカバレッジ要件のある新機能開発」に限定。日常的なバグ修正・リファクタは「変更した挙動に focused なテスト」（rules/testing.md と整合）。絶対表現（ALWAYS / not optional）をワークフロー内デフォルトに緩和、80% は「プロジェクト基準に合わせた目安」へ。npm 固定コマンドをスタック別例示化、E2E は Web UI 限定と明記、references は JS/TS 向けと注記
+- **verification-loop（#116）**: 6 観点とレポート様式は維持しつつ、固定コマンド + `| tail -20` 等の出力打ち切り指定を例示に降格・削除。Phase 5 の `grep "sk-"` 式 secret 検査を「gitleaks/trufflehog → security-review skill → 最低限 diff 追加行の確認」に置換（リポジトリ全体 grep で PASS を出さない）。実行不能な「15 分ごとに検証」「mental checkpoint」の Continuous Mode セクションを削除（定期実行は hook / /loop の領分と明記）
+- **eval-harness（#116）**: 対話セッションでは測定不能な pass@k / pass^k 指標の手書き記録と Model-Based Grader の 1-5 自己採点を削除。「PASS (pass@2)」は「PASS (attempts: 2)」に改名（再試行回数として有用）。Model Grader はサブエージェントによる YES/NO チェックリスト + PASS/FAIL に置換。「本当に pass@k を測るなら headless 自動実行スクリプトで」と注記。成功条件の事前定義・Code-Based Grader・Eval Storage は維持
+- **prompt-patterns（#116）**: 旧世代の「ultrathink」キーワード詠唱機構の説明を「Deep Reasoning」（Plan Mode / harness の thinking・effort 制御 / 自然言語で深さを促す）に置換。Phase-wise Gated Plan の「Estimated context usage」（モデルに実測手段がなかった時代の項目）を「Rollback plan if verification fails」に差し替え
+- **frontend-patterns（#116）**: メモ化 3 行（useMemo/useCallback/React.memo）を React Compiler 未採用プロジェクト条件付きに変更 + Compiler 採用時の注記。手書き useQuery フック（onSuccess/onError 形・依存配列の無限再フェッチ footgun 含む）を TanStack Query / SWR の最小例に置換。Framer Motion → motion 改称（`import from 'motion/react'`）
+- **project-guidelines-example（#116）**: 例示コードの `claude-sonnet-4-5-20250514`（存在しない疑いのある日付サフィックス付き旧 ID）を `claude-opus-4-8` + 「最新 ID は公式 docs で確認」コメントに修正
+
 ## [0.65.0] - 2026-06-12
 
 LLM 性能監査（#121）P3 の第 2 弾（#115）。commands の低優先掃除（ネイティブ重複・呪文・ハードコードの除去）。

agents/tdd-guide.md

@@ -1,6 +1,6 @@
 ---
 name: tdd-guide
-description: Test-driven development guide. Use when adding behavior, fixing bugs, or refactoring code where tests should describe the expected contract.
+description: Test-driven development guide. Use when the user explicitly requests TDD or tests-first development, or when building new behavior where test coverage is a stated requirement.
 tools: Read, Write, Edit, Bash, Grep
 model: sonnet
 ---

skills/eval-harness/SKILL.md

@@ -14,7 +14,6 @@ Eval-Driven Development treats evals as the "unit tests of AI development":
 - Define expected behavior BEFORE implementation
 - Run evals continuously during development
 - Track regressions with each change
-- Use pass@k metrics for reliability measurement
 
 ## Eval Types
 
@@ -58,16 +57,16 @@ npm run build && echo "PASS" || echo "FAIL"
 ```
 
 ### 2. Model-Based Grader
-Use Claude to evaluate open-ended outputs:
+Have a separate instance (subagent) review open-ended outputs against a checklist:
 ```markdown
 [MODEL GRADER PROMPT]
-Evaluate the following code change:
+Review the following code change and answer each question with YES/NO plus evidence:
 1. Does it solve the stated problem?
 2. Is it well-structured?
 3. Are edge cases handled?
 4. Is error handling appropriate?
 
-Score: 1-5 (1=poor, 5=excellent)
+Verdict: PASS/FAIL
 Reasoning: [explanation]
 ```
 
@@ -80,19 +79,7 @@ Reason: Why human review is needed
 Risk Level: LOW/MEDIUM/HIGH
 ```
 
-## Metrics
-
-### pass@k
-"At least one success in k attempts"
-- pass@1: First attempt success rate
-- pass@3: Success within 3 attempts
-- Typical target: pass@3 > 90%
-
-### pass^k
-"All k trials succeed"
-- Higher bar for reliability
-- pass^3: 3 consecutive successes
-- Use for critical paths
+Note: statistical metrics like pass@k require running the same task k times independently. If you truly need them, implement an automated script (e.g., a headless `claude -p` loop), not manual bookkeeping in an interactive session.
 
 ## Eval Workflow
 
@@ -109,10 +96,6 @@ Risk Level: LOW/MEDIUM/HIGH
 1. Existing login still works
 2. Session management unchanged
 3. Logout flow intact
-
-### Success Metrics
-- pass@3 > 90% for capability evals
-- pass^3 = 100% for regression evals
 ```
 
 ### 2. Implement
@@ -135,9 +118,9 @@ EVAL REPORT: feature-xyz
 ========================
 
 Capability Evals:
-  create-user:     PASS (pass@1)
-  validate-email:  PASS (pass@2)
-  hash-password:   PASS (pass@1)
+  create-user:     PASS (attempts: 1)
+  validate-email:  PASS (attempts: 2)
+  hash-password:   PASS (attempts: 1)
   Overall:         3/3 passed
 
 Regression Evals:
@@ -146,10 +129,6 @@ Regression Evals:
   logout-flow:     PASS
   Overall:         3/3 passed
 
-Metrics:
-  pass@1: 67% (2/3)
-  pass@3: 100% (3/3)
-
 Status: READY FOR REVIEW
 ```
 
@@ -188,11 +167,10 @@ Store evals in project:
 
 1. **Define evals BEFORE coding** - Forces clear thinking about success criteria
 2. **Run evals frequently** - Catch regressions early
-3. **Track pass@k over time** - Monitor reliability trends
-4. **Use code graders when possible** - Deterministic > probabilistic
-5. **Human review for security** - Never fully automate security checks
-6. **Keep evals fast** - Slow evals don't get run
-7. **Version evals with code** - Evals are first-class artifacts
+3. **Use code graders when possible** - Deterministic > probabilistic
+4. **Human review for security** - Never fully automate security checks
+5. **Keep evals fast** - Slow evals don't get run
+6. **Version evals with code** - Evals are first-class artifacts
 
 ## Example: Adding Authentication
 
@@ -221,7 +199,7 @@ Run: /eval check add-authentication
 ### Phase 4: Report
 EVAL REPORT: add-authentication
 ==============================
-Capability: 5/5 passed (pass@3: 100%)
-Regression: 3/3 passed (pass^3: 100%)
+Capability: 5/5 passed
+Regression: 3/3 passed
 Status: SHIP IT
 ```

skills/frontend-patterns/SKILL.md

@@ -15,29 +15,31 @@ Composition over inheritance, compound components, render props.
 See [references/component-patterns.md](references/component-patterns.md) for implementations.
 
 ### Custom Hooks
-Reusable hooks: useToggle, useQuery, useDebounce.
+Reusable hooks: useToggle, useDebounce; server state via TanStack Query / SWR.
 See [references/hooks-patterns.md](references/hooks-patterns.md) for implementations.
 
 ### State Management & Performance
 Context + Reducer pattern, memoization, code splitting, virtualization.
 See [references/state-performance.md](references/state-performance.md) for implementations.
 
 ### Forms, Error Boundaries, Animation & Accessibility
-Controlled forms with validation, ErrorBoundary, Framer Motion, keyboard navigation, focus management.
+Controlled forms with validation, ErrorBoundary, motion (formerly Framer Motion), keyboard navigation, focus management.
 See [references/forms-errors-a11y.md](references/forms-errors-a11y.md) for implementations.
 
 ## Quick Decision Guide
 
 | Need | Pattern |
 |------|---------|
 | Shared state across siblings | Context + Reducer |
-| Expensive computation | `useMemo` |
-| Stable callback reference | `useCallback` |
-| Prevent unnecessary re-renders | `React.memo` |
+| Expensive computation (no React Compiler) | `useMemo` |
+| Stable callback reference (no React Compiler) | `useCallback` |
+| Prevent unnecessary re-renders (no React Compiler) | `React.memo` |
 | Large list rendering | Virtualization (`@tanstack/react-virtual`) |
 | Heavy component | `lazy()` + `Suspense` |
 | Form validation | Controlled form + error state |
 | Graceful error handling | ErrorBoundary class component |
 | Keyboard accessible UI | `role`, `aria-*`, `onKeyDown` handlers |
 
+**Note**: On projects using React Compiler, manual memoization (`useMemo`/`useCallback`/`React.memo`) is generally unnecessary; add it only when profiling shows a real problem.
+
 **Remember**: Choose patterns that fit your project complexity. Not every project needs every pattern.

skills/frontend-patterns/references/forms-errors-a11y.md

@@ -88,10 +88,10 @@ export class ErrorBoundary extends React.Component<
 }
 ```
 
-## Framer Motion Animations
+## motion Animations (formerly Framer Motion)
 
 ```typescript
-import { motion, AnimatePresence } from 'framer-motion'
+import { motion, AnimatePresence } from 'motion/react'
 
 export function AnimatedList({ items }: { items: Item[] }) {
   return (

skills/frontend-patterns/references/hooks-patterns.md

@@ -10,46 +10,31 @@ export function useToggle(initialValue = false): [boolean, () => void] {
 }
 ```
 
-## Async Data Fetching Hook
+## Server State (Data Fetching)
+
+Do not hand-roll data-fetching hooks. Use a dedicated server-state library — TanStack Query or SWR — which handles caching, deduplication, retries, and revalidation correctly.
 
 ```typescript
-interface UseQueryOptions<T> {
-  onSuccess?: (data: T) => void
-  onError?: (error: Error) => void
-  enabled?: boolean
+// TanStack Query (v5: isPending; v4 used isLoading)
+import { useQuery } from '@tanstack/react-query'
+
+export function UserProfile({ userId }: { userId: string }) {
+  const { data, error, isPending } = useQuery({
+    queryKey: ['user', userId],
+    queryFn: () => fetchUser(userId),
+  })
+
+  if (isPending) return <Spinner />
+  if (error) return <ErrorMessage error={error} />
+  return <Profile user={data} />
 }
+```
 
-export function useQuery<T>(
-  key: string,
-  fetcher: () => Promise<T>,
-  options?: UseQueryOptions<T>
-) {
-  const [data, setData] = useState<T | null>(null)
-  const [error, setError] = useState<Error | null>(null)
-  const [loading, setLoading] = useState(false)
-
-  const refetch = useCallback(async () => {
-    setLoading(true)
-    setError(null)
-    try {
-      const result = await fetcher()
-      setData(result)
-      options?.onSuccess?.(result)
-    } catch (err) {
-      const error = err as Error
-      setError(error)
-      options?.onError?.(error)
-    } finally {
-      setLoading(false)
-    }
-  }, [fetcher, options])
-
-  useEffect(() => {
-    if (options?.enabled !== false) refetch()
-  }, [key, refetch, options?.enabled])
+```typescript
+// SWR (2.x: isLoading)
+import useSWR from 'swr'
 
-  return { data, error, loading, refetch }
-}
+const { data, error, isLoading } = useSWR(`/api/users/${userId}`, fetcher)
 ```
 
 ## Debounce Hook

skills/frontend-patterns/references/state-performance.md

@@ -49,6 +49,8 @@ export function MarketProvider({ children }: { children: React.ReactNode }) {
 
 ## Memoization
 
+For projects **not** using React Compiler. With the Compiler enabled, manual memoization is generally unnecessary — add it only when profiling shows a real problem.
+
 ```typescript
 // useMemo for expensive computations
 const sortedMarkets = useMemo(() => {

skills/project-guidelines-example/references/code-patterns.md

@@ -67,7 +67,7 @@ class AnalysisResult(BaseModel):
 async def analyze_with_claude(content: str) -> AnalysisResult:
     client = Anthropic()
     response = client.messages.create(
-        model="claude-sonnet-4-5-20250514",
+        model="claude-opus-4-8",  # Check the official docs (Models Overview) for the latest model IDs
         max_tokens=1024,
         messages=[{"role": "user", "content": content}],
         tools=[{

skills/prompt-patterns/SKILL.md

@@ -65,12 +65,14 @@ Process these 5 files in parallel using subagents. Each subagent handles one fil
 Collect all results and present a unified summary.
 ```
 
-### Ultrathink
-For complex reasoning tasks, include the keyword:
+### Deep Reasoning
+For complex design and architecture decisions:
+- Use Plan Mode for work that benefits from an explicit reviewed plan before changes.
+- Extended thinking is controlled by the harness (thinking toggle / effort settings), not by magic keywords in the prompt.
+- In the prompt itself, ask for depth in natural language, e.g.:
 ```
-ultrathink about the best architecture for this system
+Before implementing, compare alternative designs and their trade-offs.
 ```
-Triggers extended thinking mode for higher effort reasoning.
 
 ## Debugging Patterns
 
@@ -93,7 +95,7 @@ Look at this screenshot. The layout is broken. Fix it.
 Create a phase-wise plan for this feature. Each phase must have:
 1. Clear deliverable
 2. Test criteria (unit, integration, or manual verification)
-3. Estimated context usage
+3. Rollback plan if verification fails
 
 Do not proceed to the next phase until the current phase passes all tests.
 ```