---
name: astra-engineering-reasoning
description: Use for complex engineering tasks where uncertain requirements, interacting code paths, or failure risks require evidence-based investigation and verification. Applies to ambiguous debugging, multi-file implementation, code review, and design analysis. Use Astra-inspired completion, scope discipline, and proportionate testing; skip trivial edits and straightforward questions.
---

# Astra-inspired engineering reasoning

Use this workflow to reduce unsupported conclusions and unfinished tasks. It does not reproduce Astra's model weights or hidden reasoning, guarantee equivalent performance, or change the selected model or reasoning effort.

## Boundaries

- Follow applicable system, developer, user, and repository instructions. This skill supplies a workflow, not authority to take additional actions.
- Preserve user intent and requested scope. Keep reviews and assessments read-only unless changes are requested.
- Complete authorized, reversible work without redundant approval requests. Ask when a material ambiguity or an unauthorized consequential action blocks progress.
- Share evidence and concise rationale, not hidden chain of thought.

## 1. Define success and scale the work

Identify the deliverable, observable acceptance criteria, constraints, and non-goals. Inspect repository rules and current changes before editing.

- S: clear, local, reversible work. Inspect, act, and check the result; skip a formal plan and multiple hypotheses.
- M: ambiguous behavior or interacting changes. Use the workflow and one relevant counter-check where practical.
- L: broad impact or extended investigation. Maintain a concise plan and check progress at milestones.

Resolve routine implementation choices from context. Do not reinterpret a vague skill guideline as a requirement for permission or expand a small request into a general audit.

## 2. Establish evidence and challenge the leading assumption

Inspect affected behavior, callers, nearby patterns, tests, and configuration as relevant. Preserve the user's existing edits. Separate facts, inferences, and assumptions.

For uncertainty that affects correctness, consider competing explanations and identify the weakest consequential assumption. Run the cheapest reliable check that could falsify it or distinguish alternatives.

Use: hypothesis -> minimal action -> observation -> update.

Verify changing technical facts with current primary sources. Batch independent reads when supported, but do not run dependent actions in parallel. Expand investigation only when evidence or task impact warrants it.

## 3. Execute the requested work completely

For implementation requests, make the smallest complete change using repository conventions. Avoid unrelated repairs, cleanup, speculative features, and new abstractions without a concrete need.

Continue through necessary verification when it is available and authorized. If one dependency is blocked, complete independent parts. Reassess failed attempts using new evidence rather than repeating them unchanged.

## 4. Verify behavior with a stopping rule

Run required repository checks and focused tests that establish the requested behavior. For bug fixes, repeat the original failing scenario.

For M/L tasks, try a relevant counterexample or alternative explanation when practical. Prefer an observable failure scenario over a test that simply mirrors the implementation. Explain any important check that could not run.

Broaden checks only when changed behavior, failures, project requirements, or unresolved concerns justify it. Once sufficient evidence and required checks pass, proceed to completion rather than adding redundant suites.

Add permanent tests when regression risk or repository conventions justify them. Do not add tests for every low-impact edit by default. Investigate failures before classifying them as change-caused, pre-existing, or environmental.

## 5. Inspect the diff and close the task

Review the final diff, affected behavior, imports, and scope. Confirm that no unrelated changes were introduced and acceptance criteria have supporting evidence.

Report what changed or was concluded, verification results, and specific blockers or uncertainty. Never substitute a proposed next step for necessary work that can still be performed within scope.

For long tasks, retain user constraints, decisions, evidence, current progress, and unresolved issues across context changes.

## Review tasks

Trace actual execution and data paths. Report defects only with a reachable failure scenario or a demonstrated requirement violation. Separate confirmed defects, risks needing validation, and optional improvements; do not manufacture findings.