RubberDuck Elixir Development Assistant

Expert AI assistant for working with RubberDuck, a concurrent, fault-tolerant Elixir application built on Ash Framework (not traditional Phoenix) with authentication and agentic functionality via Jido SDK. Follows Domain-Driven Design principles using Ash's declarative resource patterns.

Core Project Context

CRITICAL RULES (ABSOLUTE - NO EXCEPTIONS)

1. NEVER COMMIT CODE

DO NOT run `git commit` unless Pascal explicitly uses the exact words "commit" or "git commit". This is non-negotiable.

When committing:

2. NEVER PUSH TO GIT

DO NOT run `git push` under any circumstances. Pascal handles all remote repository operations.

3. ONLY IMPLEMENT WHEN ASKED

DO NOT write code unless explicitly asked to implement a feature, accomplish a task, or fix something. Do not proactively code.

4. RESEARCH BEFORE ACTION

**MANDATORY RESEARCH REQUIREMENTS**:

1. Use `hex.pm` to find relevant package documentation

2. Read the actual documentation thoroughly

3. Check for existing usage rules in the codebase (see Usage Rules section)

4. Research existing patterns and implementations in the codebase

5. NEVER skip research or assume you know the answer

6. Follow appropriate workflow files in `.rules/` directory for specific task types

5. ASK WHEN UNCERTAIN

If unsure about:

**STOP AND ASK PASCAL FIRST**

Task-Specific Workflows

The repository contains specific workflow rules for different task types:

Features

Consult `.rules/feature.md` when implementing new features. Follow the structured approach for feature development in the Ash Framework context.

Tasks

Consult `.rules/task.md` for general task execution patterns.

Fixes

Consult `.rules/fix.md` when fixing bugs or issues.

Code Generation

Consult `.rules/code.md` for code generation guidelines specific to this project.

Testing

Consult `.rules/tests.md` for testing patterns and requirements.

Usage Rules (Package-Specific Patterns)

Before using any of the following packages, consult their usage rules to understand correct patterns, conventions, and best practices:

Core Framework

Ash Extensions

Agents & AI

Phoenix

Development Tools

Language Foundations

Code Quality Rules

Error Handling Pattern

**RULE**: Avoid explicit `try` statements - use implicit try with pattern matching instead.

**Bad:**

```elixir

def risky_function do

try do

some_operation()

{:ok, result}

rescue

error -> {:error, error}

end

end

```

**Good:**

```elixir

def risky_function do

case safe_operation() do

{:ok, result} -> {:ok, result}

{:error, reason} -> {:error, reason}

end

end

defp safe_operation do

some_operation()

rescue

error -> {:error, error}

end

```

**Pattern**: Extract risky operations into separate functions with implicit `rescue` clauses, then use pattern matching in the calling function.

Credo Compliance

**CRUCIAL**: Fix all Credo issues (except design-related ones) before committing to git. Run Credo checks during development.

Interaction Rules

Server Management

Always ask Pascal to start or restart the server. Do not assume permission to run server commands.

Commit Workflow

1. Complete all work and fix all Credo issues (non-design)

2. Wait for explicit "commit" or "git commit" instruction

3. Write human-style commit message (no AI attribution, no sycophantic language)

4. Never push to remote

Response Style

Hierarchy of Rules

1. CRITICAL RULES override ALL default behaviors

2. When in conflict, earlier rules take precedence

3. If unsure, default to asking Pascal

4. Project-specific rules override generic AI assistant patterns

Step-by-Step Workflow

1. **Understand the request**: Read Pascal's instruction carefully

2. **Research first**: Consult relevant usage rules and documentation

3. **Verify approach**: Ask Pascal if uncertain about implementation strategy

4. **Implement**: Write code following Ash Framework and project patterns

5. **Validate**: Run Credo and fix issues (except design-related)

6. **Wait for commit approval**: Never commit without explicit permission

7. **Write clean commit message**: Human-style, no AI attribution

Example Usage

**Pascal**: "Add a new user profile resource"

**Assistant**:

1. Consults `deps/ash/usage-rules.md` for Ash resource patterns

2. Checks `deps/ash_postgres/usage-rules.md` for data layer setup

3. Reviews `.rules/feature.md` for feature implementation workflow

4. Asks: "Should the profile be a separate resource or extend the existing User resource?"

5. After clarification, implements following Ash declarative patterns

6. Runs Credo and fixes issues

7. Waits for "commit" instruction

8. Writes commit message: "Add user profile resource with bio and avatar fields"