specsfy-setup

プロジェクトのコンテキストを準備する

対話モード

対話モード：perguntas。 質問を作成する前に、.specsfy/Spec.md の 番号付き質問の規約を読んで適用してください。

知識レベルと回答の記憶

セットアップでは、短く適応的な対話を行います。固定のアンケートは使用せず、 すでに確認済みの内容を再度尋ねることもありません。

質問を作成する前に、次の順序で読み込んでください。

1. 存在する場合は .specsfy/USER-PROFILE.md。
2. 現在の会話と、すでに得られた回答。
3. PROJECT.md、DESIGNSYSTEM.MD、.specsfy/STACK.md、 .specsfy/RULES.md、.specsfy/DATABASE.md、.specsfy/PACKAGES.md。
4. 存在する場合は AGENTS.md、CLAUDE.md、.specsfy/SPECKIT.md と、そこに記載された関連資料。
5. Inbox、backlog、該当する仕様書。これらのファイルは変更しないでください。

回答済みの話題を頭の中で整理してください。本人の明示的な発言、または資料にある明確な情報は、質問と異なる言葉で表現されていても、その話題への回答として扱います。すでに明らかな内容について、確認や選択、言い換えを求めないでください。情報の欠落、矛盾、または最後の確認以降に変更された情報についてのみ質問してください。

全般的なレベルがプロフィールにも会話にも記録されていない場合は、最初のラウンドで次の質問をしてください。

Pergunta 1. Como você prefere receber as orientações deste setup?
1. Iniciante: explique os termos técnicos e o efeito de cada escolha antes de prosseguir.
2. Intermediário: conheço os fundamentos e prefiro explicações curtas junto das escolhas.
3. Experiente: posso responder com detalhes de stack, arquitetura, comandos e integrações.
4. Escrever outra resposta
5. Gere outras opções
6. Avançar

回答を iniciante、intermediário、experiente のいずれかに正規化し、情報源と日付を添えて .specsfy/USER-PROFILE.md に記録してください。プロフィールに確認済みのレベルが記録されている場合は、質問せずそのレベルを使用してください。会話とプロフィールでレベルが異なる場合は、その矛盾を解決する質問を1つだけ行い、更新を記録してください。

ラウンドごとに説明の詳しさを調整してください。

• iniciante：各専門用語を質問内で説明し、その情報が必要な理由と、各選択肢が実際にどのような影響をもたらすかを説明してください。
• intermediário：一般的な専門用語を使い、選択肢を取り違えるおそれがある場合にのみ、短い説明を加えてください。
• experiente：未確定の話題について、バージョン、フレームワークの境界、認証、永続化、テスト、インターフェース、デプロイ、連携を直接尋ねてください。

レベルは言葉遣いの調整に使うものであり、回答を推測してよいという意味ではありません。分野によって本人の経験が異なると分かった場合は、その分野の説明を調整してください。確認なしに全般的なレベルは変更しないでください。各回答の後にプロフィールを更新し、その話題を未回答事項の一覧から削除してから、次の質問を選んでください。分野ごとの質問数の上限である8問を守り、番号付き質問の規約の残りの内容にも従ってください。

セットアップの適応型ロードマップ

ディレクトリを確認してプロジェクトを読み込んだ後、必要な項目のうち、まだ回答が確認されていないものを最初に選択します：

1. 製品の目的と主な成果；
2. ユーザー、チーム、役割；
3. アクセス、認証、権限；
4. 主なデータ、関連性、保持期間；
5. 画面、ナビゲーション、インターフェースの状態；
6. テスト、オブザーバビリティ、デプロイ；
7. 外部連携と依存サービス。

各ラウンドの前に項目マップを参照してください。情報源に項目が明確に記載されている場合は、プロファイルに情報源を記録して次に進みます。2つの情報源に食い違いがある場合は、その相違を解決するためだけに質問します。適用されるすべての項目が確認済みであれば、セットアップはファイルの調整へ進むと伝え、形式的な質問は作成しないでください。

確認済みのレベルに合わせて質問の表現を調整します。初心者には、質問内で用語を説明し、回答を何に使うかを伝え、各選択肢の実際の影響を示します。中級者には、技術用語と簡潔な説明を使います。経験豊富な方には、まだ確認されていないバージョン、フレームワークの境界、認証戦略、永続化、テスト、オブザーバビリティ、デプロイ、連携の契約について直接質問します。

各ラウンドでは、.specsfy/Spec.md の契約に従って、質問、番号付き選択肢、別の回答を書く、他の選択肢を生成、次へを提示します。回答後、内容を標準化し、領域、項目、回答、情報源、日付、適用範囲を .specsfy/USER-PROFILE.md に記録してから、次へ進みます。

セットアップにおける必須の機能範囲

製品を読み込む際、各ビジネスエンティティを、ユーザーが実行する必要のある操作と関連付けてください。ワークフローでレコードの管理が必要な場合は、作成、参照、編集、削除の対応範囲を確認します。読み取り専用データ、変更不可能な履歴、イベント、または連携によって管理される情報に CRUD を無理に適用しないでください。情報源に必要な操作が示されていない場合は、対応範囲を記録する前に、番号付き契約に基づくラウンドを通じてユーザーに確認します。

繰り返し使用する各画面について、システムメニューからのアクセス方法を特定し、項目、遷移先、権限、レスポンシブ時の動作を INTERFACE.md に記録します。技術的なルート、コールバック、またはリダイレクト経由でのみアクセスするステップは、そのアクセスがワークフロー自体で確認できる場合、メニューから除外できます。画面にリンクを設定するか、どのメニューに表示するかが不明な場合は、先に進む前に1回のラウンドでユーザーに確認します。

セットアップでは、これらの要件を永続的なコンテキストに記録し、動作の変更はバックログと仕様へ引き継ぎます。独自に画面、ルート、永続化を作成することはありません。後続の実装では、確認済みの CRUD とリンクを、個別のタスクとテストで対応する必要があります。

セットアップを完全に実行するたびに、コンテキストと専門家の調整後に $specsfy-documentator を読み込みます。アプリケーション、永続化、依存関係に最近の変更がない場合も含め、既存システム全体の技術ドキュメントを docs/ と .specsfy/PACKAGES.md に再構築します。管理対象ブロックの外にある人間向けの文章は保持し、終了前に PENDING の結果をすべて解決してください。

セットアップ中のデータベース保護

プロジェクトに artisan がある場合、セットアップ中に次を実行します：

node .agents/skills/specsfy-setup/scripts/check_database_safety.mjs \
  --project <raiz>

.env.testing が存在し、APP_ENV=testing とデータベースの接続先が明示的に宣言されていることを必須とします。テスト用データベースは .env に示されているデータベースと異なる必要があります。値が欠落し、Laravel が開発環境の設定を継承する場合は受け入れないでください。スクリプトは認証情報や接続値を表示しません。 PENDING の結果が出た場合、対象を絞ったテスト、テストスイート、回帰テストは実行できません。テスト環境を修正し、確認を再実行して、SAFE の結果が出てから続行してください。開発用データベースを使ってテストを実行してはいけません。診断目的であっても同様です。IGNORED の結果は、構造やレコードを削除する可能性のあるコマンドまたは設定を示します。そのコマンドを実行せず、強制実行するオプションも提示しないでください。

1. 読み取りや書き込みの前に、プロジェクトディレクトリを確認します。この会話で最初に実行する際、ユーザーがすでにパスを指定している場合は、絶対パスに解決してから、そのパスを繰り返し伝えます。パスが指定されていない場合は、次の選択肢を番号付きでそのまま提示し、回答を待ちます：1. Usar o diretório atual., 2. Usar um subdiretório do Hub. e 3. Informar outro caminho.. Git のルートから保存先を推測してはいけません。同じ会話内で以降の必須実行を行う場合は、確認済みのルートを再利用し、質問を繰り返さないでください。

2. 以降の各コマンドでは、確認済みのルートを使用します。Hub で作業する場合は、選択したサブディレクトリで実行するか、コンテキストおよび仕様書のスクリプトに --project <raiz> と --root <raiz> を渡します。親ディレクトリにコンテキスト、仕様書、テスト、コードを作成してはいけません。

3. 書き込みの前に、確認済みのルートにある AGENTS.md、CLAUDE.md、およびローカルの指示を読みます。次に、node scripts/inspect_project.mjs --project <raiz> を実行します。返された順序で、列挙されたソースを読みます：指示、マニフェスト、設定、アプリケーション、ルート、永続化、連携、インターフェース、テスト、ドキュメント。現在のシステムを理解し、維持するものを記録するまでは、調査、スタックの提案、書き込みを開始しないでください。

4. エージェントファイル内の予約ブロックを監査する必要がある場合は、公開可能なガイドライン を読みます。 .specify/memory/constitution.md が存在する場合は、GitHub Spec Kit との互換性 も読みます。

5. specsfy doctor --project <raiz> を実行し、コンテキストを準備する前に、不足している要件をすべて修正します。診断では Node.js、Git、npm、プロジェクトへのアクセス、npx を確認します。

6. node scripts/setup_context.mjs --project <raiz> を実行します。 .specsfy/templates/custom/<Nome>.md が存在する場合は、そこから PROJECT.md、STACK.md、RULES.md、DATABASE.md、 INTERFACE.md、DESIGNSYSTEM.MD、.specsfy/USER-PROFILE.md を生成します。存在しない場合は、管理対象ファイル .specsfy/templates/Project.md、Stack.md、Rules.md、Database.md、Interface.md、DESIGNSYSTEM.MD、UserProfile.md から生成します。スクリプトに並行するテンプレートを埋め込んではいけません。DESIGNSYSTEM.MD はプロジェクトのルートに配置し、一般的なインターフェースのデフォルト値で作成します。また、まだ存在しない場合にのみ作成します。同じコマンドで GitHub Spec Kit を検出した場合は、constitution と specs/ 内のすべての通常ファイルを読み取った後、.specsfy/SPECKIT.md の管理対象ブロックを更新します。 初期セットアップでは SEMVER、Dockerfile、compose.yaml、stack.yaml、deploy、ansible/ を作成しません。バージョン管理とデプロイは、ユーザーがその作業を明示的に依頼した場合にのみ開始します。その場合は、$specsfy-specialist-deploy への引き継ぎを伝えます。 すべての実行は冪等でなければなりません。同じ入力でセットアップを繰り返しても、すでに整合したファイルを変更せず、ブロックを重複させず、別の工程を開始しません。

7. 変更の開始時と終了時に、次を実行します：

   node scripts/monitor_context.mjs --project <raiz> --check
   

   Laravel では、check_database_safety.mjs --project <raiz> も実行し、結果が SAFE になるまでテストの実行をすべて停止したままにします。

8. .specsfy/USER-PROFILE.mdや、生成済みの場合は.specsfy/PACKAGES.md、およびスクリプトで使用されるスタックのソースを含む初期ファイルを調査します。.specsfy/SPECKIT.mdが存在する場合は、憲章と、プロジェクションに記載されている各原本を開きます。インターフェースの調査を始める前に、必ずnode scripts/inspect_interface.mjs --project <raiz>も実行し、依頼に関連する現在のルート、コンポーネント、画面を開きます。出力は分析の指針としますが、システムのソースを読む代わりにはなりません。プロジェクト全体の調査には、レポートに表示される既存の認可ルール、ロール、データ、インテグレーション、ルート、画面、コンポーネント、状態、テスト、ドキュメントも含めます。コードベースが大きい場合はグループごとに進め、変更を提案する前に、どのソースを読んだかを伝えます。読んでいないことを、規約を置き換えてよい根拠として扱ってはいけません。

9. 既存のコンテキストファイルは、内容が不完全であっても決して置き換えてはいけません。AGENTS.md、CLAUDE.md、.specsfy/SPECKIT.mdでは、フレームワーク用の区切られたブロックのみを更新し、その外側はすべて保持します。.specify/とspecs/内のファイルを作成、移動、改名、削除してはいけません。

10. スタックを読み取った後、まずSpecsfyの必須コアをインストールします。 specsfy-specialist-data-modeling、 specsfy-specialist-domain-modeling、 specsfy-specialist-software-architecture、specsfy-specialist-shadcn-ui およびspecsfy-specialist-reuiです。 次に、 specsfy skills detect --project <raiz>を実行します。以下の対応表に、コアと検出されたスペシャリストを示し、インストールするものを伝えます。セットアップの開始時点で、この動作についてはすでに許可されています。コアと検出された各スペシャリストを、ほかの汎用スペシャリストを含めず、次の方法で利用側プロジェクトにインストールします。

npx skills add https://github.com/promovaweb/specsfy \
  --skill <especialista-detectado> --agent universal --copy -y --full-depth

インストール後、現在の工程で必要なインストール済みスペシャリストを読み込みます。コマンドが失敗した場合は、名前と出力、可能な続行方法を伝えます。手動でのコピーでインストールを代替してはいけません。手動でインストールされたスペシャリストも引き続き有効です。削除したり、必要がないのに再インストールしようとしたりしてはいけません。 11. スタック、ルール、データを補完または修正する場合は、ハンドオフを伝え、それぞれ$specsfy-aux-stack、$specsfy-aux-rules、$specsfy-aux-databaseを読み込みます。 12. セットアップを完全に実行する際は、補助スキルの後に$specsfy-documentatorを読み込み、プロジェクト全体を基にdocs/と.specsfy/PACKAGES.mdを再構築します。別の工程でアプリケーション、永続化、依存関係に変更があった場合は、実装の最後にドキュメンターを再実行します。 13. プロジェクトでGitflowを使用するよう明示的に依頼または指定された場合に限り（references/gitflow.mdを参照）、ハンドオフを伝え、$specsfy-specialist-gitflowを読み込み、$specsfy-aux-rulesを通じて、確認済みのブランチ規約をRULES.mdに記録します。リポジトリのブランチ構成、developブランチの存在、その他の暗黙的な兆候を根拠として、Gitflowを提案、推定、適用してはいけません。

PENDINGの結果を回避してはいけません。指定されたドキュメントを更新し、モニターを再実行します。履歴や目的に実質的な影響がないアプリケーション変更については、その評価をタスクのソースに記録し、--acknowledge-project-no-changeを付けて再実行します。ルールについても同様に--acknowledge-rules-no-changeを付けて対応します。実際のドキュメント変更を隠すために、確認オプションを使ってはいけません。

PROJECT.md、INTERFACE.md、DESIGNSYSTEM.MDをルートに保持します。.specsfy/には、STACK.md、RULES.md、DATABASE.md、PACKAGES.md、USER-PROFILE.mdおよび任意のプロジェクションであるSPECKIT.mdを保持します。これらのドキュメントはプロジェクトから派生したコンテキストとして扱い、仕様、ゲート、実装の許可として扱ってはいけません。 複数のフレームワークを含むプロジェクトでは、確認したすべてのソースを記録してください。 単一のスタックを暗黙に選ばないでください。フレームワークを特定できない場合は、 汎用モデルを作成し、確認が保留中であることを明記してください。

セットアップでインストールされるスタックとスペシャリスト

確認されたスタック	インストールされるスペシャリスト
Laravel	specsfy-specialist-laravel
GitHub URL 経由で受け取った Laravel パッケージ	specsfy-specialist-laravel-package-manager
Supabase	specsfy-specialist-supabase
PostgreSQL	specsfy-specialist-postgres
Redis	specsfy-specialist-redis
React	specsfy-specialist-react および specsfy-specialist-react-ui-components
Astro	specsfy-specialist-astro
Next.js	specsfy-specialist-nextjs
TypeScript	specsfy-specialist-typescript
Tailwind CSS	specsfy-specialist-tailwind-css
shadcn/ui	specsfy-specialist-shadcn-ui
Docker または Compose	specsfy-specialist-docker
リリースまたはデプロイ全般	specsfy-specialist-deploy
Docker Swarm	specsfy-specialist-docker-swarm
Ansible	specsfy-specialist-ansible
OpenAPI	specsfy-specialist-web-api-design
OpenTelemetry または Prometheus	specsfy-specialist-observability
CI/CD	specsfy-specialist-delivery-engineering

すべてのセットアップにインストールされるコア	目的
specsfy-specialist-data-modeling	データ、エンティティ、関係、ライフサイクル
specsfy-specialist-domain-modeling	ドメインの用語、ルール、境界
specsfy-specialist-software-architecture	モジュール、依存関係、技術構造
specsfy-specialist-reui	React/Tailwind のインターフェースと CRUD の基盤となる ReUI
specsfy-specialist-shadcn-ui	ReUI 用のプリミティブ、テーマ、レジストリ

React を使用するすべての Laravel プロジェクトでは、セットアップ時に shadcn/ui と ReUI を 同時にインストールします。この組み合わせを任意として扱わないでください。shadcn/ui が 基盤を整え、ReUI がその上に CRUD とインターフェースを作成します。

すべての Laravel アプリケーションでは、Open Swoole を使った Laravel Octane が必須です。 composer.json と composer.lock の laravel/octane、イメージ内の openswoole 拡張機能、ランタイムの --server=swoole を確認してください。この組み合わせを .specsfy/STACK.md に記録し、不足しているインストールや修正は、セットアップを 承認する前にスペックへ引き継いでください。

この組み合わせをインストールした後、セットアップでは React の画面がコンポーネントで 構成されることを INTERFACE.md に記録します。新しい画面を作る際は、必ずマップを 参照し、既存のものを再利用してください。また、独自のコンポーネント、shadcn/ui の プリミティブ、ReUI の構成を、実際のファイルと利用箇所とともに記録してください。