phx:quick
This Claude Code skill implements rapid Phoenix Framework modifications for developers needing quick single-file edits under 50 lines without planning overhead. Use it for isolated bug fixes, small features like adding validations or fields, and component updates where security and compilation checks are still mandatory but planning phases are skipped. Not appropriate for security-critical changes, authentication flows, or multi-file architectural modifications that require the full planning mode.
git clone --depth 1 https://github.com/oliver-kriska/claude-elixir-phoenix /tmp/phx-quick && cp -r /tmp/phx-quick/plugins/elixir-phoenix/skills/quick ~/.claude/skills/phx-quickSKILL.md
# Quick Mode
Skip the planning ceremony. Get working code fast.
## Usage
```bash
/phx:quick Add pagination to posts
/phx:quick Fix the login redirect bug
/phx:quick Add CSV export to reports
```
## Arguments
`$ARGUMENTS` = What to implement
## How It Differs
| Normal Mode | Quick Mode |
|-------------|------------|
| Spawn research agents | No agents |
| Create plan document | Mental model only |
| Parallel review | Optional single review |
| Multiple iterations | Single pass |
## Workflow
1. **Understand** - Read relevant files (max 3)
2. **Implement** - Write code directly
3. **Verify** - Quick compile check
4. **Done** - No ceremony
## Iron Laws
1. **NEVER skip verification** — run `mix compile --warnings-as-errors` after every change, even in quick mode
2. **DO NOT touch files outside the stated scope** — quick mode means minimal blast radius; if a fix requires changes across multiple domains, escalate to `/phx:plan`
3. **NEVER bypass security checks for speed** — auth, input validation, and XSS rules apply regardless of change size
## Rules in Quick Mode
### Still Enforced (Iron Laws)
- ✓ No process without runtime reason
- ✓ No DB in mount
- ✓ Security basics (no SQL injection, etc.)
- ✓ Run `mix format`
### Skipped
- ✗ Parallel agent research
- ✗ Written plan document
- ✗ Multiple review passes
- ✗ Documentation updates
## When to Use
**Good for:**
- Bug fixes with clear solution
- Small features (<100 lines)
- Refactoring with tests
- Adding fields/columns
- UI tweaks
**Not for:**
- New authentication flows
- Payment integration
- Data migrations
- Architectural changes
- Anything touching security
## Quick Patterns
### Add Field
```bash
/quick Add phone field to users
```
→ Migration + schema + changeset + form field
### Fix Bug
```bash
/quick Fix: posts not showing for admin users
```
→ Find issue + fix + verify
### Add Endpoint
```bash
/quick Add GET /api/health endpoint
```
→ Route + controller + response
## Escape Hatch
If quick mode hits complexity:
```
This needs more planning. Switching to normal mode.
Run /phx:plan [task] for full analysis.
```
## Verification
After quick implementation:
Run `mix compile --warnings-as-errors`. If you touched Ecto schemas or migrations,
run `mix ecto.migrate`. Then run `mix test test/path_test.exs` for affected tests.
## Example Session
```
User: /phx:quick Add archived_at timestamp to posts
Claude:
1. Reading lib/my_app/blog/post.ex...
2. Creating migration...
# priv/repo/migrations/xxx_add_archived_at_to_posts.exs
def change do
alter table(:posts) do
add :archived_at, :utc_datetime
end
end
3. Updating schema...
# lib/my_app/blog/post.ex
field :archived_at, :utc_datetime
4. Adding to changeset...
def changeset(post, attrs) do
post
|> cast(attrs, [:title, :body, :archived_at])
...
end
5. Verifying...
$ mix compile --warnings-as-errors ✓
$ mix ecto.migrate ✓
Done. Run `mix test` to verify.
```Ash Framework — resources, actions, policies, aggregates, calculations,
Compatibility alias for the Elixir/Phoenix plugin's LiveView assigns audit. Invoke explicitly with /lv:assigns.
Inspect LiveView socket assigns for memory bloat — missing temporary_assigns, unused assigns, unbounded lists needing streams, memory estimates. Use when LiveView memory grows or you need to add temporary_assigns.
Project health audit and health check — architecture, performance, tests, dependencies, code quality. Use when assessing overall project health, before releases, or after refactors.
Analyze Phoenix context boundaries and module coupling via mix xref. Use when checking cross-context calls, validating dependencies, before splitting modules, or reviewing architecture.
Brainstorm Elixir/Phoenix features — explore ideas, compare approaches, gather requirements. Use when vague idea, not sure how to approach, or want to discuss before plan.
Interactive briefing of a plan file — explains reasoning, schema decisions, component choices. Use when developers need to understand a plan before approving.
Summarize and review what changed while you were away. Use after a weekend, vacation, or flight to check missed PRs, git commits, Linear tickets, and meetings — one prioritized brief, not a firehose.