@agent-native/core 0.101.14 → 0.102.1

package/corpus/templates/tasks/.agents/skills/efficient-frontier/README.md

@@ -0,0 +1,53 @@
+# /efficient-frontier
+
+Apply the same orchestration as `/efficient-fable` to any high-cost frontier
+model.
+
+`/efficient-frontier` is the model-agnostic version of `/efficient-fable`. It
+works for any high-cost model where the expensive part should be reserved for
+judgment, synthesis, integration, and final quality.
+
+## What It Does
+
+- Separates frontier-only decisions from delegable work.
+- Pushes research scans, docs extraction, log reduction, browser checks,
+  mechanical edits, and narrow coding tasks to cheaper agents.
+- Asks delegated agents for compact evidence instead of broad essays.
+- Uses self-contained handoff packets with scope, verification, and stop
+  conditions.
+- Treats delegated findings as leads that the frontier model verifies before
+  relying on them.
+- Keeps final integration and risk assessment with the frontier model.
+
+## When To Use It
+
+Use it for large or ambiguous work where independent slices can run in parallel:
+repo exploration, refactors, multi-file implementation, test-failure clustering,
+or PR-quality validation.
+
+Skip it when the work is tiny, when edits are all in the same fragile files, or
+when the next step depends on one immediate blocker you need to inspect yourself.
+
+## Testing Guidance
+
+The frontier model should choose the validation plan. Cheaper agents can run
+unit checks, browser flows, screenshots, and log reduction, then return exact
+commands, failures, likely causes, and the signal quality.
+
+## Delegation Quality
+
+Give each delegated agent enough context to succeed without the full chat:
+objective, repo path, in-scope files, out-of-scope areas, expected evidence,
+verification commands, and stop conditions.
+
+The frontier model should reopen important cited files, review high-risk diffs,
+and spot-check verification before presenting the final answer.
+
+## Install
+
+```sh
+npx @agent-native/skills@latest add --skill efficient-frontier --update-instructions
+```
+
+Use `--update-instructions` when you want the orchestration convention added to
+project instructions.

package/corpus/templates/tasks/.agents/skills/efficient-frontier/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: efficient-frontier
+description: Apply the same orchestration as `/efficient-fable` to any high-cost frontier model: delegate research, coding, and testing to cheaper subagents while keeping planning, synthesis, and final review with the expensive model.
+---
+
+# Efficient Frontier
+
+Use the expensive frontier model where its marginal judgment matters. Push
+repeatable, bounded, or token-heavy work to cheaper/faster subagents.
+
+## Workflow
+
+1. Identify the frontier-only decisions: architecture, prioritization,
+   ambiguity resolution, risk, synthesis, and final review.
+2. Identify delegable work: research scans, repository inventory, search, docs
+   extraction, browser/testing passes, log reduction, test failure clustering,
+   narrow coding, and mechanical edits.
+3. Spawn parallel subagents for independent slices with clear ownership,
+   bounded scope, verification gates, and expected evidence.
+4. Require compact returns: findings, changed files, commands run, residual
+   risk, stop conditions hit, and anything the frontier model must decide.
+5. Integrate and review centrally before presenting the result.
+
+## Handoff Packets
+
+Write delegated prompts as self-contained packets. Assume the receiving agent
+has not seen the conversation. Include the repo path, objective, scope,
+out-of-scope areas, relevant files or search targets, expected return format,
+verification commands, and stop conditions.
+
+Useful stop conditions:
+
+- The live code does not match the assumption in the handoff.
+- A verification command fails twice after a reasonable fix or retry.
+- The work appears to require files outside the assigned scope.
+- The agent cannot produce concrete evidence for its claim.
+
+## Review Loop
+
+Treat delegated output as evidence to inspect, not a verdict to forward. Reopen
+important cited files, skim high-risk diffs, and rerun or spot-check the
+verification that matters before claiming completion. If delegated agents
+disagree, resolve the disagreement at the frontier-model layer.
+
+## Common Scenarios
+
+Use these as soft suggestions:
+
+- Research: delegate broad repo scans, docs extraction, and source comparison;
+  the frontier model keeps the judgment about what matters.
+- Coding: delegate bounded patches, refactors, or mechanical edits when file
+  ownership is clear; integrate and review centrally.
+- Testing: let the frontier model choose the validation strategy and scripts,
+  then use cheaper agents to run unit checks, browser flows, screenshots, and
+  log reduction. Ask them to return exact commands, failures, likely causes, and
+  whether the signal looks flaky, environmental, or product-relevant.
+- Debugging: send independent agents after separate theories, logs, or repro
+  paths; keep the final diagnosis with the frontier model.
+
+## Guardrails
+
+- Do not delegate the immediate blocker if your next step depends on it.
+- Do not ask multiple agents to edit the same files at the same time.
+- Do not trust subagent conclusions blindly when the risk is high; inspect the
+  important evidence yourself.
+- Do not claim universal savings. The pattern works best when exploration and
+  implementation, testing, or research can be parallelized.
+
+## Default Framing
+
+"I will use the frontier model as the orchestrator and reviewer, and use
+cheaper subagents for token-heavy research, coding, or testing so the expensive
+tokens go to judgment, synthesis, and final quality."

package/corpus/templates/tasks/.agents/skills/frontend-design/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: frontend-design
+description: >-
+  Create distinctive, production-grade frontend interfaces with high design
+  quality. Use when building web components, pages, artifacts, posters, or
+  applications (websites, landing pages, dashboards, React components,
+  HTML/CSS layouts, or when styling/beautifying any web UI). Generates
+  creative, polished UI that avoids generic AI aesthetics.
+scope: dev
+license: Complete terms in LICENSE.txt
+source: https://github.com/anthropics/skills/blob/main/skills/frontend-design/SKILL.md
+metadata:
+  internal: true
+---
+
+# Frontend Design
+
+This skill guides creation of distinctive, production-grade frontend interfaces. Implement real working code with strong product judgment, excellent accessibility, and a clear visual point of view.
+
+The user may ask for a component, page, full app, dashboard, marketing surface, or restyle. Before coding, understand the audience and pick a direction that fits the product instead of defaulting to generic SaaS polish.
+
+## Design Thinking
+
+Before coding, decide:
+
+- **Purpose**: What workflow does this surface make easier? What is the primary action?
+- **Audience**: Who will use it repeatedly, and what should feel fast, calm, playful, premium, editorial, technical, or utilitarian?
+- **Tone**: Choose a concrete aesthetic direction: refined minimal, dense operations console, editorial, playful, industrial, warm handmade, high-contrast data tool, etc.
+- **Information hierarchy**: What must be visible in the first five seconds, and what should be progressively disclosed?
+- **Differentiation**: What makes this feel designed for this exact domain?
+
+Then implement working code that is cohesive, accessible, responsive, and polished in small details: typography, spacing, copy, motion, empty states, loading states, focus states, and error states.
+
+## Minimalism And Progressive Disclosure
+
+Default to Apple/Linear-level restraint: make the primary workflow obvious, then remove everything that does not help that workflow right now. A polished UI often has fewer visible controls, fewer borders, fewer labels, and fewer explanatory surfaces than the first reasonable implementation.
+
+- **Start by subtracting**: Before adding a visible control, banner, toolbar row, card, or explanatory block, ask what can be removed, merged, renamed, or moved into an existing affordance.
+- **One primary action**: Each surface should have one dominant next action. Secondary actions belong in menus, popovers, command palettes, disclosure rows, or contextual hover/focus states unless they are used constantly.
+- **Progressively disclose rare work**: Advanced options, diagnostics, metadata, settings, import/export, destructive actions, and inspection tools should stay tucked away until requested. Prefer small icon triggers with tooltips, popovers, drawers, or detail panels over permanent chrome.
+- **Keep chrome quiet**: Avoid new always-visible bars, badges, callouts, helper text, and counters unless they prevent mistakes or are central to repeated use. Status can often be a dot, ring, muted count, or tooltip.
+- **Favor content over containers**: Do not wrap every section in a card. Use whitespace, alignment, typography, dividers, and full-width bands before adding boxes.
+- **Design for repeated use**: Production app UI should feel calm after the hundredth use. If a control shouts, animates, explains itself, or occupies a full row for an occasional action, hide or compress it.
+- **Make absence intentional**: Empty states should be sparse and action-oriented. Do not fill blank space with marketing copy, decorative art, or lists of features just because the screen feels empty.
+- **Use familiar primitives**: Icon buttons need clear tooltips. Menus, popovers, tabs, switches, and segmented controls should carry complexity instead of exposing every option at once.
+
+## Aesthetic Guidelines
+
+- **Typography**: Use the product's existing type system first. For net-new public pages, choose characterful but readable type and keep sizing appropriate to the surface.
+- **Color and theme**: Use semantic tokens and CSS variables. Avoid one-note palettes and default purple/blue gradients unless the brand demands them.
+- **Motion**: Prefer purposeful transitions and small state changes. Use CSS transitions/keyframes unless the app already uses a motion library. Never `transition-all` — list the properties that actually change (e.g. `transition-[opacity,transform]`). Use the shared easing tokens defined in `packages/core/src/styles/agent-native.css` instead of hand-typing curves: `var(--ease-drawer)` (260ms, drawers/app chrome), `var(--ease-collapse)` (200ms, expand/collapse), `var(--ease-out-strong)` (snappy entrances) — in Tailwind, `ease-[var(--ease-collapse)]`. Enter/exit with ease-out, never `ease-in`. Overlays that zoom in must set the Radix origin var (e.g. `origin-[--radix-popover-content-transform-origin]`). Animate `transform`/`opacity`, not width/height/padding/box-shadow. Gate looping or large-movement animations with `motion-reduce:`. Command palettes and keyboard-triggered actions get no animation.
+- **Composition**: Match the workflow. Operational apps should be dense and scannable; marketing or portfolio pages can be more immersive.
+- **Visual assets**: Websites, games, and object-focused pages need real or generated media when images help users understand the subject.
+- **Responsive fit**: Text must not overflow buttons, cards, tabs, sidebars, or fixed-format tools. Use stable dimensions for boards, grids, toolbars, and counters.
+
+**Beat convergence, not just defaults.** You sample toward the "on-distribution" center, so naming what to avoid is not enough: every "don't" needs a "do", or you converge on the next safe option (ban Inter and you reach for Roboto; ban purple gradients and you reach for Space Grotesk + a teal accent on every screen). Commit to one named direction, pair any reference with the reason it fits ("Linear: the quiet confidence of its spacing" — a bare "Linear" collapses back to the average), and match implementation effort to the vision: maximalist wants elaborate motion and effects, minimal wants restraint and precise spacing. When building on an existing app, inspect its tokens/type/components first and treat any drift back to a default as a missing token to pin, not something to re-prompt.
+
+## Agent-Native UI Rules
+
+- Agent-native apps use React, Vite, Tailwind CSS, shadcn/ui, and `@tabler/icons-react`.
+- **Use shadcn/ui primitives for standard UI**: `DropdownMenu`, `Popover`, `Dialog`, `AlertDialog`, `Sheet`, `Tabs`, `Tooltip`, `Select`, `Command`, `Sidebar`, `Table`, `Card`, `Badge`, `Skeleton`, and related primitives.
+- **When touching shadcn/ui components, also read `shadcn-ui` if it exists.** That skill covers `components.json`, CLI docs, component composition, theming, and registry workflows.
+- Check `app/components/ui/` before importing a shadcn component. If a primitive is missing, add it from the app root with `pnpm dlx shadcn@latest add <component>`, then review the generated file.
+- Do not build custom dropdowns, menus, popovers, modals, or confirmations with manual absolute positioning and click-outside effects.
+- Never use browser dialogs (`window.alert`, `window.confirm`, `window.prompt`). Use `AlertDialog`, `Dialog`, or app-specific confirmation UI.
+- Use Tabler icons for all first-party UI icons. Do not add Lucide, Heroicons, inline SVG icon sets, or emoji icons.
+- Use `useActionQuery` and `useActionMutation` from `@agent-native/core/client` for action-backed UI. Standard CRUD should go through actions, not custom `/api/` routes.
+- Keep UI optimistic where possible: update cache and navigation immediately, then reconcile or roll back on mutation result.
+- Custom styles belong in Tailwind classes, component CSS, or the existing global CSS theme file; avoid inline styles.
+
+## shadcn/ui Design Rules
+
+- Use built-in component variants first (`variant`, `size`) before overriding classes.
+- Use semantic tokens (`bg-background`, `text-muted-foreground`, `border-border`, `bg-primary`) instead of raw Tailwind colors for app chrome and reusable components.
+- Use `gap-*` in flex/grid layouts instead of `space-x-*` or `space-y-*`.
+- Use `size-*` when width and height are equal, and `truncate` instead of spelling out overflow/ellipsis/nowrap.
+- Use `cn()` from the local utils alias for conditional classes.
+- Dialog, Sheet, Drawer, and AlertDialog content must have an accessible title. Use `sr-only` only when the visible design already communicates the title.
+- Put menu/list items inside their group primitives: `SelectGroup`, `DropdownMenuGroup`, `CommandGroup`, and equivalents.
+- Use full `Card` composition when the content has a title, description, content, or actions. Do not dump complex cards into a single `CardContent`.
+- Use `ToggleGroup` for small option sets, `Switch` for binary settings, `Checkbox` for multi-select, `RadioGroup` for one-of-many, and `Slider`/inputs for numeric values.
+- For forms, prefer the app's existing shadcn form pattern. If newer `Field`, `FieldGroup`, or `InputGroup` primitives are installed or appropriate to add, use them instead of raw layout divs.
+- Loading states use `Skeleton`, `Progress`, `Spinner`, or the app's existing loading primitives. Empty states should have one clear next action.
+
+## Anti-Patterns
+
+Avoid:
+
+- Generic AI aesthetics: purple gradients, glassy cards everywhere, vague sparkle language, decorative blobs, and context-free hero sections.
+- Custom reimplementations of shadcn primitives.
+- Raw color overrides on shared components when semantic tokens or variants would work.
+- New always-visible controls for rare actions. Prefer menus, popovers, sheets, tabs, collapsibles, or advanced sections.
+- Full-width banners, persistent helper rows, decorative cards, or explanatory chrome for status that could be a compact affordance.
+- Treating progressive disclosure as optional. If a control is not part of the main daily workflow, hide it until context, hover, focus, or explicit user intent makes it relevant.
+- UI cards nested inside other cards.
+- Text or icons that resize or shift fixed-format UI on hover/loading.
+
+## Verification
+
+For substantial frontend work:
+
+1. Run the relevant formatter/checks.
+2. Start the dev server when the app needs one.
+3. Verify with browser screenshots at desktop and mobile widths.
+4. Check interactive states: hover, focus, loading, empty, error, and destructive confirmations.
+
+## Related Skills
+
+- **shadcn-ui** — shadcn CLI, component docs, composition rules, theming, and registries
+- **self-modifying-code** — The agent can edit source code to apply design changes
+- **storing-data** — All data lives in SQL; use actions for data access
+- **actions** — `useActionQuery`/`useActionMutation` hooks for frontend data fetching

package/corpus/templates/tasks/.agents/skills/plan-arbiter/README.md

@@ -0,0 +1,41 @@
+# /plan-arbiter
+
+Compare competing agent plans and choose one executable direction.
+
+`/plan-arbiter` is for workflows where two or more agents, often Codex and
+Claude Code, each produce a plan and then need a judge to cross-review,
+reconcile, and pick what should actually be implemented.
+
+## What It Does
+
+- Collects plans from pasted text, files, sessions, transcripts, PRs, comments,
+  or plan links.
+- Normalizes each plan into assumptions, scope, files, sequence, and
+  verification.
+- Reviews plans against each other and against the real task context.
+- Chooses a winner, creates a hybrid, or sends the plans back for revision.
+- Produces one implementation handoff with rejected alternatives and validation
+  gates.
+
+## When To Use It
+
+Use it when a user says things like:
+
+- "Have Codex and Claude each make a plan, then choose one."
+- "Review these two plans against each other."
+- "Merge the best parts and tell me which agent should execute."
+- "Pick the cheaper execution path if quality is comparable."
+
+Skip it when there is only one straightforward plan and no meaningful
+alternative to evaluate.
+
+## Output
+
+The skill returns a short decision memo: decision, why, execution plan, borrowed
+pieces, rejected ideas, verification, and executor recommendation.
+
+## Install
+
+```sh
+npx @agent-native/skills@latest add --skill plan-arbiter
+```

package/corpus/templates/tasks/.agents/skills/plan-arbiter/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: plan-arbiter
+description: Use when asked to compare, cross-review, merge, judge, choose, or arbitrate competing plans from multiple agents such as Codex and Claude Code; when given two or more proposed plans, session IDs, transcripts, plan documents, PR descriptions, or pasted strategies; or when the user wants one recommended execution plan after agents review each other's proposals.
+---
+
+# Plan Arbiter
+
+Turn competing plans into one executable direction. Preserve the best ideas,
+reject weak assumptions, and produce a clear handoff instead of a blended mush.
+
+## Workflow
+
+1. Collect the source plans.
+2. Normalize each plan into comparable claims.
+3. Cross-review the plans against each other and the real codebase or task
+   context.
+4. Choose a winner, merge a better hybrid, or send the plans back for revision.
+5. Produce one execution handoff with verification gates and rejected
+   alternatives.
+
+Planning is read-only unless the user explicitly asks you to implement after the
+decision.
+
+## Collect Source Plans
+
+Accept plans as pasted text, local files, session IDs, transcript paths, PRs,
+comments, visual-plan links, or chat history. Resolve the original artifacts
+when possible so you can see prompt changes and assumptions that may be missing
+from a final summary.
+
+If a plan is still being written and the user asked you to wait, monitor it
+until it is done or blocked. If a plan cannot be resolved, continue with the
+available plan text and mark the missing source as a risk.
+
+## Normalize
+
+For each plan, extract:
+
+- Objective and scope.
+- Key assumptions and unresolved questions.
+- Proposed files, modules, APIs, data shapes, UI states, or workflows.
+- Implementation sequence.
+- Validation strategy.
+- Rollback or migration concerns.
+- Cost, complexity, and expected executor fit.
+
+Do not reward verbosity. Prefer plans that are concrete, grounded in real code,
+and honest about tradeoffs.
+
+## Cross-Review
+
+Review each plan as if another capable agent wrote it:
+
+- Check whether it satisfies the user's actual request.
+- Verify claims against the repo, docs, tests, screenshots, or external systems
+  when those are relevant and available.
+- Identify hidden dependencies, missing tests, risky sequencing, vague steps,
+  unnecessary scope, and hard-to-reverse decisions.
+- Notice complementary strengths: one plan may have the better architecture
+  while another has the better migration or validation path.
+- Separate plan quality from executor preference. A cheaper/faster executor can
+  be the right choice for implementation even when another model produced the
+  best critique.
+
+Use subagents for independent review when the plans are large, the codebase is
+wide, or the decision would benefit from separate technical and product passes.
+
+## Decide
+
+Choose one of three outcomes:
+
+- **Adopt:** pick one plan mostly as written.
+- **Hybrid:** combine specific pieces into a stronger execution plan.
+- **Revise first:** request another planning pass because both plans miss a
+  key constraint or depend on an unresolved decision.
+
+Use this tie-break order:
+
+1. Correctness and fit to the user's request.
+2. Grounding in real files, APIs, tests, data, and UI behavior.
+3. Simpler first implementation that does not block the intended future.
+4. Better validation and rollback story.
+5. Lower token/time cost for execution once quality is acceptable.
+
+## Handoff
+
+Return a compact decision memo:
+
+```md
+Decision
+- Adopt Plan A / Hybrid / Revise first.
+
+Why
+- The deciding evidence and tradeoffs.
+
+Execution Plan
+- Ordered steps with files or surfaces to touch.
+
+Borrowed From Other Plans
+- Useful pieces kept from non-winning plans.
+
+Rejected
+- Ideas intentionally not taking, with reasons.
+
+Verification
+- Tests, browser checks, screenshots, CI, review, or deploy checks needed.
+
+Executor Recommendation
+- Which agent/model should implement and why.
+```
+
+When the user already asked for execution and the chosen path is clear, proceed
+with the selected plan after reporting the decision briefly. Otherwise stop at
+the handoff and ask for approval.

package/corpus/templates/tasks/.agents/skills/plan-arbiter/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Plan Arbiter"
+  short_description: "Compare competing agent plans and pick one."
+  default_prompt: "Use $plan-arbiter to compare competing plans, cross-review them, and choose an execution plan."

package/corpus/templates/tasks/.agents/skills/plow-ahead/README.md

@@ -0,0 +1,42 @@
+# /plow-ahead
+
+Keep working through ordinary ambiguity and finish with a clear decision recap.
+
+`/plow-ahead` is for explicit autonomy: the user does not want the agent to stop
+for routine clarification questions. The agent should make reasonable
+assumptions, proceed, validate, and explain the decisions it made.
+
+## What It Does
+
+- Converts ordinary questions into stated assumptions.
+- Keeps momentum through implementation choices, missing context, and normal
+  test failures.
+- Stops only for true blockers like credentials, destructive actions,
+  irreversible production changes, explicit branch operations, or high-risk
+  safety/security uncertainty.
+- Uses conservative, reversible, repo-consistent choices.
+- Ends with a recap of decisions, changes, validation, and residual risk.
+
+## When To Use It
+
+Use it when a user says things like:
+
+- "Use your best judgment and finish."
+- "Do not stop for questions unless truly blocked."
+- "Keep going until done."
+- "I want this done when I come back."
+- "Plow ahead."
+
+Skip it when the user is explicitly asking to brainstorm, compare options, or
+wait for approval before implementation.
+
+## Final Recap
+
+The final response should make the autonomous work easy to audit: goal, key
+decisions, assumptions, files changed, validation run, and remaining risk.
+
+## Install
+
+```sh
+npx @agent-native/skills@latest add --skill plow-ahead
+```

package/corpus/templates/tasks/.agents/skills/plow-ahead/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: plow-ahead
+description: >-
+  Use when the user explicitly wants autonomous progress without routine
+  clarification stops: "plow ahead", "do not stop", "use your best judgment",
+  "keep going until done", "finish while I am away", "do not ask questions
+  unless truly blocked", or similar. Convert ordinary ambiguity into stated
+  assumptions, proceed through implementation and validation, stop only for true
+  blockers, and end with a clear recap of decisions, changes, verification, and
+  residual risk.
+---
+
+# Plow Ahead
+
+Proceed through ordinary ambiguity. Make reasonable assumptions, keep momentum,
+validate as you go, and make the final recap strong enough that the user can see
+what decisions were made while they were away.
+
+## Autonomy Contract
+
+Treat the user's instruction as permission to continue through normal
+uncertainty:
+
+- Turn routine questions into explicit assumptions.
+- Prefer the smallest reversible choice that satisfies the request.
+- Use repo conventions, nearby patterns, local docs, tests, and existing product
+  behavior as the decision source.
+- Keep working through normal test failures, missing context, implementation
+  choices, and minor ambiguity.
+- Use subagents for independent research, implementation, or verification when
+  parallel work can reduce idle time or improve coverage.
+- Do not pause merely to ask which reasonable option the user prefers. Pick one,
+  record why, and keep going.
+
+## Stop Conditions
+
+Stop and ask only for true blockers:
+
+- Required credentials, secrets, accounts, paid services, or private data are
+  unavailable.
+- The next step would be destructive, irreversible, or production-mutating.
+- The task requires an explicit branch operation, history rewrite, force push, or
+  deletion that the user did not directly request.
+- Legal, safety, privacy, or security risk is high and cannot be reduced by a
+  conservative local choice.
+- The user explicitly reserved a decision for themselves.
+- A verification failure repeats after reasonable investigation and the next fix
+  would be speculative or broad.
+
+If blocked, leave a self-contained handoff: what was done, what blocks progress,
+what exact input is needed, and the next command or file to inspect.
+
+## Decision Rules
+
+When choosing without the user:
+
+1. Reuse existing patterns before inventing new ones.
+2. Prefer local, reversible, low-blast-radius changes.
+3. Keep scope tight to the user's request.
+4. Choose correctness and maintainability over cleverness.
+5. Validate with the smallest meaningful test first, then broaden only when the
+   risk justifies it.
+6. If two options are close, choose the one that is easier for the user or a
+   reviewer to understand later.
+
+Maintain a lightweight decision log while working. It can live in notes, the
+plan, or your final answer, but do not create a new repo artifact unless the task
+needs one.
+
+## Work Loop
+
+1. Restate the goal internally and identify likely acceptance criteria.
+2. Inspect the real files, docs, issue, PR, screenshots, or runtime behavior
+   before editing.
+3. Make assumptions explicit, then act on them.
+4. Implement in small coherent steps.
+5. Run targeted validation and fix issues found by validation.
+6. Repeat until the requested work is complete or a stop condition applies.
+7. Before final response, review the diff and verification evidence against the
+   original request.
+
+## Final Recap
+
+End with a recap that makes autonomous decisions auditable:
+
+```md
+Goal
+- What you completed.
+
+Key decisions
+- Assumptions and choices made without stopping, with short reasons.
+
+Changes
+- Files, behavior, docs, or configuration changed.
+
+Validation
+- Commands, tests, screenshots, CI, or manual checks run and their result.
+
+Remaining risk
+- Anything not verified, deferred, or blocked.
+```
+
+Keep the recap factual. Do not hide uncertainty, skipped validation, or judgment
+calls.

package/corpus/templates/tasks/.agents/skills/plow-ahead/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Plow Ahead"
+  short_description: "Proceed autonomously through ordinary ambiguity."
+  default_prompt: "Use $plow-ahead to keep working through ordinary ambiguity, make reasonable assumptions, validate, and recap decisions clearly."

package/corpus/templates/tasks/.agents/skills/quick-recap/README.md

@@ -0,0 +1,55 @@
+# /quick-recap
+
+Make the agent's work state obvious at the end of every response.
+
+`/quick-recap` adds a small red/yellow/green status footer convention. It answers
+the thing users otherwise have to infer from a long response: done, pending, or
+blocked.
+
+## What It Does
+
+- Adds a single final status line.
+- Defines when to use green, yellow, or red.
+- Keeps the status user-facing and under 100 characters.
+- Installs cleanly into `AGENTS.md` or `CLAUDE.md` through a managed block.
+
+## When To Use It
+
+Use it when you want every completed unit of work to end with a reliable state
+signal. It is especially useful in repos where multiple agents, long-running
+work, or partial handoffs can make status hard to scan.
+
+## Status Meanings
+
+- Green: the requested coding or work unit is finished.
+- Yellow: specific non-routine follow-up remains.
+- Red: the agent cannot continue without user input.
+
+## Output Examples
+
+Green means the work unit is done:
+
+```md
+🟢 Updated quick recap docs with output examples
+```
+
+Yellow means a specific non-routine item remains:
+
+```md
+🟡 Code updated, set PROVIDER_WEBHOOK_SECRET before testing webhooks
+```
+
+Red means the agent is blocked on user input:
+
+```md
+🔴 Need the production API key to continue
+```
+
+## Install
+
+```sh
+npx @agent-native/skills@latest add --skill quick-recap --update-instructions
+```
+
+Use `--update-instructions`; copying the skill alone does not make the footer
+automatic.

package/corpus/templates/tasks/.agents/skills/quick-recap/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: quick-recap
+description: Use when adding or following the red/yellow/green final status block convention for agent responses, especially by installing managed AGENTS.md or CLAUDE.md instructions.
+---
+
+# Quick Recap
+
+Make completion state obvious at the end of every response.
+
+## Status Block
+
+Every response that completes a unit of work must end with:
+
+```md
+🟢 Actual concise status sentence
+```
+
+Rules:
+
+- Keep the status line under 100 characters.
+- Use `🟢` when the requested work is finished.
+- Use `🟡` when non-routine follow-up remains; name the pending item.
+- Use `🔴` only when blocked on user input.
+- Put the status line at the very end of the response.
+- Do not add `---`, spacer lines, or any content after the status line.
+
+## Installer Behavior
+
+This convention is only automatic when it is present in project or user
+instructions. When installing this skill, prefer adding the managed
+`AGENTS.md` / `CLAUDE.md` block unless the user opts out.
+
+If you are following the convention manually, choose the status from the user's
+perspective: finished, pending a specific non-routine step, or blocked.
+
+## Examples
+
+Finished work:
+
+```md
+🟢 Updated quick recap docs with output examples
+```
+
+Non-routine follow-up remains:
+
+```md
+🟡 Code updated, set PROVIDER_WEBHOOK_SECRET before testing webhooks
+```
+
+Blocked on user input:
+
+```md
+🔴 Need the production API key to continue
+```