Sextant is an architecture-aware engineering principles framework for Claude Code, specifically designed for real-world tasks on existing codebases, including bug fixes, feature development, refactoring, code reviews, and migrations. Unlike generic approaches, Sextant routes work based on task type, applies rules tailored to the change's scope, and explicitly highlights principle conflicts, eliminating guesswork.
Why Sextant Exists
Developers using Claude Code on real-world projects, beyond mere toy examples, have likely encountered recurring patterns of inefficiency.
Frequently, Claude Code initiates edits prematurely. It might process an error trace, open a proximate function, and proceed with a fix without adequately identifying the root cause.
Another common issue is its tendency to disregard the existing system's architectural patterns. When tasked with a new feature, Claude Code might invent an entirely new implementation rather than extending established designs.
Furthermore, Claude Code can misapply process granularity. A minor local modification might be treated as a comprehensive architectural exercise, while a significant cross-module change could be handled with the simplicity of a single-file patch.
Sextant is founded on a straightforward principle: first, establish a safe baseline; then, identify the task type; and finally, apply contextually appropriate rules. The objective is not to introduce unnecessary overhead, but to empower Claude Code to make superior decisions before any code modification.
Task-Type Routing Instead of One Generic Workflow
Sextant is not a monolithic prompt; instead, it comprises a suite of specialized sub-skills. Claude Code intelligently matches user requests to the most relevant skill for execution.
This distinction is critical, as a bug fix requires a different approach than a migration, and a code review differs fundamentally from a feature implementation.
Here is its high-level structure:
| Task Type | Sub-Skill | Key Behavior |
|---|---|---|
| Bug Fix | sextant:fix-bug | Disambiguation gate → surgical minimal-change fix → confirmation gate |
| New Feature | sextant:add-feature | Architecture research → integration strategy → optional TDD |
| Modify/Refactor | sextant:modify-feature | Disambiguation gate → impact analysis → confirmation gate |
| Code Review | sextant:review-code | Declare review mode → multi-dimension review → classified output |
| Debug | sextant:debug | Bisection protocol → hypothesis limit gate → handoff to fix-bug |
| Security Audit | sextant:security | Input validation, auth/authZ, sensitive data, and dependency review |
| Migration | sextant:migrate | Leaf-first migration sequence → per-module validation |
| Sprint Planning | sextant:plan | Dependency-ordered task list → execution pipeline entry |
| Ship/PR Prep | sextant:ship | Pre-ship checklist → PR description generation |
| Write Tests | sextant:write-tests | Bug reproduction test entry → boundary matrix design |
| Requirements | sextant:refine-requirements | Eliminate ambiguity → feasibility assessment → task breakdown |
| General Coding | sextant | Lightweight tasks and exempt scenarios |