Agent skill · Audited from source
Work
skill · oliver-kriska/claude-elixir-phoenixMIT licenceAudited 18 Oct 2026 · source 492f17636999
Is it safe? Yes — SAFE, grade B (89/100). We read this skill's source at commit 492f17636999 and found no filesystem, network or shell access and no hard-coded secrets. What it does: 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.
Cite
Cite this page
ModelsAtlas. “Work (oliver-kriska/claude-elixir-phoenix)”. Retrieved 18 Oct 2026. https://modelsatlas.com/skills/oliver-kriska/work
Trust audit
Audit 0.4.1 · source read 18 Oct 2026
SAFE means nothing in the source contradicts what the skill says it does. Grade B is shared by 16,667 of 17,602 audited skills.
What the source does
- FilesystemNone observedNo reads or writes in the source
- NetworkNone observedNo outbound calls in the source
- ShellNone observedNo commands run in the source
- DependenciesPinnedNothing floats
- SecretsNone foundNo keys in source
Five audit layers
| Layer | What we check | Result | Findings |
|---|---|---|---|
L0 Provenance | Repo owner, licence, archive status, activity | PASS | 0 |
L1 Static source | Secrets, path traversal, supply chain, hidden code | NA | 0 |
L2 Instructions | Prompt injection, authority framing, hidden directives | PASS | 0 |
L3 Inventory | The files and declarations match the source | PASS | 0 |
L4 Sandbox | Run in isolation and watch behaviour | SKIPPED why | 0 |
Gates applied: no behavioural pass.
Findings (0)
No findings at any severity. We re-audit when the source changes.
Audit 0.4.1 · source sha 492f17636999 · 18 Oct 2026Report an issue or request a re-scan
Provenance
Who published it, and what the verdict is pinned to
- Publisheroliver-kriska GitHub userOwner of the repository this skill is read from
- Source folderoliver-kriska/claude-elixir-phoenix/plugins/elixir-phoenix/skills/workThe exact folder we audited
- LicenceMITAs the repository states it
- Commit pinned for this verdict492f17636999A new audit runs when the source changes
- Repository statusNot archivedLast push 2 days ago
- Sandboxed runNot runSkills are read, not executed; layer L4 is skipped
What it tells the agent
Full source on GitHub ↗Its description: 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.
---
name: work
description: 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.
effort: high
argument-hint: <path to plan file>
---
# Work
Execute tasks from a plan file with checkpoint tracking and verification.
## Usage
```
/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
```
## Arguments
- `<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
## Iron Laws (NON-NEGOTIABLE)
1. **NEVER auto-proceed** to /phx:review or any next workflow
phase -- always ask the user what to do next
2. **AUTO-CONTINUE between plan phases** -- when Phase N completes,
immediately start Phase N+1. Do NOT stop or ask for permission
between phases. Only stop at BLOCKERS or when ALL phases are done.
3. **Plan checkboxes ARE the state** -- `[x]` = done, `[ ]` = pending.
No separate JSON state files. Resume by reading the plan.
4. **Verify after EVERY task** -- never skip verification
5. **Max 3 retries then BLOCKER** -- don't keep retrying forever
6. **Stage specific files** -- never use `git add -A` or `git add .`
7. **Read scratchpad BEFORE implementing** -- scratchpad has dead-ends
and decisions that prevent rework. Step 2 is not optional.
8. **Clarify ambiguous tasks** -- ask the user rather than guessing
when a plan task's intent is unclear
## Step 1: Research Decision
Ask the user for plans with >3 tasks:
> This plan has {count} remaining tasks across {count} phases.
>
> 1. **Start working** -- Begin immediately (familiar patterns)
> 2. **Quick research** -- Read source files first (~10 min)
> 3. **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:plan` if not already.
## Step 2: Check Context (MANDATORY)
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.
## Step 3: Load, Create Task List, and Resume
Read plan file, count `[x]` (completed) vs `[ ]` (remaining).
Find first unchecked task by `[Pn-Tm]` ID.
**Create Claude Code tasks** only if `TaskCreate` is in your tool list (Sonnet 5+ and Opus 4.8+
omit it unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=1`; never ToolSearch for it). Without it, skip every
`TaskCreate`/`TaskUpdate` step in this skill — plan checkboxes and `progress.md` are the state:
```
For each unchecked `- [ ] [Pn-Tm] Description`:
TaskCreate({
subject: "[Pn-Tm] Description",
description: "Full task details from plan",
activeForm: "Implementing: Description"
})
```
Skip already-checked items (`[x]`). Set `blockedBy` between phases
(Phase 2 tasks blocked by Phase 1 tasks).
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 `${CLAUDE_SKILL_DIR}/references/resume-strategies.md` for all resume modes.
## Step 4: Execute Tasks
Execute each unchecked task (`- [ ] [Pn-Tm][agent] Description`):
1. **Start task**: `TaskUpdate({taskId, status: "in_progress"})`
2. **Route** by `[agent]` annotation (see `${CLAUDE_SKILL_DIR}/references/execution-guide.md`)
3. **Implement** the task
4. **Verify**: `mix format` + `mix compile --warnings-as-errors`
(at phase end, also run `mix test <affected>` — see tiers below)
5. **Complete task**: Mark checkbox `[x]` on pass, **append
implementation note** inline, AND
`TaskUpdate({taskId, status: "completed"})`. 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.
6. **On failure**: retry up to 3 times, then create BLOCKER
and write DEAD-END to scratchpad (see error-recovery.md)
**Parallel groups**: Tasks under `### Parallel:` header spawn
as background subagents. See `${CLAUDE_SKILL_DIR}/references/execution-guide.md`
for spawning pattern, prompt template, and checkpoint flow.
**Verification tiers** (scoped to minimize redundant runs):
- Per-task: `mix compile --warnings-as-errors` only
(format is checked by PostToolUse hook automatically)
- Per-phase: `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)
- Per-feature (Tidewave): behavioral smoke test via `project_eval`
(create record, fetch, verify -- see execution-guide.md)
- Final gate: `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.
The PostToolUse hook checks formatting but does NOT modify files —
run `mix format` explicitly during verification or before committing.
## Step 5: Completion
Summarize results with `AskUserQuestion`:
> 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 wasExcerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.
Install
Pinned to the audited commit 492f176
git clone https://github.com/oliver-kriska/claude-elixir-phoenix git -C claude-elixir-phoenix checkout 492f17636999
The author documents no install command, so this uses the repository directly. Our verdict covers commit 492f17636999 only.
Works in which agents?
What its own text says, not a test
| Agent | Status | More |
|---|---|---|
| Claude Code | Mentioned in its text, not tested | Skills for Claude Code · About Claude Code |
Audit history
Every audit, every source change
- ✓SAFE B 89 / 100
first audit · source
492f17636999
README badge
For maintainers · shows the latest audit
[](https://modelsatlas.com/skills/oliver-kriska/work/)
The badge shows our verdict and grade for this skill, and links back to this page. It changes when the audit does.
Similar skills
All automation skills →oliver-kriska/claude-elixir-phoenix
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.
oliver-kriska/claude-elixir-phoenix
Project health audit and health check — architecture, performance, tests, dependencies, code quality. Use when assessing overall project health, before releases, or after refactors.
oliver-kriska/claude-elixir-phoenix
Analyze Phoenix context boundaries and module coupling via mix xref. Use when checking cross-context calls, validating dependencies, before splitting modules, or reviewing architecture.
oliver-kriska/claude-elixir-phoenix
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.
oliver-kriska/claude-elixir-phoenix
Interactive briefing of a plan file — explains reasoning, schema decisions, component choices. Use when developers need to understand a plan before approving.
oliver-kriska/claude-elixir-phoenix
Claude Code plugin for Elixir/Phoenix/LiveView — 26 specialist agents, Iron Laws enforcement, and Tidewave MCP integration. Plan features with parallel research agents, execute with automatic verification, review with…
Add this badge to your README
[](https://modelsatlas.com/skills/oliver-kriska/work/)
<a href="https://modelsatlas.com/skills/oliver-kriska/work/"><img src="https://modelsatlas.com/skills/oliver-kriska/work/badge.svg" alt="ModelsAtlas: SAFE B"></a>
Questions about Work
What does the Work skill do?
Is Work safe to install?
What can Work access on my machine?
Which assistants does Work work with?
How current is this page?
Sources
- github.com/oliver-kriska/claude-elixir-phoenix/tree/main/plugins — the audited source at commit 492f17636999 and every finding aboveObserved · 18 Oct 2026
Spotted something wrong? Report a correction · Methodology
Keep going in your AI
Opens with this page as the source. We add nothing else to the prompt.
- What does the Work skill do?
- Is Work safe to install?
- What can Work access on my machine?