resolve-findings
Resolve findings by implementing the chosen fix path in code, tests, or docs. Accept optional `path` and a `priority` selector; by default resolve only the next highest remaining priority bucket, in order `P0`, `P1`, `P2`, `P3`. Also accept explicit levels or `all`. Default to `path=infer`. Confirm effective variables before starting.
git clone --depth 1 https://github.com/Agenta-AI/agenta /tmp/resolve-findings && cp -r /tmp/resolve-findings/.agents/skills/resolve-findings ~/.claude/skills/resolve-findingsSKILL.md
# Resolve Findings Read these shared references when needed: - `../shared/references/findings.schema.md` - `../shared/references/findings.lifecycle.md` ## Role Resolve is execution mode from findings back into code, tests, and docs. - It may change production code for verification findings. - It may change tests or test harnesses for validation findings. - It should update the active findings record after implementation and rerun targeted checks when feasible. ## Priority Input Accept a `priority` parameter from the prompt: - omitted priority: resolve the next highest remaining bucket only - explicit level: `P0`, `P1`, `P2`, or `P3` - `all`: resolve all remaining buckets Default: - `priority=next-highest` ## Path Input Accept an optional `path` from the prompt. - If `path` is provided, use it as the local design or findings folder. - If `path` is omitted, infer it from the branch, subsystem, or matching docs and state the inferred value before starting. Default: - `path=infer` ## Workflow 1. Determine the selected bucket. Confirm the effective variables first: - `path` - `priority` - target findings files when inferable Use the requested `priority`, or the next highest unresolved bucket in the active findings record. 2. Load the active findings record. Use `path/findings.md`. 3. Check readiness before coding. If the intended resolution path, policy boundary, or data contract is still ambiguous, ask the next follow-up question before editing. 4. Implement the selected fixes. Make the smallest coherent set of code, test, and doc changes needed for the selected findings bucket. 5. Re-run targeted checks. Use the narrowest useful verification or validation pass that demonstrates the fix. 6. Update the findings record. Move findings between open and closed sections, preserve notes and open questions ordering, and record what was fixed or what remains blocked. ## Rules - Do not hide ambiguity behind `open` or `needs-user-decision` when the user already started answering. Ask the next concrete question. - Do not silently widen scope from the selected priority bucket unless the fix is tightly coupled.
Helps add announcement cards to the sidebar banner system. Use when adding changelog entries, feature announcements, updates, or promotional banners to the Agenta sidebar. Handles both simple changelog entries and complex custom banners.
Playbook for adding a new coding-agent harness to Agenta (Codex, Hermes, Gemini, OpenCode, ...). Use when starting, planning, or reviewing a new-harness project. Covers the readiness audit of prior art, the spike-first milestone plan, the full integration-surface checklist, the per-harness variance axes to probe, and the process/communication contract with Mahmoud. Living document: every harness project appends its lessons to resources/LESSONS.md.
>-
Where to put frontend code (package vs app layer) and how to use the @agenta/* packages. Use when authoring or moving code in web/packages, choosing between @agenta/ui, @agenta/entities, @agenta/entity-ui, @agenta/shared, @agenta/playground, using molecules, loadable/runnable bridges, the EntityPicker, or writing package unit tests.
Use this skill to create and publish changelog announcements for new features, improvements, or bug fixes. This skill handles the complete workflow - creating detailed changelog documentation pages, adding sidebar announcement cards, and ensuring everything follows project standards. Use when the user mentions adding changelog entries, documenting new features, creating release notes, or announcing product updates.
Hard-won GitButler mechanics for multi-lane work in this repo — committing to a specific lane in a stack, spreading a pile of edits back across an existing stack, ordering a stack and setting PR bases, and recovering from a scrambled workspace. Use when working with stacked branches, when `but rub`/`but absorb`/`but commit --only` mis-routes a change, when a stack collapses or a commit lands on the wrong lane, or when a hunk gets dropped. Not needed for ordinary single-lane work.
Drive a researched and planned feature to a landed, tested change. Use after plan-feature has produced a docs/design/<project>/ workspace and the user says "implement it", "build the plan", "run the plan", or "let's ship this". Orchestrates refresh-plan, implement, review, a debug-local-deployment loop, and a test loop across the daytona / local-pi / claude x SDK / UI matrix, then documentation and a GitButler stacked branch. The orchestrator stays in the loop and spins narrow subagents for each phase.
Feature-folder layout, states/ convention, and data-flow rules for the Agenta mobile app (web/mobile). Use when creating or moving files under web/mobile, deciding where a component lives, adding a new feature or screen, or wiring data into mobile components.