create-project
用於在使用者標準結構中建立新專案的技能。所有操作均遵循 ~/.claude/rules/ 中的全域規則（主要是 project-meta.md、spcfctn-code.md、org-babel.md、file-editing.md）；此處僅列出操作順序。
明確呼叫此技能即表示允許建立 spcfctn/（全域規則「請使用者建立 spcfctn/」在此不適用 — 使用者已提出請求）。
步驟 0 — 準備
- 專案根目錄為目前工作目錄（或使用者指定的目錄）。檢查已有內容：
ls -la、find -L（注意符號連結）。 - 如果
.claude-root、.claude/CLAUDE.md等已存在 — 這不是新專案：不要覆寫任何內容，僅補充缺失的部分，並回報已有的項目。 - 如果
spcfctn/已是共同倉儲（monorepo）的一部分 — 不要拆分。在報告中說明此事，並提議在下次提交時，進行保留歷史記錄的子目錄拆分（spcfctn-code.md）。 - 在每次請求許可前，先用烏克蘭語給出簡短摘要（
file-editing.md）。
步驟 1 — 專案語言
- 如果使用者在請求中未指定語言 — 透過
AskUserQuestion詢問（「專案使用哪種語言？」：烏克蘭語、英語、其他）。在確定語言之前，不要撰寫任何散文文字。 - 專案語言適用於倉儲中的所有檔案（程式碼、註解、提交訊息、org/md 檔案）以及專案的外部產出（Jira 任務、Confluence 頁面）。與使用者的對話語言是獨立的，始終使用烏克蘭語。
步驟 1a — 專案代碼
每個專案都有自己的短代碼，由兩個字母組成。只有在萬不得已、找不到可接受的兩個字母選項時，才使用三個字母。大小寫不固定：取決於使用情境（例如 Jira 任務金鑰使用大寫 KB-1676；程式碼或名稱中的前綴則遵循所在位置的慣例，通常為小寫）。因此，在提案中顯示代碼時無需指定大小寫，而在 CLAUDE.md 中則以主要使用形式記錄，並說明各情境應使用哪種形式。
- 不要默默自行決定代碼，也不要隨便選第一個想到的：明確提出 3–4 個你個人覺得不錯的選項（依據專案名稱、主旨或文字遊戲 — 附帶簡短解釋說明為何選此選項），並讓使用者從中選擇或自行指定。建議透過
AskUserQuestion來進行（第一個選項為你認為最佳的，標註「(Recommended)」；系統會自動加入「Other」以供使用者輸入自訂代碼）。 - 檢查所選代碼是否與使用者既有專案的代碼衝突（搜尋
~/.claude/projects/*/memory、相鄰專案的.claude/CLAUDE.md，必要時使用locate），如果衝突，則告知使用者並提供其他選項。 - 將代碼記錄在
.claude/CLAUDE.md（步驟 3）和最終報告中。
步驟 2 — 結構
在根目錄中建立：
| 項目 | 內容 |
|---|---|
.claude-root | 空檔案（標記共享工作目錄的根目錄） |
.dir-locals.el | 下方表單，務必包含結尾換行 |
code/ | 空目錄（子倉儲/程式碼將放置於此） |
spcfctn/code/ | 如果尚不存在則建立此目錄（自行建立 spcfctn/，見上文），並在其中執行 git init（常規操作，無需請求許可），以及包含單一行 *~ 的 .gitignore；在使用者要求之前不要提交。spcfctn/ 本身不是倉儲 |
.mcp.json | 空內容：{"mcpServers": {}}（project-meta.md — 僅限 project 範圍的 MCP，絕不使用 user 範圍） |
env.org | .env.example 的文字來源 — 見下方 |
.claude/ | 見步驟 3 |
env.org — 為專案的每個 MCP 伺服器建立一個區段（* MCP 名稱），以散文描述該伺服器需要哪些變數及其用途；每個區段使用標籤（:noweb-ref）連結到共用的 .env.example（公開檔案，僅顯示變數名稱及佔位符，不含實際值 — org-babel.md，此處不需要「多重目標」範本，因為只有一個目標）。實際的 .env（權限設為 600，project-meta.md）由使用者自行建立 — 不要建立或編輯它；專案根目錄不需要為其建立 .gitignore，因為根目錄永遠不是 git 倉儲（project-meta.md）。如果建立專案時尚無 MCP 伺服器，則 env.org 可保留一句預留文字（「目前尚未連接任何 MCP」）代替區段，待第一個伺服器出現時再回來處理。
.dir-locals.el（org 連結的 root: 縮寫，可攜式，無需硬編碼路徑）：
((org-mode
. ((eval . (add-to-list 'org-link-abbrev-alist
(cons "root" (locate-dominating-file default-directory ".dir-locals.el")))))))
（在實際檔案中，這是純 elisp — #+begin_example/#+end_example 行不會包含在內。）
如果需要 spcfctn/ui/（用於分析設計稿）— 可以在後續需要時再建立；不要預先建立空目錄。spcfctn/ 日後出現的每個子目錄（ui/、deploy/ 等）應立即獲得各自的 git init 和包含 *~ 的 .gitignore — spcfctn/ 本身不是倉儲。除非有內容需要放置，否則不要建立 draft/、raw/、data/ 目錄，也不要預先將它們的模式加入 .gitignore（project-meta.md）。
步驟 3 — .claude/
-
mkdir .claude並單獨git init在.claude/中（即使根目錄本身是 git 倉儲或位於其他倉儲內）。這是常規操作，無需請求許可。在使用者要求之前不要提交。 -
.claude/.gitignore：settings.local.json *~（
*~是 Emacs 備份檔案的通用模式，包括*.~undo-tree~；需有結尾換行。） -
.claude/CLAUDE.md— 使用專案語言。最少內容：- 語言相關章節：專案的所有散文（文件、程式碼註解、提交訊息、org 標題等）使用專案語言；Jira/Confluence 產出亦同；與使用者的對話保持烏克蘭語；
- 專案代碼（步驟 1a）以單獨一行呈現，例如「專案代碼：
kb（在 Jira 任務金鑰中為KB」）； - 簡短結構說明：
.claude-root標記根目錄；code/— 程式碼；spcfctn/code/— 既有程式碼實務的文件（自有 git）；.claude/— 專案的意圖與慣例（自有 git）。
不要自行加入任何額外資訊（如 Jira 金鑰、指派對象等）— 這些會隨著工作進程自然出現。
-
不要寫入
settings.local.json— 這是個人設定，不在 git 中。
步驟 4 — 根目錄不在 git 中
專案根目錄永遠不是 git 倉儲（project-meta.md）：不要在根目錄執行 git init，也不要建立根層級的 .gitignore。如果根目錄已有 .git — 不要動它，並在報告中告知使用者。如果已有根層級的 .mcp.json — 不要對它進行任何操作。
步驟 5 — 翻譯既有檔案
將建立專案前已存在的所有內容（*~ 檔案、.git、二進位檔以及剛剛建立的服務檔案除外）轉換為專案語言（如果它們是使用其他語言撰寫）：
- 文字進行完整翻譯，保留結構、表格、程式碼區塊、識別碼和引用（錯誤訊息保留原文）。
- 烏克蘭語：使用「перелік」而非「список」（表示 list）；使用「зачіпка」表示 hook；不要翻譯識別碼和 CSS 類別（
org-babel.md）。 .md僅由 AI 編輯；.org— 不要刪除使用者不明確的編輯，應先詢問。對於包含:tangle的 org 檔案，請編輯 org 來源並透過emacsclient進行纏繞（org-babel.md）。- 在編輯段落（散文，非程式碼區塊或表格）後，透過
emacsclient --eval執行真實的fill-paragraph來對齊換行（對於 org，先執行(font-lock-ensure)）；在new_string/Write中以單行書寫段落。如果emacsclient無法連線 — 請要求使用者啟動伺服器，不要模擬。 - 對於 org/md 散文，在此之後執行
org-lint技能。 - 如果部分內容引用了此處不存在的檔案/專案 — 不要「修正」連結，僅翻譯周圍的文字。
步驟 6 — 報告
簡要列出所選的專案代碼、已建立的項目、已有的項目、已翻譯的內容，並提醒：.claude/ 和 spcfctn/ 子目錄中的提交尚未完成（需待使用者要求時才進行）。
禁止事項
- 不要編輯
.env/.env.*（project-meta.md），也不要建立包含機密的.mcp.json。 - 不要寫入
code/*中元件子倉儲的CLAUDE.md/.claude/檔案 — 僅限根層級的.claude/。 - 不要替使用者發明語言規則 — 僅使用所詢問的語言。
- 不要未經提出選項並讓使用者選擇就自行指定專案代碼。
- 不要在專案根目錄或
spcfctn/根目錄執行git init：倉儲僅在.claude/、code/*和spcfctn/*子目錄中。