triage-findings
Coordinate findings work with the user, decide whether scan, test, or sync should run, and turn the current findings set into a ready plan. Accept optional `path` and GitHub PR `url`; default to `path=infer`. Confirm effective variables before starting.
git clone --depth 1 https://github.com/Agenta-AI/agenta /tmp/triage-findings && cp -r /tmp/triage-findings/.agents/skills/triage-findings ~/.claude/skills/triage-findingsSKILL.md
# Triage Findings Read these shared references when needed: - `../shared/references/findings.schema.md` - `../shared/references/findings.lifecycle.md` ## Role Triage is the planning and clarification layer across findings work. - Decide whether the next step is `scan-codebase`, `test-codebase`, `sync-findings`, or `resolve-findings`. - Read the active findings record and current code or docs as needed. - Ask the next concrete follow-up questions instead of leaving ambiguity buried in statuses. ## URL Input Accept an optional GitHub PR `url` from the prompt. - If a PR URL is provided, use it when triage needs GitHub context or should invoke `sync-findings`. - If no URL is provided, stay local-only unless the user adds remote context. Default: - `url=local-only` ## 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. Establish triage scope. Confirm the effective variables first: - `path` - `url` - branch, PR URL if present, current findings file, and any focus areas 2. Load the active findings record. Use `path/findings.md`. 3. Decide what is missing. Determine whether the next need is: - more review via `scan-codebase` - more validation via `test-codebase` - findings or GitHub reconciliation via `sync-findings` - direct implementation via `resolve-findings` 4. Surface decisions and blockers. Present open questions, competing fix paths, policy ambiguity, and missing confirmations clearly. If the user has already started answering, ask the next concrete follow-up questions in the same turn. 5. Produce a ready plan. End triage with a concrete next step, not a vague status-only handoff. ## Rules - Triage is discussion and planning, not silent execution by default. - Do not hide ambiguity behind `open` or `needs-user-decision`. - Do not force a CR or QA label when the user wants one shared findings workflow.
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.