← Back to Use Cases
Engineering

Architecture Review To Action Plan

Some teams do not need another repo summary. They need a clear read on architectural risk, a sensible plan, and a path into execution that still feels controlled.

Electron App · Deep Research

Inspect The Repo, Then Route The Work Into A Safe Plan

Use Deep Research to inspect the repository, surface the architectural risks that matter, and turn the findings into a plan the team can act on.

Research Question
Review the architecture, surface what matters, and route the output into a phased plan that future Kendr runs can continue without repeating the initial analysis.
Kendr Electron app Deep Research workspace for architecture review
Output package
Architecture summary, risk register, 30/60/90 plan
The run should move from understanding to a phased plan.
Decision motion
Turn repo analysis into execution-ready sequencing
This is where analysis becomes work the team can actually act on.
Reusable memory
Keep project context for later edits
Future runs should inherit the architecture read and next steps.
Focus
Module boundaries, dependencies, risk, sequencing
Keep the run centered on architectural signal, not code trivia.
Source families
Repo files, configs, git signals, docs
Use the codebase and its history together.
Output package
Architecture brief, risk register, 30/60/90
Keep the deliverable readable by both engineering and leadership.
Knowledge retention
Project memory + future edits
Save the analysis so later work starts with the same context.

Primary workflow

Agentic Work

Analyze a repo, synthesize findings, and propose phased actions.

Secondary value

Project Memory

Keep the architecture summary and next steps reusable for future work.

Why Kendr

Analysis plus governed execution

Kendr matters when the system may later act on the same codebase under approval control.

Use on a real repository

Run these prompts inside Kendr against an actual project. Then replace the placeholders with the resulting architecture summary, risk list, and phased plan.

What The Team Needs

Engineering leaders need to understand system boundaries, risky dependencies, technical debt patterns, and where to intervene first without forcing a manual repo crawl.

What Kendr Should Produce

A concise architecture map, a prioritized risk register, a phased plan, and a retained project context that future work can reuse safely.

Prompt Samples

Run These In Kendr

Prompt 01 · Architecture Scan
Review this repository and explain the architecture to a technical lead.

I need:
- system boundaries and major modules
- data flow and dependency hotspots
- operational or scaling risks
- code organization issues that will slow future work
- gaps in tests, contracts, or documentation

Use repo evidence, not generic advice.
Prompt 02 · Action Plan
Turn the architecture findings into a practical action plan.

Produce:
- quick wins
- medium-term refactors
- risky areas that need explicit approval before change
- dependencies and sequencing
- a recommended 30/60/90 day execution path

Keep it grounded in the repository you reviewed.
Prompt 03 · Persist Project Context
Save the important findings from this architecture review into persistent project memory.

Summarize:
- what this repo does
- what the main risks are
- what work should happen next
- what future Kendr runs should know before planning any edits or execution
Example Deliverables

What The Team Gets Back

Architecture summary

Drop in the repo summary from Prompt 01.

Risk register

List the technical risks and dependency hotspots Kendr identified.

Phased action plan

Insert the prioritized roadmap from Prompt 02.

Saved project memory

Show what future Kendr runs inherit from Prompt 03.

Join Early Access