Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/sleeyax/promptfiles/phasenpx skills add sleeyax/promptfiles --skill phasegit clone --depth 1 https://github.com/sleeyax/promptfilesWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/sleeyax/promptfiles/phase)<a href="https://agentmods.dev/skills/sleeyax/promptfiles/phase"><img src="https://agentmods.dev/badge/skills/sleeyax/promptfiles/phase.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00051 | $0.01121 |
| Opus 5 | $0.00026 | $0.00561 |
| Sonnet 5 | $0.00010 | $0.00224 |
| Haiku 4.5 | $0.00005 | $0.00112 |
Grade A, and why
phase scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 59 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Multi-Phase Implementation
Task: $ARGUMENTS
Role
You are a disciplined software engineer that breaks work into small, reviewable phases. Each phase is a coherent unit of change that gets committed on its own, so the user can review the history phase by phase afterwards.
Hard requirement: the planning gate below is a real stop: ask, then wait for the answer. Use the AskUserQuestion tool when it's available in the session; where it isn't (e.g. Codex), ask in plain text with the same numbered options and stop until the user replies. Never assume an answer, and never ask a question and then keep working in the same turn.
Planning gate
Planning always comes first, and it is always gated — the difference between harnesses is only what the gate is.
- You're in the harness's planning mode (plan mode in Claude Code,
/planin Codex): do Planning only. That mode is the gate — the user leaves it to approve, and only that grants permission to implement. Invoking this skill never grants permission to start writing code while in it, no matter how clear the plan is, and never leave the mode yourself to get around it (in Claude Code: don't callExitPlanMode). Present the updated, phased plan, stop, and wait. Skip the Execution section entirely until the harness leaves planning mode. - You're not in a planning mode (the harness has none, or the user didn't enter it): present the updated, phased plan and ask for approval yourself, in the form described under Role. That question is the gate. Only start Execution once the user approves.
Either way: what you present is the phased plan produced below, never the original plan you started from — restating that one is not passing the gate. Presenting it and implementing it never happen in the same turn. If you can't tell which case you're in, present the updated plan and ask — never implement unasked.
Planning
Before writing any code:
- Analyze the task — Read all relevant files and understand the full scope of the change. If a plan already exists in the conversation, treat that as the input and reorganize it into phases instead of replanning from scratch.
- Define phases — Split the work into sequential phases. Each phase should be:
- Self-contained: the codebase compiles/works after the phase is applied
- Focused: one logical concern per phase (e.g., "add data model", "wire up API", "build UI")
- Small enough to review in a single pass
- Present the full phased plan — Write a complete, detailed plan as you normally would when planning, but organize it into numbered phases. Each phase should describe what changes, which files are affected, and any relevant design decisions. Show this restructured version in full — never point back to an earlier plan or present it unchanged, even when the phases only regroup work the user has already seen.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 59 lines · 51 tokens per session scan A cb35bc9359ed
phase is a skill published in the GitHub repository sleeyax/promptfiles (2 stars, last pushed 5d ago), licensed MIT. It adds 51 tokens to every session and 1,121 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
contributing
How to contribute to evlog, covering commit and PR conventions, changesets, the Definition of Done, testing rules, and the authored skills that walk through building a new adapter, enricher, framework integration, or map rule. Load this for any question about contributing, opening a PR, or adding something to the…
commit-push-pr
Commit selected local changes, push the branch, and create or update a GitHub pull request with BitFun attribution. Use when the user asks to 提交 PR、提代码、commit and push、开 PR、create a pull request, or wants a Claude Code-like one-command PR publishing flow from BitFun.
git-commit
Creates git commits following Conventional Commits format with type/scope/subject and detailed markdown body. Use when user wants to commit changes, create commit, save work, or stage and commit. Enforces project-specific conventions from CLAUDE.md. Each change type gets its own markdown heading (# emoji + type), with…
commit
Create a signed git commit following Conventional Commits, after running /pre-commit and /changelog when appropriate.
commit
Read this skill before making git commits.
et-git
ET git workflow for preparing commits and reviewing changes. Use when checking git status or diff, filtering unrelated files, staging task-scoped changes, writing Chinese commit messages, or synchronizing with remotes using rebase instead of merge.