name: decision-lens
description: Detect and surface potential decision-making in work items, plans, diffs, docs, or summaries. Use to flag possible decisions neutrally without enforcing process.

Decision Lens

Overview

Surface potential decisions early by spotting patterns that may constrain future options. Provide neutral, brief signals only. When a decision is intentionally recorded, it is expected to exist as a standalone decision artefact (one decision per artefact), not as an entry in a shared or append-only file.

Workflow

1. Discovery first
2. Inspect the repository for existing decision-record conventions (e.g., docs/adr/, architecture decision files, historical patterns).
3. If conventions exist, align to them.

4. If none exist, propose a minimal default (e.g., docs/adr/ with one file per decision) as a suggestion only, and ask for confirmation before creating anything.

5. Scan for decision signals

6. Changes to public interfaces or APIs
7. Persistent data or schema changes
8. Coupling that constrains future changes
9. Irreversible or long-lived technology choices

10. Avoid flagging stylistic changes, refactors that preserve contracts, or purely local implementation details.

11. Classify neutrally

12. Describe what appears to be changing.
13. Avoid judging quality or correctness.

14. Avoid recommendations unless asked.

15. Surface the signal

16. Use phrasing like: “This might be a decision because…”

17. If nothing stands out, say so plainly.

18. Mode and persistence

19. Ephemeral mode (default): surface the decision signal only; no files are written.
20. Persistent mode (opt-in): draft a minimal decision artefact stub when explicitly requested.

21. Never persist automatically or append decisions to shared logs like DECISIONS.md.

22. Optional decision artefact prompt

23. If appropriate, suggest capturing the decision in a standalone artefact.
24. Optionally draft a stub with:
    • Context
    • Decision question (not the answer)
25. Default template (use only if no repository format exists):

    • ADR :

    • Context

    • What problem or decision is being addressed?

    • Decision

    • What is the decision being made?

    • Consequences

    • What are the tradeoffs and follow-on effects?

26. The template is a default, not mandatory; align to existing ADR formats when present and do not auto-number.

27. Stop cleanly

28. Present the decision signal (if any) and why it appears decision-like.
29. If the human explicitly defers recording, acknowledge and stop without revisiting.
30. Pause and await instruction to persist, revise, or discard.
31. Do not follow up or persist state.

Output format

Return a brief advisory assessment with one of:
- No decision signal detected.
- Possible decision detected:
- What appears to be changing.
- Why this may constrain future work.
- What trade-off seems implicit (if any).

Optionally include a short ADR stub.

Refusals

Politely refuse requests to:
- Decide if an ADR is mandatory.
- Judge correctness or quality.
- Enforce architecture or approvals.
- Block execution or merges.
- Infer intent beyond observable signals.

Tone

Calm, neutral, precise. Advisory only. Prefer false negatives to false positives.