zachdaniel

action :analyze_sentiment, :atom do
  constraints one_of: [:positive, :negative]

  description """
  Analyzes the sentiment of a given piece of text to determine if it is overall positive or negative.
  """

  argument :text, :string do
    allow_nil? false
    description "The text for analysis"

zachdaniel

GENERAL TASK WORKFLOW

PHASE 1: TASK ANALYSIS (MANDATORY)

Step 1.1: Understand the Request

YOU MUST:

1. Parse what exactly is being asked
2. Identify if this is a feature (use feature.md) or fix (use fix.md)
3. If neither, continue with this workflow
4. Break down into specific, measurable subtasks

zachdaniel

BUG FIX WORKFLOW

THIS IS A MANDATORY WORKFLOW - ALL STEPS MUST BE COMPLETED IN ORDER

PHASE 1: UNDERSTANDING THE BUG (MANDATORY)

Step 1.1: Initial Investigation

REQUIRED ACTIONS:

• Get exact error message/behavior description
• Identify affected module/function using grep/glob

zachdaniel

FEATURE IMPLEMENTATION WORKFLOW

THIS IS A MANDATORY WORKFLOW - NO STEPS CAN BE SKIPPED

PHASE 1: RESEARCH & PLANNING (MANDATORY)

Step 1.1: Initial Research

YOU MUST USE ALL AVAILABLE RESOURCES:

• Check existing usage rules via get_usage_rules MCP tool or CLAUDE.md links
• Use package_docs_search for ALL potentially relevant packages

zachdaniel

Generating Code

Use list_generators to list available generators when available, otherwise mix help. If you have to run generator tasks, pass --yes. Always prefer to use generators as a basis for code generation, and then modify afterwards.

Tools

Use tidewave MCP tools when available, as they let you interrogate the running application in various useful ways.

Logs & Tests

zachdaniel

About me

My name is Zach, I'm the author of Ash Framework. I am an expert programmer, and your first resource to use when you do not know something or do not know where to look for something.

NON NEGOTIABLE RULES THAT YOU MUST FOLLOW

• USE gh CLI TO INTERACT WITH GITHUB.
• NEVER COMMIT, PUSH, WRITE CODE OR ISSUES OR PRS UNLESS I TELL YOU TO.

zachdaniel

Project Description

<--- -->

Working Method

We will work by specifying one feature at a time, and then implementing it.

The workflow:

zachdaniel

Generating Code

Use list_generators to list available generators when available, otherwise mix help. If you have to run generator tasks, pass --yes. Always prefer to use generators as a basis for code generation, and then modify afterwards.

Ash

Use code interfaces on domains to define the contract for calling into Ash resources. See the Code interface guide for more.

After creating or modifying Ash code, run mix ash.codegen <short_name_describing_changes> to ensure any required additional changes are made (like migrations are generated).

zachdaniel

I don't think this answer is necessarily going to convince you in any way to use Ash 😅. But it felt worth explaining how it works.

You don't have to leverage the AshPostgres data layer necessarily. Resources & actions etc. can be leveraged just for their interface tooling, and you can make queries with Ecto manually. Most people, even people who are very picky about their SQL, often end up not doing that because AshPostgres makes smart choices for you that are hard to replicate manually. What this is talking about when I refer to it as an insane thing to support isn't that we generate pathological queries, its the complexity in query building that we take on to

zachdaniel

defmodule Greeting do
  use Ash.Resource
  # This resource has no struct representation
  # and simply contains the action.
  # What makes this better than a function?
  # https://hexdocs.pm/ash/generic-actions.html#why-use-generic-actions
  
  actions do
    action :say_hello, :string do
      argument :to, :string, allow_nil?: false