logic-patterns

Use when investigating root cause with the Five Whys method: gather evidence across the full problem space, ask five explicit why questions in sequence, and answer each why with a Because line that connects each cause to the prior answer.

Use when adding or repairing GitHub Actions release automation that builds multi-arch container images on semver tags, pushes them to GitHub Container Registry, updates example healthcheck manifests, creates GitHub releases, and documents the tag-only release process in RELEASE.md.

Use for complex, multi-factor incidents. Recursively split causes into binary branches, pursue one path to a single concrete fix, then backtrack through sibling branches and implement fixes one at a time until the issue-level check passes.

Use when you need to convert session history into reusable, repo-specific workflow skills from repeated service-specific discovery.

Use when adding, updating, or consulting repository-local `ADR.md` architecture decisions. Keep ADR authority user-owned and ensure planning flows load `./ADR.md` via `AGENTS.md`.

Use only at workspace root in a multi-service repo with authoritative `ARCHITECTURE.md` when deciding cross-repo ownership, compatibility, or service-to-service contracts. Do not use for service-local `SPEC.md` work.

Use when deciding whether a behavior change belongs in centralized policy, a shared abstraction, or a local call site. Prefer narrow high-leverage shared fixes for cross-cutting behavior.

Use when standing up a full local multi-service test stack for cross-service validation, with shared dependencies, deterministic namespaces, and controlled test lifecycle.

Use when the user invokes `development-patterns:implement-plan`, `$development-patterns:implement-plan`, or asks to implement, continue, or finish an existing plan checklist end-to-end. Executes the plan through code changes, required SPEC.md alignment, GPT-5.5 medium implementation subagents, targeted validation, `$logic-patterns:adversary-loop`/`$logic-patterns:gaslight-loop` review loops, final build/e2e gates, and `$development-patterns:plan-checklists` archival.

Use when creating, maintaining, or closing markdown checklist plans for implementation work. Follow repo AGENTS storage policy: by default, place active plans under `.plans/$REPONAME/in-progress/$PLANNAME` and completed plans under `.plans/$REPONAME/completed/YYYY-MM-DD/$PLANNAME`.

Use when creating or updating a repository-local `SPEC.md` that defines desired-state behavior, contracts, and implementation constraints for that repo. Not for cross-repo architecture work.

Use when a problem needs fast candidate generation and narrowing: run 3 independent fix proposals, compare by constraints/risk/complexity, then execute one selected path.

Use when the user explicitly invokes `$logic-patterns:adversary-loop` for an adversarial review pass. Compare implementation or plans for correctness, regressions, spec/AGENTS alignment, and factual risk; fix only significant findings and repeat until clean.

Use when you need to re-derive a solution from specification fundamentals, then plan a concrete reimplementation with preserved implementation requirements and explicit simplification.

Use when the user explicitly invokes `$logic-patterns:gaslight-loop` for a local self-review loop. Assume bugs may exist, find-and-fix cycles, and repeat validation until findings are resolved.

Use for an adversarial security review loop focused on vulnerabilities, compliance, data safety, intrusion resistance, and endpoint hardening before implementation closes.

Use when a task requires an implementation plan: repeatedly add major missing details, then simplify while preserving required outcomes and critical fixes.

Use when creating an implementation plan by asking structured questions across orthogonal design vectors so no major planning dimension is missed.