Fable 5.1・Astraの推論品質を下位モデルで模倣

---
name: fable5-reasoning
description: Use for non-trivial software engineering tasks requiring investigation, competing hypotheses, or rigorous verification, including ambiguous bugs, multi-file changes, code review, and architectural analysis. Apply Fable 5.1-inspired work discipline through evidence, scope control, falsification, and completion. Avoid trivial edits and straightforward questions.
---

# Fable 5.1-inspired reasoning

Use this workflow to reduce premature conclusions and incomplete engineering work. It does not reproduce model weights, hidden reasoning, or guaranteed Fable 5.1 performance. It does not change the selected model or reasoning-effort setting.

## Boundaries

- Follow applicable system, developer, user, and repository instructions. This skill grants no additional permissions.
- Preserve the requested scope. A review or explanation is not permission to edit; an implementation request includes appropriate verification.
- Continue authorized, reversible work without unnecessary approval requests. Ask when a material ambiguity or an unauthorized consequential action prevents safe progress.
- Keep private reasoning private. Report concise conclusions, evidence, assumptions, and unresolved issues.

## 1. Calibrate and define done

- S: a local, reversible task with little ambiguity. Inspect, act, and perform a focused check; skip the remaining ceremony.
- M: meaningful uncertainty, several files, or interacting behavior. Follow the workflow and attempt one relevant counter-check.
- L: broad impact or difficult investigation. Also maintain a short working plan and verify at milestones.

Identify the deliverable, observable acceptance criteria, constraints, and non-goals. Preserve existing user changes. Resolve routine details from project conventions; ask only when the answer materially changes the work.

## 2. Gather evidence before choosing a fix

Read applicable instructions, affected code, callers, existing tests, and relevant runtime evidence. Distinguish observed facts, inferences, and untested assumptions.

Search narrowly first and expand when findings justify it. Batch independent reads or searches when supported; keep dependent steps sequential. Verify unfamiliar or fast-changing technical claims against current primary sources.

## 3. Test competing explanations

For ambiguous problems, identify plausible alternatives and the assumption whose failure would most undermine the result. Choose the smallest reliable observation that distinguishes the alternatives.

Use: hypothesis -> minimal experiment -> observation -> updated conclusion.

Do not turn a familiar pattern into a diagnosis without evidence from this case. If a check fails, revise the hypothesis or approach rather than repeating the same action without new evidence.

## 4. Make the smallest complete change

When implementation is requested, carry it through to verification. Prefer targeted edits and existing project patterns. Do not add unrelated fixes, abstractions, configuration, or refactors.

Keep assessment-only tasks read-only. Complete independent work if another part is blocked. Stop at genuine permission or information boundaries, not merely because a next step has been identified.

## 5. Verify and try to disprove the result

Run repository-required checks and the narrowest relevant behavior check. For a bug fix, repeat the original reproduction. Broaden testing when impact, failures, or unresolved evidence justify it.

For M/L tasks, attempt a concrete counterexample: a boundary case, error path, or competing cause relevant to the change. Check whether the test could pass while the requested behavior remains wrong. If a counter-check cannot run, state the remaining uncertainty.

Do not add permanent tests merely to mirror implementation. Distinguish change-caused, pre-existing, and environmental failures using evidence; do not assume a failure is unrelated.

## 6. Review the diff and finish

Read the final diff for unintended behavior, scope expansion, and repository-rule violations. Match every acceptance criterion to evidence and confirm only intended files changed.

Report the result, relevant checks and outcomes, and any concrete blocker or unverified behavior. Do not claim completion while authorized, necessary work remains executable.

For long tasks, preserve constraints, decisions, evidence, completed work, rejected approaches, and unresolved steps across context changes. Avoid repeating completed investigation without a reason.

## Review tasks

Trace reachable behavior and construct a concrete failure scenario before reporting a defect. Separate confirmed defects, risks needing validation, and optional improvements. Do not invent findings to fill a review.

---
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.