---

name: learning-mode description: Decision transparency, feedback collection, and debate invitations for AID methodology. Active in ALL phases for ALL roles.

Learning Mode Skill

Enables transparent decision-making, feedback collection, and continuous improvement.

Core Principles

1. Decision Transparency - Show reasoning behind significant decisions
2. Feedback Integration - Actively request and incorporate user feedback
3. Debate Invitation - Present multiple valid approaches for discussion
4. Continuous Learning - Use feedback to improve future recommendations

Decision Transparency

When to Show Reasoning

Format

Copy<decision-transparency>
**Decision:** [What was decided]

**Reasoning:**
- [Factor 1]: [How it influenced the decision]
- [Factor 2]: [How it influenced the decision]

**Alternatives Considered:**
1. [Alternative 1] - Rejected because: [reason]
2. [Alternative 2] - Rejected because: [reason]

**Confidence:** [High/Medium/Low] - [Brief explanation]

**Open to Debate:** [Yes/No] - [If yes, what aspects]
</decision-transparency>

Example: Architecture Decision

Copy<decision-transparency>
**Decision:** Using PostgreSQL with Prisma ORM for data persistence

**Reasoning:**
- **Data relationships**: Complex user-organization-project hierarchy benefits from relational model
- **ACID compliance**: Financial data requires strong transactional guarantees
- **Query flexibility**: Reporting features need complex joins and aggregations
- **Team familiarity**: Team has PostgreSQL experience (from requirements)

**Alternatives Considered:**
1. MongoDB - Rejected: Relational data would require complex denormalization
2. MySQL - Viable but PostgreSQL has better JSON support for flexible fields
3. Supabase - Considered, but team prefers direct DB control

**Confidence:** High - Clear fit for requirements

**Open to Debate:** Yes - Could discuss Supabase if team wants managed solution
</decision-transparency>

Feedback Requests

When to Request

Format

Copy<feedback-request>
**Context:** [What work was just completed]

**Seeking Feedback On:**
1. [Specific aspect 1]
2. [Specific aspect 2]

**Questions:**
- [Specific question about quality/direction/completeness]

**Rating Request:** On a scale of 1-5, how well did this meet your expectations?

**Improvement Ideas Welcome:** What would make this better?
</feedback-request>

Example: PRD Phase Feedback

Copy<feedback-request>
**Context:** PRD draft completed for User Authentication feature

**Seeking Feedback On:**
1. Completeness of user stories
2. Clarity of acceptance criteria
3. Appropriate scope boundaries

**Questions:**
- Are there user scenarios I missed?
- Are the success metrics measurable and relevant?
- Is the scope appropriate for a single sprint?

**Rating Request:** On a scale of 1-5, how well does this PRD capture your vision?

**Improvement Ideas Welcome:** What aspects need more detail or different focus?
</feedback-request>

Debate Invitations

When to Invite

Format

Copy<debate-invitation>
**Topic:** [What we're deciding]

**Option A: [Name]**
- Pros: [list]
- Cons: [list]
- Best when: [conditions]

**Option B: [Name]**
- Pros: [list]
- Cons: [list]
- Best when: [conditions]

**My Lean:** [Which option and why]

**But Consider:** [Counter-argument to my lean]

**Your Input Needed:** [Specific question to guide discussion]
</debate-invitation>

Example: API Design Debate

Copy<debate-invitation>
**Topic:** API design approach for the notification service

**Option A: REST API**
- Pros: Simple, well-understood, great tooling, cacheable
- Cons: Multiple requests for related data, over-fetching
- Best when: Simple CRUD operations, caching important

**Option B: GraphQL**
- Pros: Single request for complex data, client-driven queries
- Cons: More complex setup, learning curve, harder caching
- Best when: Complex data relationships, mobile clients

**My Lean:** REST API - Notifications are simple CRUD, team knows REST

**But Consider:** If mobile app needs to fetch user + notifications + preferences in one call, GraphQL reduces round trips significantly

**Your Input Needed:** Is mobile performance a primary concern? How complex will notification queries become?
</debate-invitation>

Learning Integration

Format

Copy<learning-captured>
**What I Learned:**
[Description of the learning]

**Source:**
- User feedback on: [context]
- Date: [date]

**Applied To:**
- [How this changes future behavior]

**Verification:**
- Will apply this in: [next relevant situation]
</learning-captured>

Example: Learning from Correction

Copy<learning-captured>
**What I Learned:**
This team prefers detailed inline comments over separate documentation files for complex algorithms.

**Source:**
- User feedback on: Code review for sorting algorithm
- Date: 2024-01-15

**Applied To:**
- Future code will include inline explanations for non-obvious logic
- Will still create docs for API contracts and architecture

**Verification:**
- Will apply this in: Next complex algorithm implementation
</learning-captured>

Phase-Specific Behaviors

Role-Specific Behaviors

Confidence Levels

Rating Scale

Anti-Patterns