Ash Framework — resources, actions, policies, aggregates; Use when generating resources via mix ash.codegen, editing…
日本語の概要は準備中です。原文の説明を表示しています。
Execute Elixir/Phoenix plan tasks with progress tracking. Use after phx-plan to implement features with mix compile and mix test verification after each step, or --continue to resume interrupted work.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Execute tasks from a plan file with checkpoint tracking and verification.
phx-work .claude/plans/user-auth/plan.md
phx-work .claude/plans/user-auth/plan.md --from P2-T3
phx-work --skip-blockers
phx-work # Resumes most recent plan
<plan-file> -- Path to plan file (optional, auto-detects recent)--from <task-id> -- Resume from specific task (e.g., P2-T3)--skip-blockers -- Continue past blocked tasks--continue -- Resume IN_PROGRESS plan from checkboxes[x] = done; [ ] = pending
unless the row is visibly tagged [BLOCKED]. No separate JSON state files.
Resume by reading the plan.git add -A or git add .Ask the user for plans with >3 tasks:
This plan has {count} remaining tasks across {count} phases.
- Start working -- Begin immediately (familiar patterns)
- Quick research -- Read source files first (~10 min)
- Extensive research -- Web search + docs (~30 min)
Skip for plans with 3 or fewer simple tasks -- just start.
Split warning: Plans with >10 tasks risk 2-3 context compactions. Suggest splitting via
phx-planif not already.
Read scratchpad and compound docs before writing any code — skipping
this causes rework. Read .claude/plans/{slug}/scratchpad.md (short,
critical context) for dead-ends and decisions, then Grep .claude/solutions/
for solved patterns. Apply findings: skip dead-ends, follow decisions,
reuse patterns. Ask the user when a task's intent is ambiguous — never
guess, corrections are expensive.
Read plan file, count [x] (completed) vs [ ] (remaining).
Select the first unchecked task not tagged [BLOCKED]. Stop if an unresolved
[BLOCKED] task precedes it unless --skip-blockers is explicit.
--skip-blockers skips only tagged blocked rows; --from <blocked-id>
explicitly retries that row and clears [BLOCKED] when starting.
Use the plan file as the portable task list. For every unchecked item,
preserve its - [ ] [Pn-Tm] row and ordering. At the start of a task, set its
phase to [IN_PROGRESS] and append a Started: entry to
.claude/plans/{slug}/progress.md. Mark the plan checkbox [x] only after
verification passes, then append the completion evidence to progress.md.
Dependencies remain explicit in phase order: do not start a later phase while an earlier phase has unchecked non-blocked tasks. This checklist is the progress UI, durable state, and resume mechanism; no runtime task API is required.
With --from P2-T3: Skip to that specific task.
Stale-plan check: if the plan predates this session (file mtime), spot-check 2-3 files it references before executing — assumptions may have drifted.
See references/resume-strategies.md for all resume modes.
Execute each unchecked task (- [ ] [Pn-Tm][concern] Description):
[IN_PROGRESS] and log the start in .claude/plans/{slug}/progress.mdreferences/execution-guide.md); it never selects a named workermix format + mix compile --warnings-as-errors
(at phase end, also run mix test <affected> — see tiers below)[x] on pass, append
implementation note inline, and log verification evidence in progress.md. Example:
- [x] [P1-T3] Add user schema — citext for email, composite index on [user_id, status]
This survives context compaction; the plan is re-read on resume.[BLOCKED], optionally mark its phase [BLOCKED], record the
blocker in progress.md, write a DEAD-END to scratchpad, and stop by
default. Continue only when --skip-blockers was explicitly suppliedParallel groups: Tasks under ### Parallel: may use native generic workers only when independent; otherwise execute them sequentially in the current session. See references/execution-guide.md
for the optional-worker pattern, sequential fallback, and checkpoint flow.
Verification tiers (scoped to minimize redundant runs):
mix compile --warnings-as-errors only
and mix format --check-formatted <changed_files>mix compile --warnings-as-errors + mix test <affected_files> + mix credo --strict
(scope tests: mix test test/path/to_affected_test.exs — NOT full suite)mix test (full suite — run ONCE at the end, not per-phase)Token efficiency: Write user-facing text for non-obvious decisions
and failures; routine verification passes need no commentary. When
several checkboxes complete together (parallel groups, resume catch-up),
batch them into ONE edit pass — never one Edit call per checkbox.
No hook is assumed. Run mix format explicitly during verification and
mix format --check-formatted <changed_files> before completing each task.
Summarize results, then ask the user a normal conversational question:
Implementation complete! {done}/{total} tasks finished. {count} files modified across {count} phases.
Options: 1. Run review (phx-review) (Recommended),
2. Get a briefing (phx-brief — understand what was built),
3. Create a git commit with the platform's native git workflow, 4. Continue manually.
If any task fixed a non-obvious bug, also mention phx-compound
to capture the solution.
With blockers: list them, offer Replan (phx-plan),
Review first (phx-review), or Handle myself.
If blockers remain, auto-write HANDOFF to scratchpad:
### [HH:MM] HANDOFF: {plan name}
Status: {done}/{total} tasks. Blockers: {list}.
Next: {first unchecked task ID and description}.
Key decisions: {brief list from this session}.
Include context beyond checkboxes for fresh session resume.
Wait for the user's choice before starting phx-review or any other phase.
After completion, use Glob to find other plan files matching
.claude/plans/*/plan.md. If pending plans exist, inform the
user. Do NOT auto-start.
phx-plan → phx-work (YOU ARE HERE) → phx-review → phx-compound
↑ ASK USER before each transition
references/execution-guide.md -- Task routing, parallel execution, verificationreferences/resume-strategies.md -- Resume modes and state persistencereferences/file-formats.md -- Plan and progress file formatsreferences/error-recovery.md -- Error handling and blockersreferences/harness-patterns.md -- Critic-refiner pattern for debugging loopsまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Ash Framework — resources, actions, policies, aggregates; Use when generating resources via mix ash.codegen, editing…
日本語の概要は準備中です。原文の説明を表示しています。
Ash Framework — resources, actions, policies, aggregates, calculations, AshPhoenix.Form, LiveView, migrations. Use when generating resources via mix ash.codegen, editing changes, checks, types, validations, or domain code interfaces.
日本語の概要は準備中です。原文の説明を表示しています。
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.
日本語の概要は準備中です。原文の説明を表示しています。