菜单
This skill should be used after discovery completes on a greenfield project when the discovery document contains a Module Structure section. Contains the full procedure for parsing module boundaries, generating BOUNDARIES.md, and optionally linking it from CLAUDE.md.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
This skill should be used when an orchestrator needs to choose or resolve a model for a delegated agent — i.e. by /bee:planner when authoring a plan (assigning a capability tier per agent per slice) and by /bee:plan-implementer when executing one (resolving a tier to a concrete subagent model value). Contains the single source of truth mapping capability tiers (best / excellent / fast) to Claude Code subagent model values, with per-tier guidance for picking the right one. Load this skill instead of hardcoding any model name.
Engine for the /ccaf:practice command. Asks which specific CCAF domains to focus on and how many questions (10/20/30), assembles a proportionally-weighted partial exam anchored to the reference bank and independently verified, administers it 4 questions per screen with resumable progress, and scores it with a per-domain performance chart. Attempt state lives in ~/.claude/ccaf-practice.local.md — separate from /ccaf:mock-exam. Use when running or resuming /ccaf:practice.
Engine for the /ccaf:mock-exam mock exam. Assembles a 60-question CCAF mock (all questions generated fresh per attempt, anchored to a self-authored reference bank and independently verified), administers it 4 questions per screen with resumable progress, and scores it on the real 100–1000 band with a 720 pass line. Use when running or resuming /ccaf:mock-exam.
Engine for the /ccaf:prepare conversational tutor. Teaches the Claude Certified Architect – Foundations (CCAF) syllabus turn by turn — one concept at a time, with a knowledge check every turn — adapting pace and difficulty to the learner. Opens with a multi-select topic menu over the blueprint's 5 domains and 30 task statements; the learner picks what to learn. Spawns the ccaf-check-author agent for scenario checks; hands off to /ccaf:mock-exam when a domain looks solid. Use when running /ccaf:prepare.
Generates a full incident postmortem markdown document from a cached timeline (built by incident-timeline-builder) and the source materials gathered during investigation. Uses a Google-SRE-style blameless template by default. Produces the postmortem as plain markdown text for the caller to render or save; the skill itself never writes to disk or posts anywhere. Use when the incident-postmortem agent reaches Phase 4, or when a user has a structured timeline and wants the full document.
Restructures a poorly written tracker issue into a clear, self-contained document a stranger can open cold and act on. Works on any archetype (Bug, Incident, Story, Feature, Task, Spike) and any supported tracker (Azure DevOps, Jira). Returns the refined title and markdown body; the caller owns the write (issuekit:tracker-adapter projects markdown to the vendor's format).
| name | boundary-generation |
| description | This skill should be used after discovery completes on a greenfield project when the discovery document contains a Module Structure section. Contains the full procedure for parsing module boundaries, generating BOUNDARIES.md, and optionally linking it from CLAUDE.md. |
After discovery completes on a greenfield project, check whether the discovery document contains a Module Structure section. If absent, skip this entirely.
Parse the Module Structure section from the discovery document — extract each module name, its owned concepts, and its allowed dependencies.
Ask the developer for consent using AskUserQuestion:
"Discovery produced module boundaries for this project. Want me to save these so Claude respects them in all code it writes? I'll create .claude/BOUNDARIES.md."
Options: "Yes, save boundaries (Recommended)" / "No, skip for now"
If the developer consents, generate .claude/BOUNDARIES.md in the target project (not the bee plugin directory) with this format:
# Module Boundaries
> Generated by /bee:discover from the project's milestone map.
> Edit this file to adjust boundaries as the project evolves.
## Modules
- `modulename/` — owns: Concept1, Concept2. Depends on: (none)
- `modulename/` — owns: Concept3. Depends on: modulename
## Rules
- Modules may only import from declared dependencies
- Domain concepts live in their owning module — do not scatter across modules
- No circular dependencies
- When in doubt, duplicate code rather than create a coupling that violates boundaries
Populate the Modules section from the discovery document's Module Structure entries.
If .claude/BOUNDARIES.md already exists (from a previous discovery run), ask:
"Existing boundaries found. Update with new module structure or keep current?"
Options: "Update with new boundaries (Recommended)" / "Keep existing"
If CLAUDE.md exists in the target project and doesn't already reference BOUNDARIES.md, ask:
"Want me to add a reference to BOUNDARIES.md in your CLAUDE.md so Claude always has boundary context?"
Options: "Yes, add reference (Recommended)" / "No, skip"
If yes, append a line to CLAUDE.md: Read .claude/BOUNDARIES.md for module boundary rules.
Report to the developer which modules and boundaries were saved.
→ Update state: "${CLAUDE_PLUGIN_ROOT}/scripts/update-bee-state.sh" set --boundaries ".claude/BOUNDARIES.md"
Proceed normally without boundaries. They are valuable but not blocking.