Claude Skill

init

Initialize plugin in a project — install Iron Laws, auto-activation rules, and reference auto-loading into CLAUDE.md. Use when setting up or updating the plugin.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download oliver-kriska-claude-elixir-phoenix-plugins_elixir-phoenix_skills_init-9767a82.zip · 7 KB
Part of oliver-kriska/claude-elixir-phoenix — 93 skills

Install

skills CLI npx skills add https://github.com/oliver-kriska/claude-elixir-phoenix/tree/main/plugins/elixir-phoenix/skills/init
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install oliver-kriska-claude-elixir-phoenix@llmmart
Git git clone https://github.com/oliver-kriska/claude-elixir-phoenix.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole oliver-kriska/claude-elixir-phoenix collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Plugin Initialization

Install the Elixir/Phoenix plugin's behavioral instructions into the project's CLAUDE.md.

Usage

/phx:init           # First-time installation
/phx:init --update  # Update existing installation with latest rules

Iron Laws

  1. NEVER overwrite content outside plugin markers — User-written CLAUDE.md rules must be preserved verbatim
  2. Always detect stack before generating — Never assume Phoenix/Ecto versions
  3. Always validate after installation — Verify markers present and stack correct

Workflow

Step 1: Check Existing CLAUDE.md

Use Glob to check if CLAUDE.md exists. Then use Grep to check for existing ELIXIR-PHOENIX-PLUGIN:START marker in CLAUDE.md.

Step 2: Detect Project Stack

Scan the project to customize the injected instructions:

Read mix.exs and use Grep to extract:

  • Phoenix version: search for phoenix.*"~> in mix.exs
  • Ecto version: search for ecto.*"~> in mix.exs
  • Oban: search for "oban" and "oban_pro" in mix.exs
  • Frameworks: search for "ash", "surface" in mix.exs
  • Tidewave: search for "tidewave" in mix.exs
  • Project size: use Glob to count lib/**/*.ex files

Step 3: Handle Installation Modes

Mode A: Fresh Install (no CLAUDE.md or no markers)

  1. Create/append to CLAUDE.md
  2. Insert full behavioral instructions between markers
  3. Include only relevant sections based on detected stack

Mode B: Update (--update flag or markers exist)

  1. Find content between <!-- ELIXIR-PHOENIX-PLUGIN:START --> and <!-- ELIXIR-PHOENIX-PLUGIN:END -->
  2. Replace with latest behavioral instructions
  3. Preserve everything outside the markers

In both modes, CLAUDE.md content outside the plugin markers — user-written rules, project conventions, other plugin sections — stays verbatim (Iron Law 1)

Step 4: Generate Content

Write the following structure to CLAUDE.md:

<!-- ELIXIR-PHOENIX-PLUGIN:START -->
<!-- Last updated: {date} | Plugin version: 1.0 | Stack: Phoenix {version}, Ecto {version}, {optional: Oban, Tidewave} -->

# Elixir/Phoenix Plugin - Auto-Activation Rules

{Include all sections from the Content Template below, filtered by detected stack}

<!-- ELIXIR-PHOENIX-PLUGIN:END -->

Step 4b: Offer Codex Review Guidelines (optional)

If command -v codex succeeds (or the user asks): offer to install a managed ## Review guidelines block into the project's AGENTS.md — honored by BOTH codex exec review locally and the Codex cloud PR reviewer. Follow the install rules and exact block in ${CLAUDE_SKILL_DIR}/references/codex-review-guidelines.md: markers ELIXIR-PHOENIX-REVIEW-GUIDELINES:START/END, upsert in place on --update, never touch content outside markers, and STOP to ask if an unmanaged ## Review guidelines section already exists. When codex is absent and not requested, skip silently — never mention codex to users who don't have it.

Step 5: Output Summary

✅ Elixir/Phoenix plugin initialized

Detected stack:
- Phoenix {version}
- Ecto {version}
- {Oban standard | Oban Pro | not detected}
- {Tidewave ✓ | Tidewave not detected}
- {Ash Framework detected - Ecto patterns disabled | not detected}

Added to CLAUDE.md:
- Auto-activation rules (complexity detection, interview mode)
- Agent trigger patterns ({n} agents available)
- Reference auto-loading ({n} reference docs)
- Iron Laws enforcement ({n} laws)
- Verification rules
{- Codex review guidelines → AGENTS.md (only if installed in Step 4b)}

Run /phx:init --update after plugin updates.
Run /phx:audit for a full project health check.

Content Template

The exact content to inject is in ${CLAUDE_SKILL_DIR}/references/injectable-template.md.

Key structure:

  1. Routing table — which /phx:* command fits which kind of request
  2. Iron Laws — STOP behavior on violations
  3. Conditional Sections — Include based on detected stack:
    • {OBAN_SECTION} — If Oban detected (not Pro)
    • {OBAN_PRO_SECTION} — If Oban Pro detected
    • {ASH_SECTION} — If Ash Framework detected
    • {TIDEWAVE_SECTION} — If Tidewave detected
  4. Verification — Mandatory after code changes
  5. Quick Reference — Skill routing table

Placeholder substitution:

Placeholder Source
{DATE} Current date
{PHOENIX_VERSION} From mix.exs
{ECTO_VERSION} From mix.exs
{OPTIONAL_STACK} Detected optional deps

See ${CLAUDE_SKILL_DIR}/references/injectable-template.md for full template with all placeholders and conditional sections.

Validation

After running /phx:init:

  1. Check CLAUDE.md contains markers
  2. Verify detected stack matches actual project
  3. New session should:
    • Auto-detect complexity when given tasks
    • Stop on Iron Law violations
    • Offer relevant workflows based on task

Error Handling

Scenario Action
CLAUDE.md read-only Error: "Cannot modify CLAUDE.md - check permissions"
Markers corrupted Warn, offer to remove and reinstall
Unknown Phoenix version Use conservative defaults (all features enabled)
Not an Elixir project Error: "No mix.exs found - is this an Elixir project?"

Relationship to Other Commands

Command When to Use
/phx:init First time, or after plugin updates
/phx:audit Periodic project health check
/phx:verify After code changes
Files (claude-elixir-phoenix)
  • references
    • codex-review-guidelines.md 3.6 KB
      # AGENTS.md Review Guidelines Block (Codex rubric)
      
      Managed `## Review guidelines` block for the target project's `AGENTS.md`.
      Codex honors this section in BOTH surfaces: the local CLI
      (`codex exec review`) and the cloud GitHub reviewer apply "guidance from
      the closest AGENTS.md to each changed file". This is the ONLY reliable
      rubric injection point — `codex exec review` rejects a custom-instructions
      prompt combined with `--base`/`--uncommitted`/`--commit`.
      
      ## Install rules
      
      1. If `AGENTS.md` does not exist: create it with just the block below.
      2. If it exists WITHOUT plugin markers but WITH a `## Review guidelines`
         section: show the existing section and STOP — ask before touching.
         User-authored guidelines win; offer to append missing rules only.
      3. If plugin markers exist: replace content between markers only
         (same upsert convention as the `ELIXIR-PHOENIX-PLUGIN` CLAUDE.md block).
         **Exception**: carry over the project's existing `### Known non-issues`
         entries verbatim — they are project knowledge, not template content;
         wiping them resurrects the false positives they suppress.
      4. Never modify anything outside the markers.
      
      ## Block to inject
      
      ```markdown
      <!-- ELIXIR-PHOENIX-REVIEW-GUIDELINES:START -->
      <!-- Last updated: {DATE} | Managed by /phx:init — edits inside markers are overwritten on --update -->
      
      ## Review guidelines
      
      Elixir/Phoenix review priorities. Flag violations at the given priority.
      
      - **P1** Money as float — monetary values must use `Decimal` or integer
        cents; flag any float arithmetic on prices/amounts.
      - **P1** Unpinned query values — Ecto query values must use `^`; flag any
        interpolation of user input into queries.
      - **P1** `String.to_atom/1` on user-controlled input — atom exhaustion DoS;
        require allowlist or validated `String.to_existing_atom/1`.
      - **P1** Unconditional DB queries in LiveView `mount` — mount runs twice;
        expect `assign_async` or a `connected?/1`-guarded branch.
      - **P1** Missing authorization in LiveView `handle_event` — every event
        handler must authorize; mount-time authorization is not sufficient.
      - **P1** `raw/1` with untrusted content — XSS.
      - **P1** Implicit cross join — `from(a in A, b in B)` without `on:` creates
        a Cartesian product.
      - **P2** Lists over ~100 items in LiveView assigns — require streams.
      - **P2** Oban worker hazards — non-idempotent `perform`, atom keys in args,
        structs stored in args (store IDs).
      - **P2** Bare `{:error, _}` swallowing changesets — `{:error,
        %Ecto.Changeset{}}` must be matched explicitly or form errors never
        re-render.
      - **P2** Unsupervised long-lived processes — no bare `GenServer.start_link`
        / `Agent.start_link` outside a supervision tree in production code.
      - **P3** `has_many` preloads via JOIN — prefer separate queries for
        `has_many`, JOIN for `belongs_to` (row multiplication).
      
      ### Known non-issues (do NOT report these)
      
      <!-- Add project-specific disproven findings here as reviewers repeat them.
           One line per pattern: what the reviewer keeps claiming + why it's wrong.
           Example:
      - Ecto does NOT validate schema-declared generated columns used via
        fragment() in this codebase — verified {date}, do not report as a crash.
      -->
      
      <!-- ELIXIR-PHOENIX-REVIEW-GUIDELINES:END -->
      ```
      
      ## Notes
      
      - Keep the block under ~35 lines — cloud reviews read the nearest AGENTS.md
        per changed file; a bloated rubric dilutes focus.
      - Cloud reviews surface mainly P0/P1 per OpenAI docs (P2/P3 observed in
        practice) — putting a priority on each rule steers what Codex reports.
      - Re-running `/phx:init --update` refreshes the block in place.
      
    • injectable-template.md 6.4 KB
      # Injectable Template for /phx:init
      
      This file contains the exact content to inject between markers. Replace `{PLACEHOLDER}` values with detected values.
      
      ## Full Template
      
      ~~~markdown
      <!-- ELIXIR-PHOENIX-PLUGIN:START -->
      <!-- Auto-generated by /phx:init | {DATE} | Phoenix {PHOENIX_VERSION}, Ecto {ECTO_VERSION}{OPTIONAL_STACK} -->
      
      # Elixir/Phoenix Plugin
      
      ## Routing
      
      | Request | Path |
      |---------|------|
      | Bug, unexpected behavior, stack trace | `/phx:investigate` |
      | Small change (<50 lines), config, CSS tweak | `/phx:quick` |
      | Feature spanning 2+ contexts, or a new domain concept | `/phx:plan` → `/phx:work` → `/phx:review` |
      | Auth, sessions, tokens, payments, billing | `/phx:plan` plus the `security-analyzer` agent — security work does not skip planning |
      | Scope still unclear | `/phx:brainstorm` |
      
      Ask about scope, access, and rollback before building anything in the bottom three
      rows. Skip the questions when the user says "quick" or "just do it".
      
      ## Running a `/phx:*` skill
      
      Skills are procedures — run their steps in order rather than improvising a
      different workflow. Each one names an artifact file (`.claude/plans/{slug}/…`);
      write it, including agent findings, before synthesizing anything from it. Chat-only
      output loses the artifact the next phase reads.
      
      Discovering the feature already exists is a finding to record in that artifact, not
      a reason to exit early.
      
      ---
      
      ## IRON LAWS — STOP if violated
      
      If code would violate ANY of these, you MUST:
      1. STOP immediately
      2. Show the problematic code
      3. Show the correct pattern
      4. Ask permission to apply the fix
      
      **LiveView**:
      1. NO DB queries in disconnected mount → use `assign_async`
      2. Use streams for lists >100 items
      3. Check `connected?/1` before PubSub subscribe
      4. Match `{:error, %Ecto.Changeset{}}` explicitly — bare `{:error, _}` silently hides form errors
      
      **Ecto**:
      5. NO `:float` for money → `:decimal` or `:integer` (cents)
      6. Pin values with `^` in queries — never interpolate
      7. Separate queries for `has_many`, JOIN for `belongs_to`
      
      **Security**:
      8. NO `String.to_atom(user_input)` — atom exhaustion attack
      9. AUTHORIZE every `handle_event` — mount auth is not enough
      10. NO `raw/1` with untrusted content — XSS vulnerability
      
      **OTP**:
      11. NO process without runtime reason — processes are for concurrency/state/isolation
      12. Mix tasks: `Mix.Task.run("app.config")` + `Application.ensure_all_started/1`, NEVER `Mix.Task.run("app.start")` (boots full tree: endpoint port, Oban consuming)
      13. Capture Gettext/CLDR locale BEFORE spawning Task/GenServer — locale is process-local, spawned processes reset to default
      
      **Code Style**:
      14. Comments aren't commit messages — change reasoning (the bug, what it replaces) goes in the commit/PR, not code. No issue tags inline (`# ENA-1234`). Keep only durable facts: footguns, quirks
      
      {OBAN_SECTION}
      
      {OBAN_PRO_SECTION}
      
      {ASH_SECTION}
      
      {TIDEWAVE_SECTION}
      
      ## VERIFICATION — MANDATORY after code changes
      
      After each code change, run this before presenting results:
      
      ```
      mix compile --warnings-as-errors && mix format --check-formatted
      ```
      
      Present code as complete only after verification passes.
      Offer `mix test` after significant changes.
      
      ## POST-ACTION — Offer follow-ups
      
      | After | Offer |
      |-------|-------|
      | Bug fix | "Capture as lesson with /phx:learn-from-fix?" |
      | Feature complete | "Quality check with /phx:review?" |
      | Migration | "Check migration safety?" |
      
      ## QUICK REFERENCE
      
      | Want To... | Use |
      |------------|-----|
      | Simple feature | Describe it (auto-complexity runs) |
      | Complex feature | `/phx:plan` → `/phx:work` → `/phx:review` |
      | Debug bug | `/phx:investigate` |
      | Review code | `/phx:review` |
      | Project health | `/phx:audit` |
      
      <!-- ELIXIR-PHOENIX-PLUGIN:END -->
      ~~~
      
      ## Conditional Sections
      
      ### OBAN_SECTION (if Oban detected, not Pro)
      
      ```markdown
      ## Oban — STOP if violated
      
      - Jobs MUST be idempotent (safe to retry)
      - Args MUST use STRING keys: `%{"user_id" => id}` not atoms
      - NEVER store structs in args — store IDs only
      ```
      
      ### OBAN_PRO_SECTION (if Oban Pro detected)
      
      ```markdown
      ## Oban Pro — Different API
      
      Use `process/1` NOT `perform/1`. Use `@impl Oban.Pro.Worker`.
      Standard Oban patterns DO NOT apply.
      ```
      
      ### ASH_SECTION (if Ash detected)
      
      ```markdown
      ## Ash Framework — Use ash-framework skill
      
      This project uses Ash Framework. Before writing ANY Ash code:
      
      1. Load the `ash-framework` skill — it owns all Ash patterns and Iron Laws
      2. Research: `mix usage_rules.search_docs "<topic>" -p ash -p ash_phoenix -p ash_postgres -p ash_authentication -p ash_oban`
      3. Module lookup: `mix usage_rules.docs Ash.Resource`
      4. Generators: `mix ash.gen.resource`, `mix ash.codegen`, `mix ash.gen.domain`
      
      Ash is a complement to Phoenix/Ecto — LiveView, security, and OTP Iron Laws still apply. For data access, prefer Ash actions via domain code interfaces over direct `Repo` calls.
      ```
      
      ### TIDEWAVE_SECTION (if Tidewave detected)
      
      ```markdown
      ## Tidewave — Use MCP tools
      
      PREFER these over file-based alternatives:
      - `mcp__tidewave__get_docs` — Fetch docs
      - `mcp__tidewave__project_eval` — Evaluate in running app
      - `mcp__tidewave__execute_sql_query` — Database queries
      ```
      
      ## Placeholder Values
      
      | Placeholder | Source | Example |
      |-------------|--------|---------|
      | `{DATE}` | Current date | 2026-02-05 |
      | `{PHOENIX_VERSION}` | `grep phoenix mix.exs` | 1.8.3 |
      | `{ECTO_VERSION}` | `grep ecto mix.exs` | 3.13.5 |
      | `{OPTIONAL_STACK}` | Detected optional deps | , Oban, Tidewave |
      | `{OBAN_SECTION}` | If oban in deps | Include Oban section |
      | `{OBAN_PRO_SECTION}` | If oban_pro in deps | Include Pro warning |
      | `{ASH_SECTION}` | If ash in deps | Include Ash warning |
      | `{TIDEWAVE_SECTION}` | If tidewave in deps | Include Tidewave section |
      
      ## Detection Commands
      
      ```bash
      # Phoenix version
      grep -oP '{:phoenix.*"~> \K[0-9.]+' mix.exs 2>/dev/null || echo "?"
      
      # Ecto version
      grep -oP '{:ecto.*"~> \K[0-9.]+' mix.exs 2>/dev/null || echo "?"
      
      # Optional dependencies
      grep -q ':oban,' mix.exs && echo "oban"
      grep -q ':oban_pro,' mix.exs && echo "oban_pro"
      grep -q ':ash,' mix.exs && echo "ash"
      grep -q ':tidewave,' mix.exs && echo "tidewave"
      
      # Project size (for greenfield detection)
      find lib -name "*.ex" 2>/dev/null | wc -l
      ```
      
      ## Marker Format
      
      **Start marker**: `<!-- ELIXIR-PHOENIX-PLUGIN:START -->`
      **End marker**: `<!-- ELIXIR-PHOENIX-PLUGIN:END -->`
      
      Content between markers is fully replaceable by `--update`.
      Content outside markers is NEVER modified.
      
  • SKILL.md 5.6 KB
    ---
    name: init
    description: Initialize plugin in a project — install Iron Laws, auto-activation rules, and reference auto-loading into CLAUDE.md. Use when setting up or updating the plugin.
    effort: low
    argument-hint: "[--update]"
    ---
    
    # Plugin Initialization
    
    Install the Elixir/Phoenix plugin's behavioral instructions into the project's CLAUDE.md.
    
    ## Usage
    
    ```
    /phx:init           # First-time installation
    /phx:init --update  # Update existing installation with latest rules
    ```
    
    ## Iron Laws
    
    1. **NEVER overwrite content outside plugin markers** — User-written CLAUDE.md rules must be preserved verbatim
    2. **Always detect stack before generating** — Never assume Phoenix/Ecto versions
    3. **Always validate after installation** — Verify markers present and stack correct
    
    ## Workflow
    
    ### Step 1: Check Existing CLAUDE.md
    
    Use Glob to check if `CLAUDE.md` exists. Then use Grep to check for existing `ELIXIR-PHOENIX-PLUGIN:START` marker in `CLAUDE.md`.
    
    ### Step 2: Detect Project Stack
    
    Scan the project to customize the injected instructions:
    
    Read `mix.exs` and use Grep to extract:
    
    - Phoenix version: search for `phoenix.*"~>` in `mix.exs`
    - Ecto version: search for `ecto.*"~>` in `mix.exs`
    - Oban: search for `"oban"` and `"oban_pro"` in `mix.exs`
    - Frameworks: search for `"ash"`, `"surface"` in `mix.exs`
    - Tidewave: search for `"tidewave"` in `mix.exs`
    - Project size: use Glob to count `lib/**/*.ex` files
    
    ### Step 3: Handle Installation Modes
    
    **Mode A: Fresh Install** (no CLAUDE.md or no markers)
    
    1. Create/append to CLAUDE.md
    2. Insert full behavioral instructions between markers
    3. Include only relevant sections based on detected stack
    
    **Mode B: Update** (`--update` flag or markers exist)
    
    1. Find content between `<!-- ELIXIR-PHOENIX-PLUGIN:START -->` and `<!-- ELIXIR-PHOENIX-PLUGIN:END -->`
    2. Replace with latest behavioral instructions
    3. Preserve everything outside the markers
    
    In both modes, CLAUDE.md content outside the plugin markers — user-written rules, project conventions, other plugin sections — stays verbatim (Iron Law 1)
    
    ### Step 4: Generate Content
    
    Write the following structure to CLAUDE.md:
    
    ```markdown
    <!-- ELIXIR-PHOENIX-PLUGIN:START -->
    <!-- Last updated: {date} | Plugin version: 1.0 | Stack: Phoenix {version}, Ecto {version}, {optional: Oban, Tidewave} -->
    
    # Elixir/Phoenix Plugin - Auto-Activation Rules
    
    {Include all sections from the Content Template below, filtered by detected stack}
    
    <!-- ELIXIR-PHOENIX-PLUGIN:END -->
    ```
    
    ### Step 4b: Offer Codex Review Guidelines (optional)
    
    If `command -v codex` succeeds (or the user asks): offer to install a
    managed `## Review guidelines` block into the project's `AGENTS.md` —
    honored by BOTH `codex exec review` locally and the Codex cloud PR
    reviewer. Follow the install rules and exact block in
    `${CLAUDE_SKILL_DIR}/references/codex-review-guidelines.md`: markers
    `ELIXIR-PHOENIX-REVIEW-GUIDELINES:START/END`, upsert in place on
    `--update`, never touch content outside markers, and STOP to ask if an
    unmanaged `## Review guidelines` section already exists. When codex is
    absent and not requested, skip silently — never mention codex to users
    who don't have it.
    
    ### Step 5: Output Summary
    
    ```
    ✅ Elixir/Phoenix plugin initialized
    
    Detected stack:
    - Phoenix {version}
    - Ecto {version}
    - {Oban standard | Oban Pro | not detected}
    - {Tidewave ✓ | Tidewave not detected}
    - {Ash Framework detected - Ecto patterns disabled | not detected}
    
    Added to CLAUDE.md:
    - Auto-activation rules (complexity detection, interview mode)
    - Agent trigger patterns ({n} agents available)
    - Reference auto-loading ({n} reference docs)
    - Iron Laws enforcement ({n} laws)
    - Verification rules
    {- Codex review guidelines → AGENTS.md (only if installed in Step 4b)}
    
    Run /phx:init --update after plugin updates.
    Run /phx:audit for a full project health check.
    ```
    
    ## Content Template
    
    The exact content to inject is in `${CLAUDE_SKILL_DIR}/references/injectable-template.md`.
    
    **Key structure:**
    
    1. **Routing table** — which `/phx:*` command fits which kind of request
    2. **Iron Laws** — STOP behavior on violations
    3. **Conditional Sections** — Include based on detected stack:
       - `{OBAN_SECTION}` — If Oban detected (not Pro)
       - `{OBAN_PRO_SECTION}` — If Oban Pro detected
       - `{ASH_SECTION}` — If Ash Framework detected
       - `{TIDEWAVE_SECTION}` — If Tidewave detected
    4. **Verification** — Mandatory after code changes
    5. **Quick Reference** — Skill routing table
    
    **Placeholder substitution:**
    
    | Placeholder | Source |
    |-------------|--------|
    | `{DATE}` | Current date |
    | `{PHOENIX_VERSION}` | From mix.exs |
    | `{ECTO_VERSION}` | From mix.exs |
    | `{OPTIONAL_STACK}` | Detected optional deps |
    
    See `${CLAUDE_SKILL_DIR}/references/injectable-template.md` for full template with all placeholders and conditional sections.
    
    ## Validation
    
    After running `/phx:init`:
    
    1. Check CLAUDE.md contains markers
    2. Verify detected stack matches actual project
    3. New session should:
       - Auto-detect complexity when given tasks
       - Stop on Iron Law violations
       - Offer relevant workflows based on task
    
    ## Error Handling
    
    | Scenario | Action |
    |----------|--------|
    | CLAUDE.md read-only | Error: "Cannot modify CLAUDE.md - check permissions" |
    | Markers corrupted | Warn, offer to remove and reinstall |
    | Unknown Phoenix version | Use conservative defaults (all features enabled) |
    | Not an Elixir project | Error: "No mix.exs found - is this an Elixir project?" |
    
    ## Relationship to Other Commands
    
    | Command | When to Use |
    |---------|-------------|
    | `/phx:init` | First time, or after plugin updates |
    | `/phx:audit` | Periodic project health check |
    | `/phx:verify` | After code changes |
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related