team-levelup
Skill145 starsChanged 19 days agoMITView on GitHub
Use when a session ends to extract CDRs, score confidence, batch review, and publish accepted CDRs to team-ai-directives. Auto-triggers on session_end event. Also invoked from team-boot's Class Boots catalog for CDR descriptor matches.
In this repository48 other files it gives its agents.
- architect-analyzeSkill
- architect-bootSkill
- architect-clarifySkill
- architect-implementSkill
- architect-initSkill
- architect-specifySkill
- writing-skillsSkill
- change-bootSkill
- change-clarifySkill
- change-initSkill
- change-publishSkill
- change-specifySkill
- evals-analyzeSkill
- evals-clarifySkill
- evals-implementSkill
- evals-initSkill
- evals-specifySkill
- evals-validateSkill
- factory-cleanSkill
- factory-initSkill
- factory-intentSkill
- factory-learnSkill
- factory-missionSkill
- factory-orchestratorSkill
- factory-queueSkill
- factory-releaseSkill
- factory-reviewSkill
- factory-runbookSkill
- factory-setupSkill
- factory-ticketsSkill
- mission-briefSkill
- product-analyzeSkill
- product-bootSkill
- product-clarifySkill
- product-implementSkill
- product-initSkill
- product-roadmapSkill
- product-specifySkill
- team-bootSkill
- team-constitutionSkill
- team-diagnoseSkill
- team-discoverSkill
- team-initSkill
- team-repairSkill
- team-setupSkill
- team-skillsSkill
- workspaceSkill
- tech-radar-bootSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 6 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 24
When no local context-module records exist in the current working directory and the directory sits inside a workspace (detected via a …
- Distinctive: line 32
Never defer to session end.
- Very specific: line 40
Brownfield discovery: Use /team-init to scan existing code
- Distinctive: line 41
ADR/PDR/ChDR capture: Use the respective clarify skills (architect-clarify, product-clarify, change-clarify)
- Distinctive: line 64
Run the setup script:
- Very specific: line 72
If TEAM_AI_DIRECTIVES is not configured, exit with message to run /team-setup.
- Very specific: line 85
Write session trace to adlc branch: reports/sessions/<user>/<YYYY-MM>.md.
- Distinctive: line 139
Wait for user input before proceeding.
- Very specific: line 150
Read accepted CDRs from drafts/cdr/
- Very specific: line 152
Write to context_modules/ in main branch
- Distinctive: line 153
Create branch, commit, push, open draft PR
- Very specific: line 157
Write to adlc branch:
- Very specific: line 165
Write report to .adlc/team-levelup-report.md (local, not committed):
- Distinctive: line 184
When two projects draft the same pattern:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
team-levelup
What this skill does
Session-end CDR lifecycle — extracts reusable patterns from the completed
session, scores them by confidence, presents for batch review, and publishes
accepted CDRs as a draft PR to team-ai-directives.
Replaces the former levelup-specify, levelup-clarify, and levelup-publish
skills with a single streamlined workflow.
Searched N CDRs, K matched. 0 rows matched → emit the section heading + the searched line only — no table, never a table header.
When no local context-module records exist in the current working directory
and the directory sits inside a workspace (detected via a .gitmodules marker
in an ancestor), read the workspace root's records instead.
When to use
Invoke at the START of a matching task — before planning the todo list and before implementation — so the CDR context informs planning. Never defer to session end.
- Session end (automatic):
.events.jsonmapssession_end→ this skill - Manual invocation:
/team-levelupafter completing work - Before closing a branch: Extract team-wide learnings
When NOT to use
- Brownfield discovery: Use
/team-initto scan existing code - ADR/PDR/ChDR capture: Use the respective clarify skills (architect-clarify, product-clarify, change-clarify)
Storage
CDR drafts live in the adlc orphan branch of team-ai-directives:
team-ai-directives (adlc branch, orphan)
├── drafts/cdr/
│ ├── CDR-001.md # Pending CDR
│ └── cdr.md # Draft index
└── reports/
├── sessions/<user>/<YYYY-MM>.md
├── projects/<project>.json
└── confidence-scores.jsonMain branch has NO drafts directory — only accepted CDRs in context_modules/.
Process
Phase 0: Environment Setup
Run the setup script:
scripts/bash/team-levelup.sh --setupParse JSON for REPO_ROOT, TEAM_AI_DIRECTIVES, NEXT_CDR, ADLC_BRANCH_EXISTS.
If TEAM_AI_DIRECTIVES is not configured, exit with message to run /team-setup.
Phase 1: Extract CDRs from Session
Review the current session to identify reusable patterns:
- What did the user ask for?
- What did the agent do? (file changes, key decisions, approach)
- What reusable patterns emerged?
- What files were created/modified? (
git diff --stat,git log --oneline -10)
For each pattern, create a CDR draft using the shared template at skills/team/templates/cdr-draft-template.md.
Write session trace to adlc branch: reports/sessions/<user>/<YYYY-MM>.md.
Phase 2: Score Confidence
For each extracted CDR, calculate confidence:
Base scores by type:
- Rule: 0.60
- Persona: 0.50
- Example: 0.50
- Constitution: 0.70
Bonuses:
- +0.20 if paired eval exists
- +0.10 if evidence includes file paths/commits
- +0.10 if multiple projects reference same pattern
Usage multiplier (from reports/confidence-scores.json):
- success_rate > 0.8: ×1.2
- success_rate 0.5-0.8: ×1.0
- success_rate < 0.5: ×0.8
Thresholds:
- ≥ 0.8: HIGH — batch review, auto-accept after review
- 0.5-0.79: MEDIUM — batch review required
- < 0.5: LOW — keep as draft
Phase 3: Batch Review
Present CDRs one at a time (same as former team-learn logic):
## CDR-{ID}: {Title}
**Context Type**: {type}
**Confidence**: {score} ({HIGH/MEDIUM/LOW})
**Current Status**: {status}
### Current Content
...
### Choose Action
| Option | Action |
|---|---|
| A | Accept — Approve for implementation |
| B | Reject — Decline with reason |
| C | Defer — Skip for now, keep pending |
| D | Accept all remaining — Accept this and all pending CDRs |
| P | Promote to check (mechanical rules only) |
Reply with your choice (A/B/C/D/P).Wait for user input before proceeding. Update CDR file after each decision.
Absent Context
If team-boot injected no team context this session (no Team Context & Decisions section in the first user message — unconfigured project or hook failure): say so in one line, maintain rows in Team Context & Decisions with a 0 CDRs matched (no team context injected — run /team-setup) source line, and continue the task on directly-read CDR modules. Never treat a missing injection as an empty record set. Recovery: run /team-diagnose.
Phase 4: Publish
For accepted CDRs, create a draft PR to team-ai-directives main branch:
- Switch to
adlcbranch worktree - Read accepted CDRs from
drafts/cdr/ - Transform to OKF v0.2 format with confidence frontmatter
- Write to
context_modules/in main branch - Create branch, commit, push, open draft PR
Phase 5: Write Usage Data
Write to adlc branch:
reports/sessions/<user>/<YYYY-MM>.md— privacy-scrubbed session summaryreports/projects/<project>.json— CDR match/apply counts- Update
reports/confidence-scores.json
Phase 6: Notify
Write report to .adlc/team-levelup-report.md (local, not committed):
## Team-Levelup Report
**Date**: {date}
**CDRs Extracted**: N
**CDRs Accepted**: N
**CDRs Rejected**: N
**CDRs Deferred**: N
**PR**: {URL or "none — no accepted CDRs"}
### Next Steps
1. Review PR (if created)
2. Run `/team-repair --update-confidence` after mergeConflict Resolution
When two projects draft the same pattern:
- First draft creates CDR-001 with
project: project-a - Second draft detects existing CDR with matching descriptor → merges:
- Adds project-b to
project:field - Appends evidence section
- Increments confidence (multi-project validation)
- Adds project-b to
Team Context & Decisions
team-levelup integrates with Team Context & Decisions maintained by team-boot.
CDR-class decisions detected during the session are surfaced as capture
suggestions (run /team-levelup to write the draft — the boot never writes
it) and
tracked as table rows in the same section. Mirror each CDR-class decision as a task-list todo
(suggest capture → /team-levelup at session end); after code-modifying tasks, add a
trailing todo to sweep Team Context & Decisions until Unrecorded: 0 pending · Unclarified: 0 drafts (a draft leaves Unclarified only via its clarify skill or an explicit user handoff to a named clarify or execute skill). At session end, deliver the clarify prompt naming each uncaptured decision (ID + capture skill) and each captured draft (ID + clarify skill); if the user defers clarify, mark those rows handed off. Do not fabricate
table rows — only record decisions that actually emerged from the session.
Verification
- CDRs written to
adlcbranchdrafts/cdr/ - Session summary written to
adlcbranchreports/sessions/ - Usage counts written to
adlcbranchreports/projects/ - Accepted CDRs published as draft PR to main branch
- team-levelup-report.md written locally
- No drafts in main branch
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

