@markus-global/cli 0.6.3 → 0.6.5

package/templates/skills/image-generation/skill.json

@@ -0,0 +1,26 @@
+{
+  "type": "skill",
+  "name": "image-generation",
+  "displayName": "Image Generation",
+  "version": "1.0.0",
+  "description": "Generate images using AI models — supports 14 providers including OpenAI DALL-E, Stability AI, Google Imagen, Replicate, SiliconFlow, Together AI, FAL, Ideogram, Tongyi, Zhipu, Baidu, Hunyuan, Volcengine, and more",
+  "author": "markus",
+  "category": "creative",
+  "tags": ["image", "drawing", "dall-e", "stable-diffusion", "generation", "art", "mcp"],
+  "i18n": {
+    "zh-CN": {
+      "displayName": "AI 画图",
+      "description": "使用 AI 模型生成图片 — 支持 14 个平台：OpenAI DALL-E、Stability AI、Google Imagen、Replicate、SiliconFlow、Together AI、FAL、Ideogram、通义万相、智谱 CogView、百度文心、腾讯混元、火山引擎等"
+    }
+  },
+  "skill": {
+    "skillFile": "SKILL.md",
+    "requiredPermissions": ["network", "file"],
+    "mcpServers": {
+      "image-generation": {
+        "command": "node",
+        "args": ["${SKILL_DIR}/server.mjs"]
+      }
+    }
+  }
+}

package/templates/skills/markus-admin-cli/SKILL.md

@@ -5,7 +5,7 @@ description: System administration via markus CLI — system controls, audit, us
 
 # System Administration via CLI
 
-> **NOTE**: Most admin CLI commands have no built-in tool equivalent — CLI is the primary interface for system administration. Use `builder_install`/`builder_list` for artifact management when available.
+> **NOTE**: Most admin CLI commands have no built-in tool equivalent — CLI is the primary interface for system administration. Use `package_install`/`package_list` for package management when available.
 
 ## How to invoke
 

package/templates/skills/self-evolution/SKILL.md

@@ -41,7 +41,7 @@ Skip trivial matters — typos, one-off path errors, situations that won't recur
 | Tool tip or preference | Observation buffer | `memory_save` with tags: `["insight", "tool:<name>"]` |
 | Validated pattern from successful task | Observation buffer | `memory_save` with tags: `["insight", ...]` |
 | Multi-step repeatable workflow (personal) | MEMORY.md | `memory_update_longterm({ section: "<your-section>", mode: "patch" })` |
-| Practice worth sharing with the team | Skill package | Create via **skill-building**, install with `builder_install` |
+| Practice worth sharing with the team | Skill package | Create via **skill-building**, install with `package_install` |
 | Behavioral rule or guiding principle | ROLE.md | `file_read` → `file_edit` to append |
 | New recurring check for your patrol | HEARTBEAT.md | `file_read` → `file_edit` to add/remove items |
 
@@ -146,21 +146,21 @@ When a practice would benefit **other agents on the team** (not just you), packa
 
 Before creating a new skill, check if one already exists:
 1. Run `discover_tools({ mode: "list_skills" })` to see all installed skills
-2. Run `builder_list` to see artifacts in builder-artifacts
+2. Run `package_list` to see packages in builder-artifacts
 3. If a similar skill exists, **update it** instead of creating a new one
 
 ### How to Create and Install
 
 1. Use the **skill-building** skill to create the package:
    - Write `skill.json` manifest + `SKILL.md` instructions to `~/.markus/builder-artifacts/skills/{name}/`
-2. Install with `builder_install({ type: "skill", name: "{name}" })`
+2. Install with `package_install({ type: "skill", name: "{name}" })`
 3. Log the creation via `memory_save` with tags `["insight", "skill-created"]`
 
 ### How to Update an Existing Skill
 
 1. Edit the files in `~/.markus/builder-artifacts/skills/{name}/` (use `file_read` then `file_edit`)
 2. Bump the version in `skill.json` (e.g., `"1.0.0"` → `"1.1.0"`)
-3. Re-install with `builder_install({ type: "skill", name: "{name}" })` — this overwrites the old version and re-registers
+3. Re-install with `package_install({ type: "skill", name: "{name}" })` — this overwrites the old version and re-registers
 4. Log the update via `memory_save` with tags `["insight", "skill-updated"]`
 
 Only create a skill when you are confident the practice is validated (proven across 2+ tasks) and genuinely useful for others.

package/templates/skills/skill-building/SKILL.md

@@ -150,7 +150,7 @@ file_write("~/.markus/builder-artifacts/skills/git-changelog/README.md", "# Git
 Once all files are written, tell the user:
 
 1. **The skill has been created and saved** — summarize what was created (name, purpose, what agents can do with it).
-2. **Ready to install** — the user can install from the Builder page, or ask you to install it (you would use `builder_install`). Do NOT install unless asked.
+2. **Ready to install** — the user can install from the Builder page, or ask you to install it (you would use `package_install`). Do NOT install unless asked.
 3. **To modify or improve** this skill (e.g., add more instructions, update examples, fix edge cases), just continue the conversation here — describe what you want to change and I'll update the files directly.
 
 ## Guidelines

package/templates/skills/team-building/SKILL.md

@@ -189,7 +189,7 @@ file_write("~/.markus/builder-artifacts/teams/research-team/members/senior-resea
 Once all files are written, tell the user:
 
 1. **The team has been created and saved** — summarize the team composition (name, members, their roles).
-2. **Ready to install** — the user can install from the Builder page, or ask you to install it (you would use `builder_install`). Do NOT install unless asked.
+2. **Ready to install** — the user can install from the Builder page, or ask you to install it (you would use `package_install`). Do NOT install unless asked.
 3. **To modify or improve** this team (e.g., add new members, update roles, change team norms), just continue the conversation here — describe what you want to change and I'll update the files directly.
 
 ## Rules

package/templates/teams/content-team/ANNOUNCEMENT.md

@@ -1,24 +1,28 @@
-# Content Creation Team
-
-Research-backed content pipeline for documentation, marketing, and technical writing.
-
-## Team Structure
-- **Editor-in-Chief** — Plans editorial calendar, creates briefs, reviews and approves all content
-- **Senior Writer** — Marketing copy, blog posts, user-facing documentation
-- **Technical Writer** — API docs, architecture guides, developer documentation
-- **Research Analyst** — Source material, data gathering, fact-checking, competitor analysis
-
-## How We Work
-1. Research Analyst gathers source material and publishes research briefs
-2. Editor creates content briefs with audience, goals, and key messages
-3. Writers draft in parallel, each handling their assigned pieces
-4. Editor reviews for accuracy, tone, and brief compliance
-5. Approved content moves to publish
-
-## Key Principles
-- Every claim traces to a source. No unsupported assertions.
-- Write for the audience, not yourself.
-- Share early, iterate fast.
-
-## Current Focus
-Awaiting content brief or project assignment from stakeholders.
+# 自媒体内容团队 — Content Creation Team
+
+多平台自媒体内容创作团队，专注于微信公众号、知乎、小红书、X.com 和 LinkedIn 等多平台内容生产与运营。
+
+## 团队结构
+
+- **编辑（Editor）** — 选题策划、内容审核、发布排期、质量标准把控
+- **中文写手（Chinese Writer）** — 微信公众号推文、知乎长文回答与文章
+- **小红书运营（Xiaohongshu Operator）** — 图文笔记创作、短视频制作与发布
+- **英文写手（English Writer）** — X.com 推文/Thread、LinkedIn 文章与帖子
+- **通用内容创作者（General Content Creator）** — 多平台内容适配、素材复用、口播文案
+
+## 工作流程
+
+1. **编辑制定内容日历** — 基于热点趋势和品牌方向，制定月度选题规划
+2. **并行创作** — 各平台写手独立创作，研发分析师提供资料支持和事实核查
+3. **编辑审核** — 内容审核（准确性、调性、合规性），审核通过后发布
+4. **发布与跟踪** — 各平台运营者负责发布，跟踪数据反馈
+
+## 核心原则
+
+- **受众优先** — 每个平台的内容要为该平台读者量身定制
+- **素材复用** — 一个主题产出多平台版本，提高内容 ROI
+- **数据驱动** — 根据发布数据调整内容策略
+
+## 当前关注
+
+等待编辑制定内容日历或接收来自利益相关者的内容需求。

package/templates/teams/content-team/NORMS.md

@@ -1,48 +1,50 @@
-# Content Team — Working Norms
-
-## Pipeline: Research → Brief → Draft → Edit → Publish
-
-### 1. Research (Research Analyst)
-- Use `web_search` and `web_fetch` to gather source material, competitor analysis, and data.
-- Use `spawn_subagent` for parallel research tracks: market data, user insights, technical accuracy.
-- Publish research briefs as `deliverable_create` artifacts with citations and key findings.
-- Every factual claim must trace to a source. Unsupported claims are flagged in review.
-
-### 2. Brief (Editor-in-Chief)
-- Create a content brief for each piece: audience, goal, key messages, tone, word count, references.
-- Assign briefs to writers based on expertise — technical docs to Technical Writer, marketing copy to Senior Writer.
-- Set dependencies: writing tasks should `blockedBy` the corresponding research task.
-- Define the content calendar as a task dependency graph when running campaigns.
-
-### 3. Draft (Writers, Parallel)
-- Each writer works on their assigned pieces independently.
-- Reference research deliverables — don't re-research what the analyst already covered.
-- Use `spawn_subagent` for fact-checking individual claims during drafting.
-- Submit drafts via `task_submit_review` with a summary: audience, key messages, word count, and any deviations from the brief.
-- Include all content as `deliverable_create` artifacts so the editor can review inline.
-
-### 4. Edit (Editor-in-Chief)
-- Review for: accuracy, clarity, tone consistency, audience fit, brief compliance.
-- Use `spawn_subagent` to cross-reference claims against research deliverables.
-- Leave structured feedback via `task_note`: categorize as "must fix", "suggestion", or "approved".
-- For major rewrites, create a new task rather than overloading revision notes.
-- Approved pieces move to publish. Rejected pieces return to the writer with specific feedback.
-
-### 5. Publish (Editor-in-Chief coordinates)
-- Final proofread pass.
-- Generate metadata: title, description, tags, categories.
-- Publish via the appropriate channel (docs site, blog, CMS).
-
-## Quality Standards
-
-- **No unsupported claims.** Every factual statement needs a traceable source in the research deliverable.
-- **Audience-first.** Write for the reader, not yourself. Technical docs explain; marketing copy persuades.
-- **Consistency.** Use the established style guide for terminology, formatting, and tone.
-- **Conciseness.** Every sentence must carry information. Cut filler ruthlessly.
-
-## Communication
-
-- Share drafts early for directional feedback — don't wait until "perfect."
-- Research Analyst: proactively share interesting findings with writers via `agent_send_message`.
-- Writers: flag brief ambiguities immediately. Don't guess at the editor's intent.
-- Use `deliverable_create` for all artifacts — research briefs, drafts, final pieces. This creates an audit trail.
+# 自媒体内容团队 — 工作规范
+
+## 工作流：选题 → 创作 → 审核 → 发布 → 复盘
+
+### 1. 选题与规划（编辑）
+- 使用 `web_search` 研究各平台趋势、热点话题和竞争对手内容。
+- 制定月度内容日历，包含：发布主题、目标平台、目标受众、关键时间节点。
+- 使用 `task_create` 创建内容任务，明确 `assigned_agent_id` 和 `reviewer_id`。
+- 内容日历作为 `deliverable_create` 发布，供全团队可见。
+
+### 2. 并行创作（各写手，独立工作）
+- **中文写手**：使用 `web_search` 和 `web_fetch` 收集素材，撰写公众号/知乎长文。
+- **小红书运营**：使用 `xhs-posting` 技能创建图文笔记，注意图片配文和话题标签。
+- **英文写手**：使用 `x-com-browser-posting` 技能撰写 X.com Thread/LinkedIn 文章。
+- **通用内容创作者**：适配多平台格式，复用已有素材制作口播文案或短视频脚本。
+- 使用 `spawn_subagent` 进行事实核查，确保每个声明可追溯。
+- 通过 `task_submit_review` 提交初稿，附上：目标平台、受众分析、关键词、字数。
+
+### 3. 审核（编辑）
+- 审核标准：准确性、调性一致性、受众适配度、平台规范合规性。
+- 使用 `spawn_subagent` 交叉验证声明与来源材料。
+- 通过 `task_note` 留下结构化反馈：分类为"必须修改"、"建议"、"已通过"。
+- 审核通过的内容标记为可发布。驳回的内容附上具体修改意见退回写手。
+
+### 4. 发布（各平台运营者）
+- **中文写手**：公众号排版（使用微信编辑器或 Markdown 转换），定时发布。
+- **小红书运营**：使用 `xhs-posting` 技能发布图文笔记，配置正确的话题标签。
+- **英文写手**：使用 `x-com-browser-posting` 技能发布 Thread 或推文。
+- **通用内容创作者**：根据需求将内容分发到其他平台（抖音、B站等）。
+- 在 `deliverable_create` 中记录发布链接和发布时间。
+
+### 5. 数据复盘（编辑）
+- 定期检查各平台数据（阅读量、互动率、转化等）。
+- 将数据洞察反馈到下一轮内容日历规划中。
+- 记录成功模式和失败教训到团队 NORMS 中。
+
+## 质量标准
+
+- **平台适配**：每个平台的内容风格必须适配该平台特点（微信长文 vs 小红书图文 vs X 短推文）。
+- **可追溯声明**：每个事实性声明必须有可查证的来源。
+- **一致性**：保持品牌调性一致，使用统一的术语和风格指南。
+- **ROI 思维**：一个主题产出多平台版本，最大化内容投资回报。
+
+## 沟通规范
+
+- 编辑通过 `agent_send_message` 发布内容日历更新和选题通知。
+- 写手在遇到平台适配问题时第一时间在团队内沟通。
+- 所有内容成品通过 `deliverable_create` 登记，确保可追溯。
+- 紧急发布需求使用 `notify_user` 通知编辑。
+- 各平台数据表现定期通过 `task_note` 汇总。

package/templates/teams/content-team/team.json

@@ -2,52 +2,82 @@
   "type": "team",
   "name": "content-team",
   "displayName": "Content Creation Team",
-  "version": "2.0.0",
-  "description": "A research-backed content team with a structured pipeline: Research → Brief → Draft → Edit → Publish. Features parallel writing with independent workstreams, fact-checking via subagent research, and editorial review gates. Ideal for documentation projects, marketing campaigns, technical writing, and content operations.",
+  "version": "3.0.0",
+  "description": "A multi-platform content creation team with specialized writers for Chinese and English markets. Editor-in-Chief plans the editorial calendar and reviews content; Chinese writer handles WeChat public accounts and Zhihu long-form articles; Little Red Book (Xiaohongshu) operator creates image-text notes and short videos; English writer produces X.com threads and LinkedIn articles; General content creator handles multi-platform adaptation and asset reuse. Each writer owns their platform domain. Designed for content operations, brand marketing, and cross-platform content strategies.",
   "author": "Markus Team",
   "category": "productivity",
-  "tags": ["content", "writing", "marketing", "documentation", "creative", "editorial"],
+  "tags": ["content", "writing", "marketing", "multi-platform", "social-media", "wechat", "xiaohongshu", "x.com", "linkedin", "zhihu"],
   "icon": "edit",
+  "starterTasks": [
+    {
+      "title": "制定内容日历",
+      "description": "制定接下来一个月的选题规划，包含各平台发布节奏、内容主题、目标受众和关键时间节点。需要产出内容日历文档（Google Sheets 或 Markdown），供全体团队成员审阅。",
+      "priority": "high"
+    },
+    {
+      "title": "各平台账号配置与调研",
+      "description": "调研目标平台当前趋势和热门话题，确认各平台账号状态并完成配置。包括：微信公众号排版规范确认、小红书笔记格式适配、X.com Thread 模板准备、LinkedIn 文章风格调研。产出各平台内容风格指南。",
+      "priority": "medium"
+    },
+    {
+      "title": "第一篇内容策划与发布",
+      "description": "根据内容日历，选择第一个内容主题进行写作。各平台写手并行工作：中文内容适配公众号/知乎，小红书笔记同步制作，英文内容适配 X/LinkedIn。编辑审核后发布。",
+      "priority": "high"
+    }
+  ],
   "i18n": {
     "zh-CN": {
-      "displayName": "内容创作团队",
-      "description": "以研究驱动的内容团队，具有结构化的流水线：调研 → 简报 → 草稿 → 编辑 → 发布。支持并行写作、事实核查和编辑审核。适用于文档项目、营销活动、技术写作和内容运营。",
+      "displayName": "自媒体内容团队",
+      "description": "多平台自媒体内容创作团队，配备覆盖中文和英文市场的专业创作者。编辑负责选题策划与内容审核；中文写手负责公众号和知乎长文；小红书运营制作图文笔记与短视频；英文写手生产 X.com 推文与 LinkedIn 文章；通用内容创作者负责多平台适配与素材复用。适用于内容运营、品牌营销和跨平台内容策略。",
       "members": {
-        "Editor-in-Chief": "主编",
-        "Senior Writer": "高级作者",
-        "Technical Writer": "技术文档工程师",
-        "Research Analyst": "研究分析师"
+        "Editor": "编辑",
+        "Chinese Writer": "中文写手",
+        "Xiaohongshu Operator": "小红书运营",
+        "English Writer": "英文写手",
+        "General Content Creator": "通用内容创作者"
       }
     }
   },
   "team": {
     "members": [
       {
-        "name": "Editor-in-Chief",
+        "name": "Editor",
         "role": "manager",
         "roleName": "project-manager",
         "count": 1,
+        "description": "选题策划、内容审核、发布排期协调",
         "skills": ["self-evolution"]
       },
       {
-        "name": "Senior Writer",
+        "name": "Chinese Writer",
         "role": "worker",
         "roleName": "content-writer",
         "count": 1,
+        "description": "微信公众号/知乎长文写作",
         "skills": ["self-evolution"]
       },
       {
-        "name": "Technical Writer",
+        "name": "Xiaohongshu Operator",
         "role": "worker",
-        "roleName": "tech-writer",
+        "roleName": "content-writer",
         "count": 1,
-        "skills": ["self-evolution"]
+        "description": "小红书图文/短视频创作与发布",
+        "skills": ["chrome-devtools", "xhs-posting", "self-evolution"]
       },
       {
-        "name": "Research Analyst",
+        "name": "English Writer",
         "role": "worker",
-        "roleName": "research-assistant",
+        "roleName": "content-writer",
+        "count": 1,
+        "description": "X.com/LinkedIn 英文推文与文章",
+        "skills": ["x-com-browser-posting", "self-evolution"]
+      },
+      {
+        "name": "General Content Creator",
+        "role": "worker",
+        "roleName": "content-writer",
         "count": 1,
+        "description": "多平台适应、素材复用、抖音口播文案",
         "skills": ["self-evolution"]
       }
     ]

package/templates/teams/research-lab/ANNOUNCEMENT.md

@@ -1,25 +1,30 @@
-# Research Lab
+# 调研研究团队 — Research Lab
 
-A team for investigating complex problems through parallel, adversarial research.
+结构化智库研究团队，专注于深度调研、竞品分析、行业报告和知识综合。
 
-## Team Structure
-- **Research Lead** — Frames questions, assigns hypotheses, synthesizes consensus
-- **3 Researchers** — Each investigates a different angle, then cross-examines peers' findings
+## 团队结构
 
-## How We Work
-1. Lead frames the problem and assigns competing hypotheses to researchers
-2. Researchers investigate in parallel — different angles, same question
-3. Researchers challenge each other's findings (adversarial review)
-4. Lead synthesizes evidence into a conclusion with confidence levels
+- **主任（Director）** — 制定调研方向、分配任务、审核综合产出
+- **高级研究员（Senior Researcher）** — 深度调研、报告撰写、方法论证
+- **助理研究员（Junior Researcher）** — 资料收集、初步分析、文献综述
+- **协调秘书（Coordinator）** — 会议记录、进度跟踪、交付物整理
 
-## Best For
-- **Root cause debugging**: Multiple hypotheses tested in parallel
-- **Technology evaluation**: Each researcher champions a different option
-- **Security audits**: Divide by attack surface, cross-verify findings
-- **Architecture exploration**: Map a codebase from multiple perspectives
+## 工作流程
 
-## Key Principle
-The hypothesis that survives cross-examination is most likely correct. Adversarial challenge eliminates anchoring bias.
+1. **主任制定框架** — 明确研究问题、设定成功标准、分配调研方向
+2. **并行调研** — 研究员在各自方向上独立调研，使用子代理进行深度挖掘
+3. **交叉验证** — 研究员挑战彼此的发现，用对抗性检验提升结论可靠性
+4. **综合产出** — 高级研究员综合各方成果撰写报告，主任审核后交付
 
-## Current Focus
-Awaiting research question. The Lead will frame the investigation and assign angles once a question is submitted.
+## 核心方法论
+
+- **竞争性假设检验**：每个问题从多个角度探索，避免锚定偏差
+- **证据分级**：区分事实（直接支持）、推理（合理推断）和推测（未支持）
+- **置信度评估**：每个结论附带置信度评级，当有新证据时更新
+
+## 最适合
+
+- 行业研究与竞品分析
+- 技术趋势与架构评估
+- 政策与市场分析报告
+- 深度知识综合与白皮书撰写

package/templates/teams/research-lab/NORMS.md

@@ -1,88 +1,77 @@
-# Research Lab — Working Norms
-
-## Methodology: Frame → Investigate → Challenge → Synthesize
-
-### Phase 1: Frame (Research Lead)
-- Define the research question precisely. Vague questions produce vague answers.
-- Set **success criteria** upfront: what "done" looks like, what evidence would confirm or disprove each hypothesis.
-- Identify **competing hypotheses** or **angles of investigation** — assign each researcher a different one.
-- Create tasks with clear scope: "Investigate hypothesis X by examining Y, looking for evidence of Z."
-- Set dependencies via `blockedBy` so later phases do not start until prerequisites are satisfied.
-
-### Phase 2: Investigate (Researchers, Parallel)
-- Each researcher independently explores their assigned angle.
-- Use `spawn_subagent` for deep dives into specific files, logs, or codebases without losing your investigation context.
-- Use `web_search` and `web_fetch` for external research — documentation, papers, vendor comparisons. Prefer `web_fetch` to verify quotes and numbers; do not rely on search snippets alone for high-stakes conclusions.
-- Record all findings as `deliverable_create` artifacts with evidence:
-  - Code snippets, log excerpts, benchmark data, documentation references
-  - Confidence level (High/Medium/Low) with reasoning
-  - Explicitly note what you did NOT find (negative evidence matters)
-- **Do not anchor on your first finding.** Actively look for disconfirming evidence.
-- Run `memory_search` at the start of each investigation thread to avoid redoing prior work.
-
-### Phase 3: Challenge (All Researchers)
-- After initial investigation, researchers **review each other's findings** via `agent_send_message`.
-- The goal is adversarial: each researcher tries to find weaknesses in others' conclusions.
-- Ask: "What would have to be true for this finding to be wrong?"
-- Prefer specific questions over rubber-stamp agreement. Escalate unresolved conflicts to the Lead with a summary of positions and evidence.
-- Update your deliverables based on challenges received. Strengthen or retract claims.
-
-### Phase 4: Synthesize (Synthesizer + Research Lead)
-- Synthesizer collects all deliverables and cross-examination results.
-- Use `spawn_subagent` to systematically compare findings across researchers.
-- Produce a synthesis deliverable (`deliverable_create`) that includes:
-  1. **Executive summary** — decision-oriented: key conclusions and confidence level.
-  2. **Methodology** — scope, sources consulted, tools used, limitations.
-  3. **Findings** — organized by theme or question, each tied to cited evidence.
-  4. **Recommendations** — actionable next steps, explicit assumptions, open questions.
-- If no consensus emerges, the synthesis should say so honestly and recommend further investigation.
-- Research Lead reviews and approves the final synthesis.
-
-## Competing Hypotheses Protocol
-
-For ambiguous investigations (unclear root cause, conflicting sources, multiple plausible explanations):
-
-1. Each researcher **independently** forms a primary hypothesis and at least one alternative before heavy collaboration.
-2. Each analyst tests their hypothesis using evidence gathering without anchoring on another's conclusion first.
-3. Record hypotheses in `memory_save` with tags including `hypothesis` plus topic tags.
-4. Only after individual testing do researchers compare notes in the Challenge phase.
-
-## Investigation Playbooks
-
-### Debugging / Root Cause Analysis
-- Assign researchers to different hypotheses: "race condition" vs "data corruption" vs "configuration issue."
-- Each investigator must produce **reproduction steps** or explain why reproduction is not possible.
-- Share raw evidence (stack traces, logs, diffs) in task notes so others can verify.
-
-### Technology Evaluation
-- Assign each researcher a different technology to evaluate against the same criteria.
-- Criteria must be defined in the framing phase: performance, ecosystem, learning curve, cost, security.
-- Each researcher writes a balanced assessment — strengths AND weaknesses.
-- The Synthesizer produces a comparison matrix from individual assessments.
-
-### Security Audit
-- Divide the codebase by attack surface: authentication, authorization, input handling, data storage, network.
-- Each researcher focuses on one surface using the OWASP framework.
-- Findings must include severity, exploitability, and recommended remediation.
-- Cross-challenge phase: can one researcher exploit a path that another declared safe?
-
-## Evidence Standards
-
-- **Every non-trivial claim** must cite specific sources (URL, file path, log line, or deliverable reference).
-- Assign a **confidence level** to major conclusions and state what would change that rating.
-- Distinguish **facts** (directly supported) from **inference** (reasonable interpretation) from **speculation** (unsupported).
-- A finding without evidence is an opinion, not research.
-- Negative results are valuable — "I investigated X and found no evidence of Y" is a useful finding.
-
-## Knowledge Accumulation
-
-- Run `memory_search` at the start of new investigation threads to avoid redoing work.
-- `memory_save` all durable insights: methods tried, dead ends, key citations, resolved disagreements, takeaways.
-- Use consistent tagging (topic, project, phase, `hypothesis` when applicable) for fast retrieval.
-
-## Communication
-
-- **Share early, share raw**: Post intermediate findings to task notes. Don't wait for polished conclusions.
-- **Cite your sources**: Every claim links to a file, URL, log line, or benchmark.
-- **Disagree constructively**: "I found evidence that contradicts X because..." not "X is wrong."
-- **Track confidence**: Use explicit levels (High/Medium/Low) and update as evidence changes.
+# 调研研究团队 — 工作规范
+
+## 方法论：框架 → 调研 → 验证 → 综合
+
+### 阶段 1：框架（主任）
+- 精确界定研究问题。模糊的问题产生模糊的答案。
+- 设定**成功标准**：什么是"完成"，什么证据足以证实或否定假设。
+- 识别**竞争性假设**或**调研角度** — 为每个研究员分配不同的角度。
+- 使用 `blockedBy` 设置依赖关系，确保后阶段在前置阶段完成后启动。
+- 通过 `task_create` 创建调研任务，明确 `assigned_agent_id` 和 `reviewer_id`。
+
+### 阶段 2：调研（研究员，并行）
+- 每个研究员独立探索分配的角度。
+- 使用 `spawn_subagent` 子代理进行深度挖掘（代码审查、文件分析、网络搜索），不丢失主调研上下文。
+- 使用 `web_search` 和 `web_fetch` 进行外部研究 — 文档、论文、竞品对比。关键结论优先使用 `web_fetch` 验证原文，不依赖搜索摘要。
+- 所有发现通过 `deliverable_create` 记录为带有证据的交付物：
+  - 代码片段、日志摘录、基准数据、文献引用
+  - 置信度（高/中/低）及理由
+  - 明确记录**没有找到什么**（负证据同样有价值）
+- **不要锚定于第一个发现**。主动寻找反证。
+- 开始调研前运行 `memory_search`，避免重复已有工作。
+
+### 阶段 3：验证与交叉检验（全体研究员）
+- 初步调研完成后，研究员通过 `agent_send_message` 互相审阅发现。
+- 目标是对抗性的：每个研究员试图找出他人结论中的弱点。
+- 追问："要让这个结论被推翻，什么必须为真？"
+- 倾向于提出具体质疑，而非简单盖章通过。未解决的分歧升级到主任，附上立场总结和证据。
+- 基于收到的质疑更新自己的交付物。加强或撤回声明。
+
+### 阶段 4：综合（高级研究员 + 主任）
+- 高级研究员收集所有交付物和交叉检验结果。
+- 使用 `spawn_subagent` 系统比较各研究员发现。
+- 产出综合交付物（`deliverable_create`），包括：
+  1. **执行摘要** — 面向决策者：关键结论和置信度
+  2. **方法论** — 范围、参考来源、使用工具、局限性
+  3. **发现** — 按主题或问题组织，每个发现附带引证证据
+  4. **建议** — 可操作的后续步骤、明确假设、未解决问题
+- 如未达成共识，综合报告应如实说明并建议进一步调研。
+- 主任审阅并批准最终综合报告。
+
+### 协调秘书的职责任务
+- 使用 `task_note` 记录调研过程中的关键决策和讨论要点。
+- 使用 `deliverable_create` 管理所有交付物版本，确保可追溯。
+- 协调跨研究员的信息同步，避免重复工作。
+- 在调研关键节点使用 `notify_user` 通知利益相关者进展。
+- 最终交付物归档：确保格式规范、引用完整、附件齐全。
+
+## 竞争性假设检验协议
+
+对于模糊的调查（不确定根本原因、冲突来源、多个合理解释）：
+
+1. 每个研究员**独立**形成主要假设和至少一个备选假设，再进行深度协作。
+2. 每个研究员先用自己的假设进行证据收集，不被他人结论锚定。
+3. 使用 `memory_save` 记录假设，标签包含 `hypothesis` 加主题标签。
+4. 只有在独立测试后才在验证阶段比较笔记。
+
+## 证据标准
+
+- **每个非平凡声明**必须引用具体来源（URL、文件路径、日志行或交付物引用）。
+- 对主要结论分配**置信度**（高/中/低），明确说明什么会改变评级。
+- 区分**事实**（直接支持）、**推理**（合理推断）和**推测**（未支持）。
+- 无证据的发现是观点，不是研究。
+- 负结果同样有价值 — "我调查了 X 但没有发现 Y 的证据"是有用的发现。
+
+## 知识积累
+
+- 开始新的调研线索前运行 `memory_search`，避免重复工作。
+- 使用 `memory_save` 保存所有持久性洞察：试验过的方法、死胡同、关键引用、已解决分歧、经验教训。
+- 使用一致的标签（主题、项目、阶段、`hypothesis`）以便快速检索。
+
+## 沟通规范
+
+- **尽早分享，分享原始数据**：将中期发现发布到任务备注。不要等到打磨成最终结论。
+- **引用来源**：每个声明链接到文件、URL、日志行或基准测试。
+- **建设性异议**："我发现了与 X 矛盾的证据，因为..."而非"X 错了。"
+- **跟踪置信度**：使用显式级别（高/中/低），随证据变化更新。
+- 协调秘书确保关键沟通内容记录可追溯。