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

Cdk Contribution Skill

by cdklabs in cdklabs/cdk-contribution-skill

Guide AWS CDK contributions from GitHub issue analysis to PR-ready code.

Apache-2.0Auto-check passedDevelopment

Install Cdk Contribution Skill

skills CLI
$ npx skills add cdklabs/cdk-contribution-skill --skill cdk-contribution-skill -a claude-code

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

GitHub CLI
$ gh skill install cdklabs/cdk-contribution-skill cdk-contribution-skill --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/cdklabs/cdk-contribution-skill.git skills-src && mkdir -p .claude/skills && cp -r skills-src/cdk-contribution-skill .claude/skills/cdk-contribution-skill && 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
cdk-contribution-skill
GitHub stars
110
Token cost
~4.6k tokens
SKILL.md length
1,347 words
Files
12 (incl. references)
Skills in repo
1
Repo updated
First seen
Licence
Apache-2.0

At a glance

Guide AWS CDK contributions from GitHub issue analysis to PR-ready code.

  • Works in 4 steps: Build & Implementation → Parallel Validation → Self Review → …
  • Contributing to aws-cdk repository
  • SKILL.md covers MANDATORY: Present Workflow…, Reference Files, Deliverables and Phase Execution Instructions, plus 2 more sections
  • Calls gh

What it does

Cdk Contribution Skill is an agent skill from cdklabs/cdk-contribution-skill. Guide AWS CDK contributions from GitHub issue analysis to PR-ready code. Use when contributing to aws-cdk repository, analyzing CDK issues, implementing fixes, or preparing pull requests.

Its SKILL.md is about 4.6k tokens, which your agent loads only when the skill is triggered. The skill folder holds 12 other files, including reference files (for example `references/build-engineer-sop.md`, `references/debug-ci.md` and `references/documentation-specialist-sop.md`).

It sits in Development, covering Pull requests. It works with Amazon Web Services and GitHub. The licence is Apache-2.0.

When your agent uses it

  • Contributing to aws-cdk repository
  • Analyzing CDK issues
  • Implementing fixes
  • Preparing pull requests

Example prompts

  • “/cdk-contribution-skill”

Workflow steps

4 steps, taken from the step headings in SKILL.md.

  1. Build & Implementation
  2. Parallel Validation
  3. Self Review
  4. PR Submission

What it can do on your machine

Read from SKILL.md and the folder at commit 1740bd4. 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:

    • gh

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

  • Network

    No URLs in SKILL.md. Its commands use gh, which can reach the network depending on how they are called.

    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

Cdk Contribution Skill loads about 4.6k tokens when it runs, and up to ~32k if it reads all its reference files. Until then it costs about 53 tokens; SKILL.md has 1,347 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~53
When it runs · the whole SKILL.md, loaded when a task matches
~4.6k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~32k

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 passed

The automated check found no risky patterns in SKILL.md.

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 cdklabs/cdk-contribution-skill at commit 1740bd4, republished under its Apache-2.0 licence (© cdklabs). 1,347 words, ~4,573 tokens.

Download SKILL.mdSave it as .claude/skills/cdk-contribution-skill/SKILL.md (or your agent's skills folder). This skill also uses 11 other files; get the full folder from GitHub.
name
cdk-contribution-skill
description
Guide AWS CDK contributions from GitHub issue analysis to PR-ready code. Use when contributing to aws-cdk repository, analyzing CDK issues, implementing fixes, or preparing pull requests.

CDK Contribution Workflow

Orchestrates specialized phases for AWS CDK contributions with human approval gates.

MANDATORY: Present Workflow Overview FIRST

BEFORE doing ANY work, you MUST present the ASCII workflow diagram below, explain the process, and wait for confirmation — because the user needs visibility into the multi-phase process and an opportunity to opt out before any work begins.

Display this to the user:

text
CDK Contribution Workflow for Issue #<NUMBER>

I'll guide you through a structured process with human approval gates:

+------------------------------------------+
|           MAIN ORCHESTRATOR              |
|         (Me - Coordinates work)          |
+--------------------+---------------------+
                     |
     +---------------+--------------+
     |       PHASE 1: ANALYSIS      |
     +---------------+--------------+
                     |
                     v
     +-------------------------------+
     |        ISSUE ANALYST          |
     |  Analyze issue, classify      |
     |  type, explore code           |
     +---------------+---------------+
                     |
     +---------------+--------------+
     |       PHASE 2: PLANNING      |
     +---------------+--------------+
                     |
                     v
     +-------------------------------+
     |      SOLUTION ARCHITECT       |
     |  Propose solution, tests,     |
     |  and impl approach            |
     +---------------+---------------+
                     |
                     v
     +-------------------------------+
     |      YOUR APPROVAL            |
     |  Issue at a glance (ASCII)    |
     |  Proposed solution (ASCII)    |
     |  Unit + integ test plan       |
     |                               |
     |  Continue? Yes | No |         |
     |             Something Else    |
     +---------------+---------------+
               [YES] |
     +---------------+--------------+
     |    PHASE 3: BUILD & IMPL     |
     +---------------+--------------+
                     |
                     v
     +-------------------------------+
     |   BUILD SETUP + IMPLEMENT     |
     |   Branch, env, write code     |
     +---------------+---------------+
                     |
     +---------------+--------------+
     |   PHASE 4: PARALLEL VALID    |
     +-------+-------+-------+------+
             |       |       |
             v       v       v
         +------+ +-----+ +------+
         | TEST | |  QA | | DOCS |
         +--+---+ +--+--+ +--+---+
            +-------+-------+
                    |
     +--------------+--------------+
     |     PHASE 5: SELF REVIEW    |
     +-------+---------------------+
             |             |
             v             v
     +------------+  +------------+
     |  SECURITY  |  | REGRESSION |
     |   REVIEW   |  |   REVIEW   |
     +------+-----+  +-----+------+
            +----------+---+
                       |
                       v
            +--------------------+
            |    SYNTHESIZE      |
            |   REVIEW REPORT    |
            +--------+-----------+
                     |
                     v
     +-------------------------------+
     |       REVIEW FINDINGS         |
     |   Submit PR or fix issues     |
     +-------------------------------+

Key Points:
- Phase 1 (Analysis) runs first, then Phase 2 (Planning) runs after — sequential, not parallel
- You review and approve the plan before any code is written
- I pause for your input at critical decision points

Should we start? Yes | No

STOP and wait for user response. You MUST NOT proceed until the user confirms — because the user needs to understand the full workflow scope before committing to it.

Reference Files

CRITICAL: The reference files in the references/ folder define the exact structure and content of each deliverable per phase. You MUST read the relevant reference file BEFORE executing each phase:

SOPPhasePurpose
issue-analyst-sop.md1 – AnalysisIssue analysis and classification
solution-architect-sop.md2 – PlanningSolution design and planning
build-engineer-sop.md3 – Build & ImplBuild environment setup
implementation-specialist-sop.md3 – Build & ImplCode implementation
test-engineer-sop.md4 – ValidationUnit and integration testing
quality-assurance-sop.md4 – ValidationLint, build, and quality checks
documentation-specialist-sop.md4 – ValidationREADME and docs updates
security-reviewer-sop.md5 – Self ReviewSecurity review
regression-reviewer-sop.md5 – Self ReviewRegression review
review-report-generator-sop.md5 – Self ReviewFinal review report synthesis

Supplementary references: debug-ci.md (use when debugging GitHub Actions CI failures)

Refer to the Quick Reference — Commands table in AGENTS.md at the aws-cdk repo root for exact commands.

Deliverables

Each phase MUST write its output to markdown files under .contributions/<ISSUE_NUMBER>/:

PhaseOutput file
Phase 1.contributions/<ISSUE_NUMBER>/01-analysis.md
Phase 2.contributions/<ISSUE_NUMBER>/02-solution.md
Phase 3.contributions/<ISSUE_NUMBER>/03-build.md
Phase 4.contributions/<ISSUE_NUMBER>/test-results.md
Phase 4.contributions/<ISSUE_NUMBER>/quality-validation.md
Phase 4.contributions/<ISSUE_NUMBER>/pr.md
Phase 4.contributions/<ISSUE_NUMBER>/04-validation.md
Phase 5.contributions/<ISSUE_NUMBER>/security-review.md
Phase 5.contributions/<ISSUE_NUMBER>/regression-review.md
Phase 5.contributions/<ISSUE_NUMBER>/05-review.md

Each phase is responsible for writing its own deliverable file(s) before completing. The orchestrator reads the file as the handoff input to the next phase.

Deliverable ASCII Diagram Requirement

Every deliverable markdown file MUST include at least one ASCII diagram that visually summarises the key findings or structure of that phase. Examples by phase:

  • Phase 1: module/file dependency map or issue impact diagram
  • Phase 2: solution architecture diagram showing files to change and their relationships
  • Phase 3: branch/build setup flow
  • Phase 4: test coverage map (unit vs integ, pass/fail)
  • Phase 5: review findings summary (security + regression side by side)

Use plain ASCII box-and-arrow style. No emoji. Example:

text
  +----------------+       +------------------+
  |  affected.ts   | ----> |  test/foo.test.ts |
  +----------------+       +------------------+
         |
         v
  +----------------+
  |  features.ts   |  (new feature flag)
  +----------------+

Phase Execution Instructions

When user says "Yes" to start:

IMPORTANT: Phase 1 and Phase 2 are SEQUENTIAL — Phase 2 depends on Phase 1's output. You MUST NOT run them in parallel — because Phase 2 requires the analysis deliverable from Phase 1.

Step A — Execute Phase 1 (Issue Analysis):

MANDATORY PRE-READ: Before executing this phase, you MUST read the instructions in references/issue-analyst-sop.md Do NOT proceed until you have read the file and understand the required deliverables.

Analyze the GitHub issue at <ISSUE_URL>.

To fetch issue data, use the following priority order:

  1. PRIMARY - gh CLI (preferred):

    • gh issue view <NUMBER> --repo aws/aws-cdk --json number,title,body,labels,comments,state
    • gh issue view <NUMBER> --repo aws/aws-cdk --comments for full comment thread
    • gh pr list --repo aws/aws-cdk --search "<issue number>" --json number,title,url for linked PRs

  2. FALLBACK - GitHub MCP server (only if gh CLI is unavailable or fails):

    • Use GitHub MCP tools with perPage: 3 to avoid token overflow

Then explore the aws-cdk codebase to understand the affected module(s), existing patterns, test conventions, and any related code. Classify the issue type (bug, feature, docs, etc.). Produce a structured analysis: issue summary, affected files/modules, root cause or gap, relevant CDK patterns observed, and any constraints or risks.

Write your full analysis to .contributions/<ISSUE_NUMBER>/01-analysis.md before returning.

Step B — WAIT for Phase 1 to complete, then read its output:

Read .contributions/<ISSUE_NUMBER>/01-analysis.md to confirm it was written successfully.

Step C — Only AFTER Phase 1 is complete, execute Phase 2 (Solution Planning):

Pass the content of 01-analysis.md as context to Phase 2:

MANDATORY PRE-READ: Before executing this phase, you MUST read the instructions in references/solution-architect-sop.md Do NOT proceed until you have read the file and understand the required deliverables.

Using the analysis provided in the context, propose a concrete solution for the CDK contribution. Include: the implementation approach, which files need to change and how, required unit tests (what to test and why), required integ tests (which integ test file, what scenario to cover), and any breaking change considerations. Be specific about CDK patterns to follow.

Write your full proposal to .contributions/<ISSUE_NUMBER>/02-solution.md before returning.

You MUST NOT ask the user for input between Phase 1 and Phase 2 — because the analysis-to-planning handoff is fully automated and interrupting it adds no value.

After both phases complete, present this proposal to the user:
ISSUE AT A GLANCE
=================

Issue:   #<NUMBER> - <TITLE>
Type:    <bug | feature | docs | ...>
Module:  <e.g. aws-lambda, aws-s3, ...>
Impact:  <one line>

Affected files:
  - <file 1>
  - <file 2>
  - ...

Root cause / gap:
  <2-3 sentence summary>

Constraints / risks:
  - <item>
  - ...


PROPOSED SOLUTION
=================

Approach:
  <concise description of the fix or feature>

Files to change:
  +---------------------------+----------------------------------+
  | File                      | Change                           |
  +---------------------------+----------------------------------+
  | <path/to/file.ts>         | <what changes>                   |
  | <path/to/other.ts>        | <what changes>                   |
  +---------------------------+----------------------------------+

Unit tests:
  File: <test file path>
  +------------------------------------------+
  | Test case                                |
  +------------------------------------------+
  | <describe what is tested>                |
  | <describe what is tested>                |
  +------------------------------------------+

Integ tests:
  File: <integ test file path>
  Scenario: <what the integ test exercises>
  Snapshot update required: Yes | No

Breaking changes: Yes | No
  <if yes, explain>


Continue with this plan? Yes | No | Something Else

Phases 3-5 (after plan approval)

Show full SKILL.md (591 more words)Show less
Phase 3: Build & Implementation

STEP 0 — READ SOPs (non-negotiable, do this FIRST):

You MUST read BOTH of these files before ANY other action in this phase:

  1. references/build-engineer-sop.md - provides instructions for the build phase
  2. references/implementation-specialist-sop.md - provides instructions for the implementation phase

After reading, confirm you understand the required deliverables and procedures.

STEP 1

Before doing anything, present this summary to the user:

text
PHASE 3: BUILD & IMPLEMENTATION
================================

Here's what I'm about to do:

  1. Create local branch   fix/issue-<NUMBER>-<slug>
  2. Sync with upstream    fetch and rebase onto upstream/main
  3. Assess build need     read 02-solution.md to decide if build is required
  4. Implement             apply all changes from the approved plan

Kicking off now...

Then proceed immediately without waiting for a response.

Steps (in order, no skipping) — see references/build-engineer-sop.md for exact commands:

  1. Create a local PR branch named fix/issue-<NUMBER>-<short-description> from current HEAD
  2. Sync with upstream main (add upstream remote if missing, then fetch and rebase)
  3. Assess whether a build is required:
    • Read 02-solution.md — if changes touch generated code, L1 constructs, or cross-package imports that require compilation, build the affected package(s)
    • If changes are purely in .ts source + tests with no codegen dependency, skip the build and go straight to implementation
    • Document the decision in 03-build.md
  4. Implement all changes from the approved plan in 02-solution.md.
  5. Write deliverable to .contributions/<ISSUE_NUMBER>/03-build.md (with ASCII diagram)
Phase 4: Parallel Validation

STEP 0 — READ SOPs (non-negotiable, do this FIRST):

You MUST read ALL THREE of these files before ANY other action in this phase:

  1. references/test-engineer-sop.md - provides instructions for the testing task. Required deliverable: test-results.md.
  2. references/quality-assurance-sop.md - provides instructions for the QA task. Required deliverable: quality-validation.md
  3. references/documentation-specialist-sop.md - provides instructions for the documentation task. Required deliverable: pr.md

After reading, confirm you understand the required deliverables and procedures.

STEP 1

Before doing anything, present this summary to the user:

text
PHASE 4: PARALLEL VALIDATION
==============================

Here's what I'm about to do (all three run in parallel):

  +---------------------+   +------------------+   +------+
  |        TEST         |   |        QA        |   | DOCS |
  +---------------------+   +------------------+   +------+
  | - Run unit tests    |   | - Lint with fix  |   | Check|
  |   for affected pkgs |   | - Build affected |   | README|
  | - Verify integ test |   |   packages       |   | needs|
  |   files exist and   |   |                  |   | update|
  |   are well-formed   |   |                  |   |      |
  | - Dry-run integ     |   |                  |   |      |
  |   snapshot check    |   |                  |   |      |
  +---------------------+   +------------------+   +------+
        |                  |                  |
        +------------------+------------------+
                           |
                    04-validation.md

Kicking off now...

Then proceed immediately without waiting for a response.

Run all three tasks in parallel. You MUST NOT wait for one to finish before starting the next — because they are independent and running them concurrently reduces wall-clock time.

  • TEST task (see references/test-engineer-sop.md for exact commands):
    • Run unit tests for all affected packages
    • Integ tests:
      1. Check if new or updated integ test files exist (compare against 02-solution.md plan)
      2. If YES — deploy and regenerate snapshots on those files
      3. If NO — run integ on the relevant module to confirm existing snapshots are intact
  • QA checks (see references/quality-assurance-sop.md for lint and build commands)
  • Documentation updates

When all three tasks have succeeded, summarize the testing, QA and documentation details in .contributions/<ISSUE_NUMBER>/04-validation.md.

Phase 5: Self Review

STEP 0 — READ SOPs (non-negotiable, do this FIRST):

You MUST read ALL THREE of these files before ANY other action in this phase:

  1. references/security-reviewer-sop.md - provides instructions for the security review task. Required deliverable: security-review.md.
  2. references/regression-reviewer-sop.md - provides instructions for the regression review task. Required deliverable: regression-review.md
  3. references/review-report-generator-sop.md - provides instructions for creating the final review report. Required deliverable: 05-review.md

After reading, confirm you understand the required deliverables and procedures.

STEP 1

Before doing anything, present this summary to the user:

text
PHASE 5: SELF REVIEW
=====================

Here's what I'm about to do (both run in parallel):

  +------------------+     +------------------+
  |    SECURITY      |     |   REGRESSION     |
  |     REVIEW       |     |     REVIEW       |
  +------------------+     +------------------+
  | - IAM/policy     |     | - Snapshot diff  |
  |   impact check   |     | - API surface    |
  |   check          |     |   breaking change|
  | - Secrets/creds  |     | - Existing test  |
  |   exposure check |     |   coverage gaps  |
  | - CDK nag rules  |     | - CloudFormation |
  +------------------+     |   drift risk     |
           |               +------------------+
           +--------+--------+
                    |
             05-review.md
                    |
                    v
          SYNTHESIZE GO/NO-GO

Kicking off now...

Then proceed immediately without waiting for a response.

Run both tasks in parallel. You MUST NOT wait for one to finish before starting the next — because security and regression reviews are independent analyses.

Synthesize findings into a go/no-go report in .contributions/<ISSUE_NUMBER>/05-review.md and present to user before PR submission.

Phase 6: PR Submission

After the user approves the go/no-go report, commit and create the PR.

MANDATORY: Every PR description body MUST end with this marker line:

[comment]: <> (by cdk-contribution-skill)

This is a hidden Markdown comment that identifies PRs created via this workflow. It MUST be the last line of the PR body. Do NOT omit it.

Prerequisites

  • Local clone of aws-cdk repository
  • Node.js v18+, Yarn
  • gh CLI (preferred for issue analysis) — gh auth login must be completed
  • GitHub MCP server (fallback if gh CLI is unavailable)

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

Files

SKILL.md and 11 other files (references) in cdk-contribution-skill of cdklabs/cdk-contribution-skill.

  • SKILL.md
  • references/build-engineer-sop.md
  • references/debug-ci.md
  • references/documentation-specialist-sop.md
  • references/implementation-specialist-sop.md
  • references/issue-analyst-sop.md
  • references/quality-assurance-sop.md
  • references/regression-reviewer-sop.md
  • references/review-report-generator-sop.md
  • references/security-reviewer-sop.md
  • references/solution-architect-sop.md
  • references/test-engineer-sop.md

Open the folder on GitHubat commit 1740bd4

Compare with similar skills

Cdk Contribution Skill 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.

Cdk Contribution Skill compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Cdk Contribution Skill this skillcdklabs/cdk-contribution-skill110—~4.6kAutomated safety check: PassApache-2.0
Create PRgo-to-k/cdkd143—~873Automated safety check: PassApache-2.0
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Check PRonyx-dot-app/onyx32k2 repos~2.3kAutomated safety check: PassMIT
Contributor-First PR MergeHKUDS/OpenHarness16k1 repos~847Automated safety check: PassMIT
Create Pull Requestcline/cline70k1 repos~1.6kAutomated safety check: PassApache-2.0

Similar skills

  • Create PR

    go-to-k/cdkd

    Run /verify-pr checks, then create a GitHub PR if all pass. An agent skill from go-to-k/cdkd.

    143 GitHub stars~873 tokensUpdated today
    DevelopmentAuto-check passed

  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed

  • Check PR

    onyx-dot-app/onyx

    Checks a GitHub, GitLab, or Perforce (p4) pull request (or merge request, or shelved changelist) for unresolved review comments, failing status checks, and incomplete PR descriptions.

    32k GitHub starsUsed in 2 repos~2.3k tokens
    DevelopmentAuto-check passed

  • Contributor-First PR Merge

    HKUDS/OpenHarness

    Merges external GitHub pull requests while keeping the original author credited, and fixes conflicts after the merge instead of rewriting the contribution.

    16k GitHub starsUsed in 1 repo~847 tokens
    DevelopmentAuto-check passed

  • Create Pull Request

    cline/cline

    Opens a GitHub pull request from your current branch with the gh CLI, after reviewing the commits and diff and gathering the details the PR needs.

    70k GitHub starsUsed in 1 repo~1.6k tokens
    DevelopmentAuto-check passed

  • Pull Request Title and Body Writer

    openinterpreter/openinterpreter

    Rewrites the title and body of one or more pull requests with gh, leading with why the change was made, then what changed, and describing only the net result.

    69k GitHub starsUsed in 2 repos~1.1k tokens
    DevelopmentAuto-check passed

Works with

Categories

Questions about Cdk Contribution Skill

What does Cdk Contribution Skill do?

Guide AWS CDK contributions from GitHub issue analysis to PR-ready code. Cdk Contribution Skill is an agent skill from cdklabs/cdk-contribution-skill. Guide AWS CDK contributions from GitHub issue analysis to PR-ready code.

When should I use Cdk Contribution Skill?

Cdk Contribution Skill fits situations like: contributing to aws-cdk repository; analyzing CDK issues; implementing fixes; preparing pull requests.

How do I install Cdk Contribution Skill in Claude Code?

Run `npx skills add cdklabs/cdk-contribution-skill --skill cdk-contribution-skill -a claude-code`. Or copy the skill folder (cdk-contribution-skill in cdklabs/cdk-contribution-skill) into .claude/skills/cdk-contribution-skill in your project. Claude Code loads it when a task matches its description.

How do I install Cdk Contribution Skill in Codex?

Run `npx skills add cdklabs/cdk-contribution-skill --skill cdk-contribution-skill -a codex`. Or copy the skill folder (cdk-contribution-skill in cdklabs/cdk-contribution-skill) into .agents/skills/cdk-contribution-skill in your project. Codex loads it when a task matches its description.

Can I use Cdk Contribution Skill 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 cdklabs/cdk-contribution-skill --skill cdk-contribution-skill -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/cdk-contribution-skill, .gemini/skills/cdk-contribution-skill, .github/skills/cdk-contribution-skill and .opencode/skills/cdk-contribution-skill in your project.

What does Cdk Contribution Skill need to run?

Going by SKILL.md and its folder, Cdk Contribution Skill needs the command-line tools its instructions call (gh).

Does Cdk Contribution Skill access the network?

SKILL.md contains no URLs. Its commands use gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Cdk Contribution Skill safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Cdk Contribution Skill use?

Cdk Contribution Skill is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Cdk Contribution Skill use?

About 4.6k tokens (SKILL.md is roughly 18k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 27k tokens, read only when the agent opens those files.

What are the alternatives to Cdk Contribution Skill?

Skills that share tags, products or a category with Cdk Contribution Skill: Create PR (go-to-k/cdkd, 143 stars), PR Babysitter (openinterpreter/openinterpreter, 69k stars), Check PR (onyx-dot-app/onyx, 32k stars) and Contributor-First PR Merge (HKUDS/OpenHarness, 16k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Cdk Contribution Skill?

cdklabs (a GitHub organization) maintains it in cdklabs/cdk-contribution-skill, which has 110 GitHub stars. The repository was last updated on July 7, 2026.

Source: cdklabs/cdk-contribution-skill on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.