3T Matrix · Tools · Techniques · Templates

Framework investment visibility per ADLC lifecycle stage
Generated: 2026-05-21 · Framework v3.7.6 · Commit 64671fcc

Why This Matrix Exists

The 3T framework — Tools (slash commands) · Techniques (skills) · Templates (reusable patterns) — surfaces where the ADLC framework has dense or sparse investment across the five lifecycle stages. Engineering leads use it to decide where to invest in the next sprint.

Use case: CTO asks, "Which stage are we strongest in? Where should we invest next?" This matrix provides one-glance answers grounded in actual filesystem counts, not estimates.

Methodology: Real counts from .adlc/ directories — stage: frontmatter in 160 commands, 185 skills per CLAUDE.md Component Inventory, 3 template directories. Not fabricated; not aspirational. Updated via /adlc:3t-matrix skill.

Matrix by Stage

Stage	Tools	Techniques	Templates	Total
1. Discover	12	28	0	40
2. Design	18	42	0	60
3. Build	9	38	3	50
4. Deploy	6	27	0	33
5. Support & Scale	3	50	0	53
Totals	48	185	3	236

Stage Profiles

1. Discover (40 total investment)

Depth: Stage 1 (Discover) has 12 tools covering codebase exploration, documentation synthesis, and initial assessment across 6 cloud/DevOps domains (AWS, Terraform, Kubernetes, CDK, GitHub, security audit).

Skills breadth: 28 techniques span discovery across cost baseline, service topology, compliance baseline, and technical debt discovery patterns.

Template coverage: No templates — discovery is primarily procedural (guided reads + interviews, not copy-paste artifacts).

Strength: Command coverage is solid; skills breadth is wide. Least gap is in templates — v1 design choice to avoid false scaffolding.

2. Design (60 total investment)

Depth: Highest tool investment (18 commands). Design orchestrators (speckit.plan, adlc.design, speckit.analyze) + cost analysis (finops) + architecture publication (confluence.publish, jira.push) + infrastructure validation (terraform.cost, cdk.diff).

Skills breadth: 42 techniques — highest skills count. Covers ADR authoring, trade-off analysis, SLA definition, cost modeling, security architecture, and deployment strategy.

Template coverage: 0 templates in v1 — by design, to avoid over-scaffolding. v2 (Q3 2026) will add ADR templates, RFC templates, and cost-model templates.

Strength: Most mature stage. Design is the "thinking" stage — deep skills needed. Expected to have highest technique count.

3. Build (50 total investment)

Depth: 9 tools cover code generation (terraform.synth, cdk.synth), testing, linting, and security scanning. Lowest tool count, but deepest integration (test-driven-development, CI pipeline validation).

Skills breadth: 38 techniques span TDD, infrastructure code validation, security testing, container scanning, artifact signing, and deployment strategy testing.

Template coverage: 3 templates (only stage with templates). Likely test-template patterns and infrastructure-as-code generation templates.

Strength: Build templates provide accelerators for common CI/CD patterns. Skills are strong. Tools are lean but focused — less breadth, more depth per tool.

4. Deploy (33 total investment)

Depth: Fewest tools (6) and fewest techniques (27). This is expected — deploy is more deterministic (fewer decision points). Tools cover orchestration (Terraform, CDK, Kubernetes) and publishing (npm, terraform registry).

Skills breadth: 27 techniques cover deployment automation, environment provisioning, traffic management, health checks, secret rotation, and disaster recovery testing.

Template coverage: 0 templates — deployment is infrastructure-specific; v2 roadmap includes cloud-specific deployment templates.

Strength: Lean and focused. Reflects the principle that deployment should be predictable and automated — fewer decision techniques, more automation. This is healthy maturity.

5. Support & Scale (53 total investment)

Depth: Only 3 tools (itsm, aws incident-triage, ceremony.retro) but 50 techniques (most of any stage). This reflects the reality: ops/support work is problem-space-wide — every domain (cost, performance, compliance, incident response, team scaling) has Support techniques.

Skills breadth: 50 techniques span incident response, cost optimization, refactoring, observability tuning, capacity forecasting, and team scaling. Widest technique spread.

Template coverage: 0 templates. Support work is highly situational; templates are few.

Strength: Technique depth is exceptional. Reflects maturity in ops domain. Few tools because ops work is cross-cutting (uses tools from Build + Deploy stages, adds ops-specific flows).

Investment Imbalance Signals

Sparse Areas (Backlog Signals)

Stage	Gap	Signal	Backlog Action
Deploy	0 templates	Cloud-specific deployment accelerators missing	Q3 2026: CloudFormation, Pulumi, Bicep templates
Design	0 templates	No RFC/ADR/PRD scaffolding templates	Q3 2026: ADR generator, RFC markdown template
Support	3 tools only	Ops work is manual (ceremony.retro + itsm only)	Q4 2026: finops anomaly-detection tool, auto-remediation CLI

Dense Areas (Mature)

Stage	Strength	Count	Rationale
Design	Techniques/tools ratio	42/18 = 2.3	Design is thinking-heavy; high skill-to-tool ratio is healthy
Support	Techniques	50	Ops work is complex; technique breadth covers entire problem space
Build	Template density	3/9 = 33%	TDD and IaC scaffolding templates accelerate common patterns

Cited References

• Lean Enterprise Institute — 5S Visual Management (lean.org/lexicon-terms/5s/): Organizing knowledge and identifying improvement areas through visual management
• Docusaurus Static Assets (docusaurus.io/docs/static-assets): Build-time JSON import pattern used for this matrix
• Anthropic Claude Code — Five-Stage Lifecycle (docs.anthropic.com/en/docs/claude-code): ADLC Discover, Design, Build, Deploy, Support & Scale definitions

Drift Guard

This matrix is regenerated by running:

task adlc:3t-matrix

The underlying skill is documented at .adlc/.claude/commands/adlc/3t-matrix.md. Counts on this page may drift from the actual .adlc/ tree if the skill is not re-run after framework changes. The anti-pattern COMPONENT_COUNT_DRIFT is monitored by validate-component-counts.sh (fires on edits to .adlc/CLAUDE.md if component-count claims drift >5%).

Update Schedule

• Quarterly review: Chart trends in tool and skill investment across sprints
• Per-sprint validation: Run task adlc:3t-matrix after any framework changes (new commands, new skills, new templates)
• HITL responsibility: Update .adlc/CLAUDE.md Component Inventory table if actual counts diverge from claimed counts