New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Development Workflow

by pyathena-dev in pyathena-dev/PyAthena

Deliver a PyAthena change through a dedicated worktree, Draft PR, two distinct self-reviews, independent review, and current CI once marked Ready.

MITAuto-check: notesDevelopment

Install Development Workflow

skills CLI
$ npx skills add pyathena-dev/PyAthena --skill development-workflow -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install pyathena-dev/PyAthena development-workflow --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/pyathena-dev/PyAthena.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/development-workflow .claude/skills/development-workflow && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
development-workflow
GitHub stars
493
Token cost
~2.1k tokens
SKILL.md length
1,065 words
Files
1
Skills in repo
4
Repo updated
First seen
Licence
MIT

At a glance

Deliver a PyAthena change through a dedicated worktree, Draft PR, two distinct self-reviews, independent review, and current CI once marked Ready.

  • Works in 6 steps: Establish the intended behavior and… → Implement and validate the change using… → Read .github/PULL_REQUEST_TEMPLATE.md… → …
  • Not for a bounded review-only request
  • SKILL.md covers Prepare and publish, Validate the affected behavior and Freeze review scope and…
  • Calls just, gh and git

What it does

Development Workflow is an agent skill from pyathena-dev/PyAthena. Deliver a PyAthena change through a dedicated worktree, Draft PR, two distinct self-reviews, independent review, and current CI once marked Ready. Use when implementing or updating a PR, not for a bounded review-only request.

Its SKILL.md is about 2.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Git worktrees. It works with Amazon Web Services. The repository describes itself as: PyAthena is a Python DB API 2.0 (PEP 249) client for Amazon Athena. The licence is MIT.

When your agent uses it

  • Not for a bounded review-only request
  • Tasks that involve Git worktrees

Example prompts

  • “/development-workflow”

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. Establish the intended behavior and affected surfaces before editing.
  2. Implement and validate the change using the applicable checks below.
  3. Read .github/PULL_REQUEST_TEMPLATE.md and create the PR with gh pr create --draft.
  4. Complete self-review, then self-review-round-two, fixing verified findings and validating affected behavior.
  5. Collect independent-review.
  6. Draft PRs run only the offline checks; gh pr ready starts the AWS jobs.

What it can do on your machine

Read from SKILL.md and the folder at commit 971dd12. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • just
    • gh
    • git
    • uv
    • mise

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • github.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Development Workflow loads about 2.1k tokens when it runs. Until then it costs about 62 tokens; SKILL.md has 1,065 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~62
When it runs · the whole SKILL.md, loaded when a task matches
~2.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteMentions a .env fileSKILL.md:24
    Keep credentials, `.env`, temporary scripts, and raw review artifacts outside tracked files.
  • NoteMentions a .env fileSKILL.md:61
    ust worktree-env` and `uv run --env-file .env pytest ...` to load the worktree environment without printing credentials.
  • NoteMentions a .env fileSKILL.md:62
    or a full recipe, use `uv run --env-file .env just test sqla` (or `sqla-async`); linking `.env` alone does not export it

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from pyathena-dev/PyAthena at commit 971dd12, republished under its MIT licence (© pyathena-dev). 1,065 words, ~2,053 tokens.

Download SKILL.mdSave it as .claude/skills/development-workflow/SKILL.md (or your agent's skills folder).
name
development-workflow
description
Deliver a PyAthena change through a dedicated worktree, Draft PR, two distinct self-reviews, independent review, and current CI once marked Ready. Use when implementing or updating a PR, not for a bounded review-only request.

PyAthena PR delivery

Read AGENTS.md for repository commands and conventions. User instructions determine scope and authorization; carry existing authorization forward without asking again. Keep unrelated worktrees and changes intact.

Prepare and publish

  1. Establish the intended behavior and affected surfaces before editing. Create one dedicated worktree per PR from the fetched origin/master, or from the agreed parent branch for a stacked PR.
  2. Implement and validate the change using the applicable checks below. Inspect the complete diff, changed paths, and deletions before committing and pushing. Keep credentials, .env, temporary scripts, and raw review artifacts outside tracked files.
  3. Read .github/PULL_REQUEST_TEMPLATE.md and create the PR with gh pr create --draft. Write WHAT and WHY around the final behavior and include validation and its limits. Pass multiline text through a temporary file with --body-file.
  4. Complete self-review, then self-review-round-two, fixing verified findings and validating affected behavior.
  5. Collect independent-review. Repairs pass through both self-review perspectives and an independent follow-up before completion.
  6. Draft PRs run only the offline checks; gh pr ready starts the AWS jobs. Before it, confirm the published head matches the reviewed head, the offline checks have completed successfully, and the PR has no merge conflict. After it, check the current PR with gh pr view and gh pr checks, and confirm all applicable checks have completed successfully. If an AWS job fails, return the PR to Draft with gh pr ready --undo until the failure is resolved. To obtain AWS results while the PR is still Draft, dispatch the Test workflow on its branch. Pending, cancelled, missing expected checks, and UNKNOWN mergeability do not establish readiness. Explain intentionally skipped jobs from workflow conditions; a passing rerun of one failed job does not make the remaining failures pass. Keep the PR Draft while required review or validation remains incomplete, unless the user explicitly changes that requirement. Merging requires the user's instruction.

Validate the affected behavior

Run just format and just lint before committing; lint precedes tests. Choose tests from the affected contracts and callers, and record the actual commands, results, and omissions. New behavior needs regression coverage that can fail for the original defect. Prefer existing fixtures and integration classes; do not build a parallel mock framework just to mirror the implementation.

Changed surfaceValidation to consider
Cursor, result set, converter, or shared utilityAffected tests/pyathena/ tests and relevant synchronous, asynchronous, and optional dependency backends
SQLAlchemy dialectRelevant PyAthena tests in tests/pyathena/sqlalchemy/ plus just test sqla; also tests/pyathena/aio/sqlalchemy/ and just test sqla-async for shared reflection or async paths. Both PyAthena directories are included in just test pyathena.
FilesystemAffected S3 filesystem tests, including listing and path boundaries
Documentationjust docs lint; just docs build for rendered documentation changes
Agent skillsjust docs lint and mise exec -- markdownlint-cli2 '.agents/skills/**/*.md'; inspect links and walk through realistic workflow scenarios
Dependency, packaging, or CI configurationAffected build/install checks and supported Python/dependency combinations from pyproject.toml, uv.lock, and CI

The tests/pyathena/ directory includes AWS integration tests despite the recipe's "unit tests" label. Before a live AWS run or CI retry, inspect active Test workflows with gh run list --workflow test.yaml and check known local test runs. Separate worktrees do not isolate AWS accounts, quotas, or shared test resources. When runs overlap, serialize live validation and use targeted -n 1 runs while iterating; complete the required suite coverage before Ready. Use just worktree-env and uv run --env-file .env pytest ... to load the worktree environment without printing credentials. For a full recipe, use uv run --env-file .env just test sqla (or sqla-async); linking .env alone does not export its variables to just. Do not cancel someone else's run or increase retry limits merely to obtain green CI. After a failure, identify the failing API, error, retry layer, and run before deciding whether a retry is informative. Markdown-only changes need no live AWS tests; inspect the actual workflow path filters when interpreting absent jobs.

Show full SKILL.md (419 more words)Show less

Freeze review scope and preserve evidence

For each round, obtain the PR's actual base branch and published head with gh pr view --json baseRefName,headRefOid. Fetch the relevant refs, confirm local HEAD matches the published head, and resolve git merge-base <head> <fetched-base-branch-tip> once. In review commands and records, <base> means that merge-base SHA, not the current base-branch tip. Use literal full merge-base and head SHAs in git diff <base>..<head> and in the record. For a stacked PR, this base comes from its parent branch, not master. Inventory every changed file and the behavior, public contract, tests, and factual claims that need checking.

Each round's initial pass covers the full inventory. After that round has completed, a narrow repair may use git range-diff <old-base>..<old-head> <new-base>..<new-head> and trace the changed hunks into affected callers, tests, and claims. Verify both old objects with git cat-file -e <sha>^{commit} first; missing objects or expanded contracts require a full pass. A round-one repair does not narrow round two's first pass. After rebasing, inspect upstream changes that affect those contracts even if the patch series is unchanged; rerun affected checks and obtain current CI. Do not substitute a tree diff between rebased heads or reset a branch to a moving base to squash it. When rewriting a published branch is necessary, verify the expected remote head and use an explicit --force-with-lease=<ref>:<expected-sha>.

Record each round separately: perspective, full base/head SHAs, covered surfaces, CLEAN or FINDINGS, concrete scenarios with file:line, repairs, and reasoned deferrals. CLEAN means no actionable findings within the stated scope, not that unrun tests passed. Publish review records as inline comments on relevant diff lines through gh api repos/OWNER/REPO/pulls/NUMBER/reviews, using a comments array and an empty review body. Use event: COMMENT, not approval of your own PR, and store the JSON request in a temporary file passed with --input. For a clean round, anchor its evidence to a relevant changed line. Record a repair in its existing thread using POST repos/OWNER/REPO/pulls/NUMBER/comments/COMMENT_ID/replies with a body field; COMMENT_ID must identify the thread's top-level comment, which has no in_reply_to_id. Replies do not use the review request's comments array, and GitHub does not support replying to another reply. For a finding outside the diff, anchor to the related changed line and name the actual file:line in the comment; GitHub rejects line anchors outside the diff. If the user's review-only scope prohibits posting, keep the result in the response instead.

This workflow takes its review sequence and scope tracking from the flink-connector-gcp skills at aad72cd8, with PyAthena-specific review and validation guidance.

© pyathena-dev, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/development-workflow of pyathena-dev/PyAthena.

Open the folder on GitHubat commit 971dd12

Compare with similar skills

Development Workflow next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Development Workflow compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Development Workflow this skillpyathena-dev/PyAthena493—~2.1kAutomated safety check: NotesMIT
Burla Parallel Dev ClustersBurla-Cloud/burla263—~1.6kAutomated safety check: PassCustom licence
Work Issuesgo-to-k/cdkd143—~1.7kAutomated safety check: PassApache-2.0
Finishing a Development Branchobra/superpowers296k5 repos~1.9kAutomated safety check: PassMIT
Migrate Core Code to Submodulestinyhumansai/openhuman42k—~2.6kAutomated safety check: PassGPL-3.0
Finishing A Development Branchfarm-fe/farm5.6k34 repos~1.8kAutomated safety check: PassMIT

Similar skills

  • Burla Parallel Dev Clusters

    Burla-Cloud/burla

    Sets up an isolated Burla dev cluster per git worktree so several agents can work in parallel, and explains when to use local-dev or remote-dev.

    263 GitHub stars~1.6k tokensUpdated 15 days ago
    DevelopmentAuto-check passed

  • Work Issues

    go-to-k/cdkd

    Work through already-filed GitHub issues (typically the bug-hunt's output) end to end — triage safely, pick as many FILE-DISJOINT issues as the run can carry, claim each on the issue before starting…

    143 GitHub stars~1.7k tokensUpdated today
    DevelopmentAuto-check passed

  • Finishing a Development Branch

    obra/superpowers

    Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.

    296k GitHub starsUsed in 5 repos~1.9k tokens
    DevelopmentAuto-check passed

  • Migrate Core Code to Submodules

    tinyhumansai/openhuman

    Plans and carries out moving non-host-specific code and its tests from the OpenHuman core into vendored tiny submodule libraries, then releases the submodule and re-pins the host.

    42k GitHub stars~2.6k tokensUpdated today
    DevelopmentAuto-check passed

  • Finishing A Development Branch

    farm-fe/farm

    A skill your agent uses when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for…

    5.6k GitHub starsUsed in 34 repos~1.8k tokens
    DevelopmentAuto-check passed

  • Git Worktree Cleanup

    lobehub/lobehub

    Audits stale Git worktrees and branches with a bundled script, classifies each one, and deletes only after you approve the exact candidates.

    83k GitHub stars~2.8k tokensUpdated today
    DevelopmentAuto-check passed

More from pyathena-dev/PyAthena

  • Self Review

    pyathena-dev/PyAthena

    Run the first PyAthena self-review after creating a Draft PR, checking implementation behavior, public contracts, simplicity, and regression coverage.

    493 GitHub stars~740 tokensUpdated yesterday
    Auto-check passed

  • Independent Review

    pyathena-dev/PyAthena

    Obtain and collect an independent read-only review of a PyAthena PR after both self-review rounds, with a frozen diff and recorded findings before Ready.

    493 GitHub stars~996 tokensUpdated yesterday
    Auto-check: notes

  • Self Review Round Two

    pyathena-dev/PyAthena

    Run the second PyAthena self-review after round one, auditing factual claims, caller compatibility, AWS operational effects, and evidence from a user's perspective before Ready.

    493 GitHub stars~820 tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Development Workflow

What does Development Workflow do?

Deliver a PyAthena change through a dedicated worktree, Draft PR, two distinct self-reviews, independent review, and current CI once marked Ready. Development Workflow is an agent skill from pyathena-dev/PyAthena. Deliver a PyAthena change through a dedicated worktree, Draft PR, two distinct self-reviews, independent review, and current CI once marked Ready.

When should I use Development Workflow?

Development Workflow fits situations like: not for a bounded review-only request; tasks that involve Git worktrees.

How do I install Development Workflow in Claude Code?

Run `npx skills add pyathena-dev/PyAthena --skill development-workflow -a claude-code`. Or copy the skill folder (.agents/skills/development-workflow in pyathena-dev/PyAthena) into .claude/skills/development-workflow in your project. Claude Code loads it when a task matches its description.

How do I install Development Workflow in Codex?

Run `npx skills add pyathena-dev/PyAthena --skill development-workflow -a codex`. Or copy the skill folder (.agents/skills/development-workflow in pyathena-dev/PyAthena) into .agents/skills/development-workflow in your project. Codex loads it when a task matches its description.

Can I use Development Workflow in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add pyathena-dev/PyAthena --skill development-workflow -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/development-workflow, .gemini/skills/development-workflow, .github/skills/development-workflow and .opencode/skills/development-workflow in your project.

What does Development Workflow need to run?

Going by SKILL.md and its folder, Development Workflow needs the command-line tools its instructions call (just, gh, git, uv and mise).

Does Development Workflow access the network?

SKILL.md names 1 domain. As links in the text: github.com. This is read from the text; nothing was executed.

Is Development Workflow safe to install?

Our automated static check of SKILL.md found notes only (mentions a .env file), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Development Workflow use?

Development Workflow is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Development Workflow use?

About 2.1k tokens (SKILL.md is roughly 8.2k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Development Workflow?

Skills that share tags, products or a category with Development Workflow: Burla Parallel Dev Clusters (Burla-Cloud/burla, 263 stars), Work Issues (go-to-k/cdkd, 143 stars), Finishing a Development Branch (obra/superpowers, 296k stars) and Migrate Core Code to Submodules (tinyhumansai/openhuman, 42k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Development Workflow?

pyathena-dev (a GitHub organization) maintains it in pyathena-dev/PyAthena, which has 493 GitHub stars. The repository holds 4 skills in this directory. The repository was last updated on October 7, 2026.

Source: pyathena-dev/PyAthena on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.