Skip to content
cccskills
FreePublished on 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.

OriginalShow the original description

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.

See how to install

Good for

  • 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

Files included (1)

  • SKILL.md6.9 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

batch

FreeSummary

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/Codewhale41.1KUpdated Oct 19, 2026

best-of-n

FreeSummary

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/Codewhale41.1KUpdated Oct 19, 2026

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/Codewhale41.1KUpdated Oct 19, 2026

computer-use

FreeSummary

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/Codewhale41.1KUpdated Oct 19, 2026

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/Codewhale41.1KUpdated Oct 19, 2026

cw-dogfood

FreeSummary

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/Codewhale41.1KUpdated Oct 19, 2026

See all skills by codewhale-hq

Report a problem with this skill