feat: 导出 SproutClaw .sproutclaw 配置

包含 extensions、skills、prompts、settings、auth、models、mcp 等配置。
排除 node_modules、npm 缓存、sessions 等运行时数据。

agent/skills-disabled/repo-to-resume-tailor/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: repo-to-resume-tailor
+description: Analyze a full code repository and generate one resume-ready project description grounded in repository evidence. Use when Codex is asked to turn a repository into concise project bullets, project summaries, or tailored experience based on either a target role direction or a specific job description for backend, AI or agent, AI product, data, full-stack, platform, or MLOps roles.
+---
+
+# Repo to Resume Tailor
+
+## Overview
+
+Analyze the repository before writing. Extract only verifiable project facts, then rewrite them into concise, resume-appropriate project descriptions. Optimize for credibility, role relevance, and hiring readability instead of broad repository summarization.
+
+Dynamically adjust extraction and writing priorities based on the user's target role direction or specific job description. For AI or Agent or LLM, AI product, backend, frontend, full-stack, data, algorithm, DevOps, security, testing, and related roles, prioritize the most role-relevant implementation evidence and technical proof from the repository. If a concrete job description is provided, treat its frequent responsibilities, technical keywords, and delivery expectations as the highest priority. If the role name is not directly covered, map it to the nearest role category based on the underlying responsibilities. Do not invent technologies, responsibilities, or outcomes that are not supported by repository evidence in order to improve match quality.
+
+Adjust repository analysis and project phrasing dynamically according to the user's target role direction or specific job description. Do not mechanically list every technology in the repository. Instead, prioritize the abilities, modules, and implementation details that are most relevant to the target role. If the user provides a concrete job description, treat its high-frequency responsibilities, keywords, and technical requirements as the highest priority.
+
+## Workflow
+
+1. Clarify the input mode.
+   Use one of these two modes:
+   - target-role mode: the user gives a role direction such as backend, AI or agent, data, full-stack, platform, or MLOps
+   - JD mode: the user pastes a concrete company job description
+   In target-role mode, prioritize the capability mapping for that role.
+   In JD mode, prioritize the keywords, skills, and responsibilities from the job description.
+2. Traverse the repository selectively and prioritize high-signal evidence.
+3. Ignore low-value noise aggressively.
+4. Build an evidence-backed view of project positioning, tech stack, modules, and delivery form.
+5. Rank findings by role fit, not by broad coverage.
+6. Write with evidence discipline and conservative wording where needed.
+
+## Evidence Priority
+
+- Level 1 evidence: README, architecture or design docs, code comments with intent, API definitions, config files, deployment files, schema definitions
+- Level 2 evidence: directory structure, module naming, dependency inference, service boundaries implied by code organization
+- Level 3 evidence: reasonable inference from surrounding code
+
+If a claim depends mostly on Level 3 evidence, weaken the wording instead of presenting it as a confirmed fact.
+
+## Role Mapping
+
+Use the role mapping reference in [role_mapping.md](role_mapping.md) when matching repository evidence to role categories.
+
+- When the role is directly covered, prioritize the mapped capability areas and evidence patterns from that reference.
+- When the user provides a concrete job description, use the role mapping as a helper but let repeated job-description responsibilities, keywords, and delivery requirements take highest priority.
+- When the role is not directly covered, merge it into the nearest category by underlying responsibilities rather than by title wording.
+- For AI product roles, prioritize product problem definition, user scenarios, feature structure, capability boundaries, evaluation loops, and landing strategy over raw infrastructure details. Even if the repository uses RAG, prompts, agent workflows, or orchestration frameworks, explain how those capabilities serve product goals and user experience.
+- If the repository mainly proves technical implementation but lacks clear product documents, workflow design, evaluation loops, or productized evidence, do not over-package it as an AI product project.
+- Never increase match quality by inventing unsupported technologies, responsibilities, or outcomes.
+
+## Tech Stack Extraction
+
+Always extract and output a dedicated tech stack line when the repository supports it.
+
+- Prefer explicit technology names proven by code, config, imports, dependencies, framework usage, or workflow files
+- For AI or agent projects, explicitly surface technologies such as RAG, LangGraph, FastAPI, vector databases, embedding pipelines, tool calling, workflow orchestration, and model SDKs when the repository supports them
+- Do not hide the stack only inside prose when it can be named directly
+- Do not guess stack items that are not evidenced
+- Use the tech stack priority templates in [role_mapping.md](role_mapping.md) to decide stack ordering, grouping, and maximum stack count for high-frequency role categories
+
+## Writing Rules
+
+- Base every final statement on repository evidence
+- Do not fabricate metrics, impact, scale, ownership scope, or unsupported architecture claims
+- Do not describe a course assignment as a production system
+- Do not describe a forked project as fully self-built unless the repository supports that
+- Do not describe third-party API integration as self-developed model capability
+- Do not assign the user an unverified role such as project owner, system architect, or primary lead
+
+Prefer conservative wording when evidence is incomplete, such as:
+- participated in implementing
+- implemented a basic capability for
+- the project includes
+- the repository structure suggests the focus is
+
+## Output Contract
+
+Before the resume text, output a short analysis section covering:
+- which file types or directories were used as the main evidence
+- which role capabilities the project best matches
+- which claims are strongly supported and which ones remain conservative
+
+Then output one final resume-ready version only.
+
+The final output should include:
+- project name
+- project positioning or background
+- tech stack summary on its own line
+- core implementation, modules, or technical highlights
+- outcomes only when clearly supported by repository evidence
+
+Keep the output short enough for a real resume:
+- about 90 to 150 Chinese characters for the main project summary, or
+- 3 to 4 bullet points, each about 20 to 35 Chinese characters
+
+Do not output two versions in the same response.
+Select the one version that best matches the user's input mode:
+- if the user gives only a target role, output one version tailored to that role
+- if the user gives a concrete job description, output one version tailored to that job description
+
+## References
+
+Read [references/prompt.md](references/prompt.md) when the user wants a fuller reusable prompt template or stricter output language.
+
+Read [references/examples.md](references/examples.md) when you need concrete examples of evidence handling and output shaping.
+
+Read [role_mapping.md](role_mapping.md) when selecting which repository signals matter most for a target role or job description.

agent/skills-disabled/repo-to-resume-tailor/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Repo to Resume Tailor"
+  short_description: "Analyze repos and draft resume-ready tailored project text"
+  default_prompt: "Use $repo-to-resume-tailor to analyze this repository and write a resume-ready project description tailored to my target role."
+
+policy:
+  allow_implicit_invocation: true

agent/skills-disabled/repo-to-resume-tailor/references/examples.md

@@ -0,0 +1,35 @@
+# Examples Reference
+
+## Evidence Handling Example
+
+Strong evidence:
+- a README explicitly says the project is a fraud detection platform
+- a Docker Compose file shows Redis and PostgreSQL
+- route definitions and service files show authentication and async task processing
+
+Safe wording:
+- designed and implemented core API modules
+- integrated Redis and PostgreSQL for application data flow
+- added basic async task handling capabilities
+
+Weak evidence:
+- only directory names imply there may be a scheduler
+- dependencies include a vector database library but no retrieval flow is visible
+
+Safe wording:
+- the repository suggests planned scheduling support
+- the project includes dependencies related to vector retrieval
+
+Unsafe wording to avoid:
+- built a production-grade scheduling platform
+- independently developed a full RAG engine
+
+## Output Framing Example
+
+General version:
+- summarize project positioning, stack, and 2 to 3 high-value modules
+
+Role-tailored version:
+- backend: stress API, data, auth, cache, deployment
+- AI or agent: stress model calls, prompt flow, retrieval, tool use, orchestration
+- data: stress pipelines, SQL, scheduling, modeling, metrics

agent/skills-disabled/repo-to-resume-tailor/references/prompt.md

@@ -0,0 +1,51 @@
+# Prompt Template
+
+Use this reference when you want a fuller reusable prompt outside native Codex skill loading.
+
+## Core Prompt
+
+You are a repository-to-resume project description generator. Analyze the whole repository and generate one resume-ready project experience text based only on evidence that can be verified from the repository.
+
+Prioritize:
+- README files, docs, architecture notes, design docs
+- core business code
+- config files such as package manifests, dependency files, Docker files, CI files, env examples
+- APIs, data models, cache, queues, auth, schedulers, deployment, inference, workflow code
+
+Ignore or down-rank:
+- node_modules, dist, build, target, coverage, caches, generated files, large vendor files, low-value static assets
+
+Use evidence priority:
+- Level 1: direct documentary or config evidence
+- Level 2: repository structure and code organization
+- Level 3: reasonable inference only with weak wording
+
+Do not fabricate:
+- responsibilities not supported by the repository
+- unsupported architecture claims
+- fake metrics, performance gains, business results, user scale, or ownership claims
+- self-developed model capability when the repository only integrates a third-party API
+
+Output requirements:
+- first give a brief analysis of evidence sources, role fit, and conservative claims
+- then output one final resume-ready version only
+- include a dedicated tech stack line when the repository supports explicit stack extraction
+- if the user gives only a target role, tailor the result to that role
+- if the user gives a concrete job description, tailor the result to that job description
+- keep the project description short enough for a real resume
+
+Role keyword mapping:
+- Backend: API, DB, cache, queue, auth, scheduling, deployment, monitoring
+- AI or Agent: model calls, prompt design, RAG, vector retrieval, tool calling, orchestration, evaluation
+- Data: ETL, scheduling, cleaning, modeling, metrics, SQL, pipelines
+
+Preferred tone:
+- concise
+- professional
+- result-oriented
+- evidence-first
+- no inflated claims
+
+## Suggested Invocation
+
+Use $repo-to-resume-tailor to analyze this repository and write one resume-ready project description tailored to the following target role or JD: ...

agent/skills-disabled/repo-to-resume-tailor/role_mapping.md

@@ -0,0 +1,343 @@
+# Role Mapping Reference
+
+Use this reference when matching repository evidence to a target role direction or a specific job description. If a role is not directly covered, classify it into the nearest category by underlying responsibilities rather than by title wording.
+
+If a concrete job description is provided:
+- treat repeated responsibilities as the highest-priority extraction signal
+- treat repeated technical keywords as the highest-priority stack signal
+- treat explicit delivery expectations as the highest-priority phrasing signal
+- use the categories below as a fallback structure, not as a replacement for the job description
+
+Do not fabricate technologies, responsibilities, ownership, or outcomes that the repository does not support.
+
+## Tech Stack Priority Templates
+
+Use these templates when generating the dedicated tech stack line. Do not list every technology found in the repository. Prefer 4 to 6 high-signal items, ordered by role relevance and hiring value.
+
+General rules:
+- prefer technologies with direct evidence in code, config, imports, runtime wiring, or deployment files
+- prefer a mix of capability words and framework or infrastructure names when that makes the role fit clearer
+- avoid listing low-signal utilities unless they are central to the target role
+- avoid duplicate abstraction levels such as listing both a generic category and several weak examples unless the examples are strongly evidenced
+- if the repository supports fewer than 4 solid items, output fewer rather than guessing
+
+### AI / LLM / Agent
+
+Preferred order:
+1. capability words such as RAG, agent workflow, tool calling, multi-agent, evaluation
+2. orchestration or framework words such as LangGraph, LangChain, LlamaIndex
+3. service layer words such as FastAPI or inference service framework
+4. retrieval or storage infrastructure such as vector database, retriever, reranker
+5. model SDK or provider when directly evidenced
+
+Recommended shape:
+- capability plus framework plus service plus retrieval
+- example: `RAG, LangGraph, FastAPI, Milvus, OpenAI SDK`
+
+Avoid:
+- listing only generic Python libraries when stronger AI workflow evidence exists
+- hiding RAG or agent workflow inside prose while surfacing only web framework names
+
+### Backend
+
+Preferred order:
+1. primary backend framework or runtime
+2. database or ORM
+3. cache or queue
+4. auth, gateway, or service-support middleware when strongly evidenced
+5. deployment or containerization layer
+
+Recommended shape:
+- framework plus data layer plus runtime support plus deployment
+- example: `FastAPI, PostgreSQL, Redis, Celery, Docker`
+
+Avoid:
+- listing frontend tooling ahead of service runtime
+- overloading the stack line with every middleware package
+
+### Frontend
+
+Preferred order:
+1. primary frontend framework
+2. language and build stack if central
+3. state management or routing
+4. UI or visualization layer when important
+5. engineering or performance tooling when strongly evidenced
+
+Recommended shape:
+- framework plus language plus state or route plus UI or charting
+- example: `React, TypeScript, Vite, Zustand, ECharts`
+
+Avoid:
+- listing minor utility libraries instead of core page or component stack
+- treating lint or format tools as primary stack items unless engineering is the key story
+
+### Full-stack
+
+Preferred order:
+1. frontend framework
+2. backend framework
+3. database
+4. auth or API integration layer when central
+5. deployment or containerization
+
+Recommended shape:
+- front plus back plus data plus delivery
+- example: `Next.js, NestJS, PostgreSQL, JWT Auth, Docker`
+
+Avoid:
+- giving only one side of the stack when both are clearly evidenced
+- listing too many frontend-only or backend-only details without showing the end-to-end nature
+
+When a concrete job description is provided, override these templates if the JD repeatedly emphasizes a narrower subset, such as only retrieval, only deployment, or only data pipeline capability.
+
+## 1. Backend / Server / Platform Application Development
+
+Focus on:
+- API design and endpoint implementation
+- database modeling, SQL, and transaction handling
+- Redis and cache design
+- message queues, async jobs, and schedulers
+- auth, permissions, and user systems
+- logging, monitoring, and exception handling
+- microservices, service split, and gateways
+- Docker, deployment, and runtime delivery
+
+Common evidence:
+- `controller`, `service`, `dao`, `repository`
+- SQL, ORM usage, cache config, MQ config
+- `Dockerfile`, compose files, `nginx`, CI or CD files
+
+## 2. Frontend / Web Frontend
+
+Focus on:
+- page and component design
+- state management
+- interaction implementation and API integration
+- frontend engineering and build tooling
+- auth routes, forms, and data visualization
+- performance and maintainability
+
+Common evidence:
+- `components`, `pages`, `views`, `router`, `store`
+- Vite, Webpack, ESLint, TypeScript
+- charting code, rich interactions, lazy loading, reusable hooks
+
+## 3. Full-stack
+
+Focus on:
+- full front-to-back product flow
+- API design and data flow
+- login, auth, and business loop closure
+- deployment and environment configuration
+- complete system implementation ability
+
+Common evidence:
+- both frontend and backend directories exist
+- API call chains, database code, and deployment scripts are all present
+
+## 4. Mobile / Android / iOS / Cross-platform Mobile
+
+Focus on:
+- page structure and user interaction
+- local storage and network requests
+- state management and component reuse
+- performance optimization, adaptation, and packaging
+- collaboration with backend APIs
+
+Common evidence:
+- Android or iOS project files
+- Flutter, React Native, uni-app, or Taro
+- routing, network layer, and state layer code
+
+## 5. Test Development / QA Automation
+
+Focus on:
+- automated testing frameworks
+- unit, integration, and API tests
+- test data generation and coverage
+- CI or CD testing integration
+- quality assurance workflow
+
+Common evidence:
+- `test`, `tests`, `e2e`, `mock`
+- `pytest`, `junit`, `jest`, `playwright`, `cypress`
+- pipeline test steps
+
+## 6. DevOps / SRE / Cloud Native
+
+Focus on:
+- automated deployment
+- containerization and orchestration
+- monitoring, alerting, and logging systems
+- service reliability and recovery
+- CI or CD, environment management, and release flow
+
+Common evidence:
+- `Dockerfile`, `docker-compose`, Kubernetes, Helm
+- GitHub Actions, GitLab CI, Jenkins
+- Prometheus, Grafana, ELK, Nginx, Terraform
+
+## 7. Data Development / Data Engineering
+
+Focus on:
+- ETL or ELT flows
+- data cleaning, transformation, and warehouse ingestion
+- scheduling and batch processing
+- warehouse modeling
+- SQL development and data pipeline construction
+
+Common evidence:
+- Airflow, dbt, Spark, Flink, Hive
+- SQL scripts, scheduling config, DAG definitions
+- table schemas and metric-spec docs
+
+## 8. Data Analysis
+
+Focus on:
+- data cleaning and analysis flow
+- metric system construction
+- visualization dashboards
+- A or B test analysis
+- business conclusion extraction
+
+Common evidence:
+- notebooks, BI reports, SQL, pandas, visualization code
+- metric definitions, experiment analysis, conclusion docs
+
+## 9. Algorithm / Machine Learning / Deep Learning
+
+Focus on:
+- data preprocessing and feature engineering
+- model training and tuning
+- evaluation metrics and experiment design
+- inference deployment and service exposure
+- result analysis and optimization
+
+Common evidence:
+- `train`, `infer`, `eval`, `dataset`, `metrics`
+- PyTorch, TensorFlow, scikit-learn, XGBoost
+- experiment config, checkpoints, inference endpoints
+
+## 10. AI / LLM / Agent Development
+
+Focus on:
+- model integration and inference services
+- prompt design and context organization
+- RAG, vector retrieval, and knowledge QA
+- tool calling, function calling, and workflow orchestration
+- multi-agent collaboration, evaluation, and optimization
+- result tracing, observability, and safety controls
+
+Common evidence:
+- LangChain, LangGraph, LlamaIndex, FastAPI
+- vector databases, embeddings, retrievers, rerankers
+- `tool`, `agent`, `workflow`, `memory`, `eval`, `trace`
+
+## 11. Recommendation / Search / Ads Algorithms
+
+Focus on:
+- recall, ranking, and reranking
+- feature engineering and sample construction
+- offline training and online inference
+- metric evaluation such as CTR, AUC, or NDCG
+- search indexing, retrieval strategy, and ad logic
+
+Common evidence:
+- `recall`, `rank`, `rerank`, `feature`, `candidate`
+- Elasticsearch, Faiss, ANN, ranking models
+- metric scripts and experiment configs
+
+## 12. Client / Desktop / Cross-platform App
+
+Focus on:
+- local feature implementation
+- UI interaction and state flow
+- system capability access
+- local data management and sync
+- packaging and distribution
+
+Common evidence:
+- Electron, Qt, C# WPF, Tauri
+- local file handling, IPC, and system API calls
+
+## 13. Security / Cybersecurity
+
+Focus on:
+- access control and security strategy
+- vulnerability detection and protection
+- attack-surface analysis
+- audit logs and risk control mechanisms
+- identity, encryption, and network security implementation
+
+Common evidence:
+- `auth`, `crypto`, `audit`, `filter`, `waf`
+- scanners, rule engines, security middleware, access control
+
+## 14. Game Development
+
+Focus on:
+- core gameplay implementation
+- game logic and state machines
+- UI, level, and asset management
+- performance optimization and event systems
+- networking, save systems, or client interactions
+
+Common evidence:
+- Unity, Unreal, Cocos
+- `scene`, `entity`, `state`, `event`, `input`, `physics`
+
+## 15. Technical Product / Product Planning
+
+Focus on:
+- requirement breakdown and feature structure
+- prototype and process design
+- technical solution collaboration
+- data feedback loops
+- project progress and cross-role coordination
+
+Common evidence:
+- PRD, flowcharts, API docs, tracking plans, analysis docs
+
+Important note:
+- Only extract this category when the repository clearly contains product docs, process artifacts, or planning materials. Do not force a pure code repository into a product-management framing.
+
+## 16. Technical Project Management / RnD Coordination
+
+Focus on:
+- module split and task organization
+- development process norms
+- documentation and collaboration mechanisms
+- continuous integration and delivery
+- cross-role coordination traces
+
+Common evidence:
+- project docs, process specs, task templates, CI or CD, release records
+
+Important note:
+- Only express project-management capability when the repository contains explicit management traces. Do not infer management responsibilities from ordinary code structure alone.
+
+## 17. AI Product Manager / AI Product / LLM Product / Agent Product
+
+Focus on:
+- product scenario definition and problem breakdown
+- user-flow design and feature-structure design
+- mapping LLM capabilities to business or product requirements
+- how prompt, RAG, agent, or workflow capabilities land in concrete product features
+- evaluation design, experience optimization, and feedback-loop closure
+- feature boundaries, fallback behavior, safety, and controllability design
+- cross-functional collaboration, requirement pushing, and iteration strategy
+
+Common evidence:
+- README or docs describing scenarios, target users, user flows, or product goals
+- PRD, flowcharts, feature specs, evaluation docs, or solution-comparison docs
+- API or workflow modules that clearly represent product flow rather than only infrastructure
+- fallback, permission control, citation tracing, result explanation, or feedback mechanisms
+- explicit constraints on output quality, explainability, stability, or safety
+
+Writing emphasis:
+- explain what user or business problem the project tries to solve, what features were designed, and how AI capabilities were used to deliver them
+- do not mechanically translate pure engineering implementation into product language
+- do not only list low-level technologies; explain how the technology supports product goals and user experience
+- if the repository mainly proves technical implementation but lacks clear product design, requirement analysis, or feedback-loop evidence, do not over-package it as an AI product project
+- when both technical implementation and product evidence are strong, it is acceptable to express both AI product positioning and AI application or agent landing capability