Sextant

Fallback for general coding work that does not match any specific sextant sub-skill. Use for lightweight tasks: config changes, style fixes, utility functions, one-off scripts, or tasks too small to warrant a dedicated workflow. All dedicated sub-skills take priority over this one — check these first: sextant:fix-bug (broken behavior), sextant:debug (unknown bug location), sextant:add-feature (new functionality), sextant:modify-feature (changing existing behavior), sextant:review-code (evaluating code), sextant:write-tests (test coverage), sextant:refine-requirements (ambiguous scope), sextant:plan (multi-step sequencing), sextant:ship (release prep), sextant:migrate (cross-module upgrade), sextant:security (vulnerability audit). Only use this skill when none of the above match.

Use when implementing new functionality, new modules, new classes, or new API endpoints that do not yet exist in the codebase. Stronger signals: "add", "implement", "create", "build", "new feature", explicit new requirement. Use when the thing being built does not already exist. Apply this skill before starting any new-feature work.

Use when the user is fixing a bug, error, crash, regression, or unexpected behavior in existing code. Stronger signals: error messages, stack traces, "not working", "broken", "failing", "it used to work". Apply this skill before starting any bug-fix work.

Use when migrating code from one version, technology, or pattern to another — such as Vue 2 → Vue 3, JavaScript → TypeScript, database schema migration, or framework upgrades. Stronger signals: "migrate", "upgrade", "convert", "port", "move from X to Y". Distinct from sextant-modify-feature (single module behavior change); use this when multiple modules must change in a coordinated sequence with rollback points.

Use when changing, enhancing, optimizing, or refactoring existing functionality in the codebase. Stronger signals: "modify", "refactor", "optimize", "improve", "change how X works", "enhance". Use when the thing being changed already exists — if it doesn't exist yet, use sextant-add-feature instead. Apply this skill before starting any modify/refactor work.

Use when you need a complete execution plan for a confirmed requirement — breaking it into ordered tasks with skill assignments, impact radius scores, and testable acceptance criteria. Stronger signals: "plan this", "how should we build this", "break this into tasks", "sprint plan", "what order should we do this in", "create a task list". Use after sextant-refine-requirements (which confirms the what); this skill answers the how and in what order.

Use when writing test cases, adding test coverage, or verifying code behavior through tests. Stronger signals: "write tests", "add tests", "unit test", "integration test", "test coverage", "TDD", "test this function". Also triggered automatically after a bug fix to write the reproduction test. Apply this skill before starting any test-writing work.

Use when you have a symptom (error, crash, unexpected output) but cannot yet point to the specific function or line where the bug lives. Stronger signals: "I don't know where this is coming from", "can't reproduce consistently", "something is wrong but I don't know where". When you CAN point to a specific function or line, use sextant-fix-bug instead.

Use for a security-focused audit of code changes or modules. Stronger signals: "security review", "check for vulnerabilities", "is this safe", "audit this", "OWASP", "injection", "auth check", "XSS", "SQL injection". Distinct from sextant-review-code (general quality review); this skill specifically targets security dimensions. Can be run standalone or as a follow-up after sextant-review-code.

Internal reference injected by sextant sub-skills when .gitnexus/ is detected. Not intended for direct invocation. Provides enhanced tool-call guidance for all sextant workflows: context, impact, query, trace, diff_review, and rename MCP tools.

Use when requirements are ambiguous, need breaking down into tasks, or feasibility assessment is needed before implementation. Stronger signals: "unclear requirements", "break this down", "is this feasible", "help me design", "what do we need to build", vague one-sentence feature requests. Use before coding when the "what" is unclear. If requirements are already clear, skip directly to sextant-add-feature.

Use when preparing code to ship — creating a PR, writing a changelog, bumping a version, or doing final pre-merge checks. Stronger signals: "ship this", "create a PR", "write changelog", "bump version", "prepare for merge", "what do I need before merging". Distinct from sextant-review-code (which evaluates code quality); this skill handles the logistics of getting finished code across the finish line.

Use when reviewing code quality, pull requests, diffs, or evaluating changes before merge. Stronger signals: "review", "PR", "pull request", "code review", "check this code", "is this correct", "review this file". Takes highest priority over other task types when the primary request is to evaluate existing code. Apply this skill before starting any code review.