adlc-team-skills
Agent skills that give coding agents your team's context at session start,
so they stop working like strangers.
Table of contents
How it works
It starts the moment you open a session. team-boot fires via the
session_start event hook and injects a lean index of your team's rules —
roughly a hundred tokens of names and one-line descriptors. Not the rules
themselves. When the active task matches a rule, the agent pulls that
rule's full text on demand. A task touching SQL loads the SQL rule;
nothing else does.
The index lives in a git repo — your team-ai-directives —
versioned, reviewed by PR, shared by the whole team. No more personal
CLAUDE.md files that live on one machine, drift out of date, and don't
transfer between teammates or tools.
When you ask the agent to build something, it doesn't jump to code.
factory-mission forces a contract first — goal, constraints, non-goals,
success criteria (the mission-brief format) — then walks specify → plan → implement ↔ converge, with
gates, a circuit breaker, resume, and an audit trail. When a session
surfaces a hard-won fix, team-levelup extracts it as a Context
Directive Record (CDR), scores it by confidence, and publishes accepted
CDRs back to the team repo. Usage data and confidence scores live in
the adlc orphan branch — the next session starts smarter and CDRs
rank by real usage.
Verification, history, and tech selection have loops of their own.
When a rule or skill's behavior needs proof, the evals-* skills build
executable graders — binary checks where code can verify, LLM judges only
for what static checks can't — validated with holdout splits and TPR/TNR.
When you touch old code and wonder why it looks like this, change-init
mines git history for issue-linked commits and recovers the past-change
rationale as ChDRs. And when a tech choice comes up, tech-radar-boot
injects the Tikal Tech Radar's opinion — adoption ring, quadrant — before
the selection is captured as an ADR.
That session loop sits inside a bigger one: the software factory.
factory-queue triages incoming work, factory-mission executes it as
spec-gated missions in isolated worktrees, factory-review grades the
resulting PRs against policy-as-code, and factory-learn feeds what the
runs taught back into team-ai-directives — with human gates (⭐) at every
decision point. One platform: intake → mission → review → learning.
And because the skills trigger automatically from the index, you don't do
anything special once they're installed. Your coding agent just has your
team's context.
The developer journey
What it actually looks like to get from zero to a factory, in order.
0. Prerequisites
- A coding agent (opencode, Claude Code, Cursor, Codex, Gemini CLI, …)
adlc-cli — npx works, no install neededjq — required by the setup scripts (they build all JSON output with jq -n; missing jq fails loudly instead of silently resolving defaults)
1. Install — one command per project
npx adlc-cli team setup tikalk/adlc-team-skills -a opencode
This installs the skills (via npx skills add), generates the /name slash
commands, wires the event hooks, then runs /team-setup headlessly to
clone, link, or scaffold your team-ai-directives repo. It writes
.adlc/init-options.json (agent, skills source, directives path) so every
later command knows where things live.
Plain npx adlc-cli skills add tikalk/adlc-team-skills -a <agent> installs
skills + commands + events without the team configuration.
2. First session — context arrives on its own
Open a session in the project. team-boot fires on session_start and
injects the index (constitution titles, CDR index ranked by confidence,
Class Boots catalog, skills registry, MCP servers). On an unconfigured
project it points you to /team-setup; /team-constitution fills in your
team's principles once. There is nothing to remember after this point —
skills trigger when the task matches.
3. Daily work — index, class boots, decision capture
- The agent checks the directives index before any task; full rule bodies
load on demand.
- Class boots fire when a decision class shows up:
architect-boot
(ADR index), product-boot (PDR index), change-boot (ChDR index),
tech-radar-boot (radar opinion before a tech selection).
- Decision capture is suggested, never automatic: decisions detected
mid-session surface a
_Suggested capture_ line naming the class capture
skill (/architect-specify, /product-specify, /change-specify, …);
running that skill writes the lightweight draft to
.adlc/drafts/{adr,pdr,chdr,cdr,evals}/.
The file_edited hook notices each draft landing and nudges the matching
clarify skill (adr→/architect-clarify, pdr→/product-clarify, …).
- When harness compaction summarizes history away,
session_compact
re-injects the index.
4. Session end — learnings become records
team-levelup fires on session_end: it extracts hard-won fixes as CDRs +
paired eval CDRs, scores confidence, batch-reviews them, and publishes
accepted CDRs as a draft PR to team-ai-directives. Drafts and usage reports
live in the adlc orphan branch (drafts/cdr/ + reports/).
5. Individual lifecycles — on demand
Each record class has its own skill loop you invoke explicitly:
This is the beginning of the README. Read the rest at the original. Read the full README ↗
