elixir-phoenix-brief
Brief a Phoenix plan so reviewers understand design, schema, and component choices.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Brief a Phoenix plan so reviewers understand design, schema, and component choices.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Recommend the right `$elixir-phoenix-*` skill for the current task.
Elixir/Phoenix: Review lifecycle, state-machine, Oban, persistence, pause/resume, retry, and restart-sensitive changes before commit, push, or PR. Use for concurrency-sensitive runtime work to produce explicit blocking vs optional findings, require durability checks, and verify smoke plus restart resilience when applicable.
Capture a solved Phoenix problem as a reusable solution doc.
Audit LiveView assigns for memory bloat, dead assigns, and stream candidates.
Audit project health across architecture, security, performance, tests, and deps.
Analyze Phoenix context boundaries and coupling with `mix xref`.
| name | elixir-phoenix-brief |
| description | Brief a Phoenix plan so reviewers understand design, schema, and component choices. |
| metadata | {"short-description":"Brief Phoenix implementation plans"} |
Interactive walkthrough of a plan's reasoning, decisions, and solution shape. Designed for developers who need to understand a plan in 1-2 minutes instead of reading the full document.
Plans answer "what to do" but bury "why." This skill bridges that gap with an interactive walkthrough.
`elixir-phoenix-brief` # Latest plan
`elixir-phoenix-brief` .codex/plans/user-auth/plan.md # Specific plan
$ARGUMENTS = Path to plan file (optional, auto-detects latest)Read the plan file and determine mode from phase statuses:
[PENDING] = Pre-work briefing (what WILL happen)[COMPLETED] or [IN_PROGRESS] = Post-work briefing
(what WAS done and why)If $ARGUMENTS has a path, use it
Otherwise, find latest plan:
Use rg --files to find .codex/plans/*/plan.md and pick the most recent.
If no plan found, tell user and suggest elixir-phoenix-plan
Read the plan file
Read what's available (don't fail if missing):
.codex/plans/{slug}/summaries/consolidated.md (research summary).codex/plans/{slug}/scratchpad.md (decisions, dead-ends).codex/plans/{slug}/progress.md (work log, post-work only)Present ONE section at a time, wrapped in the visual briefing block
(see references/briefing-guide.md Visual Formatting). After each
section, use ask the user directly with options:
| # | Title | Source |
|---|---|---|
| 1 | What We're Building | Summary + Scope |
| 2 | Key Decisions | Technical Decisions + scratchpad rationale |
| 3 | Solution Shape | Phases overview + Data Model |
| 4 | Risks & Confidence | Risks table + unknowns/spikes |
| # | Title | Source |
|---|---|---|
| 1 | What Was Built | Summary + completion status |
| 2 | Key Decisions & Why | Technical Decisions + scratchpad |
| 3 | How It Was Built | Phases with implementation notes |
| 4 | Lessons & Patterns | Risks encountered + patterns used |
See references/briefing-guide.md for section content templates.
elixir-phoenix-work without explicit user requestAfter final section (or when user stops):
That's the briefing! For full details, see:
{plan_path}
Ready to proceed? Try ``elixir-phoenix-work` {plan_path}` to start execution.
Post-work variant:
That's what was built! For full details, see:
{plan_path}
Consider ``elixir-phoenix-compound`` to capture key learnings for future reference.
`elixir-phoenix-plan` --> `elixir-phoenix-brief` (optional) --> `elixir-phoenix-work` --> `elixir-phoenix-brief` (optional)
create understand before execute understand after
For plans with 5+ phases or 4+ key decisions, consider suggesting
visual rendering after Section 3. See
references/visual-explainer.md for thresholds and commands.