feel-flow

Keep environment variables and deploy-time settings inside a typed config boundary

Enforce six-layer forward-only imports: types -> config -> repositories -> services -> runtime -> ui

Write ADRs for harness boundaries, provider choices, dependency exceptions, and enforcement changes

Introduce the six-layer harness into an existing TypeScript project gradually

Fix six-layer harness violations reported by dependency-cruiser, ESLint, or review

Review a PR for six-layer harness, provider, ADR, and enforcement consistency

Keep auth, telemetry, flags, and external connectors behind provider interfaces

Keep database and ORM access inside repository implementations

Enforces error handling standards: silent error prohibition, custom error class hierarchy (AppError base with ValidationError, NotFoundError, InternalError), Result pattern (Result.ok/Result.fail), proper try-catch with error type checking, structured error logging with context metadata, and HTTP status code mapping. Use when implementing error handling, reviewing catch blocks, or designing error responses.

Enforces project coding standards during code review: naming conventions (PascalCase for classes, camelCase for methods/variables, UPPER_SNAKE_CASE for constants, kebab-case for files), standard file structure, anti-magic-number policy, file size limits (500/800 lines), security patterns, and design patterns. Use when reviewing code, writing new code, or checking adherence to project conventions.

Guides test implementation following the test pyramid (75% unit, 20% integration, 5% E2E), Arrange-Act-Assert pattern, and project coverage thresholds (branches 70%, functions 80%, lines 80%, statements 80%). Covers test naming conventions, test independence, mock and stub patterns, test data management with fixtures and builders, and CI integration. Use when writing tests, reviewing test code, or setting up test infrastructure.

Creates and reviews agent skills safely by enforcing deletion-prevention harness rules: no fixed absolute temp paths, no cwd-dependent cleanup, no wildcard deletes, no workspace-external file operations, no silent cleanup failures, and mandatory temp-root validation before any destructive command. Use when creating a new skill, updating an existing SKILL.md, or reviewing prompts/runbooks that include temp files, extraction, cleanup, PowerShell, bash, rm, del, Remove-Item, or archive expansion.

プロジェクトガイドラインへの準拠をチェックし、バグ、スタイル違反、コード品質問題を検出する。PRレビュー時に使用。

機能を保持したまま不要な複雑性を排除し、コードの簡潔性と可読性を向上させる。30行超の関数や3段以上のネスト検出時に使用。

コードコメントの正確性、完全性、長期的な保守性を分析する。JSDoc、コメント、README等のドキュメントが変更された場合に使用。

サイレント失敗を検出し、堅牢なエラーハンドリングを確保する。PRレビューでのエラーハンドリング検査時に使用。

プロジェクトの規約に従ったReactコンポーネントを生成する。新規コンポーネントやページの作成時に使用。

既存の書籍本文から用語を自動抽出し、terminology.yamlを生成するスキル。

用語集に基づいて表記揺れを検出し、修正を提案する。文書の校正時に使用。

コードレビューを行い、品質レポートを出力する。プルリクエストのレビュー、コード品質チェック時に使用。

ファクトチェック。研究論文、統計データ、技術的主張の裏付けを検証。

日本語技術書の総合校正スキル。章単位または書籍全体の校正を実行し、重要度別にレポートを出力する。

章構造・フォーマットチェック。見出しの階層構造と必須セクションの有無を検証。

Conventional Commitsに従ったコミットを実行する。変更差分を分析し、適切なtype・スコープ・メッセージを生成する。

サービス名と概要を受け取って `src/content/services/` 配下にサービスページを追加するスキル。「○○というサービスページを追加して」「新サービスのページを作って」と言われたときに使用する。

短いニュース 1 件を `src/content/news/` に追加するスキル。「お知らせを 1 つ追加して」「○○のニュースを書いて」と言われたときに使用する。URL を伴う「ブログ記事化」は write-blog スキルを使うこと。

受け取った URL を読み込み、指定された深掘りポイントに沿ってブログ記事化し、`src/content/news/` 配下に Markdown ファイルを追加して PR を作成するスキル。「URL を渡すからブログ記事化して」「この記事をベースに ○○ を深掘りして」と言われたときに使用する。

ページ 1 枚または PR 全体を SEO 観点でレビューするスキル。title / description の長さ、見出し階層、内部リンク、JSON-LD、画像 alt を一通り確認する。「この記事を SEO レビューして」「PR の SEO チェックして」と言われたときに使用する。

Use when finding improvements, bugs, or refactoring opportunities outside the current task's scope during implementation or code review. First decides whether the finding is small enough to fix inline in the same PR, or large enough to deserve a new GitHub Issue, then takes action. Triggers on phrases like "スコープ外", "別Issueで", "out of scope", "別対応", "後で対応", or when review tools flag suggestions for future work.

エージェントハーネス（ツール設計・コンテキスト管理・マルチエージェント構成・失敗設計）の設計をレビューし、重大度付きの指摘を出すスキル。設計書・構成ドキュメント・リポジトリを入力に、7観点のチェックと根拠付き指摘・良い点・情報不足を報告する。「ハーネス設計をレビューして」「エージェント構成のレビュー」「この構成で暴走しないか見て」「マルチエージェント設計の妥当性確認」と言われたとき、またはエージェントシステムの実装前・本番化前の設計確認で使用。

開発タスクを仕様駆動の5ゲート（要件→仕様→計画→実装→検証）で進行管理するスキル。機能要求や Issue を受けたとき、受け入れ基準の確定と仕様文書の先行更新をゲートとして強制し、進行表に証拠付きで記録する。「仕様駆動で進めて」「spec-driven」「ゲート管理して」「要件から順に固めて」「受け入れ基準を決めてから実装して」と言われたとき、または曖昧な機能要求のまま実装に入りそうなときに使用。