Od ticketa do zmergowanego PR‑a w sześciu skillach

---
name: investigate-ticket
description: Investigate a ticket or reported problem and propose a fix for discussion before implementation.
---

Read the ticket and any supplied context, then thoroughly investigate the relevant code.
Split the ticket into separate claims (symptoms, conditions, suspected causes, expectations) and verify each one against the code, tests, and history instead of accepting the ticket's framing.
Follow the call path from the entry point to the line where the behaviour goes wrong, including every module it delegates to (workers, queues, frontend state, external APIs). Do not stop at the first plausible cause.
Before proposing a change to shared code, list its existing callers and check how each would be affected.
For bugs, write and run regression tests that reproduce the problem and fail against the current implementation. If a claim needs production or local database data to confirm, ask for it instead of querying.
Stop before implementing the fix until we have discussed and agreed on the approach.

## Report

The report is the deliverable. A developer who has not seen the code must be able to judge from it alone whether the proposed implementation makes sense, without redoing the investigation. A short summary is not an acceptable report. Write it in the user's language and use these sections:

1. **What is wrong** — plain-language explanation: what the user sees, who is affected, under which conditions, and why it happens. Explain the mechanism in words first, then point at the code.
2. **Ticket claims** — every claim from the ticket marked as confirmed, not confirmed, contradicted, or not verifiable, each with its evidence (`file:line`, test output, commit). Add relevant findings the ticket does not mention.
3. **Reproduction** — the test file and name, the command to run it, the relevant failing output, and the conditions it depends on (data, plan, flags, timing). If the problem did not reproduce, list what was tried and what that rules out. For non-bug tickets, show the current behaviour instead.
4. **Root cause** — the call path from entry point to faulty line with `file:line` at each hop, why that line is wrong, and when it was introduced if history explains it.
5. **Fix options** — for each option:
   - the concrete changes per file and function, including migrations, API or contract changes, and frontend changes;
   - why it removes the root cause rather than the symptom;
   - the affected callers and behaviour changes elsewhere;
   - what happens to existing data already in the bad state and whether it needs a backfill or cleanup;
   - risks and edge cases;
   - the tests to add or change;
   - the relative size of the change.

   End with a recommendation and its reasoning, and list the open questions that need a decision before implementation.

---
name: grill-me
description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when the user wants to stress-test a plan, get grilled on their design, needs clarification before implementation, or mentions "grill me" or the "grill-me" skill.
---

# Grill Me

Interview the user relentlessly about every aspect of the plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one by one.

For each question, provide your recommended answer.

Ask the questions one at a time.

If a question can be answered by exploring the codebase, explore the codebase instead.

---
name: local-app-login
description: Select a local app account and organization and log in using development-only Mix commands. Use for local app browser testing, not the admin panel or production.
---

In the current checkout's app directory, list available accounts:

```bash
mix app.accounts
```

Choose a customer–organization pair suitable for the task and generate a login link:

```bash
mix app.login --customer <integer> --organization <guid>
```

Open the printed URL in the browser and verify the selected account and organization.
The app must already be running.

For command options and output details, use `mix app.accounts --help` or
`mix app.login --help`. Help is authoritative.

Login persists in localStorage across reloads and switches the account in all tabs
on the same origin (scheme, host and port). Worktrees on different ports are isolated.

git clone https://github.com/openclaw/agent-skills.git
cp -R agent-skills/skills/autoreview .agents/skills/autoreview

---
name: babysit
description: Monitor a PR until ready to merge. Use when asked to babysit a PR, watch CI, or keep handling review feedback.
---

Poll CI, comments, and unresolved review threads together; handle review feedback without waiting for CI to finish. A push is never the end of the task; resume watching.
Keep review fixes within the PR's original scope. Treat suggestions to add features or unrelated improvements critically; even if worthwhile, get explicit user approval before implementing them.
Verify findings against the latest code. Fix real issues within scope, including cheap nits; run relevant tests, commit, push.
Before every push, fetch origin and rebase onto origin/main; resolve conflicts and run all required checks on the rebased code before pushing.
For false positives, reply with a one-line reason and resolve the thread. Escalate valid findings you would rather defer, and subjective or architectural feedback, instead of dismissing them.
Resolve threads only after verifying they are addressed; outdated does not mean resolved.
Retry confirmed infra flakes up to twice, then report the blocker; if a check also fails on main, report it as a blocker.
Prefix comments you post with "<model slug> on behalf of <name>".
Before declaring readiness, freshly confirm that CI passes, required reviews are satisfied, no automated reviewer is still running (check their status comments and reactions), the PR is mergeable, and no comments or threads remain unaddressed. Check recent merged PRs for the review bots this repo uses; a bot that has not posted yet has not started, which is not a pass.
Stop when ready, merged, closed, or blocked on a human decision; briefly report the outcome or blocker.
Do not merge unless explicitly asked.

---
name: babysit-merge
description: Babysit a PR, then squash-merge it and move its Jira ticket to Done. Only when the user explicitly invokes /babysit-merge; never invoke on your own.
disable-model-invocation: true
---

Babysit the PR, and once it is ready, squash-merge it and move its Jira ticket to Done.
The user's invocation approves only the code as it was at that moment, so do not merge if the PR's code has changed since, for any reason including your own fixes, or if you have any open question or doubt about the code; report it and wait for the user to invoke this skill again.