waypoint-codex 0.19.2 → 1.0.0

package/templates/.agents/skills/docs-sync/SKILL.md

@@ -1,78 +0,0 @@
----
-name: docs-sync
-description: Audit routed docs against the actual codebase and shipped behavior. Use when the user asks to sync docs, when docs may be stale after implementation work, before pushing or opening a PR, when routes, contracts, config, commands, or shipped behavior changed, or when Codex should find missing, incorrect, outdated, or broken documentation and then update or flag the exact gaps. Do not use this for vendor-doc ingestion, repo-memory cleanup, or broad code review that is not specifically about docs drift.
----
-
-# Docs Sync
-
-Use this skill to keep repo docs aligned with reality.
-
-This is not a vendor-doc ingestion skill and not a workspace-cleanup skill. It owns one job: compare the codebase and shipped behavior against routed docs, then fix or flag the mismatches.
-
-## When Not To Use This Skill
-
-- Skip it for importing or summarizing upstream vendor docs. Link to the real source instead of copying it into the repo.
-- Skip it for workspace compression or tracker cleanup. This skill is about docs drift, not handoff hygiene.
-- Skip it for broad code review that is not specifically about docs-to-reality mismatches.
-- Skip it when the user only wants a new durable plan or architecture note; use the planning or normal docs-writing flow in that case.
-
-## Read First
-
-Before auditing docs:
-
-1. Read `.waypoint/SOUL.md`
-2. Read `.waypoint/agent-operating-manual.md`
-3. Read `.waypoint/WORKSPACE.md`
-4. Read `.waypoint/context/MANIFEST.md`
-5. Read every file listed in that manifest
-6. Read the routed docs for the area under review
-
-## Step 1: Compare Docs To Reality
-
-Audit the real code, routes, contracts, config surfaces, and user-visible behavior against `.waypoint/docs/`.
-
-Look for:
-
-- missing docs for real shipped behavior
-- stale docs that describe removed or changed behavior
-- broken routing links or docs index gaps
-- examples or commands that no longer work
-- contract/schema/config docs that no longer match the code
-- docs that still describe future work as if it is already shipped
-
-## Step 2: Fix Or Flag
-
-- Update the docs when the correct wording is clear.
-- Add the smallest routed doc needed when behavior exists but is undocumented.
-- Remove or reframe stale claims instead of letting them linger.
-- If a mismatch is real but the correct doc shape is unclear, flag it explicitly instead of bluffing.
-
-Do not mirror vendor reference docs into the repo. Link to the real upstream docs when that is the right source of truth.
-
-## Step 3: Refresh Routing
-
-After changing routed docs:
-
-- Run `node .waypoint/scripts/prepare-context.mjs` so the docs index and generated context match the updated docs.
-
-## Step 4: Report The Sync Result
-
-Summarize:
-
-- what docs were stale or missing
-- what you updated
-- what still needs a decision, if anything
-
-## Gotchas
-
-- Do not trust docs-to-docs consistency alone. The source of truth is the shipped code and behavior, not whether two markdown files agree with each other.
-- Do not leave stale future-tense claims behind after a feature ships or is cut. Docs drift often shows up as roadmap language that quietly became false.
-- Do not update prose without checking commands, routes, config names, and examples. Small copied snippets are often where docs rot first.
-- Do not invent certainty when the right doc shape is unclear. Flag the mismatch instead of bluffing a final answer.
-- After touching routed docs, always refresh the generated docs/context layer so the repo’s index and bootstrap bundle match the new reality.
-
-## Keep This Skill Sharp
-
-- After meaningful runs, add new gotchas when the same docs-drift pattern, broken example shape, or stale-claim mistake keeps recurring.
-- Tighten the description if the skill misses real prompts like "sync the docs" or fires on requests that are really about repo-memory cleanup instead.
-- If the skill starts needing detailed provider-specific or command-heavy guidance, move that detail into references instead of bloating the hub file.

package/templates/.agents/skills/docs-sync/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Docs Sync"
-  short_description: "Audit docs against the real codebase"
-  default_prompt: "Use $docs-sync to audit routed docs against the actual codebase and shipped behavior, then update or flag any missing, incorrect, or outdated documentation."

package/templates/.agents/skills/merge-ready-owner/SKILL.md

@@ -1,196 +0,0 @@
----
-name: merge-ready-owner
-description: Own a non-trivial change from approved plan through implementation, verification, PR creation or update, review handling, and merge-ready handoff. Use when the user wants Codex to take full ownership after the problem and plan are agreed, keep going without repeated check-ins, and return only when there is a clean PR ready to merge or a concrete blocker that cannot be cleared alone.
----
-
-# Merge Ready Owner
-
-Use this skill when the user wants one continuous ownership loop instead of a handoff after coding.
-
-The job is not "write some code." The job is "carry the agreed work all the way to a merge-ready PR or a clearly explained blocker."
-
-## When Not To Use This Skill
-
-- Skip it when the problem is still being shaped or the plan is not actually approved. Use `planning` first.
-- Skip it for tiny local edits that do not justify a full ship loop.
-- Skip it when the user explicitly wants to stay in the loop for each step instead of delegating the closeout.
-
-## Finish Line
-
-Before starting, treat this as the default definition of done:
-
-- the agreed scope is implemented
-- the work is based on the repo's current default branch state
-- the right PR exists and is up to date when the repo uses PRs
-- the relevant tests, typechecks, lint, builds, or smoke checks for the touched surface are green
-- real verification has been done against the risky user or runtime path when practical
-- docs, trackers, and workspace state are updated when the shipped behavior changed materially
-- review comments are answered and meaningful findings are fixed
-- CI is green when the repo uses CI
-- the PR is merge-ready, or there is a concrete blocker that cannot be cleared alone
-
-When the product surface makes it practical, extend done to include:
-
-- a short recorded walkthrough of the verified final browser or app flow
-- the local path to that recording
-
-Do not stop at "the code compiles" or "the first push is up."
-
-During the loop, keep live execution state current:
-
-- update `WORKSPACE.md` as milestones, blockers, verification state, and next steps change
-- if a tracker exists or the work has become tracker-worthy, update the tracker during the work instead of reconstructing it later
-
-## Step 1: Reconfirm The Scope And Ownership Mode
-
-- Make sure the plan is already approved or the user explicitly said to proceed.
-- Restate the finish line to yourself before editing.
-- Identify the highest-risk parts of the change so verification matches the real failure surface.
-
-If the plan is not actually settled, stop and use `planning` instead of guessing.
-
-## Step 2: Start From Fresh Branch State
-
-- Sync with the repo's current default branch and base the work on that fresh state.
-- If there is no branch yet, create one from the refreshed default branch.
-- If there is already a PR, confirm it is still open before pushing more commits.
-- If an old PR was closed or merged, create a fresh branch from the current default branch, carry forward only the needed work, and open a new PR if the repo uses PRs.
-
-## Step 3: Implement In Small Verified Chunks
-
-- Make the change in small logical chunks inside the current approved plan phase.
-- Batch related edits into a meaningful phase slice before running heavyweight checks, reviewer passes, or a commit.
-- Commit at phase boundaries or other meaningful checkpoints when the repo workflow benefits from granular history.
-- Keep unrelated local changes intact.
-- Do not stop after the first implementation pass if clear follow-up fixes are still needed.
-
-For bugs, prefer reproducing the problem first, then fixing it, then proving the fix.
-
-## Step 4: Use The Right Repo-Local Helpers
-
-Use the repo's existing skills and reviewer agents instead of inventing a parallel process.
-
-- Use `work-tracker` early when the work becomes non-trivial, multi-step, review-heavy, or checklist-driven enough that `WORKSPACE.md` alone will stop being a good live record.
-- Use `docs-sync` when shipped behavior, routes, contracts, or commands changed materially.
-- Use `pre-pr-hygiene` before pushing or opening/updating a PR when the change surface is substantial.
-- Use `pr-review` once active PR review or automated review has started.
-- Use `break-it-qa` for extra abuse testing on risky interactive flows when that pass is worth the time.
-
-If the repo ships reviewer agents under `.codex/agents/`, use them in the closeout flow when they are available:
-
-- run `code-reviewer` for every non-trivial completed phase before declaring the work clear
-- run `code-health-reviewer` when the change is medium or large, especially when it adds structure, duplicates logic, or introduces new abstractions
-- launch them in parallel when both apply
-- use them at phase checkpoints, not only at the very end: after completing a substantial phase, before opening or materially updating a PR, after fixing substantial findings, and before final closeout
-- treat them as fresh closeout passes, not as optional decoration
-- if either reviewer finds anything more serious than obvious optional polish, fix those findings, rerun the most relevant verification, and run fresh reviewer passes instead of trusting stale results
-- keep iterating until the remaining reviewer feedback is only nitpicks or none
-
-If those reviewer agents are not present in the repo, do the equivalent closeout thinking locally and continue instead of blocking on missing helpers.
-
-## Step 5: Choose Verification That Matches The Real Risk
-
-- Discover and use the verification tools that already exist in the current project instead of assuming one fixed stack.
-- For browser-facing work, use the available browser QA tooling and exercise the real UI.
-- For mobile or desktop app work, use the app or simulator tooling available in the repo and exercise the real flow.
-- For backend work, hit the real route, worker, or runtime boundary when practical instead of trusting only unit tests.
-- For environment-specific bugs, prefer the environment's logs, traces, payloads, or metrics over local guesswork.
-
-If an existing repo-local skill clearly matches the verification surface, use it.
-
-## Step 6: Run The Phase Checkpoint And Pre-Push Loop
-
-At the end of each completed phase:
-
-- run the required tests and typechecks for the touched package or service
-- run builds, lint, migrations, or focused smoke tests when they are part of the real risk surface
-- run the relevant reviewer-agent passes for non-trivial work
-- fix failing checks and reviewer findings before moving to the next phase
-- rerun the checkpoint until the current phase is clean
-- update `WORKSPACE.md`, `.waypoint/ACTIVE_PLANS.md`, and any active tracker with the current verification state before moving on
-
-Before pushing:
-
-- make sure the latest completed phase checkpoint is still green
-- for user-facing flows, do at least one realistic manual or UI-driven pass beyond pure unit coverage
-
-Do not push a branch that still obviously fails its own touched-surface checks.
-
-## Step 7: Open Or Update The PR Cleanly
-
-When the repo uses PRs:
-
-- open the PR if one does not exist
-- keep the PR title and body focused on user value and capability, not implementation trivia
-- keep the PR description concise
-- request preview or staging environments when they are part of validation
-
-If the repo does not use PRs, keep moving through the equivalent review and handoff workflow instead of forcing PR-shaped steps.
-
-Before opening or materially updating the PR on non-trivial work, strongly prefer a fresh reviewer-agent pass when those agents are available.
-
-## Step 8: Babysit The PR Instead Of Dropping It
-
-When the repo uses PRs, CI, or preview environments:
-
-- watch CI until it settles
-- investigate red checks instead of treating them as someone else's problem
-- if a preview, staging, or deployment environment is required for validation, follow it through until the environment is usable or a real external blocker is proven
-- if the live preview or deployed environment is the real risk surface, verify it directly when helpful instead of waiting only on a bot summary
-
-The ownership loop is still active while CI, preview, or rollout is in flight.
-
-## Step 9: Close The Review Loop
-
-Once review starts:
-
-- use `pr-review`
-- read every meaningful comment
-- fix valid findings
-- reply inline where the workflow supports inline reply
-- rerun the relevant verification after review-driven fixes
-- if the fixes were meaningful, run fresh reviewer-agent passes before you call the work clear when those agents are available
-
-Do not leave comments unanswered just because the code changed.
-
-## Step 10: Re-Test The Risky User Paths
-
-- Re-run the happy path after fixes.
-- Re-run the exact paths that were previously broken.
-- For stateful flows, also probe nearby failure surfaces: repeat actions, bad input, stale state, back navigation, recovery, and environment toggles.
-- Capture screenshots when using interactive UI tooling if the environment allows it.
-
-Record the walkthrough only after the verified final state is stable. Do not record the first flaky pass and call that proof.
-
-## Step 11: Hand Back A Merge-Ready Truthful State
-
-Only close out when you can truthfully say one of these:
-
-- the PR is ready to merge
-- or there is a concrete blocker you cannot clear alone
-
-The final handoff should say:
-
-- what is now working for the user
-- what verification actually ran
-- the PR link when there is one
-- any remaining blocker or caveat that still matters
-
-Keep the handoff plain and direct. The point of this skill is to reduce the user's need to supervise the loop.
-
-## Gotchas
-
-- Do not mistake planning approval for permission to stop at implementation; this skill owns the full closeout.
-- Do not let `WORKSPACE.md` or an active tracker fall behind reality while the work is in flight.
-- Do not rely only on automated tests when the risky surface is interactive.
-- Do not let stale previews, staging selectors, old PR branches, or half-deployed environments quietly poison verification.
-- Do not treat CI failures, review comments, or rollout gates as outside the task once the user asked for full ownership.
-- Do not declare success while known meaningful review findings or failing checks still exist.
-- Do not confuse a reusable test harness or scripted UI test with the final walkthrough artifact; the artifact should show the real verified surface when practical.
-- Do not forget the reviewer-agent loop when `code-reviewer` and `code-health-reviewer` are available. They are part of the closeout signal, not an afterthought, and serious findings should reopen the fix-and-review cycle.
-
-## Keep This Skill Sharp
-
-- Add new gotchas when the same ownership failure mode repeats.
-- Tighten the description if the skill fires too early before planning is settled.
-- If the closeout loop keeps depending on the same helper skills, reviewer agents, or verification surfaces, encode that expectation here instead of rediscovering it in chat.

package/templates/.agents/skills/merge-ready-owner/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Merge-Ready Owner"
-  short_description: "Own approved work through merge-ready closeout"
-  default_prompt: "Use $merge-ready-owner when the plan is already approved and you should carry the work all the way through implementation, verification, reviewer-agent passes, PR handling, and merge-ready handoff without repeated check-ins."

package/templates/.agents/skills/pre-pr-hygiene/SKILL.md

@@ -1,83 +0,0 @@
----
-name: pre-pr-hygiene
-description: Run a broad final hygiene pass before pushing, before opening or updating a PR, or after a large implementation chunk when the diff is substantial and needs a deeper audit than per-commit review. Verify code-guide compliance, docs-to-behavior alignment, shared contract/schema drift, typing gaps, optimistic UI rollback or invalidation strategy, persistence correctness risks, and any other cross-cutting quality issues that would make the next review painful.
----
-
-# Pre-PR Hygiene
-
-Use this skill for the larger final audit before code leaves the machine.
-
-## When Not To Use This Skill
-
-- Skip it for tiny changes that do not justify a broad hygiene pass.
-- Skip it after a PR already has active review comments; use `pr-review` for that loop.
-- Skip it when the task is only a narrow coding-guide check or only a docs sync pass.
-
-## Read First
-
-Before the hygiene pass:
-
-1. Read `.waypoint/SOUL.md`
-2. Read `.waypoint/agent-operating-manual.md`
-3. Read `.waypoint/WORKSPACE.md`
-4. Read `.waypoint/context/MANIFEST.md`
-5. Read every file listed in that manifest
-6. Read the repo's routed code guide and the routed docs relevant to the area being shipped
-
-In standard Waypoint repos, the code guide lives at `.waypoint/docs/code-guide.md`. If the repo routes it somewhere else, follow the repo's own docs and routing instead of assuming another fixed path.
-
-## Step 1: Audit The Whole Change Surface
-
-Inspect the code and docs that are about to ship.
-
-Look for:
-
-- code-guide violations such as silent fallbacks, swallowed errors, weak boundary validation, unsafe typing, or stale compatibility layers
-- stale docs, stale routes, or workspace notes that no longer match real behavior
-- shared schema, fixture, or API-contract drift
-- typing gaps such as avoidable `any`, weak narrowing, or unnecessary casts
-- optimistic UI without rollback or invalidation
-- persistence risks such as missing provenance, missing idempotency protection, weak uniqueness, or missing foreign-key style invariants
-
-Skip checks that truly do not apply, but say that you skipped them.
-
-## Step 2: Fix Or Stage Findings
-
-- Fix meaningful issues directly when the right remediation is clear.
-- Update `.waypoint/docs/` when shipped behavior or routes changed.
-- If the live handoff has become bloated or stale, use `workspace-compress`.
-
-Do not stop at reporting obvious fixable issues.
-
-## Step 3: Verify Before Ship
-
-Run the most relevant verification for the area:
-
-- tests
-- typecheck
-- lint
-- build
-- targeted manual QA
-
-## Step 4: Report The Gate Result
-
-Summarize:
-
-- what you checked
-- what you fixed
-- what verification ran
-- what residual risks remain, if any
-
-## Gotchas
-
-- Do not turn this into a whole-repo cleanup mission. Keep the pass tied to the change surface that is about to leave the machine.
-- Do not stop at reporting obvious fixable issues if the correct remediation is clear.
-- Do not call the pass complete without real verification that matches the risk of the change.
-- Do not let docs, contracts, and code drift just because the implementation itself "works."
-- Do not use this as a replacement for active PR review or the normal closeout loop.
-
-## Keep This Skill Sharp
-
-- Add new gotchas when the same hygiene blind spot, contract drift, or verification miss keeps recurring.
-- Tighten the description if the skill fires on tiny edits or misses real prompts about "do a final pass before I push."
-- If the same cross-cutting checks keep being rediscovered, encode them more explicitly here instead of relying on chat memory.

package/templates/.agents/skills/pre-pr-hygiene/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Pre-PR Hygiene"
-  short_description: "Run the final cross-cutting ship audit"
-  default_prompt: "Use $pre-pr-hygiene before pushing or opening/updating a PR for substantial work to do a broader hygiene pass across code, docs, contracts, typing, UI rollback, persistence correctness, and code-guide compliance."

package/templates/.agents/skills/work-tracker/SKILL.md

@@ -1,139 +0,0 @@
----
-name: work-tracker
-description: Create or maintain a durable tracker under `.waypoint/track/` for any non-trivial workstream that needs ongoing execution state. Use when work has multiple steps, meaningful verification, review follow-ups, milestone checkpoints, or any real chance that `WORKSPACE.md` alone will stop being enough as the work evolves.
----
-
-# Work Tracker
-
-Use this skill when the work has enough moving parts that the next state should not live only in chat or in a few workspace bullets.
-
-This skill owns the execution tracker layer:
-
-- create or update `.waypoint/track/<slug>.md`
-- keep `WORKSPACE.md` pointing at the active tracker
-- move detailed checklists and progress into the tracker instead of bloating the workspace
-
-## When Not To Use This Skill
-
-- Skip it for small single-shot tasks that fit comfortably in `WORKSPACE.md`.
-- Skip it when the work has already finished and does not need a durable execution log.
-- Skip it when the real need is docs compression or docs sync rather than active execution tracking.
-
-## Read First
-
-Before tracking:
-
-1. Read `.waypoint/SOUL.md`
-2. Read `.waypoint/agent-operating-manual.md`
-3. Read `.waypoint/WORKSPACE.md`
-4. Read `.waypoint/ACTIVE_PLANS.md`
-5. Read `.waypoint/context/MANIFEST.md`
-6. Read every file listed in that manifest
-7. Read `.waypoint/track/README.md`
-
-## When A Tracker Is Required
-
-Create or update a tracker when any of these are true:
-
-- the work is non-trivial and will unfold across multiple meaningful steps
-- the work will likely span multiple sessions
-- there are many actionable items to implement
-- an audit, QA pass, or review produced a remediation campaign
-- verification requires a substantial checklist
-- the work has milestone checkpoints, PR stages, or repeated fix-and-verify loops
-- `WORKSPACE.md` would become noisy if it carried all the detail
-
-When in doubt, prefer creating or updating the tracker for non-trivial work instead of hoping the workspace alone will stay enough.
-Small, single-shot work does not need a tracker.
-
-## Step 1: Choose The Tracker File
-
-- Use `.waypoint/track/<kebab-case-slug>.md`.
-- If a relevant tracker already exists, update it instead of creating a competing one.
-- Keep one tracker per coherent workstream, not one tracker per tiny edit.
-
-## Step 2: Set The Frontmatter
-
-Trackers need:
-
-```yaml
----
-summary: One-line description
-last_updated: "2026-03-13 11:38 PDT"
-status: active
-read_when:
-  - resuming this workstream
----
-```
-
-Valid statuses:
-
-- `active`
-- `blocked`
-- `paused`
-- `done`
-- `archived`
-
-Use `active` unless there is a clear reason not to.
-
-## Step 3: Structure The Tracker
-
-A good tracker usually includes:
-
-- `Goal`
-- `Source`
-- `Current State`
-- `Next`
-- `Workstreams`
-- `Phase Checkpoints`
-- `Verification`
-- `Decisions`
-- `Notes`
-
-Use `- [ ]` checkboxes when there are many concrete tasks to track. Use status-style entries when the work is better expressed as phase/state updates than as a task list. Use timestamped bullets for materially revised state.
-
-## Step 4: Link It From The Workspace
-
-Add or update a bullet under `## Active Trackers` in `.waypoint/WORKSPACE.md` that points at the tracker path and states the current phase or next step.
-If the work is driven by an approved plan, keep `.waypoint/ACTIVE_PLANS.md` aligned with the same phase naming and checkpoint language.
-
-`WORKSPACE.md` should answer "what matters right now?"
-`.waypoint/ACTIVE_PLANS.md` should answer "what plan and phase must be followed right now?"
-The tracker should answer "what exactly is happening across the whole workstream?"
-
-## Step 5: Maintain It During Execution
-
-- Update `last_updated` whenever you materially change the tracker.
-- Keep task lists or status entries current instead of deleting history. Mark completed checkbox items as `- [x]`, and update status-style entries when the phase or state changes.
-- Add blockers, new tasks, and verification status as the work evolves.
-- Update the tracker during the work, not only at the end. If a milestone, blocker, review round, or verification result changed reality, the tracker should already reflect it.
-- When the workstream finishes, set `status: done` or `status: archived`.
-
-Do not let the tracker become fiction. It must match reality.
-
-## Step 6: Distill Durable Knowledge
-
-If the tracker reveals durable architecture, rollout, or debugging knowledge, move that durable knowledge into `.waypoint/docs/` and leave the tracker focused on execution state.
-
-## Report
-
-When you create or update a tracker, report:
-
-- the tracker path
-- the current status
-- what `WORKSPACE.md` now points to
-
-## Gotchas
-
-- Do not create a new tracker if a relevant active tracker already exists for the same workstream.
-- Do not wait until final handoff to start the tracker if the work has already become multi-step, review-heavy, or hard to summarize from memory.
-- Do not let the tracker become fiction. Completed items, blockers, and verification state should match reality.
-- Do not stuff durable architecture or debugging knowledge into the tracker if it belongs in `.waypoint/docs/`.
-- Do not leave `WORKSPACE.md` carrying the full execution log after a tracker exists.
-- Do not keep trackers "active" forever after the work is done; update the status.
-
-## Keep This Skill Sharp
-
-- Add new gotchas when the same tracker drift, duplicate-tracker pattern, or workspace-bloat problem keeps recurring.
-- Tighten the description if the skill fires for tiny work that does not need a tracker or misses long-running remediation campaigns.
-- If the tracker format keeps needing the same recurring section or checklist pattern, capture that reusable pattern in the skill instead of rediscovering it each time.

package/templates/.agents/skills/work-tracker/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Work Tracker"
-  short_description: "Create or maintain a durable tracker for a large workstream"
-  default_prompt: "Use $work-tracker to create or update a tracker under .waypoint/track/, keep WORKSPACE.md pointing to it, and move detailed execution state out of chat and into the repo."

package/templates/.agents/skills/workspace-compress/SKILL.md

@@ -1,113 +0,0 @@
----
-name: workspace-compress
-description: Compress and refresh the repository's live workspace handoff so `WORKSPACE.md` stays short, current, and useful to the next agent. Use after finishing a meaningful chunk of work, before stopping for the session, before asking for review, before opening or updating a PR, or whenever the workspace has started accumulating stale history, repeated status logs, or resolved context that should no longer stay in the live handoff. Keep the minimum current operational state, collapse old resolved entries, and move durable detail into existing routed docs instead of duplicating it in the workspace.
----
-
-# Workspace Compress
-
-Keep `WORKSPACE.md` as a live handoff, not a project diary.
-
-This skill is for compression, not for erasing context. Preserve what the next agent needs in the first few minutes of a resume, and push durable detail into the docs layer that already exists in the repo.
-
-## When Not To Use This Skill
-
-- Skip it when the workspace is still short, current, and easy to resume from.
-- Skip it when the detail you want to remove is still active execution state that belongs in a tracker.
-- Skip it when the real problem is stale docs rather than stale workspace history.
-
-## Read First
-
-Before compressing:
-
-1. Read `.waypoint/SOUL.md`
-2. Read `.waypoint/agent-operating-manual.md`
-3. Read `.waypoint/WORKSPACE.md`
-4. Read `.waypoint/context/MANIFEST.md`
-5. Read every file listed in that manifest
-6. Read the routed docs relevant to the active workspace sections
-
-## Step 1: Build Context From Routing, Not From Git Diff
-
-This skill must work even in a dirty tree or an arbitrary session state.
-
-- Read the workspace file in full.
-- Read `.waypoint/DOCS_INDEX.md` and the workspace's obvious routing pointers.
-- Read the project or domain docs directly linked from the active sections you may compress.
-- If the workspace references a progress, status, architecture, or release doc, treat that as the durable home for details before removing anything from the live handoff.
-
-Do not rely on `git diff` as the primary signal for what matters.
-
-## Step 2: Apply The Handoff Test
-
-Ask one question:
-
-**What does the next agent need in the first 10 minutes to resume effectively?**
-
-Keep only the answer to that question in the workspace. Usually that means:
-
-- active tracker pointers
-- current focus
-- latest verified state
-- open blockers or risks
-- immediate next steps
-- only the last few meaningful timestamped updates
-
-Usually remove or collapse:
-
-- resolved implementation logs
-- repeated status updates that say the same thing
-- validation transcripts
-- old milestone history
-- duplicated durable documentation
-- per-item implementation checklists that belong in `.waypoint/track/`
-
-Compression is documentation quality, not data loss.
-
-## Step 3: Compress Safely
-
-When editing the workspace:
-
-1. Preserve the active operational truth.
-2. Collapse stale resolved bullets into one short summary when history still matters.
-3. Remove entries that are already preserved elsewhere and no longer affect immediate execution.
-4. Keep timestamp discipline for new or materially revised bullets.
-5. Do not turn the workspace into an archive, changelog, or debug notebook.
-
-If durable context is missing from `.waypoint/docs/`, add or refresh the smallest coherent routed doc before removing it from the workspace.
-If execution detail is still active but too large for the workspace, move it into `.waypoint/track/` instead of deleting it.
-
-## Step 4: Protect User-Owned State
-
-- Never overwrite or revert unrelated user changes.
-- If a workspace or doc already has in-flight edits you did not make, read carefully and work around them.
-- Prefer surgical edits over broad rewrites.
-- Do not delete project memory just because live state is being compressed.
-
-## Step 5: Refresh Routing
-
-After changing routed docs or the workspace:
-
-- Run `node .waypoint/scripts/prepare-context.mjs` so the docs index and generated context match the edited sources.
-
-## Step 6: Report The Result
-
-Summarize:
-
-- what stayed in the live handoff
-- what was collapsed or removed
-- which durable docs now hold the preserved detail
-- any remaining risk that still belongs in the workspace
-
-## Gotchas
-
-- Do not compress away the active operational truth just because the workspace feels long.
-- Do not rely on `git diff` to decide what matters; the workspace must stay useful even in a dirty tree.
-- Do not delete detail unless you know which routed doc or tracker now preserves it.
-- Do not compress unresolved blockers or immediate next steps into vague summaries.
-- Do not rewrite over in-flight user edits in the workspace or linked docs.
-
-## Keep This Skill Sharp
-
-- Add new gotchas when the same compression mistake, lost-context problem, or stale-workspace pattern keeps recurring.
-- Tighten the description if the skill fires on already-clean workspaces or misses real "clean up the handoff" requests.
-- If the same compression pattern keeps moving detail into the same durable home, make that routing more explicit in the skill.

package/templates/.agents/skills/workspace-compress/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Workspace Compress"
-  short_description: "Compress the live workspace handoff"
-  default_prompt: "Use $workspace-compress after a meaningful chunk of work, before stopping, before review, or before opening or updating a PR to keep WORKSPACE.md short, current, and useful to the next agent."