Community程式設計與開發github.com

DevArtsLab/devartslab-career-knowledge-bank

將來自多個來源的歷史職業資訊轉換為單一相互關聯的職業知識庫,保留事實、故事、語調、術語和證據,以便未來針對特定角色進行提取和重新詮釋。

devartslab-career-knowledge-bank 是什麼?

此技能旨在建立一個長期、可重複使用的歷史職業內容庫,而非傳統履歷。它從各種來源(如成績單、履歷、專案文件、認證等)提取事實、術語和證據,並以緊湊的關鍵詞格式進行組織,使用 `/` 連接同一來源內的相關資訊,並使用 `||` 分隔多個來源。該技能的核心原則包括證據完整性、來源追溯(provenance)及歷史真實性,嚴格區分原始來源、證據、能力、詮釋和目標表達。此內容庫專為未來提取而設計,可根據目標職位(例如前端工程師、UI/UX設計師、雲端開發者)或面試問題,從中檢索相關技能、術語和轉換經驗。支援平台包括 Claude Code、Cursor、Codex 及任何相容Markdown輸入的AI代理,其操作方式是透過結構化的Skill.md檔案引導AI進行資料處理與輸出。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/DevArtsLab/agent-skills/tree/main/skills/devartslab-career-knowledge-bank

Installed? Explore more 程式設計與開發 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

歷史職業內容銀行

目的

將來自多個來源的大量歷史職業資訊,轉換為一個相互關聯的職業內容銀行。

支援的輸入包含:

學術成績單 教育記錄 課程列表 學位 證書 培訓記錄 過往履歷 針對特定職位的履歷 工作申請 作品集內容 專案文件 僱傭記錄 學徒記錄 專業發展 認證 獎項 其他與職業相關的歷史資訊

輸出內容「不是」一份履歷。

輸出內容「不是」一組分開的履歷章節。

輸出內容是一個可重複使用的歷史內容銀行,之後可從中提取針對特定角色的內容。

核心輸出模型

每個輸入來源都成為一個緊湊的包裹式內容區塊。

多個來源區塊之間使用以下符號分隔:

||

除非為了保留來源身分,否則不要在來源區塊之間使用重複的標題、編號、解釋、項目符號或冗長標籤。

首選結構:

[包裹式來源 1] || [包裹式來源 2] || [包裹式來源 3]

所有來源區塊共同形成一個相互關聯的歷史內容銀行。

包裹規則

在每個來源區塊內:

保留歷史事實 保留有用的術語 保留課程名稱 保留技能 保留概念 保留工具 保留技術 保留日期 保留成績 保留GPA 保留憑證 保留成就 保留相關短語 保留可轉換的概念

使用緊湊的分隔符連接相關資訊。

首選內部分隔符:

/

範例:

Boston Architectural College / Boston, Massachusetts / 研究所 / 建築碩士 / 建築學 / 2012 秋季 / 2013 春季 / 設計原則 / 建築設計 / 設計工作室 / 空間設計 / AutoCAD I-2D / AutoCAD II-3D / AutoCAD / 2D CAD / 3D CAD / 電腦輔助設計 / 技術製圖 / 2D 繪圖 / 3D 繪圖 / 視覺溝通 / 設計思考 / 空間思考 / 創意問題解決 / 視覺呈現

大量輸入處理

當同時提供多個歷史來源時,首先獨立處理每個來源。

針對每個來源:

提取 標準化 整合 移除不必要的重複 識別相關術語 識別可轉換概念 保留事實證據 將所得資訊包裹成一個緊湊區塊

然後使用以下方式連接區塊:

||

如果這麼做會破壞來源上下文,請勿將不相關的來源事實合併成一個無法區分的序列。

請勿僅僅為了分開輸入而建立冗長的來源標籤。

大量輸出範例

輸入來源可能包含:

成績單 先前的「前端開發者」履歷 先前的「UI/UX」履歷 專案歷史

輸出:

Boston Architectural College / Boston, Massachusetts / 建築碩士 / 建築學 / 設計原則 / 建築設計 / 設計工作室 / 空間設計 / AutoCAD I-2D / AutoCAD II-3D / 2D CAD / 3D CAD / 電腦輔助設計 / 技術製圖 / 視覺溝通 / 設計思考 / 空間思考 / 創意問題解決 / 3.33 累積 GPA || React / Next.js / JavaScript / TypeScript / 前端開發 / 元件開發 / 響應式介面 / UI 開發 / 可重用元件 / 網頁開發 || 使用者介面設計 / 使用者體驗 / 視覺層級 / 響應式設計 / 無障礙設計 / 設計系統 / 原型設計 / 以使用者為中心的設計 || 專案開發 / Git / GitHub / API 整合 / 資料庫整合 / 部署 / 協作

整個結果就是一個歷史內容銀行。

|| 分隔符標示原始大量輸入之間的邊界,無需冗長的標題。

歷史保留

切勿僅僅因為資訊看起來與使用者當前的目標角色不相關就將其丟棄。

歷史資訊日後可能會與另一個角色相關。

維護「單一事實來源」。

請勿為每個職稱建立一個獨立的永久內容銀行。

去重複

移除完全相同的重複項。

當重複出現未增加任何額外意義時,移除明顯的重複。

當不同變體具有檢索價值時,保留它們。

範例:

AutoCAD AutoCAD I-2D AutoCAD II-3D 2D CAD 3D CAD 電腦輔助設計

應保留在一起,因為它們提供了不同的有用檢索詞。

請勿將所有內容簡化成:

AutoCAD

同樣地,保留:

React React.js 元件開發 可重用元件 前端開發 UI 開發

當每個詞都提供有用的檢索價值時。

語義連接

連接代表相關知識的術語。

範例:

建築設計 / 設計工作室 / 空間設計 / 視覺設計 / 設計原則 / 設計思考 / 空間思考 / 視覺溝通 / 視覺呈現 / 創意問題解決

技術設計:

AutoCAD / 2D CAD / 3D CAD / 電腦輔助設計 / 技術製圖 / 2D 繪圖 / 3D 繪圖 / 技術設計

學術證據:

A AutoCAD I-2D / A 3D 設計 / A- 2D 設計繪圖 / A- AutoCAD II-3D / C+ 徒手繪圖 / 3.33 累積 GPA / 3.08 2012 秋季 GPA / 3.85 2013 春季 GPA

履歷來源

處理現有履歷時:

保留職稱 保留雇主 保留日期 保留職責 保留成就 保留技術 保留工具 保留專案 保留技能 保留術語 保留針對特定角色的關鍵字 保留可轉換概念

一份為某個角色量身打造的履歷,仍然是歷史來源材料。

請勿將其術語限制於該角色。

如果多份量身打造的履歷使用了不同的術語,請在移除不必要重複的同時,保留來自每份履歷的有用術語。

學術來源

針對成績單和教育記錄:

保留機構 地點 學位 課程 主修 專攻 課程 學期 學分 成績 GPA 學業表現 特定課程的證據

從課程作業中提取可轉換的概念,但需有合理依據。

請勿將課程作業轉換為專業工作經驗。

請勿僅憑一門課程就暗示專業精通。

專業來源

針對僱傭、學徒、志願服務、專案或專業發展來源:

保留組織 角色 日期 職責 技術 工具 專案 成就 方法 領域 協作 技術能力 業務能力 專業術語

維持以下區別:

僱傭 教育 培訓 專案 志願服務 認證 獨立工作

術語擴展

提取來源支援的有用術語。

包含:

原始措辭 常見等效術語 縮寫 擴展術語 相關技術術語 相關概念術語 可轉換術語 領域術語

請勿憑空發明未經支援的專業知識。

範例:

AutoCAD II-3D / AutoCAD / 3D CAD / 電腦輔助設計 / 3D 繪圖 / 技術設計 / 3D 視覺化

證據完整性

每個事實主張都必須有輸入來源支援。

請勿將:

課程作業轉換為僱傭經歷 培訓轉換為專業經驗 興趣轉換為專業知識 接觸轉換為精通 專案轉換為僱傭經歷 關鍵字轉換為已證明的能力

保留以下區別:

專業經驗 學術經驗 培訓 專案經驗 可轉換能力 概念知識

來源追溯

每條有意義的資訊都應能在內部追溯至其來源。

例如:

React / 可重用元件 / 元件架構 / UI 一致性

可能在內部關聯到:

2025 年履歷 / 第3點

而:

建築碩士 / 設計工作室 / AutoCAD II-3D

則關聯到:

BAC 成績單

來源追溯不需要出現在緊湊的內容銀行輸出中。

編譯器應在內部保留它。

這在之後提問時會變得很有價值:

此技能從哪裡來?

這個術語真的有其歷史依據嗎?

證據 vs. 能力

區分這些階段:

來源 -> 證據 -> 能力 -> 詮釋 -> 目標表達

來源 原始輸入材料。

證據 來源所展示的確實發生過的事。

能力 從證據中合理得出的可轉移能力。

詮釋 對該能力的專業解讀。

目標表達 如何針對特定角色進行溝通。

範例:

設計工作室 (來源) -> 課程專案證據 (證據) -> 空間設計 (能力) -> 設計思考 (詮釋) -> 產品設計 (目標表達)

此過程應保持可追溯性,以防止意外膨脹。

請勿跳過中間階段,直接從來源跳到目標表達。

衝突來源

如果兩個歷史來源相互衝突:

請勿默默發明解決方案 優先採用明確具權威性或明確更新的來源 必要時保留有意義的歷史區別 請勿捏造遺失的資訊

日期

在日期能建立歷史脈絡時保留它們。

將日期與以下資訊保持連結:

學位 課程 僱傭關係 專案 培訓 認證 職業進展 學業表現

輸出風格

使用緊湊的關鍵詞導向內容。

請勿將內容變成潤飾過的散文。

請勿添加語法虛詞。

請勿解釋提取過程。

請勿在來源區塊之間添加評論。

請勿建立不必要的標題。

除非使用者特別要求,否則請勿使用項目符號。

使用:

/

連接來源區塊內的相關資訊。

使用:

||

分隔大量輸入的來源區塊。

Token 效率

優化輸出的緊湊性。

偏好:

React / TypeScript / JavaScript / 前端開發 / 元件開發

而非:

React、TypeScript 和 JavaScript,具有前端和元件開發經驗。

偏好:

Boston Architectural College / 建築碩士 / 建築學 / 2012 秋季 / 2013 春季

而非:

Boston Architectural College,使用者在2012年秋季和2013年春季於此攻讀建築碩士學程的建築學。

請勿重複:

來源名稱 類別名稱 解釋 上下文短語 語法連接詞

除非為了準確性而需要。

未來檢索

內容銀行必須支援未來請求,例如:

提取「前端開發者」的內容 提取「軟體開發者」的內容 提取「UI/UX 設計師」的內容 提取「建築設計師」的內容 提取「雲端開發者」的內容 提取「AI 軟體工程師」的內容 針對此職位量身打造我的履歷 找出所有相關的歷史技能 識別可轉換經驗 提取相關教育資訊 提取相關技術術語

當之後提供目標角色時:

搜尋整個相互關聯的內容銀行 識別直接相關的資訊 識別相鄰資訊 識別可轉換概念 識別相關術語 識別支援證據 優先考慮角色相關性 保留證據完整性

請勿僅僅因為特定角色需要不同的術語,就修改歷史的「單一事實來源」。

最終驗證

在輸出前:

保留所有有意義的歷史事實 保留有用的術語 保留來源區別 保留日期 保留學術證據 保留專業證據 移除不必要的重複項 保留有意義的變體 連接相關資訊 避免未經支援的主張 避免人為的履歷語言 使用 / 進行緊湊的內部連接 在大量輸入來源之間使用 || 使整個結果保持為一個可重複使用的歷史內容銀行

預設行為

每當使用者提供歷史職業資訊時:

提取所有有用的資訊 連接相關資訊 移除不必要的重複 獨立包裹每個大量輸入來源 使用 || 分隔來源區塊 保留完整的歷史記錄 回傳緊湊且相互關聯的內容銀行

結果應被視為長期的歷史職業「單一事實來源」,而非一份完成的履歷。

術語演進與資歷調整

目的

將歷史資訊作為「單一事實來源」的同時,允許其術語、詮釋、溝通層級和呈現方式隨著使用者的職業生涯發展而演進。

歷史資訊必須保持穩定。

專業術語可以演進。

溝通複雜度可以演進。

目標受眾框架可以演進。

資歷定位可以演進。

切勿僅僅為了讓使用者看起來更資深而更改歷史事實。

職業模型層級

維護這些概念層級:

歷史單一事實來源 職業詮釋 術語/資歷層 目標溝通

此外,有兩個屬性與歷史材料和生成的溝通相關聯:

故事庫 語調

故事和語調不是修改事實的層級。 它們是與歷史材料和生成的溝通相關聯的屬性。

歷史單一事實來源

包含實際發生的事情。

保留:

角色 職責 專案 技術 工具 課程 教育 培訓 認證 成就 日期 指標 術語 來源措辭 歷史證據

請勿根據目標職位要求改寫此層級。

職業詮釋

將歷史證據轉譯為專業概念。

識別:

技術能力 專業能力 可轉換能力 領域知識 架構概念 設計概念 工程概念 商業概念 問題解決概念 領導力概念 系統概念

隨著使用者職業生涯的發展,詮釋可能會演進。

目標溝通

將詮釋後的資訊調整為適用於:

目標職稱 目標資歷 產業 公司 職位描述 受眾 溝通媒介 技術深度 專業背景

目標

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

相關技能