@olegkoval/agent-skills 1.22.0 → 1.23.0

package/packages/software-development/ci-fix-loop/adapters/cursor/skills/ci-fix-loop/SKILL.md

@@ -0,0 +1,203 @@
+---
+name: ci-fix-loop
+description: >
+  Diagnose GitHub Actions CI failures in a loop: fetch the failing check logs, identify
+  the root cause, apply a targeted fix, push, and wait for the next run — repeating until
+  all checks are green or a real blocker needs a human. Use when CI is red after a push,
+  when the user says "fix CI", "make tests pass", "diagnose CI failures", or "drive this
+  to green". Direct analog of qodoloop / coderabbitloop for automated test and lint failures.
+license: MIT
+allowed-tools: Bash, Read, Write, Edit
+compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git and gh (GitHub CLI) authenticated, with a GitHub Actions workflow configured.
+metadata:
+  targets: ["cursor"]
+  author: Oleg Koval
+  tags:
+    - github-actions
+    - ci
+    - testing
+    - automation
+    - loop
+    - fix
+source: weekly-pattern-learner
+source_reason: "qodoloop and coderabbitloop share the push→poll→diagnose→fix→repeat loop; CI failures have the same shape but no dedicated skill existed"
+source_date: "2026-07-28"
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+> 🤖 *Auto-generated by **weekly-pattern-learner** · qodoloop and coderabbitloop share the push→poll→diagnose→fix→repeat loop; CI failures have the same shape but no dedicated skill existed*
+
+# CI Fix Loop
+
+Drive a GitHub Actions CI run from red to green: fetch failure logs, diagnose, apply
+a targeted fix, push, and repeat until all required checks pass or a blocker is hit.
+
+## Inputs
+
+- **PR number** (optional): detect from current branch if not given.
+- **Check names** (optional): limit to specific failing checks instead of all.
+- **Max iterations** (default: 5)
+
+## Workflow
+
+### 1. Identify the PR and current CI state
+
+```bash
+# Detect PR from current branch
+gh pr view --json number,headRefName,headRefOid \
+  -q '{number, branch: .headRefName, sha: .headRefOid}'
+
+# Current check status
+gh pr checks --json name,state,conclusion 2>/dev/null \
+  || gh run list --branch <branch> --limit 5
+```
+
+Classify each check as: `pass`, `fail`, `pending`, or `skipped`.
+
+**Exit immediately if all required checks already pass** — nothing to do.
+
+### 2. Loop (max 5 iterations)
+
+#### A. Identify failing checks
+
+```bash
+gh pr checks --json name,state,conclusion \
+  --jq '.[] | select(.conclusion == "failure" or .state == "FAILURE")'
+```
+
+For each failing check, record: check name, workflow file, job name.
+
+Stop if the working set is empty — all required checks are green.
+
+#### B. Check for base-branch regression first
+
+Before touching any code, verify the failure is not already present on `main`:
+
+```bash
+gh run list --branch <base-branch> --workflow <workflow-name> --limit 3 \
+  --json conclusion --jq '.[].conclusion'
+```
+
+If the same check is failing on the base branch, **stop and report** —
+this is not your PR's fault. Do not attempt a fix that masks a base-branch problem.
+Wait for a `Base branch recovered` notice before re-trying.
+
+#### C. Fetch failure logs
+
+For each failing check:
+
+```bash
+# Latest run ID for this branch/workflow
+gh run list --branch <branch> --workflow <workflow-name> --limit 1 \
+  --json databaseId --jq '.[0].databaseId'
+
+# Fetch only failing steps (not the full log)
+gh run view <run-id> --log-failed
+```
+
+Cap log reading at ~200 lines per job — the error is almost always in the last
+50 lines of a failed step.
+
+#### D. Diagnose
+
+Classify the failure before writing any code:
+
+| Category | Examples | Fix target |
+|---|---|---|
+| Test failure | `FAIL TestFoo`, `AssertionError`, `expected X got Y` | Source or test |
+| Lint / format | `gofmt`, `eslint`, `ruff`, `prettier` | Run auto-formatter |
+| Build error | compile error, missing import, type mismatch | Source |
+| Dependency | `npm ERR!`, missing module, lockfile mismatch | Update lockfile |
+| CI config | YAML parse error, bad action ref, missing secret | Workflow YAML |
+| Flaky test | same test passes on manual re-run | Re-run first; mark if it keeps failing |
+
+For flaky-looking failures, re-run the check before touching code:
+
+```bash
+gh run rerun <run-id> --failed
+```
+
+Wait for the rerun result. If it passes on rerun, skip this iteration and go to
+step F to poll for the new result.
+
+#### E. Apply a targeted fix
+
+Fix **only** what the log names as the failure. Do not refactor surrounding code,
+add unrelated tests, or touch files the failing step never mentioned.
+
+Common one-liners:
+
+```bash
+# Go format
+gofmt -w .
+goimports -w .
+
+# Node format / lint
+npx prettier --write .
+npx eslint --fix .
+
+# Python
+ruff check --fix .
+black .
+
+# Lockfile
+npm install          # Node
+poetry lock --no-update  # Python
+go mod tidy          # Go
+```
+
+For test failures: read the failing test and the code it exercises. Fix the code
+or the assertion — but not both in one commit unless the test was clearly wrong
+and the fix is trivial.
+
+#### F. Commit and push
+
+Stage **only the files touched in step E** — never `git add -A`, which can sweep
+in unrelated local changes:
+
+```bash
+git add <files touched>
+git commit -m "fix(ci): <what was broken> (ci-fix-loop iteration N)"
+git push
+```
+
+Confirm the push succeeded before polling. A resolved check whose fix never reached
+the branch is worse than an unresolved one.
+
+#### G. Wait for CI on the new SHA
+
+Poll every ~15s (timeout ~8min) for all previously-failing checks to complete
+on the new push:
+
+```bash
+gh pr checks --json name,state,conclusion,startedAt
+```
+
+Wait until all previously-failing checks show a new result (`pass` or `fail`)
+on the current SHA. Do not act on a result that still shows the old SHA.
+
+Go back to step A.
+
+### 3. Report
+
+| Field | Value |
+|---|---|
+| Iterations | N |
+| Checks fixed | names + root cause |
+| Checks blocked | names + reason (flaky / needs human / base-branch red) |
+| Final status | all green / partial / blocked |
+
+```
+CI fix loop complete.
+  Iterations:  2
+  Fixed:       lint (gofmt: 3 files), test (TestUserCreate — nil pointer in fixture)
+  Blocked:     none
+  Status:      all required checks green
+```
+
+## Chaining
+
+| Before this skill | After this skill |
+|---|---|
+| `olko:pr-description-writer` | `olko:qodoloop` |
+| Any `git push` with failing CI | `olko:coderabbitloop` |

package/packages/software-development/ci-fix-loop/adapters/grok/plugin.json

@@ -0,0 +1,6 @@
+{
+  "name": "olko:ci-fix-loop",
+  "version": "0.1.0",
+  "description": "Diagnose GitHub Actions CI failures in a loop: fetch failing check logs, fix, push, and repeat until green. Direct analog of qodoloop / coderabbitloop for test and lint failures.",
+  "skills": "skills/"
+}

package/packages/software-development/ci-fix-loop/adapters/grok/skills/ci-fix-loop/SKILL.md

@@ -0,0 +1,203 @@
+---
+name: ci-fix-loop
+description: >
+  Diagnose GitHub Actions CI failures in a loop: fetch the failing check logs, identify
+  the root cause, apply a targeted fix, push, and wait for the next run — repeating until
+  all checks are green or a real blocker needs a human. Use when CI is red after a push,
+  when the user says "fix CI", "make tests pass", "diagnose CI failures", or "drive this
+  to green". Direct analog of qodoloop / coderabbitloop for automated test and lint failures.
+license: MIT
+allowed-tools: Bash, Read, Write, Edit
+compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git and gh (GitHub CLI) authenticated, with a GitHub Actions workflow configured.
+metadata:
+  targets: [_source-only]
+  author: Oleg Koval
+  tags:
+    - github-actions
+    - ci
+    - testing
+    - automation
+    - loop
+    - fix
+source: weekly-pattern-learner
+source_reason: "qodoloop and coderabbitloop share the push→poll→diagnose→fix→repeat loop; CI failures have the same shape but no dedicated skill existed"
+source_date: "2026-07-28"
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+> 🤖 *Auto-generated by **weekly-pattern-learner** · qodoloop and coderabbitloop share the push→poll→diagnose→fix→repeat loop; CI failures have the same shape but no dedicated skill existed*
+
+# CI Fix Loop
+
+Drive a GitHub Actions CI run from red to green: fetch failure logs, diagnose, apply
+a targeted fix, push, and repeat until all required checks pass or a blocker is hit.
+
+## Inputs
+
+- **PR number** (optional): detect from current branch if not given.
+- **Check names** (optional): limit to specific failing checks instead of all.
+- **Max iterations** (default: 5)
+
+## Workflow
+
+### 1. Identify the PR and current CI state
+
+```bash
+# Detect PR from current branch
+gh pr view --json number,headRefName,headRefOid \
+  -q '{number, branch: .headRefName, sha: .headRefOid}'
+
+# Current check status
+gh pr checks --json name,state,conclusion 2>/dev/null \
+  || gh run list --branch <branch> --limit 5
+```
+
+Classify each check as: `pass`, `fail`, `pending`, or `skipped`.
+
+**Exit immediately if all required checks already pass** — nothing to do.
+
+### 2. Loop (max 5 iterations)
+
+#### A. Identify failing checks
+
+```bash
+gh pr checks --json name,state,conclusion \
+  --jq '.[] | select(.conclusion == "failure" or .state == "FAILURE")'
+```
+
+For each failing check, record: check name, workflow file, job name.
+
+Stop if the working set is empty — all required checks are green.
+
+#### B. Check for base-branch regression first
+
+Before touching any code, verify the failure is not already present on `main`:
+
+```bash
+gh run list --branch <base-branch> --workflow <workflow-name> --limit 3 \
+  --json conclusion --jq '.[].conclusion'
+```
+
+If the same check is failing on the base branch, **stop and report** —
+this is not your PR's fault. Do not attempt a fix that masks a base-branch problem.
+Wait for a `Base branch recovered` notice before re-trying.
+
+#### C. Fetch failure logs
+
+For each failing check:
+
+```bash
+# Latest run ID for this branch/workflow
+gh run list --branch <branch> --workflow <workflow-name> --limit 1 \
+  --json databaseId --jq '.[0].databaseId'
+
+# Fetch only failing steps (not the full log)
+gh run view <run-id> --log-failed
+```
+
+Cap log reading at ~200 lines per job — the error is almost always in the last
+50 lines of a failed step.
+
+#### D. Diagnose
+
+Classify the failure before writing any code:
+
+| Category | Examples | Fix target |
+|---|---|---|
+| Test failure | `FAIL TestFoo`, `AssertionError`, `expected X got Y` | Source or test |
+| Lint / format | `gofmt`, `eslint`, `ruff`, `prettier` | Run auto-formatter |
+| Build error | compile error, missing import, type mismatch | Source |
+| Dependency | `npm ERR!`, missing module, lockfile mismatch | Update lockfile |
+| CI config | YAML parse error, bad action ref, missing secret | Workflow YAML |
+| Flaky test | same test passes on manual re-run | Re-run first; mark if it keeps failing |
+
+For flaky-looking failures, re-run the check before touching code:
+
+```bash
+gh run rerun <run-id> --failed
+```
+
+Wait for the rerun result. If it passes on rerun, skip this iteration and go to
+step F to poll for the new result.
+
+#### E. Apply a targeted fix
+
+Fix **only** what the log names as the failure. Do not refactor surrounding code,
+add unrelated tests, or touch files the failing step never mentioned.
+
+Common one-liners:
+
+```bash
+# Go format
+gofmt -w .
+goimports -w .
+
+# Node format / lint
+npx prettier --write .
+npx eslint --fix .
+
+# Python
+ruff check --fix .
+black .
+
+# Lockfile
+npm install          # Node
+poetry lock --no-update  # Python
+go mod tidy          # Go
+```
+
+For test failures: read the failing test and the code it exercises. Fix the code
+or the assertion — but not both in one commit unless the test was clearly wrong
+and the fix is trivial.
+
+#### F. Commit and push
+
+Stage **only the files touched in step E** — never `git add -A`, which can sweep
+in unrelated local changes:
+
+```bash
+git add <files touched>
+git commit -m "fix(ci): <what was broken> (ci-fix-loop iteration N)"
+git push
+```
+
+Confirm the push succeeded before polling. A resolved check whose fix never reached
+the branch is worse than an unresolved one.
+
+#### G. Wait for CI on the new SHA
+
+Poll every ~15s (timeout ~8min) for all previously-failing checks to complete
+on the new push:
+
+```bash
+gh pr checks --json name,state,conclusion,startedAt
+```
+
+Wait until all previously-failing checks show a new result (`pass` or `fail`)
+on the current SHA. Do not act on a result that still shows the old SHA.
+
+Go back to step A.
+
+### 3. Report
+
+| Field | Value |
+|---|---|
+| Iterations | N |
+| Checks fixed | names + root cause |
+| Checks blocked | names + reason (flaky / needs human / base-branch red) |
+| Final status | all green / partial / blocked |
+
+```
+CI fix loop complete.
+  Iterations:  2
+  Fixed:       lint (gofmt: 3 files), test (TestUserCreate — nil pointer in fixture)
+  Blocked:     none
+  Status:      all required checks green
+```
+
+## Chaining
+
+| Before this skill | After this skill |
+|---|---|
+| `olko:pr-description-writer` | `olko:qodoloop` |
+| Any `git push` with failing CI | `olko:coderabbitloop` |

package/packages/software-development/pr-description-writer/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: pr-description-writer
+description: >
+  Draft and post a GitHub PR title and body from git diff and commit history. Use when
+  opening a new PR, when the user asks to "write a PR description", "draft a PR", "open
+  a PR for this branch", or after running the git-commit skill and pushing the branch.
+  Chains naturally after git-commit and before qodoloop / coderabbitloop.
+license: MIT
+allowed-tools: Bash, Read, Write
+compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires git and gh (GitHub CLI) authenticated.
+metadata:
+  targets: [_source-only]
+  author: Oleg Koval
+  tags:
+    - git
+    - github
+    - pull-request
+    - description
+    - pr
+    - workflow
+source: weekly-pattern-learner
+source_reason: "qodoloop and coderabbitloop both open with gh pr view — the PR creation/description step was never codified as its own skill"
+source_date: "2026-07-28"
+---
+
+> 🤖 *Auto-generated by **weekly-pattern-learner** · qodoloop and coderabbitloop both open with `gh pr view` — the PR creation/description step was never codified as its own skill*
+
+# PR Description Writer
+
+Draft a GitHub-ready PR title and body from the branch's commit history and diff, then
+create or update the PR so reviewers and AI tools have full context.
+
+## Inputs
+
+- **Base branch** (optional, default: `main` or `master` — detect from `gh repo view`)
+- **Draft mode** (optional, default: off)
+- **Template** (optional): if `.github/pull_request_template.md` exists, use its section headings
+
+## Workflow
+
+### 1. Gather branch context
+
+```bash
+# Current branch
+git rev-parse --abbrev-ref HEAD
+
+# Base branch
+gh repo view --json defaultBranchRef -q '.defaultBranchRef.name'
+
+# Commits since base
+git log <base>..<head> --oneline --no-merges
+
+# Diff summary (full diff for small PRs, stat-only for large)
+git diff <base>..<head> --stat
+git diff <base>..<head>   # only if total changes < ~500 lines
+```
+
+If the diff is large (>500 changed lines), read file-by-file rather than all at once.
+
+### 2. Check for existing PR
+
+```bash
+gh pr view --json number,title,body,state 2>/dev/null
+```
+
+- If a PR exists in `OPEN` state: update it with `gh pr edit`.
+- If no PR exists: create one with `gh pr create`.
+
+### 3. Check for a PR template
+
+```bash
+cat .github/pull_request_template.md 2>/dev/null \
+  || cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null \
+  || cat PULL_REQUEST_TEMPLATE.md 2>/dev/null
+```
+
+If a template exists, mirror its section headings and populate them. Skip sections
+that ask for credentials, tokens, internal hostnames, or content unrelated to the diff.
+
+### 4. Draft title and body
+
+**Title rules:**
+- Use Conventional Commits prefix when the branch/commits use it: `feat(scope):`, `fix:`, etc.
+- ≤ 70 characters
+- Imperative mood ("Add X", "Fix Y", not "Added X")
+- Include ticket number if present in branch name (e.g. `LIN-123`, `GH-456`)
+
+**Body sections (use the template if one was found, otherwise use this structure):**
+
+```markdown
+## Summary
+- <bullet: what changed>
+- <bullet: why>
+
+## Changes
+- `<file or subsystem>`: <what changed and why>
+
+## Test plan
+- [ ] <what to run and what result to expect>
+- [ ] <manual steps if automated tests don't cover it>
+
+## Notes
+<optional: anything a reviewer should watch for, known gaps, follow-up issues>
+```
+
+Rules:
+- Describe *intent*, not what the diff already shows line-by-line.
+- If commits already have good conventional messages, use them as the skeleton.
+- Skip any section that has nothing meaningful to say.
+- Reference specific files, functions, or lines only when they aid navigation.
+
+### 5. Create or update the PR
+
+Always pass the body via a heredoc or temp file — never interpolate it into the command
+string (quotes and newlines will break the shell):
+
+```bash
+# Create new PR
+gh pr create \
+  --title "<title>" \
+  --body "$(cat <<'PRBODY'
+<body>
+PRBODY
+)" \
+  --base <base> \
+  [--draft]
+
+# Update existing PR
+gh pr edit <number> \
+  --title "<title>" \
+  --body "$(cat <<'PRBODY'
+<body>
+PRBODY
+)"
+```
+
+### 6. Confirm and report
+
+```bash
+gh pr view --json number,title,url -q '"PR #\(.number): \(.title)\n\(.url)"'
+```
+
+Print the PR number, title, and URL. If the PR was newly created, note whether
+CI triggered automatically.
+
+## Chaining
+
+| Before this skill | After this skill |
+|---|---|
+| `olko:git-commit` + `git push` | `olko:qodoloop` |
+| `git push -u origin <branch>` | `olko:coderabbitloop` |
+| — | `olko:open-source-publisher` (for new repos) |

package/packages/software-development/pr-description-writer/adapters/claude/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "olko-pr-description-writer",
+  "description": "Draft and post a GitHub PR title and body from git diff and commit history. Chains after git-commit and before qodoloop / coderabbitloop.",
+  "skills": "./skills"
+}