Token导航 LogoToken导航TokenDH.com
研究检索操作浏览器github未标认证来源可访问许可证需确认审计通过

cold-start冷启动

Agent Skill

cold-start 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

903

周安装

38

GitHub Stars

39

下载量

316
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:cold-start(冷启动)
来源仓库:https://github.com/mrvladd-d/memobank
仓库路径:skills/cold-start
安装命令:
npx skills add https://github.com/mrvladd-d/memobank --skill cold-start
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/mrvladd-d/memobank --skill cold-start

简介

用于项目初始化引导,创建 Memory Bank 骨架并路由工作流程。

  • 适合新项目开发或现有代码库映射场景。
  • 可区分绿地(greenfield)与棕地(brownfield)模式处理。
  • 需配合具体子技能如 mb-init、mb-map-codebase 使用。
  • 主要用于开发流程标准化,不涉及代码自动生成或部署操作。

SKILL.md

Cold Start: Memory Bank + Agents bootstrap (greenfield & brownfield)

Summary

Note: cold-start is the package skill for all-in-one bootstrap. Do not confuse it with the generated project command /cold-start: that command is a lightweight router used after skeleton creation inside a target repo. For modular usage, prefer individual skills: mb-init (skeleton), mb-from-prd (greenfield), mb-map-codebase (brownfield), mb-review (review), mb-execute (implementation), mb-verify (UAT).
  • What it does: creates the Memory Bank skeleton, writes agent entry points, and routes the repo into the right workflow.
  • Use it when: you want one entry point for either a new project with a PRD or an existing codebase that needs mapping first.
  • Input: repository root plus either prd.md / requirements text or an existing codebase.
  • Output: .memory-bank/, .tasks/, .protocols/, agent entry files, and the next step for greenfield or brownfield work.

Supported scenarios:

  • Greenfield: repo has prd.md or requirements text, but no code yet.
  • Brownfield: repo already contains code and needs as-is documentation before change planning.

Non-negotiable principles

1) Orchestrator vs workers

  • You (main agent) are the orchestrator. You plan and coordinate.
  • Workers (subagents) do the heavy lifting (scanning many files, producing long reports).
  • Max depth = 2: orchestrator → subagent. No sub-sub-agents.

2) .tasks/ is runtime memory (НЕ Memory Bank)

  • Every agent process gets a unique task folder: .tasks/TASK-XXX/.
  • Subagents write *detailed* outputs there, and return *only short summaries* to the orchestrator.

3) Avoid conflicts by design

  • Split work by non-overlapping file sets.
  • If overlap is unavoidable, use git branches/worktrees per agent and merge later.

4) Parallelism limits

  • Run up to 5–7 subagents in parallel.
  • If your runtime supports multi-tool calls: spawn parallel subagents in a single orchestrator turn.

5) Docs First

After completing any meaningful unit of work:

  1. Update Memory Bank while context is fresh.
  2. Then change code / commit.

Output you MUST create/maintain

Repo root

  • AGENTS.md (canonical, short, ~100 lines)
  • CLAUDE.md → symlink (or copy) to AGENTS.md
  • *(optional)* GEMINI.md → symlink (or copy) to AGENTS.md

Repo folders

  • .memory-bank/ — durable knowledge base
  • .tasks/ — operational runtime memory
  • .protocols/ — file-based protocols (plans / decision logs / resume)

Step 0 — Detect environment (don’t guess)

  1. Check what tools you have:

- Codex available? (Codex CLI / MCP tool) - Claude Code available? (CLI claude, subagents) - Browser tools? (Playwright / agent-browser / CDP MCP)

  1. Decide primary engine:

- If working inside Codex: use gpt-5.2-high for implementation and review (prefer fresh sessions for critical reviews). - If working inside Claude Code: use subagents for analysis + use Opus for synthesis; optionally call Codex via shell for second opinion or structured review. - If both Codex and Claude are available (dual-engine): use Claude for wide-context scanning and synthesis, Codex for structured review and implementation. Cross-validate critical outputs (MB compliance, architecture) by running the review step on the other engine. See Step 4 for the hybrid workflow.

If you don’t control Codex model selection via UI, create a project .codex/config.toml profile set (see Step 1.5).

Step 1 — Bootstrap the skeleton

1.1 Create directories

Create (if missing):

  • .memory-bank/

- mbb/ - architecture/ - guides/ - adrs/ - tech-specs/ - domains/ *(optional but recommended)* - contracts/ *(optional but recommended)* - runbooks/ *(optional but recommended)* - workflows/ *(optional; can keep wfs/ if you already use it)* - quality/ *(optional but recommended)* - testing/ - skills/ - epics/ - features/ - tasks/ *(Memory Bank backlog & plans)* - commands/ *(slash-command specs used by humans/agents)* - agents/ *(subagent prompt library)* - archive/ - bugs/

  • .tasks/
  • .protocols/

1.2 Create core files (use the templates)

Use the templates in:

  • ./references/shared-structure-template.md

At minimum you must create:

  • AGENTS.md
  • CLAUDE.md symlink/copy
  • .memory-bank/index.md
  • .memory-bank/mbb/index.md
  • .memory-bank/product.md
  • .memory-bank/requirements.md
  • .memory-bank/testing/index.md
  • .memory-bank/tasks/backlog.md

Also create the command specs under .memory-bank/commands/ (use references/commands/*).

1.2.1 Create native skills (proxy commands)

Create thin proxy skills so commands work natively in each runtime:

  • .claude/skills/<name>/SKILL.md → Claude Code + OpenCode
  • .agents/skills/<name>/SKILL.md → Codex CLI + OpenCode

Each proxy just says: Read and follow the instructions in.memory-bank/commands/<name>.md. This makes commands available natively (/mb, /prd, /execute, etc.) in all three tools.

The init-mb.js script creates both sets automatically.

1.3 Enforce frontmatter rule

Every markdown file inside .memory-bank/ must include YAML frontmatter with at least:

  • description:...
  • status: draft|active|deprecated|archived

1.4 Create .tasks/ protocol

Create a task folder for this run (pick a new id):

  • .tasks/TASK-MB-INIT/

Inside it, create:

  • TASK-MB-INIT-S-00-orchestrator-plan.md — what you will do + which subagents

1.5 Optional: Codex profile presets

If Codex is used, create .codex/config.toml with profiles:

  • default: coding (gpt-5.2, high)
  • profile deep-review: review (gpt-5.2, xhigh)

(If your repo is shared, consider keeping it local or documenting it in .memory-bank/runbooks/.)


Step 2 — Choose scenario

Decision rule

  • If repo has substantial code (src/, package.json, go.mod, Cargo.toml, etc.) → Brownfield (Step 3B).
  • If repo is mostly empty and you have prd.mdGreenfield (Step 3A).
  • If both exist: treat as Brownfield + PRD delta (Step 3B).
  • If repo is empty/new and no prd.mdSkeleton-only (Step 3C).

Record the scenario in:

  • .tasks/TASK-MB-INIT/TASK-MB-INIT-S-00-orchestrator-plan.md

Step 3A — Greenfield workflow (PRD → Memory Bank)

3A.1 Read PRD and do Deep Questioning

  • Read prd.md.
  • If gaps exist, run deep questioning in rounds (3–5 questions each). Use ./references/shared-deep-questioning.md.
  • If PRD mentions “use skills/tools/CLIs” — run /find-skills first (project-installed → marketplace).

If user is temporarily unavailable (“запуск и ушёл”):

  • Record Open questions in .protocols/PRD-BOOTSTRAP/decision-log.md.
  • Stop and wait (do not invent facts; do not proceed to EP/FT/backlog generation without answers).

If the user explicitly wants autonomous mode:

  • record non-blocking gaps as Assumptions
  • halt only on blocking gaps (security/compliance/external contract/data-loss risks)
  • after L1–L3 + review gate, continue with /autonomous

3A.2 Write product brief (L1)

Update .memory-bank/product.md using user’s wording.

3A.3 Requirements + RTM

Update .memory-bank/requirements.md:

  • REQ-IDs
  • RTM table mapping REQ → Epic → Feature → Test

3A.4 Create epics and features

Create:

  • .memory-bank/epics/EP-001-<slug>.md
  • .memory-bank/features/FT-001-<slug>.md

Each feature MUST include:

  • use cases
  • acceptance criteria
  • failure modes / edge cases
  • test strategy pointers

Status policy:

  • Default EP/FT frontmatter to status: draft until Open questions are resolved.
  • Promote to status: active only when acceptance criteria + verification plan are stable.

3A.5 Tasks planning (per-feature, no “everything at once”)

Do not generate a full task backlog for all features in one pass.

Instead:

  1. Create/refresh .memory-bank/tasks/backlog.md as a skeleton (waves + placeholders).
  2. For each selected feature, run /prd-to-tasks FT-<NNN> to produce:

- .memory-bank/tasks/plans/IMPL-FT-<NNN>.md - atomic TASK-* items grouped by waves in backlog.md

3A.6 Identify key concepts and create duo docs

For every non-trivial concept, create a duo:

  • .memory-bank/architecture/<concept>.md (WHAT/WHY)
  • .memory-bank/guides/<concept>.md (HOW)

3A.7 Update index

Update .memory-bank/index.md with annotated links to all created docs.


Step 3B — Brownfield workflow (Repo → Memory Bank)

3B.1 Spawn repo-scanning subagents (parallel)

Create a new task folder:

  • .tasks/TASK-MB-MAP/

Spawn up to 5 subagents in parallel with non-overlapping scopes:

  1. S-01: build/tooling (package managers, scripts, CI)
  2. S-02: backend/services
  3. S-03: frontend/UI
  4. S-04: data layer (DB, migrations, schema)
  5. S-05: tests + quality gates

Each subagent MUST:

  • verify its file glob targets exist ("smart calling")
  • write a detailed report into .tasks/TASK-MB-MAP/ using naming: TASK-MB-MAP-S-0X-final-report-<code|docs>-YY.md
  • return a 5–10 line summary + file list

Use ./agents/shared-repo-scanner.md as baseline prompt, but scope it.

3B.2 Synthesize Memory Bank from reports

Using the .tasks/TASK-MB-MAP/ reports, fill:

  • .memory-bank/product.md — what the system is today
  • .memory-bank/architecture/ — C4 L1–L3 overview + key invariants
  • .memory-bank/runbooks/ — setup, dev, test, deploy
  • .memory-bank/contracts/ — API/event contracts
  • .memory-bank/testing/index.md — canonical gates + verification notes
  • .memory-bank/index.md — annotated links
PRD-less rule (non-negotiable): if there is no prd.md, you MUST NOT create or populate: - .memory-bank/epics/* - .memory-bank/features/* - .memory-bank/tasks/backlog.md with waves/tasks Empty skeleton files/folders are allowed if they were created by bootstrap. Repo mapping is as-is documentation, not roadmap planning. If something cannot be derived from code/logs/tests, record it as a hypothesis or an open question.

3B.3 Ask user for PRD delta

After baseline MB exists:

  • ask the user for prd.md describing what to change/add
  • run /prd and /prd-to-tasks style decomposition against the existing baseline

Step 3C — Skeleton-only workflow (no PRD, no code)

When the repo is new/empty and no prd.md is available:

3C.1 Create skeleton only

Run Step 1 as usual — create all directories, core files from templates, AGENTS.md, CLAUDE.md symlink.

The skeleton provides a ready-to-fill structure: product.md, requirements.md, backlog.md, etc. remain as draft stubs.

3C.2 Ask for PRD

After skeleton is created, ask the user to provide a PRD:

"Memory Bank skeleton created. To fill it with product details, epics, features, and a backlog, please provide a prd.md file (or paste requirements text). You can do this now or later — run /prd when ready."

3C.3 Wait or proceed

  • If user provides PRD now → continue to Step 3A (Greenfield workflow).
  • If user defers → stop here. The skeleton is valid and usable. The user can invoke $mb-from-prd or /prd later to fill the Memory Bank.
  • If user provides partial info → run deep questioning (./references/shared-deep-questioning.md) to extract enough for product.md, then stop and wait for full PRD.
Note: The skeleton-only state is a valid stopping point. AGENTS.md + .memory-bank/index.md + MBB rules are enough for agents to start navigating the repo.

Step 4 — Hybrid mode (Claude ↔ Codex)

If you’re in Claude Code but want Codex quality or long-horizon autonomy:

  1. Use Claude subagents to produce the scan reports into .tasks/TASK-MB-MAP/.
  2. Call Codex via shell to synthesize Memory Bank:
codex exec --ephemeral --full-auto -m gpt-5.2-high \
  'Read .tasks/TASK-MB-MAP and build/refresh .memory-bank per MBB. Keep AGENTS.md short. Produce a summary and run a self-review.'
  1. Then run a Codex deep review profile (or a fresh Claude session) for 5-expert review.

Step 5 — Multi-expert review loop (fresh context)

Run fresh-context reviewers (do not reuse the writer context):

  • Architect (C4 + dependencies)
  • Scope analyst (REQ → Epic → Feature → Task coverage)
  • MBB compliance reviewer (frontmatter, links, atomics, duo)
  • Plan reviewer (backlog quality, waves, gates)
  • Security reviewer (auth, sensitive data, OWASP risks)
  • Code quality reviewer (conditional: if code exists — quality gates, conventions, hotspots)

Use prompts in ./agents/shared-review-*.md and ./agents/shared-mb-reviewer.md.

Rules:

  • If any reviewer returns REJECT → fix MB and repeat review.
  • Persist reviewer reports into .tasks/TASK-MB-REVIEW/.

Step 6 — Start executing tasks

After review gate passes (APPROVE):

  1. Pick the highest-priority task from .memory-bank/tasks/backlog.md.
  2. Run mb-execute for the task (plan → implement → quality gates → MB-SYNC).
  3. Run mb-verify to check acceptance criteria and record evidence.
  4. Repeat until the wave is complete or user stops.

If the intended mode is unattended end-to-end:

  • do not stay in manual loop here
  • switch to generated project command /autonomous
If mb-execute or mb-verify are not installed, follow their SKILL.md manually.

Definition of done

You are done when:

  • AGENTS.md exists, short, points to .memory-bank/index.md.
  • CLAUDE.md is a symlink/copy of AGENTS.md.
  • .memory-bank/ contains at minimum: index + MBB + product + testing (requirements/backlog can remain as stubs until PRD exists).
  • .tasks/ contains scan/review artifacts with naming + stage ids.
  • Greenfield: epics/features/backlog created from PRD.
  • Brownfield: repo mapped as-is into MB and user asked for PRD delta (no roadmap entities invented without PRD).
  • Skeleton-only: skeleton created, user asked for PRD (valid stopping point).
  • Multi-expert review passes (APPROVE) — for Greenfield/Brownfield; skip for Skeleton-only.
  • Execution loop is available (mb-execute + mb-verify reachable or documented).
  • Autonomous loop is available (/autonomous + /autopilot documented).

References in this skill

  • ./references/shared-structure-template.md
  • ./references/shared-deep-questioning.md
  • ./agents/shared-repo-scanner.md
  • ./agents/shared-mb-reviewer.md
  • ./agents/shared-review-architect.md
  • ./agents/shared-review-scope.md
  • ./agents/shared-review-code.md
  • ./agents/shared-review-plan.md
  • ./agents/shared-review-security.md
  • ./scripts/shared-init-mb.js (optional helper)

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

36%
按下载量换算114

Claude

31.23%
按下载量换算99

Cursor

20.52%
按下载量换算65

Gemini CLI

10.11%
按下载量换算32

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

操作浏览器

该 Skill 可能涉及浏览器控制能力,使用时可能读取或操作网页内容,需要在受控环境中确认权限边界。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills