Rejection Logger

Transparency isn't just about showing what you did; it's about explaining what you didn't do. This skill helps you document rejected paths.

Core Workflow

1. Identify Rejection

When you evaluate multiple ways to solve a problem and pick one, or when you decide a user request is unsafe/out of scope, log it.

2. Log Entry

Append to .learnings/REJECTIONS.md (create if missing):

## [REJ-YYYYMMDD-XXX] <short_title>

**Timestamp**: ISO-8601
**Target**: <What was requested or considered>
**Decision**: REJECTED
**Reason**: <Why it was rejected (e.g., safety, complexity, better alternative)>
**Alternative**: <What was done instead>

When to Use

• When a user asks for something and you say "No" or "I can't".
• When you consider two tools and pick one.
• When you refactor code and decide against a specific library.

Benefits

• Audit Trail: Humans can see your internal deliberation.
• Trust: Showing rejections proves you are thinking, not just guessing.
• Self-Correction: Reviewing rejections helps you refine your decision boundaries.