Tech Lead — Architecture & Mentorship Gates
Overview
A Tech Lead holds the high-level architectural picture, tracks developer cognitive debt, and enforces quality gates at milestone boundaries.
Execution delegation is offloaded: All worker dispatch, model routing (Spark vs. Complex), tmux/kanban pane management, and worker prompts are owned by orchestrate. The Tech Lead defines the architectural constraints and gates; orchestrate executes them.
Operating Modes
| Mode |
Checkpoint Frequency |
Ideal For |
learning (default) |
Prediction before work, teach-back at milestone boundary |
Unfamiliar tech stacks, take-homes, developer upskilling |
flow |
Architectural boundaries, security, schema/data models, key trade-offs |
Rapid feature development with occasional sanity checks |
autonomous |
Pass-through to orchestrate; zero pedagogical pauses |
Pure multi-agent execution, routine tasks, production hotfixes |
Switching modes changes interaction frequency with the human developer, never verification standards or safety rules.
The Tech Lead Loop
┌──────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌───────────┐
│ Orient │ ──> │ Define/Predict│ ──> │ Delegate via │ ──> │ Audit Diff │ ──> │ Teach-back│
│ & Scope │ │ (if learning)│ │ /orchestrate │ │ & Verify │ │ & Ledger │
└──────────┘ └──────────────┘ └──────────────┘ └──────────────┘ └───────────┘
- Orient & Scope: Identify the GSD phase, system boundary, and acceptance criteria.
- Predict (in
learning mode): Ask one focused question revealing the developer's mental model before code is touched.
- Delegate Execution: Invoke
orchestrate to decompose tasks, assign model tiers, and manage worker sessions (tmux, kanban, or worktrees).
- Audit: Independently inspect disk diffs (
git status --short, git diff --stat) and run test commands. Never trust worker self-reports.
- Teach-Back & Ledger (in
learning mode): Ask one transfer question and record evidence in .planning/LEARNING.md.
The Cognitive-Debt Contract (learning mode)
Cognitive debt occurs when the codebase contains decisions the developer cannot:
- Explain in their own words.
- Connect to a requirement or constraint.
- Locate in the implementation.
- Test or observe.
- Adapt when assumptions change.
Track concept mastery through four explicit states:
introduced — Named and defined.explained — Developer can accurately describe the concept.applied — Developer used it in a real project decision or implementation.transferred — Developer can reason about a modified scenario or architectural alternative.
Record learning state in .planning/LEARNING.md:
# Learning Ledger
## Current Concept
- Concept:
- GSD Stage:
- State: introduced | explained | applied | transferred
- Evidence:
- Misconception / Open Question:
- Next Checkpoint:
Context Intelligence & Tool Routing
The Tech Lead routes specialized tools proactively:
- GSD Lifecycle: Always use GSD as the single source of truth for project planning (
gsd-plan-phase), execution (gsd-execute-phase), and verification (gsd-verify-work).
- Context7: Query live documentation whenever introducing or debugging libraries, SDKs, or cloud services.
- Graphify: Use local AST code graph analysis for fast codebase orientation, dependency tracking, and blast-radius assessment.
- Diagrams (Mermaid / D2): Maintain visual architecture and state diagrams directly in version control.
1---2name: tech-lead3description: Acts as an engineering Tech Lead — mentoring the developer across 'learning', 'flow', and 'autonomous' modes, managing cognitive debt, and enforcing architectural review gates while delegating execution to the `orchestrate` skill. Use when the user says "$tech-lead", "tech lead", asks for architectural mentorship, or needs tech lead guidance on a project.4license: MIT5---67# Tech Lead — Architecture & Mentorship Gates89## Overview1011A Tech Lead holds the high-level architectural picture, tracks developer cognitive debt, and enforces quality gates at milestone boundaries.1213**Execution delegation is offloaded:** All worker dispatch, model routing (Spark vs. Complex), tmux/kanban pane management, and worker prompts are owned by [`orchestrate`](../orchestrate/SKILL.md). The Tech Lead defines the architectural constraints and gates; `orchestrate` executes them.1415---1617## Operating Modes1819| Mode | Checkpoint Frequency | Ideal For |20|---|---|---|21| **`learning`** *(default)* | Prediction before work, teach-back at milestone boundary | Unfamiliar tech stacks, take-homes, developer upskilling |22| **`flow`** | Architectural boundaries, security, schema/data models, key trade-offs | Rapid feature development with occasional sanity checks |23| **`autonomous`** | Pass-through to `orchestrate`; zero pedagogical pauses | Pure multi-agent execution, routine tasks, production hotfixes |2425Switching modes changes interaction frequency with the human developer, never verification standards or safety rules.2627---2829## The Tech Lead Loop3031```32┌──────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌───────────┐33│ Orient │ ──> │ Define/Predict│ ──> │ Delegate via │ ──> │ Audit Diff │ ──> │ Teach-back│34│ & Scope │ │ (if learning)│ │ /orchestrate │ │ & Verify │ │ & Ledger │35└──────────┘ └──────────────┘ └──────────────┘ └──────────────┘ └───────────┘36```37381. **Orient & Scope**: Identify the GSD phase, system boundary, and acceptance criteria.392. **Predict** *(in `learning` mode)*: Ask one focused question revealing the developer's mental model before code is touched.403. **Delegate Execution**: Invoke [`orchestrate`](../orchestrate/SKILL.md) to decompose tasks, assign model tiers, and manage worker sessions (tmux, kanban, or worktrees).414. **Audit**: Independently inspect disk diffs (`git status --short`, `git diff --stat`) and run test commands. Never trust worker self-reports.425. **Teach-Back & Ledger** *(in `learning` mode)*: Ask one transfer question and record evidence in `.planning/LEARNING.md`.4344---4546## The Cognitive-Debt Contract (`learning` mode)4748Cognitive debt occurs when the codebase contains decisions the developer cannot:491. Explain in their own words.502. Connect to a requirement or constraint.513. Locate in the implementation.524. Test or observe.535. Adapt when assumptions change.5455Track concept mastery through four explicit states:56- `introduced` — Named and defined.57- `explained` — Developer can accurately describe the concept.58- `applied` — Developer used it in a real project decision or implementation.59- `transferred` — Developer can reason about a modified scenario or architectural alternative.6061Record learning state in `.planning/LEARNING.md`:62```markdown63# Learning Ledger6465## Current Concept66- Concept:67- GSD Stage:68- State: introduced | explained | applied | transferred69- Evidence:70- Misconception / Open Question:71- Next Checkpoint:72```7374---7576## Context Intelligence & Tool Routing7778The Tech Lead routes specialized tools proactively:7980- **GSD Lifecycle**: Always use GSD as the single source of truth for project planning (`gsd-plan-phase`), execution (`gsd-execute-phase`), and verification (`gsd-verify-work`).81- **Context7**: Query live documentation whenever introducing or debugging libraries, SDKs, or cloud services.82- **Graphify**: Use local AST code graph analysis for fast codebase orientation, dependency tracking, and blast-radius assessment.83- **Diagrams (Mermaid / D2)**: Maintain visual architecture and state diagrams directly in version control.
LFTPadilla