菜单
This skill should be used when processing @bee annotations in documents or managing [ ] Reviewed gates. Contains the exact comment card format and review loop rules. Load before handling any @bee comment.
用 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 | collaboration-loop |
| description | This skill should be used when processing @bee annotations in documents or managing [ ] Reviewed gates. Contains the exact comment card format and review loop rules. Load before handling any @bee comment. |
After every document-producing agent (discovery, spec-builder, TDD planners) completes and returns to the orchestrator, the developer gets a chance to review and refine the document before Bee moves to the next step.
This is additive — the agent's own AskUserQuestion confirmation flow is unchanged. The collaboration loop is an additional gate in the orchestrator.
Every document produced by an agent gets a [ ] Reviewed checkbox appended at the very end of the file, on its own line:
[ ] Reviewed
The developer marks it [x] Reviewed when satisfied. This checkbox is the only gate for proceeding to the next step. Bee re-reads the file and checks for [x] Reviewed. Until it's marked, Bee stays in the loop.
The developer can add @bee comments anywhere in the document to request changes:
@bee This acceptance criterion is too vague, can we make it more specific?
When Bee finds an @bee annotation, it:
@bee annotation with a comment card<!-- -------- bee-comment -------- -->
> **@developer**: [original comment]
> **@bee**: [what Bee changed and why]
> - [ ] mark as resolved
<!-- -------- /bee-comment -------- -->
The HTML comment delimiters (<!-- -->) make the card boundaries machine-readable. The blockquote formatting makes it visually distinct. The [ ] mark as resolved checkbox is for the developer's tracking — it does NOT affect the gate.
Before (developer writes):
## Success Criteria
- App loads in under 2 seconds
@bee this needs to specify what network conditions — 2s on 3G is very different from 2s on fiber
- User can log in with email/password
After (Bee processes the annotation):
## Success Criteria
- App loads in under 2 seconds on a 4G connection (simulated with Chrome DevTools "Fast 3G" throttle)
<!-- -------- bee-comment -------- -->
> **@developer**: this needs to specify what network conditions — 2s on 3G is very different from 2s on fiber
> **@bee**: Added "on a 4G connection" with a specific measurement method (Chrome DevTools throttle profile) so the criterion is testable.
> - [ ] mark as resolved
<!-- -------- /bee-comment -------- -->
- User can log in with email/password
This format must be used exactly as shown. Every @bee annotation becomes a comment card with:
<!-- -------- bee-comment -------- -->**@developer**: prefix**@bee**: prefix explaining what changed- [ ] mark as resolved checkbox inside the blockquote<!-- -------- /bee-comment -------- -->Do not vary this structure. Consistency across all documents (discovery, specs, TDD plans) is required.
Only [x] Reviewed blocks progression. These do NOT block:
[ ] mark as resolved still unchecked)@bee annotations that haven't been processed yet (Bee processes them first, then re-checks [x] Reviewed)[ ] Reviewed checkbox to the document[path]. You can review it in your editor — if anything needs changing, add @bee followed by your comment on the line you want to change (e.g., @bee this AC is too vague). I'll read your annotations, make the changes, and leave a comment card so you can see what I did. When you're happy with the doc, mark [x] Reviewed at the bottom to move on."check when you're ready for me to re-read, or just keep chatting." Any message triggers a re-read of the file.@bee annotations found → process each one, make changes, replace with comment cards, write updated file, tell the developer what changed, wait for next message[x] Reviewed found → proceed to the next workflow step[path] — mark [x] Reviewed to continue." Don't block the conversation on the review gate.This loop applies after these agents return:
docs/specs/[feature]-discovery.mddocs/specs/[feature]-spec.md or docs/specs/[feature]-phase-N-spec.mddocs/specs/[feature]-slice-N-tdd-plan.mdIt does NOT apply to: quick-fix, context-gatherer, tidy, architecture-advisor, verifier, reviewer.