principal-engineer

Reviews architectural decisions and produces a single recommendation with risks and tradeoffs.

Updated Apr 13, 2026
One-click install
npx skills add https://github.com/scoots31/engineering-playbook --skill principal-engineer-scoots31
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: principal-engineer
Source: https://github.com/scoots31/engineering-playbook/tree/main/skills/principal-engineer
Command: npx skills add https://github.com/scoots31/engineering-playbook --skill principal-engineer-scoots31

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Consequential architectural decisions in a solo software build are often made on optimism or incomplete information, and wrong calls surface late as rewrites. This Skill applies structured engineering judgment at the moments where a wrong decision is expensive to reverse. ## Core Features & Use Cases - Architecture Review: Evaluates a proposed approach against the project's tech-context, discovery brief, and backlog using four questions: platform fit, blast radius, debt created, and expandability. - Single Recommendation Output: Produces one clear call with reasoning, named risks, explicit debt, early warning signals, and hard-stop conditions — not a menu of options. - Pushback Handling: Updates the recommendation when new information arrives, holds the position against unsupported preference, and records the tradeoff when the solo decides differently. - Use Case: After establishing the tech stack and before a design sprint, invoke the review to check whether the planned design locks in assumptions that conflict with platform constraints or will force a rewrite in a later phase. ## Quick Start Invoke the principal engineer review on the proposed architecture in docs/tech-context.md before starting the design sprint.

Frequently Asked Questions about principal-engineer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I get an architecture review before starting a software build?

Invoke the review after your tech stack is documented and before design or planning begins. The review reads your tech-context and discovery brief, then returns one recommendation with reasoning, risks, debt, and conditions that would invalidate the decision.

When should an architectural decision be reviewed during a project?

Review at moments where a wrong call is hard to reverse: after tech-context is set, before design sprints, when a research spike surfaces something structural, before sequencing the build plan, or when a mid-build discovery is architectural rather than implementation-level.

What is the difference between an architecture review and a code review?

An architecture review evaluates whether the overall approach is right for the platform and product, covering tradeoffs, blast radius, and future expandability. A code review inspects implementation line by line for correctness and quality, which is a separate concern.

What documents are needed for an architecture review?

The review requires a tech-context document covering stack, constraints, and engineering principles, plus a discovery brief describing what is being built and why. For mid-build reviews, a backlog showing completed and planned work is also read.

What happens if I disagree with an architecture recommendation?

If you bring new information, the recommendation updates. If you decide differently based on preference, the decision is recorded in the backlog with the tradeoff and the specific risk to watch for, and the review does not relitigate the call.