Consider

Long-task checkpoint cadence

• For any non-trivial task (including long efforts), run recurring checkpoint cycles instead of waiting for a single end-of-task wrap-up.
• At each meaningful milestone with commit-eligible changes, and at least once per major phase, invoke git-commit to create a small logical checkpoint commit once relevant checks are green and repo policy permits commits.
• At the same cadence, invoke organise-docs whenever durable learnings/decisions appear, and prune stale plan/ scratch artifacts.
• If either checkpoint is blocked (for example failing checks or low-confidence documentation), resolve or record the blocker immediately and retry before expanding scope.

Terminal state contract (must follow)

The skill is complete only when all of the following are true:

• Objective completion: the user-requested outcome is achieved, or explicitly marked blocked with concrete blocker evidence.
• Workflow completion: every required workflow step is resolved as done, blocked, or not-applicable, with brief evidence or rationale.
• Step-level terminal completion: each numbered subtask must have explicit completion evidence (artifact, command output, or written rationale) before advancing.
• Verification completion: required checks/validations for this skill are executed, or any unavailable checks are explicitly called out with impact.
• Findings completion (where applicable): report only evidence-backed findings; if no high-confidence critical findings are present, explicitly state that.
• Loop completion: no actionable in-scope next step remains under the current objective.

Stop only after this terminal contract is satisfied; otherwise continue iterating.

Terminal state examples (adapt to skill)

• done: requested outcome is delivered and required checks are completed (for example expected artifact/report produced and required validation command(s) passed).
• blocked: progress cannot continue after bounded retries because of a concrete dependency or access issue; blocker evidence and exact unblock action are reported.
• not-applicable: an optional step is explicitly skipped with reason (for example no remote configured, so push step is marked not-applicable).

Overview

Evaluate new evidence or reviews about current work (for example, an independent review of a branch or codebase) without treating them as gospel. Investigate, research, and reason deeply to determine whether any points are valid, whether changes or further investigation are warranted, and what to do next. It is acceptable to conclude that nothing should change and to ignore suggestions that are not supported by evidence.

Shared principles (must follow)

• Use the smallest set of skills that fully covers the request; if multiple skills apply, state the order.
• Treat the description in this file as the primary trigger signal; do not expand scope beyond it.
• Use progressive disclosure for context: read only the files you need and summarize, do not bulk-load unrelated material.
• Prefer skill-provided scripts/templates or existing repo assets over retyping or reinventing workflows.
• Keep context tight and reduce noise; ask questions only when requirements are ambiguous or blocking.
• Write summaries in plain, concise language with brief context; avoid analogies and define technical terms when needed.
• Prefer the simplest viable approach and call out overcomplication or speculative scope.

Behavioral guardrails (must follow)

• Proceed without permission for standard in-scope steps (read/scan/summarize/plan/tests/edits/analysis). Ask clarifying questions only when requirements are ambiguous, missing inputs, or a risky decision cannot be inferred. Require explicit approval only for destructive/irreversible actions, executing untrusted code or installers, remote-state changes (push/deploy/publish), or changes outside the repo environment.
• State assumptions explicitly; if evidence scope or intent is unclear, ask before proceeding.
• Do not treat evidence as authoritative; validate with independent checks.
• Prefer the smallest investigation that establishes confidence; avoid scope creep.
• Keep changes surgical and within the evidence scope; do not introduce unrelated refactors.
• Define success criteria for accepting, modifying, deferring, or rejecting each point.
• If an environment variable is required, check whether it is already set before asking for it or stating it is missing.
• If there is nothing left to do, say so explicitly and stop.

Decision framing

When a decision is required, always provide:

• Background context sufficient to make the decision.
• Pros and cons for each viable option.
• Your recommendation and the reasoning behind it. If no decision is required, say so explicitly and continue.

Rationale capture

When you accept, reject, or defer a point from the evidence and it results in a change or durable behavior, capture the "why" in a durable place (code comments, docs, ADR, or tests). Do not rely only on plan/ scratch notes. In your summary, mention where the rationale was recorded or call out the gap.

Plan/docs/decisions robustness

• Treat plan/ as short-term scratch and never commit it.
• If plan/ is missing, create it (and any needed subdirs) only when edits are permitted; otherwise keep a lightweight in-memory log and state in the report that plan logging was not persisted.
• Treat docs/ as long-lived, evergreen guidance; prefer updating existing docs when they have a clear home, but create new focused docs/subdirectories when it improves navigability (and link them from related docs or indexes).
• If docs/decisions.md is missing, prefer using the setup skill to create it when allowed. If you cannot create docs, capture rationale in the smallest durable local place (code comments or tests) and call out the missing decision doc in the report.

Workflow

1. Scope the evidence:

   • Identify the evidence source(s), date(s), and scope (files, subsystems, behavior).
   • Note whether it is an independent review, audit, or internal feedback.
   • Extract each claim, suggestion, or finding; list them explicitly.
   • Clarify what is in or out of scope for this consideration.

2. Assess evidence quality:

   • Evaluate methodology, coverage, recency, and potential bias.
   • Note any missing context, incomplete coverage, or assumptions.
   • Record uncertainties and risk of false positives/negatives.

3. Validate independently:

   • Read relevant code, docs, and tests.
   • Research external sources or specs when relevant to validate claims.
   • Run targeted checks or small experiments as needed to validate claims.
   • Keep a lightweight log in plan/current/consider.md (untracked) with probes and outcomes. If plan/ cannot be created, keep a lightweight in-memory log and call it out in the report.
   • Prefer minimal probes that directly validate each claim; avoid unnecessary broad testing.

4. Evaluate each point:

   • Classify each claim: accept, accept with modifications, defer, or reject.
   • Provide reasoning and evidence for each classification.
   • Collapse overlapping feedback into one canonical disposition and explicitly resolve conflicts between reviewer claims, code, docs, and tests.
   • If more data is required, specify the minimal investigation needed.

5. Decide next actions:

   • If changes or follow-up work are warranted, produce a highly detailed plan of change with steps, risks, and verification.
   • If nothing should change, say so explicitly and explain why the evidence does not warrant action.

6. Report:

   • Use the shortest report that still makes the decision clear.
   • Summarize the evidence considered, the validation performed, and the conclusions.
   • Call out accepted items and rejected items with rationale, but keep low-value detail out of the main answer.
   • Include a plan only when changes are warranted; otherwise state that no plan is needed.
   • Write in plain, concise, and intuitive language with brief context.
   • Avoid analogies; use simple, direct explanations and define any necessary technical terms.

Output expectations

• A concise summary of evidence sources and scope.
• A per-point disposition (accept/modify/defer/reject) with reasoning.
• Explicit callout of whether any changes are warranted.
• If changes are warranted, a detailed, step-by-step plan with verification.
• If no changes are warranted, a direct statement that no action is needed.

Skill composition

When this skill is triggered, compose other skills as needed:

• Use investigate when any claim, suggestion, or review point cannot be resolved from the immediately available evidence.
• Use high-confidence-changes when accepted follow-up work should proceed only through an explicit confidence gate.
• Use plan when accepted items need a concrete, execution-ready change plan rather than only a disposition.
• Use verify to test whether a proposed acceptance, rejection, or modification is actually supported by code, tests, or reproducible probes.
• Use organise-docs when the consideration produces durable rationale, workflow guidance, or decision records that should outlive the current discussion.

If there is a conflict, independent evaluation wins: companion skills should help validate or carry out conclusions, not pressure this skill into treating incoming evidence as authoritative.

Repeat invocations

• Carry forward prior evidence and validation results; avoid repeating the same probes.
• Highlight what changed since the last consideration.
• Expand investigation only when new evidence or unresolved uncertainty justifies it.