Claude Skills by apache

Paste everything below the line into the system prompt field of any capable chat model (Claude, GPT, a local model, etc.). The learner then talks to it in the normal chat window. Nothing above the line is sent to the model. The prompt does two jobs. It runs the lesson as an interactive tutor, and it can regenerate or re-explain the lesson material on request. Both behaviours are defined below. This is a longer lesson than 1 to 3 (about 60 minutes: 40 reading, 20 exercises and self-check) and ...

Paste everything below the line into the system prompt field of any capable chat model (Claude, GPT, a local model, etc.). The learner then talks to it in the normal chat window. Nothing above the line is sent to the model. The prompt does two jobs. It runs the lesson as an interactive tutor, and it can regenerate or re-explain the lesson material on request. Both behaviours are defined below. The full source page (`docs/education/debugging-skills.md`, about 50 minutes: 30 reading, 20 exercis...

**Source page:** [Your first skill](../your-first-skill.md) **Estimated time:** 60 minutes (40 min reading + 20 min exercises and self-check) **Lesson in sequence:** 4 of 11 ---

**Source page:** [Debugging a skill](../debugging-skills.md) **Estimated time:** 50 minutes (30 min reading + 20 min exercises and self-check) **Lesson in sequence:** 6 of 11 ---

This is a step-by-step guide to writing your first working skill in `<PROJECT>`. It takes you from "I have an idea" to "the pull request is merged". You do not need any earlier experience with the framework. This is not the full authoring reference. Once you know the shape of a skill, the [`write-skill`](../../skills/write-skill/SKILL.md) skill (you run it with `/magpie-utilities:write-skill`) takes you through every check, safety step, and packaging detail. Come back to it after your first s...

Read-only GitHub activity card for a named contributor on `<upstream>`. Summarizes PRs, reviews, issues, and comments over a configurable window. GitHub-visible activity only; use `contributor-nomination` for a full brief.

Post-vote committer and PMC onboarding for Apache projects. Walks the nominator through every step from ICLA check to welcome announcement for both incubating podlings and graduated top-level projects, including mapping the new committer's GitHub handle to their Slack, Discord, and social-media identities for the nominator to confirm.

Read-only brief showing a contributor's activity next to the project's committer or PMC reference levels, as plain numbers. Surfaces information only: no ranking, no status, no readiness verdict — the PMC decides.

Read-only nomination brief for a named contributor on <upstream>. Aggregates GitHub activity across contribution tracks, off-GitHub signal, and vendor-neutrality context for committer or PMC nomination threads. Surfaces information only: never rates the contributor or says whether they are ready.

Answer newcomer contribution questions grounded in `CONTRIBUTING.md` and docs. Classifies questions into setup, workflow, first-issue, or maintainer hand-off. Drafts a concise response in the mentoring register. Read-only; never writes files or posts comments without maintainer confirmation.

Measure contributor-sentiment signals on `<upstream>` over a window: thread tone, time-to-first-reply, first-PR retention, and reviewer load. Compares signals against baseline to generate a mode promotion gate report.

Read-only maintainer dashboard for the open general-issue backlog of <issue-tracker>. Surfaces a health rating, prioritised recommendations, age and staleness breakdowns, area pressure ranking, and a triage-funnel summary. Output is HTML by default; markdown fallback available.

Merge two open `<issue-tracker>` issues that describe the same root cause, preserving both reporters' context. Proposes a closing comment on the duplicate and a cross-reference comment on the kept issue. Waits for maintainer confirmation before posting anything or closing anything.

For a single triaged `<issue-tracker>` issue confirmed as a bug or feature, draft a fix against `<upstream>` on `<default-branch>`. Produces the failing test, the smallest production change, the targeted+module test runs, and the commit. The PR is NOT opened on autopilot; the human committer reviews, signs, and pushes. Hand-back artefact summarises branch, commits, test results, and scope.

Read-only dashboard over a directory of `verdict.json` files produced by `issue-reassess` campaigns. Surfaces a health rating, classification distribution, partial-fix surfaces, oldest-unresolved buckets, and per-component breakdowns. Output is HTML by default; markdown fallback available. Read-only on tracker state; consumes campaign artefacts.

Sweep a configured pool of resolved or end-of-life `<issue-tracker>` issues and re-assess each against the current `<default-branch>`. Per-issue: invoke `issue-reproducer` to extract and run the reporter's code, classify the runtime outcome, attach a nature analysis, compose a `verdict.json`. Hand-back-on-completion contract: no comments posted, no transitions, no closures.

For a single `<issue-tracker>` issue identifying a code-level bug, extract the reporter's example code from the issue body, adapt it to run on the current `<default-branch>`, execute via `<runtime>`, and compose a `verdict.json` describing the observed behaviour vs the expected failure. Read-only on the tracker — produces evidence, never posts. Invoked by `issue-triage` and `issue-reassess`; can also be run standalone.

Sweep open `<issue-tracker>` issues for inactivity past a configurable threshold and propose either a closure (when the issue has been unresponsive long enough to presume abandonment) or an update request (nudge the reporter to confirm the issue is still relevant). Waits for maintainer confirmation before posting any comment or closing anything.

For each open `<issue-tracker>` issue in the configured candidate pool, read the issue body and comments and classify the candidate disposition. On user confirmation, posts a triage-proposal comment that invites the project team to react. Read-only on tracker state — no workflow transitions, closures, or label changes. Six classes in the body.

Draft one net-new *good first issue* on the configured `<upstream>` repo from one supplied gap or small maintainer-named task. Run suitability and readiness checks before showing the draft. File via `gh` only after explicit maintainer confirmation. Never curate or relabel the existing backlog.

Sweep the open `<issue-tracker>` backlog for existing issues that could be labelled as good first issues. Classifies each candidate as READY (propose the GFI label), NEAR-MISS (surface edits to make it GFI-ready), or SKIP using the G1–G7 suitability rubric. Applies labels only after explicit maintainer confirmation; never edits issue bodies without the maintainer's direction.

Given an open good-first-issue on the configured `<upstream>` repo, explain it in beginner terms and sketch a concrete approach: which files to read first, what "done" looks like, and where to ask follow-up questions — without writing any code or fix. First runs an issue assessment to confirm the issue is open, non-security, and scope-clear. Then drafts the explanation for maintainer review. Read-only; nothing is posted without explicit maintainer confirmation.

Draft a first-contact orientation comment for a first-time contributor on a newly opened issue or PR on the configured `<upstream>` repo. Detects first-time authorship via the GitHub `author_association` field and drafts a welcome with contributing-guide link, community-norm pointers, and expected next steps. Waits for explicit maintainer confirmation before posting. Does not post for repeat contributors.

Fan a local diff through three independent, axis-focused review passes (correctness, security, conventions), then merge the findings into a single structured report. Each pass is isolated so one axis cannot bias another. The merged report uses the same format as pairing-self-review.

Run a structured pre-flight self-review on local changes before opening a PR. Reads the diff against a configurable base (default: the merge base of HEAD and origin/<default-branch>), checks correctness, security, and project conventions, and returns a structured report. No state changes, no PR, no external writes — the report is the output.

Walk a maintainer through deep, sequential code review of open PRs on the configured `<upstream>` repo. Defaults to the **"my reviews"** queue (five maintainer signals — see the Inputs table); selectors narrow to one PR, an area label, or a collaborator subset. Drafts an `approve` / `request-changes` / `comment` review per PR and posts on confirmation.

Draft a teaching-register comment on a GitHub issue or PR thread on the configured `<upstream>` repo, aimed at a contributor missing context the maintainer would spell out. Reads the thread, decides whether an intervention is warranted, drafts one comment per the tone guide and convention pointers, and waits for explicit confirmation before posting via `gh`. Escalates on the four hand-off triggers.

Sweep open PRs on the configured `<upstream>` repo for inactivity past a configurable threshold and propose either a conversion to draft (open but quiet) or a closure (abandoned long enough to presume the author moved on). Waits for maintainer confirmation before converting or closing.

Sweep open PRs on the configured `<upstream>` repo, classify each against the project's quality criteria, and — on the maintainer's confirmation — act via `gh`. One disposition per PR: draft / comment / close / rebase / CI-rerun / workflow-approve / ping-stale-reviewer / request author confirmation of readiness / mark `ready for maintainer review` / promote bot-authored draft. Does **not** review code — that is `pr-management-code-review`.

Run a newcomer-focused pre-flight checklist on a local branch before opening a PR. Checks CONTRIBUTING conventions, SPDX headers on new files, commit-message shape (including the Generated-by: trailer for AI-assisted work), and the placeholder convention — then returns a structured checklist report. Read-only; no state changes, no PR, no external writes.

Identify trivial, low-risk PRs in the `ready for maintainer review` queue of <upstream> that pass every quality gate and touch only supplementary areas (docs, changelog, translations, tests) — the "express lane". Surfaces and ranks candidates with per-PR diff summaries, an all-gates-green attestation, and the exact merge command. On explicit per-PR confirmation it can submit an APPROVE review, exactly as pr-management-code-review does. It never merges itself — automated merge is the deliberat...

Given an open issue or PR, scores the project's configured reviewer roster across three signals — touched-area eligibility, git-history familiarity with the changed paths, and current open-review load — and proposes a primary reviewer (plus an optional backup). Read-only, propose-then-confirm: nothing is assigned, labelled, or requested without confirmation. An unresolved roster yields an explicit NO ELIGIBLE REVIEWER signal, never a fabricated handle.

Read-only maintainer dashboard for the open-PR backlog of <upstream>. Surfaces a health rating, prioritised action recommendations, weekly closure velocity trends, area pressure ranking, and a triage-funnel breakdown — with the underlying area-grouped tables as a collapsible details section.

Draft the `[ANNOUNCE]` email and open (never merge) the site-bump PR for a promoted release of `<upstream>`. Never sends mail.

Scan the release distribution area (`dist/release/<project>/` when `release_dist_backend = svnpubsub`, or the configured distribution location), identify releases past the project's retention rule, and propose the backend-shaped command set to move them to the archive area. Read-only on the distribution surface; the RM executes every archival command as themselves.

Assemble a per-release audit record from lifecycle artefacts (planning issue, vote thread, artefact list, promote revision, and announcement URL) and propose a PR appending it to the project's audit log. Read-only on every release surface; the only write is a PR the RM reviews and a committer merges.

Add the Release Manager's public key to the project KEYS file: check it meets the ASF strength floor, draft the KEYS diff, and emit the `svn` (or backend) commands and keyserver reminder for the RM to run. Never holds the private key, never commits.

Draft release-preparation artefacts for `<upstream>`: the planning issue, the version-bump and changelog prep PR (with the first-release review of what the source archive ships), the post-release dev-version bump PR, and, for ASF projects, the one-time `automated-signing` setup. Every output is a draft the RM confirms; nothing is merged, filed or sent.

Emit the backend-shaped promotion command set for a release that has passed its vote. Reads the planning issue (must carry `vote-passed`), constructs the staging → release move for the configured distribution backend, checks PMC membership of the Release Manager, and proposes the `promoted` label. Never runs the promotion command itself and never publishes the release.

Emit the paste-ready commands to tag an RC, build the source archive reproducibly, sign, checksum and stage it to the distribution backend (or, with ASF automated signing, the tag push that triggers CI). Never runs them: the RM does, with their own key and credentials.

Read-only verification of a staged RC of `<upstream>`: signatures and checksums, RAT headers, NOTICE/LICENSE, prohibited binaries, JVM artefacts, the Nexus staging repository behind them (ASF projects publishing Maven artefacts), source-tree integrity, version strings, and optionally reproducibility. Emits a PASS / PASS-WITH-WARNINGS / FAIL report; `--post-to` proposes a planning-issue comment for the RM to confirm.

Draft the `[VOTE]` email body and planning-issue comment for an RC of `<upstream>`. Reads RC metadata from the planning issue and `<project-config>/release-management-config.md`; produces a ready-to-copy `[VOTE]` subject + body and a proposed planning-issue comment. Never sends mail and never posts without explicit RM confirmation.

After the approval window closes, fetch the approval signal for an RC of `<upstream>`, classify each reply as +1 / 0 / -1 and binding or non-binding against the configured roster, produce the tally summary, and draft the `[RESULT] [VOTE]` email. Never sends mail and never applies a label without explicit RM confirmation.

For a batch of findings from a non-security audit tool (`<audit-tool>` — ruff / flake8 / mypy / pylint / CodeQL / Apache Verum / Apache Caer / equivalent; full list in the body) against `<upstream>`, draft the smallest fix per finding, re-running the tool after each batch to confirm clearance. Produces a commit and a hand-back artefact; never opens a PR on autopilot or merges.

Read-only audit of GitHub Actions runner compatibility for one repository, a repository set, one Apache project, or the full Apache org. Finds obsolete GitHub-hosted runner labels and macOS runner/tool architecture mismatches. Produces TSV evidence; never edits workflows, opens PRs, or posts comments.

Read-only dependency vulnerability audit for one repository or a local checkout. Detects the project's dependency manager(s), runs the appropriate audit tool, surfaces patchable findings grouped by severity, and proposes upgrades for maintainer review. Never modifies manifests or lock files and never opens update PRs.

Read-only license audit of a dependency tree. Detects the manager(s), resolves each dependency's license from ecosystem metadata, and classifies it against a configured policy (ASF A/B/X or allowlist), surfacing incompatible, forbidden, and unknown-license dependencies. Never modifies manifests or lock files.

Read-only flaky-test detection from GitHub Actions run history for one repository: parses run outcomes over a configurable window, computes per-job failure rates, and separates intermittent failures from deterministically broken ones. Produces a prioritised triage list without modifying tests, workflows, or tracker state.

Read-only license compliance audit for one repository or checkout: LICENSE present, NOTICE complete when the declared license requires it, and source files carrying SPDX-License-Identifier headers consistent with that license. Produces a grouped report with proposed remedies for review; never modifies any file.

Read-only GitHub Actions workflow security audit for one repository, a repository set, or a whole GitHub org. Runs `zizmor` to surface injection vulnerabilities, excessive permissions, unpinned external actions, and self-hosted-runner fork-secret leaks. Produces a grouped, prioritised report; never edits workflows, opens PRs, or posts comments.