본문으로 건너뛰기
cccskills
무료GitHub에 공개

cw-land

Land verified Codewhale changes on main with focused commits and checks before pushing. Handle contributor pull requests, resolve conflicts, preserve authorship credit, and confirm required review evidence before merging.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

Use when turning verified Codewhale work into commits on main and pushing them, or merging a contributor PR: staging only your paths, the pre-push drift checks, preserving contributor credit, and honoring the gate artifact before merging.

설치 방법 보기

이럴 때 유용합니다

  • Commit and push verified changes in a shared checkout
  • Resolve contributor pull request conflicts and preserve credit
  • Confirm required approval evidence before merging a pull request

포함된 파일(1)

  • SKILL.md6.9 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

cw-land

Verified work still has to land without stepping on other writers, losing contributor credit, or merging past a gate that has not actually passed. This stage is about the boundary between "it works" and "it is in main" — and about which of those steps you are allowed to take.

Stage 5 of the loop: cw-orient → cw-slice → cw-gates → cw-dogfood → land → cw-handoff.

When to use

  • The change is verified and needs to become a commit on main.
  • You are landing someone else's PR, harvesting a contributor's work, or resolving a conflict caused by main moving.
  • You are about to merge something behind a required gate.

Workflow

  1. Land on the canonical checkout's main. AGENTS.md owns this: no maintainer PR branches, worktrees, nested clones or integration lanes. Several agents share the checkout, so partition by file, check git status before staging, stage only your paths (never git add -A), and retry a commit that fails on index.lock. Push verified main directly; hosted CI runs there. PRs are for contributors.

  2. Commit narrow and build-green. One coherent change per commit; the tree builds at every commit. Put the real verification in the message — actual pass/fail counts, not "tests pass".

    Before every push, run the cheap drift checks that have turned a green main red most often. They take seconds:

    cargo fmt --all -- --check
    sh scripts/sync-changelog.sh --check        # after any CHANGELOG.md edit
    bash scripts/release/check-versions.sh
    python3 scripts/check-runtime-contract-budget.py
    

    Add the one that matches what you touched: check-tui-locale-parity.py and check-tui-product-vocabulary.sh (locale strings), check-dead-code-budget.py (#[allow(dead_code)]), check-blocking-calls-budget.py (async code), check-readme-translations.py and check-readme-locales.sh (READMEs), node web/scripts/derive-facts.mjs && node web/scripts/check-facts.mjs (public facts). Put a new CHANGELOG entry at the top of [Unreleased]. Open contributor PRs append at its end, and an entry of ours there conflicts with every one of them.

  3. Preserve credit mechanically, not just politely. Commit authorship and Co-authored-by: trailers must use the contributor's own GitHub-linked address — GitHub reads neither .github/AUTHOR_MAP nor .mailmap for the contribution graph; those are project conventions on top. When a contributor's work lands as our commit, it carries both:

    Harvested from PR #N by @handle
    
    Co-authored-by: Name <github-linked-email>
    

    That trailer is what lets auto-close-harvested.yml close their PR with credit. Canonical human identities live in .github/AUTHOR_MAP.

    Whether a bot or agent also appears in a trailer no longer matters — the CI check that policed trailer identities was removed because it rejected ordinary agent commits. Give humans their credit; don't spend time scrubbing tool trailers.

  4. Landing someone else's work: their time is more expensive than ours.

    • Never make a contributor rebase around our churn. If their PR conflicts only because main moved, a maintainer resolves it.
    • Read their diff against the merge base first, so you know exactly what they added, then re-apply that — rather than hand-merging two large sides and hoping:
      git diff $(git merge-base main <pr-head>)..<pr-head>
      
    • Conflicts that split mid-function do not resolve by keeping both sides. Git's markers can land inside a body, so a both-sides resolution produces unbalanced braces that look plausible and do not compile. Default: take one side whole, then re-insert the other side's additions at their original anchor; when the conflict doesn't fit that pattern, resolve it however is correct and let the compiler judge.
    • Resolve on their branch without creating a local branch. Build the merge commit with git merge-tree --write-tree origin/main <pr-head> and git commit-tree <tree> -p <pr-head> -p origin/main, then push it with git push <fork-url> "${sha}:refs/heads/<their-branch>". In zsh, write ${sha}, not $sha:refs, because :r is a history modifier. maintainerCanModify does not guarantee that the push is accepted. When the fork refuses it, ask on the PR. Harvesting is the last resort.
    • Check the contribution gate before assuming a PR is stalled. An unlisted author's workflow runs sit at action_required and never start, so the PR looks abandoned when nobody has actually looked at it. Approve the runs, then fix the cause: add them to .github/APPROVED_CONTRIBUTORS (all:username), or comment /lgtm (PR scope) or /lgtmi (issue scope).
  5. Verify mergeability against the real head. A PR that is clean against main can still conflict with a release branch:

    git merge-tree $(git merge-base <base> <pr-head>) <base> <pr-head>
    
  6. Merging under a gate. AGENTS.md ("Merging under a gate") owns this: the artifact must literally say PASS, the review thread outranks the check rollup, and ambiguity blocks the merge — never the reverse. Before you merge, list the open PRs whose base is the PR's source branch (gh pr list --base <branch>) and retarget them first. Otherwise they close when that branch goes away.

Red flags / don't

  • Don't tag, create a release, publish, or deploy without explicit authorization. Pushing verified main is allowed; it is none of those.
  • Don't rewrite published history, retag a release, or force-push a shared ref.
  • Don't commit AGENTS.md / CLAUDE.md operator controls that live outside the product repository into a public repo.
  • Don't stage another writer's dirty files to get a clean commit.
  • Don't merge on a green rollup alone when a review thread has open findings.
  • Don't harvest or close from a PR title or label — review the code, tests, comments, and checks.
  • Don't add another legacy call site for convenience once a replacement architecture is adopted. Declared migrations are one-way.
  • Don't leave new enforcement live: keep it dry-run/advisory unless approved.

Output

  • Commit SHAs, the paths committed, the drift checks run, and the resulting origin/main SHA.
  • The credit trailers applied and to whom.
  • The gate artifact's literal verdict at merge time, if a gate applies.
  • Exactly which public actions you took, and which you deliberately did not.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

batch

무료

Split a large goal into clearly bounded tasks that can run in parallel. Coordinate existing agent and worktree tools, then combine and verify the results. The skill starts only when explicitly requested.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Splitting a large goal into parallel tasks
  • Coordinating work across multiple agents
  • Running tasks in separate worktrees
codewhale-hq/Codewhale4.1만2026년 10월 19일 업데이트

best-of-n

무료

Generate independent options for design, implementation, explanations, or debugging, then compare them using one shared rubric. Code candidates use separate working copies and undergo independent verification before a winner is presented for review.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Comparing several plausible design approaches
  • Evaluating independent implementations of the same task
  • Comparing explanations or debugging approaches
codewhale-hq/Codewhale4.1만2026년 10월 19일 업데이트

Check Codewhale release readiness through ordered tests, builds, version checks, and manual terminal checks. Record command results and observed behavior, including responsiveness, route isolation, and follow-up input handling, while explicitly identifying any skipped checks.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Run automated checks on the actual release branch
  • Check whether a PR merges into the release branch
  • Manually test terminal responsiveness and input behavior
codewhale-hq/Codewhale4.1만2026년 10월 19일 업데이트

Operate desktop apps and isolated browsers on registered computers by inspecting interface controls, entering information, and checking results. The skill also covers screenshots and recording, with separate routing for the user's signed-in Chrome through Chromewhale.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Entering information through a desktop app interface
  • Working in an isolated browser session
  • Capturing screenshots or recordings for a task
codewhale-hq/Codewhale4.1만2026년 10월 19일 업데이트

Check a local Codewhale checkout before contributing: inspect branch and sync status, build the CLI, and run the repository’s CI checks. Present recent commits and changelog entries from local files, with clear status for each step.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Checking a checkout before contributing
  • Reviewing local changes and sync status
  • Running the build and CI verification commands
codewhale-hq/Codewhale4.1만2026년 10월 19일 업데이트

Builds and installs Codewhale with a source revision identifier, then verifies the installed version in a fresh shell. It guides hands-on runtime checks for interface behavior, routing, approvals, and other changes that automated tests may miss.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Verifying terminal interface changes in the actual product
  • Installing and checking a local release build
  • Checking model routing and approval behavior
codewhale-hq/Codewhale4.1만2026년 10월 19일 업데이트

codewhale-hq의 스킬 모두 보기

이 스킬의 문제 신고