Imported from SilentMalachite/Portfolio (AGENTS.md). Install upstream with npx skills add SilentMalachite/Portfolio. Copyright stays with the author.

Portfolio — エージェント作業規約

目的と適用範囲

SilentMalachite の日本語中心の GitHub Pages 事業サイト兼ポートフォリオを構築・保守する。「現場の制約を理解し、業務を整理して、AIや小規模ソフトウェアで解決する人」という軸で、小規模事業者や福祉・医療・教育などの現場に課題理解・設計・制作のつながりと相談できることを伝える。製品要件、掲載内容、受け入れ条件の正本は SPEC.md とする。本書はこのフォルダ以下の作業に適用する。

対話と判断

• 日本語で応答する。冒頭は理由や経緯を省き、結論・答えを端的に述べる。補足と根拠はその後に続ける。
• 現在のユーザー指示を優先し、メモリや過去の実装方針を現在の事実として扱わない。
• 改善提案は一度に一つとし、完了後に次を提案する。比較が必要な場合に限り、判断に必要な利点・欠点を示す。
• 作業範囲内の可逆的な判断は自律的に進める。目的や公開情報に関わる不明点は、仮定を明記して文書化するか、必要な一点を確認する。
• 調査、仕様作成、実装、公開の権限を区別する。文書作成の依頼だけでサイト実装、Git 初期化、リポジトリ作成、コミット、push、Pages 設定や公開に進まない。既に許可された行為を再確認しない。

着手と変更管理

1. AGENTS.md、SPEC.md、実在する設定ファイルと作業状態を読む。Git がある場合は branch、HEAD、未追跡ファイルを含む差分を確認する。
2. 依頼の完了条件、変更対象、確認方法を短く整理してから編集する。多段階の実装は段階ごとの完了条件を示す。
3. 必要最小限のファイルだけ変更する。範囲が広がる場合は、その理由と対象ファイルを事前に報告する。
4. ユーザーの既存変更を保護する。他作品のチェックアウト、メモリ本体、無関係な設定を変更しない。
5. 独立した調査・レビューに必要な場合はサブエージェントを利用できる。対象と成果物を限定し、同じファイルを同時編集させない。最終判断と検証は主担当が行う。

コンテンツの根拠

• リポジトリの公開状態と URL を確認し、現行の公開 README を中心に紹介文を作る。A11yLab のような公開メディアは、実際のサイト・記事も根拠にする。公開資料の記述は作者の説明であり、このサイト担当者が動作検証した証拠ではない。
• 事業相談を主目的とし、Soujo・AlchemIIIF・Utsushi.Win・Katachi.Win の順で主要事例を紹介する。Tsumugi・SummaryTalkは開発中の補足事例とし、A11yLabなどの既存作品も保持する。言語数や制作件数より、利用者の困りごと、支援・業務上の制約、それに対する設計判断を示す。
• メモリは開発姿勢の編集方針に用いる。公開用コピーは独立して書き、会話ログ、ローカル絶対パス、内部レビュー、非公開ブランチの情報を転記しない。
• 実名、職歴、所属、住所、資格、健康・障害情報、顧客、利用者数、採用実績、性能値を推測しない。プロジェクトの対象者や背景から作者本人の属性を推定しない。
• 退職の見込みや職場事情は公開用コピーへ転記しない。応募用の氏名・職歴・資格・連絡先は、本人が公開用として指定したものだけ載せる。
• 本人が公開紹介として指定した「考古学の専門家」という特性を、AlchemIIIFの課題設定と結びつける。学位・所属・資格・経験年数を追加で推測しない。
• 福祉・アクセシビリティへの理解は公開記事と制作物で説明する。資格職、支援実務の担当歴、利用者検証、業務改善効果を資料なしで付け加えない。
• AIとの協働は実際の制作方法に沿って説明し、本人の担当範囲を曖昧にしない。生成コードを本人がすべて手書きしたと表現しない。
• 「公開ソース」「配布版あり」「開発中」「実験段階」を区別する。コード公開を完成・安全・本番運用の証明としない。
• fork を独自開発として紹介しない。派生版・移植版を同一成果として混同しない。リポジトリの主要言語を作者の熟練度に読み替えない。
• 数値やリリース状態を載せる場合は、根拠 URL と確認日を記録する。未確認の項目は省略し、架空のデモ・スクリーンショットで補わない。

実装方針

• v1 は SPEC.md の静的 HTML/CSS 構成に従う。閲覧のための JavaScript、フレームワーク、CMS、データベース、GitHub API 呼び出しを追加しない。
• セマンティック HTML、レスポンシブ CSS、読みやすい日本語、キーボード操作を優先する。装飾のために読書順序や操作性を崩さない。
• 主要事例は「対象者・課題 → 制約 → 作ったもの → 本人の担当・設計判断 → 検証・現状」の順で書く。技術名や自己評価だけの一覧にしない。
• GitHub Pages のプロジェクトパスを前提に相対参照を使う。canonical・OGP などの絶対 URL は実際の公開先と一致させる。
• 外部スクリプト、トラッカー、Web フォント、秘密情報を追加しない。公開 artifact は site/ のみとし、リポジトリ全体をアップロードしない。
• 過剰な抽象化や独自ビルド基盤を作らない。依存追加・構成変更は具体的な必要性を説明し、仕様と整合させる。

検証と自己監査

• 編集前に、採用した仮定と根拠が現在の依頼に適合しているか自己監査する。
• 編集後に、事実と推測、要件と実装、変更範囲と権限を再監査する。過去の成功や他エージェントの結論だけで合格にしない。
• 文書だけの変更では、内容の矛盾、リンク、未確定事項の扱い、差分を確認する。存在しないアプリのビルド・テストを実施したと報告しない。
• サイト実装では SPEC.md の受け入れ条件を確認する。表示確認と静的検査、ローカルと公開環境の結果を区別する。
• 不具合修正は可能なら先に再現し、最小修正後に再確認する。単純な文言・スタイル変更のために実装をなぞるだけのテストを増やさない。
• 完了報告には変更内容、実施した確認、未確認事項を簡潔に記載する。実行できない確認は理由を示し、未検証のまま合格としない。