Update to Progress Percent Plans

{
  "description": "Keep progress percentages visible and current inside Codex plan-step UI. Use automatically for every non-trivial multi-step task that creates, updates, rewrites, resumes, or reports a plan, checklist, TODO sequence, implementation, research, audit, test run, or staged workflow, even when the user does not explicitly request percentages. Do not use for trivial one-step answers.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 332
    }
  ],
  "name": "progress-percent-plans",
  "skill_md_contents": "---\nname: progress-percent-plans\ndescription: Keep progress percentages visible and current inside Codex plan-step UI. Use automatically for every non-trivial multi-step task that creates, updates, rewrites, resumes, or reports a plan, checklist, TODO sequence, implementation, research, audit, test run, or staged workflow, even when the user does not explicitly request percentages. Do not use for trivial one-step answers.\n---\n\n# Progress Percent Plans\n\nKeep the plan UI itself accurate enough that a user can understand current progress without reading every commentary update.\n\nThe plugin lifecycle hook re-injects the core plan policy on every user prompt, session start or resume, compaction, and subagent start. Treat that injected developer context as the always-on activation path; the user never needs to name this skill. This skill remains the detailed source of truth for calculation and update behavior.\n\n## Start the plan\n\n- Create a plan when the task has at least two meaningful execution stages, will run long enough to benefit from checkpoints, or the user explicitly asks for a plan, TODOs, stages, status, or percentages.\n- Do not create ceremonial steps for a trivial one-step answer.\n- Prefix every plan step with `[NN%]`, such as `[40%] Implement save migration`.\n- Give each step its own percentage. Do not present a step percentage as an elapsed-time or remaining-time estimate.\n- If planning begins after work has started, initialize percentages from evidence already available instead of resetting everything to zero.\n\n## Calculate step progress\n\n- Use `0%` for an untouched step and `100%` only for a step whose required output and proportional verification are complete.\n- Keep the active step between `1%` and `99%`.\n- Prefer stable 5% increments unless a concrete checklist or measurable batch supports finer precision.\n- Base movement on completed sub-results, checks, or artifacts. Do not advance percentages merely because time passed.\n- A pending step may show partial progress when preparatory work was completed in parallel, but leave its status as pending until it becomes the active step.\n- If testing reveals rework, lower the affected percentage and briefly state why.\n\n## Keep status consistent\n\n- Call the plan update tool near the start of qualifying work.\n- Treat percentage formatting as a write barrier: before every plan-tool call, verify that every step starts with exactly one `[NN%]` prefix. Do not send the update until all steps pass this check.\n- Normalize suffix forms such as `Task (40%)` or `Task （40%）` to `[40%] Task`; never mix prefix and suffix styles within a plan.\n- When rewriting, merging, splitting, or replacing plan steps, carry forward evidence-based percentages. Give genuinely new untouched steps `[0%]`; never omit a percentage because the wording or scope changed.\n- Keep at most one step marked `in_progress`.\n- Mark a step `completed` only together with `[100%]`.\n- Never leave a completed step below `100%`, or a pending/in-progress step at `100%`.\n- Preserve step wording and order where practical so the plan reads as one evolving record rather than a succession of unrelated plans.\n- Add, split, merge, or remove a step only when the task scope genuinely changes.\n\n## Update checkpoints\n\nUpdate the visible percentages whenever any of these occurs:\n\n- a material implementation, research, or review batch finishes;\n- the active phase changes;\n- a test result changes confidence or exposes rework;\n- the user asks for progress or status;\n- the task resumes after an interruption or context compaction;\n- work is about to pause for user input or an external dependency.\n\nWhen the user asks for status, update the plan before answering. Lead with the outcome, current active step, and any real blocker; do not invent an ETA.\n\n## Resume safely\n\n- Reconstruct percentages from existing files, test evidence, and prior plan state after interruption.\n- Re-run the write-barrier check after context compaction, automatic continuation, task resumption, or a user scope change; these transitions do not relax the prefix requirement.\n- Do not claim past work is complete solely because an earlier message said it was underway.\n- If the plan tool is unavailable, show the same `[NN%]` prefixes in a concise status list and resume tool-backed tracking when available.\n\n## Completion example\n\nUse a consistent progression such as:\n\n- `[100%] Audit requirements and affected files` — completed\n- `[65%] Implement the migration` — in progress\n- `[20%] Prepare regression fixtures` — pending, with fixtures drafted in parallel\n- `[0%] Run full verification and package evidence` — pending\n\nThe percentages describe the completion of each named step, not the overall project.\n"
}