ink-dev
Guides the contributor workflow for the ink library, including branching and validation.
Install
mkdir -p .claude/skills/ink-dev && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/13261" && unzip -o skill.zip -d .claude/skills/ink-dev && rm skill.zipInstalls to .claude/skills/ink-dev
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Use when contributing code to ink and needing repository-specific branching, local validation, PR, and CI conventions.Key capabilities
- →Create feature, bugfix, refactor, docs, or chore branches
- →Commit with conventional prefixes
- →Update README.md for API/behavior changes
- →Run local format checks with clang-format
- →Build and test code with CMake and ctest
- →Push branch and open pull request to master
How it works
The skill outlines a PR-first development cycle for the ink library, including branch naming conventions, commit message formats, local validation steps, and pull request creation.
Inputs & outputs
When to use ink-dev
- →Creating feature branches
- →Running local validation
- →Submitting pull requests
About this skill
ink-dev
Overview
Use this skill to follow the standard contributor workflow for the ink 2D rendering library.
Related: Use ink-release for nightly/stable release policy, gates, and hotfix handling.
This repository uses a PR-first flow even for solo development: work on branch, open PR, merge to master.
When to Use
Use when:
- starting a feature, bugfix, or refactor in this repo
- preparing a pull request to
master - checking what local commands to run before push
- preparing code for release readiness checks
Do not use when you need language-level coding patterns unrelated to repository workflow.
Branch Strategy
- Treat
masteras protected; use PRs instead of direct pushes. - Feature branch:
feat/<short-description> - Bugfix branch:
fix/<short-description> - Refactor branch:
refactor/<short-description> - Docs branch:
docs/<short-description> - Chore/CI branch:
chore/<short-description> - Do not commit feature work directly on
master.
Development Cycle
-
Create branch from latest
master:git switch master git pull git switch -c feat/<name> -
Commit with conventional prefixes:
<type>: <concise description>- Types:
feat,fix,refactor,test,docs,chore,ci
-
Update
README.mdwhen API/behavior/build/release workflow changed. -
Run local validation before push:
# Format check (matches CI) find include src -name '*.hpp' -o -name '*.cpp' | xargs clang-format --dry-run -Werror # Build + test cmake -B build -DINK_BUILD_TESTS=ON -DINK_ENABLE_GL=OFF cmake --build build -j$(nproc) ctest --test-dir build --output-on-failure -
Push branch and open PR to
master:git push -u origin feat/<name> gh pr create --base master --title "<type>: <description>" --body "$(cat <<'EOF' ## Summary - <what changed and why> ## Test plan - [ ] Local `ctest` passes - [ ] Format check passes EOF )" -
Wait for CI checks before merge.
-
Merge via GitHub (squash merge is the default convention).
Quick Reference
| Area | Current convention |
|---|---|
| Target branch | master |
| CI trigger | PR to master, push to master |
| CI checks | Format, Build & Test (gcc/clang x Debug/Release), clang-tidy, Sanitizers |
| Nightly trigger | schedule/manual in nightly.yml on default branch |
| Stable release trigger | push tag v* |
| Release outputs | CPU tarball, GL tarball, source tarball, GitHub Release notes |
Code Conventions
- C++17 with strict warnings (
-Wall -Wextra -Wpedantic). - Public headers live in
include/ink/; implementation insrc/. - GPU renderer sources live in
src/gpu/<api>/. - New features include tests in
tests/(typicallytest_<component>.cpp). - Tests use Google Test (
TEST,EXPECT_EQ, and related assertions). - When adding/removing a public header, keep
include/ink/ink.hpp(umbrella header) in sync. - When adding/removing source files, update
CMakeLists.txtaccordingly.
Common Mistakes
- Skipping local
ctestand relying only on CI feedback. - Skipping
clang-formatcheck locally — CI will reject unformatted code. - Forgetting README updates when public behavior or usage changes.
- Using vague commit titles instead of typed prefixes.
- Adding a public header but forgetting to include it in
ink.hppor the CMake install list. - Pushing release tags before the changelog PR is merged and release preflight passes.
When not to use it
- →When needing language-level coding patterns unrelated to repository workflow
- →When performing direct pushes to the master branch
- →When skipping local ctest and relying only on CI feedback
Limitations
- →Requires adherence to C++17 with strict warnings
- →Public headers must live in `include/ink/` and implementation in `src/`
- →New features must include tests in `tests/`
How it compares
This workflow enforces specific repository conventions for the ink library, ensuring consistent code contributions and release readiness through a structured PR-first approach, unlike generic development practices.
Compared to similar skills
ink-dev side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| ink-dev (this skill) | 0 | 2mo | Review | Intermediate |
| dev | 2 | 6mo | Review | Advanced |
| read-unmodified-c-module | 1 | 6mo | Review | Beginner |
| testing | 0 | 2mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
dev
atopile
LLM-focused workflow for working in this repo: compile Zig, run the orchestrated test runner, consume test-report.json/html artifacts, and discover/debug ConfigFlags.
read-unmodified-c-module
RediSearch
Read the source of the C module we are working on, before we made any changes.
testing
hw-native-sys
Testing guide and pre-commit testing strategy for PTO Runtime. Use when running tests, adding tests, or deciding what to test before committing.
unity-developer
sickn33
Build Unity games with optimized C# scripts, efficient rendering, and proper asset management. Masters Unity 6 LTS, URP/HDRP pipelines, and cross-platform deployment. Handles gameplay systems, UI implementation, and platform optimization. Use PROACTIVELY for Unity performance issues, game mechanics, or cross-platform builds.
unreal-engine-cpp-pro
sickn33
Expert guide for Unreal Engine 5.x C++ development, covering UObject hygiene, performance patterns, and best practices.
code-coverage-with-gcov
gadievron
Add gcov code coverage instrumentation to C/C++ projects