add-puzzle-type
Scaffold a new puzzle type across all 10+ pipeline integration points in jigsawR. Creates the core puzzle module, wires it into the unified pipeline (generation, positioning, rendering, adjacency), adds ggpuzzle geom/stat layers, updates DESCRIPTION and config.yml, extends the Shiny app, and creates a comprehensive test suite. Use when adding a completely new puzzle type to the package or following the 10-point integration checklist to ensure nothing is missed end-to-end.
Best use case
add-puzzle-type is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Scaffold a new puzzle type across all 10+ pipeline integration points in jigsawR. Creates the core puzzle module, wires it into the unified pipeline (generation, positioning, rendering, adjacency), adds ggpuzzle geom/stat layers, updates DESCRIPTION and config.yml, extends the Shiny app, and creates a comprehensive test suite. Use when adding a completely new puzzle type to the package or following the 10-point integration checklist to ensure nothing is missed end-to-end.
Teams using add-puzzle-type should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/add-puzzle-type/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How add-puzzle-type Compares
| Feature / Agent | add-puzzle-type | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Scaffold a new puzzle type across all 10+ pipeline integration points in jigsawR. Creates the core puzzle module, wires it into the unified pipeline (generation, positioning, rendering, adjacency), adds ggpuzzle geom/stat layers, updates DESCRIPTION and config.yml, extends the Shiny app, and creates a comprehensive test suite. Use when adding a completely new puzzle type to the package or following the 10-point integration checklist to ensure nothing is missed end-to-end.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Add Puzzle Type
Scaffold a new puzzle type across all pipeline integration points in jigsawR.
## When to Use
- Adding a completely new puzzle type to the package
- Following the established integration checklist (CLAUDE.md 10-point pipeline)
- Ensuring nothing is missed when wiring a new type end-to-end
## Inputs
- **Required**: New type name (lowercase, e.g. `"triangular"`)
- **Required**: Geometry description (how pieces are shaped/arranged)
- **Required**: Whether the type needs external packages (add to Suggests)
- **Optional**: Parameter list beyond the standard (grid, size, seed, tabsize, offset)
- **Optional**: Reference implementation or algorithm source
## Procedure
### Step 1: Create Core Puzzle Module
Create `R/<type>_puzzle.R` with the internal generation function:
```r
#' Generate <type> puzzle pieces (internal)
#' @noRd
generate_<type>_pieces_internal <- function(params, seed) {
# 1. Initialize RNG state
# 2. Generate piece geometries
# 3. Build edge paths (SVG path data)
# 4. Compute adjacency
# 5. Return list: pieces, edges, adjacency, metadata
}
```
Follow the pattern in `R/voronoi_puzzle.R` or `R/snic_puzzle.R` for structure.
**Got:** Function returns a list with `$pieces`, `$edges`, `$adjacency`, `$metadata`.
**If fail:** Compare the return structure against `generate_voronoi_pieces_internal()` to identify missing list elements or incorrect types.
### Step 2: Wire into jigsawR_clean.R
Edit `R/jigsawR_clean.R`:
1. Add `"<type>"` to the `valid_types` vector
2. Add type-specific parameter extraction in the params section
3. Add validation logic for type-specific constraints
4. Add filename prefix mapping (e.g., `"<type>"` -> `"<type>_"`)
```r
# In valid_types
valid_types <- c("rectangular", "hexagonal", "concentric", "voronoi", "snic", "<type>")
```
**Got:** `generate_puzzle(type = "<type>")` is accepted without "unknown type" error.
**If fail:** Verify the type string is added to `valid_types` exactly as spelled, and that parameter extraction covers all required type-specific arguments.
### Step 3: Wire into unified_piece_generation.R
Edit `R/unified_piece_generation.R`:
1. Add dispatch case in `generate_pieces_internal()`
2. Add fusion handling if the type supports PILES notation
```r
# In the switch/dispatch
"<type>" = generate_<type>_pieces_internal(params, seed)
```
**Got:** Pieces are generated when the type is dispatched.
**If fail:** Confirm the dispatch case string matches the type name exactly and that `generate_<type>_pieces_internal` is defined and exported from the puzzle module.
### Step 4: Wire into piece_positioning.R
Edit `R/piece_positioning.R`:
Add positioning dispatch for the new type. Most types use shared positioning logic, but some need custom handling.
**Got:** `apply_piece_positioning()` handles the new type without errors and pieces are placed at correct coordinates.
**If fail:** Check whether the new type needs custom positioning logic or can reuse the shared positioning path. Add a dispatch case if the default path does not apply.
### Step 5: Wire into unified_renderer.R
Edit `R/unified_renderer.R`:
1. Add rendering case in `render_puzzle_svg()`
2. Add edge path function: `get_<type>_edge_paths()`
3. Add piece name function: `get_<type>_piece_name()`
**Got:** SVG output is generated for the new type with correct piece outlines and edge paths.
**If fail:** Verify `get_<type>_edge_paths()` returns valid SVG path data and `get_<type>_piece_name()` produces unique identifiers for each piece.
### Step 6: Wire into adjacency_api.R
Edit `R/adjacency_api.R`:
Add neighbor dispatch so `get_neighbors()` and `get_adjacency()` work for the new type.
**Got:** `get_neighbors(result, piece_id)` returns correct neighbors for any piece in the puzzle.
**If fail:** Check that the adjacency dispatch returns the correct data structure. Test with a small grid and manually verify neighbor relationships against the geometry.
### Step 7: Add ggpuzzle Geom Layer
Edit `R/geom_puzzle.R`:
Create `geom_puzzle_<type>()` using the `make_puzzle_layer()` factory:
```r
#' @export
geom_puzzle_<type> <- function(mapping = NULL, data = NULL, ...) {
make_puzzle_layer(type = "<type>", mapping = mapping, data = data, ...)
}
```
**Got:** `ggplot() + geom_puzzle_<type>(aes(...))` renders without error.
**If fail:** Verify `make_puzzle_layer()` receives the correct type string and that the geom function is exported in the NAMESPACE via `@export`.
### Step 8: Add Stat Dispatch
Edit `R/stat_puzzle.R`:
1. Add type-specific default parameters
2. Add dispatch case in `compute_panel()`
**Got:** The stat layer computes puzzle geometry correctly and produces the expected number of polygons.
**If fail:** Check that the `compute_panel()` dispatch case returns a data frame with the required columns (`x`, `y`, `group`, `piece_id`) and that default parameters are sensible for the new type.
### Step 9: Update DESCRIPTION
Edit `DESCRIPTION`:
1. Add new type to the Description field text
2. Add any new packages to `Suggests:` (if external dependency)
3. Update `Collate:` to include the new R file (alphabetical order)
**Got:** `devtools::document()` succeeds. No NOTE about unlisted files.
**If fail:** Check that the new R file is listed in the `Collate:` field in alphabetical order and that any new Suggests packages are spelled correctly with version constraints.
### Step 10: Update config.yml
Edit `inst/config.yml`:
Add defaults and constraints for the new type:
```yaml
<type>:
grid:
default: [3, 3]
min: [2, 2]
max: [20, 20]
size:
default: [300, 300]
min: [100, 100]
max: [2000, 2000]
tabsize:
default: 20
min: 5
max: 50
# Add type-specific params here
```
**Got:** Config is valid YAML. Defaults produce a working puzzle when used by `generate_puzzle()`.
**If fail:** Validate YAML with `yaml::yaml.load_file("inst/config.yml")`. Ensure default grid and size values produce a sensible puzzle (not too small or too large).
### Step 11: Extend Shiny App
Edit `inst/shiny-app/app.R`:
1. Add the new type to the UI type selector
2. Add conditional UI panels for type-specific parameters
3. Add server-side generation logic
**Got:** Shiny app shows the new type in the dropdown and generates puzzles when selected.
**If fail:** Check that the type is added to the `choices` argument of the UI selector, that the conditional panel for type-specific parameters uses `conditionalPanel(condition = "input.type == '<type>'")`, and that the server-side handler passes the correct parameters.
### Step 12: Create Test Suite
Create `tests/testthat/test-<type>-puzzles.R`:
```r
test_that("<type> puzzle generates correct piece count", { ... })
test_that("<type> puzzle respects seed reproducibility", { ... })
test_that("<type> adjacency returns valid neighbors", { ... })
test_that("<type> fusion merges pieces correctly", { ... })
test_that("<type> geom layer renders without error", { ... })
test_that("<type> SVG output is well-formed", { ... })
test_that("<type> config constraints are enforced", { ... })
```
If the type requires an external package, wrap tests with `skip_if_not_installed()`.
**Got:** All tests pass. No skips unless external dependency is missing.
**If fail:** Check each integration point individually. The most common issue is missing dispatch cases — run `grep -rn "switch\|valid_types" R/` to find all dispatch locations.
## Validation
- [ ] `generate_puzzle(type = "<type>")` produces valid output
- [ ] All 10 integration points are wired correctly
- [ ] `devtools::test()` passes with new tests
- [ ] `devtools::check()` returns 0 errors, 0 warnings
- [ ] Shiny app renders the new type
- [ ] Config constraints are enforced (min/max validation)
- [ ] Adjacency and fusion work correctly
- [ ] ggpuzzle geom layer renders without error
- [ ] `devtools::document()` succeeds (NAMESPACE updated)
## Pitfalls
- **Missing dispatch case**: Forgetting one of the 10+ files causes silent failure or "unknown type" errors
- **strsplit with negative numbers**: When creating adjacency keys with `paste(a, b, sep = "-")`, negative piece labels produce keys like `"1--1"`. Use `"|"` separator instead and split with `"\\|"`.
- **Using `cat()` for output**: Always use `cli` package logging wrappers (`log_info`, `log_warn`, etc.)
- **Collate order**: DESCRIPTION Collate field must be alphabetical or dependency-ordered
- **Config.yml format**: Ensure YAML is valid; test with `yaml::yaml.load_file("inst/config.yml")`
## Related Skills
- `generate-puzzle` — test the new type after scaffolding
- `run-puzzle-tests` — run the full test suite to verify integration
- `validate-piles-notation` — test fusion with the new type
- `write-testthat-tests` — general test-writing patterns
- `write-roxygen-docs` — document the new geom functionRelated Skills
setup-tailwind-typescript
Configure Tailwind CSS with TypeScript in a Next.js or React project. Covers installation, configuration, custom theme extensions, component patterns, and type-safe styling utilities. Use to add Tailwind CSS to an existing TypeScript project, customize the Tailwind theme for a project's design system, set up type-safe component styling patterns, or configure Tailwind plugins and extensions.
run-puzzle-tests
Run jigsawR test suite via WSL R. Supports full suite, filtered by pattern, or single file. Interprets pass/fail/skip counts and identifies failing tests. Never use `--vanilla` (renv needs `.Rprofile` to activate). Use after R source changes, after adding a puzzle type or feature, before commits, or when debugging a specific failure.
generate-puzzle
Generate jigsaw puzzles via generate_puzzle() or geom_puzzle_*() with parameter validation against inst/config.yml. Supports rectangular, hexagonal, concentric, voronoi, and snic puzzle types with configurable grid, size, seed, offset, and layout parameters. Use when creating puzzle SVG files for a specific type and configuration, testing generation with different parameters, generating sample output for documentation or demos, or creating ggplot2 puzzle visualizations.
skill-name-here
One to three sentences describing what this skill accomplishes, followed by key activation triggers. This field is the primary mechanism agents use to decide whether to activate the skill — it is read during discovery before the full body is loaded. Start with a verb. Include the most important "when to use" conditions inline. Max 1024 characters.
write-vignette
Create R package vignettes using R Markdown or Quarto. Covers vignette setup, YAML configuration, code chunk options, building and testing, and CRAN requirements for vignettes. Use when adding a Getting Started tutorial, documenting complex workflows spanning multiple functions, creating domain-specific guides, or when CRAN submission requires user-facing documentation beyond function help pages.
write-validation-documentation
Write IQ/OQ/PQ validation documentation for computerized systems in regulated environments. Covers protocols, reports, test scripts, deviation handling, and approval workflows. Use when validating R or other software for regulated use, preparing for a regulatory audit, documenting qualification of computing environments, or creating and updating validation protocols and reports for new or re-qualified systems.
write-testthat-tests
Write comprehensive testthat (edition 3) tests for R package functions. Covers test organization, expectations, fixtures, mocking, snapshot tests, parameterized tests, and achieving high coverage. Use when adding tests for new package functions, increasing test coverage for existing code, writing regression tests for bug fixes, or setting up test infrastructure for a package that lacks it.
write-standard-operating-procedure
Write a GxP-compliant Standard Operating Procedure (SOP). Covers regulatory SOP template structure (purpose, scope, definitions, responsibilities, procedure, references, revision history), approval workflow design, periodic review scheduling, and operational procedures for system use. Use when a new validated system requires operational procedures, when existing informal procedures need formalisation, when an audit finding cites missing procedures, when a change control triggers SOP updates, or when periodic review identifies outdated procedural content.
write-roxygen-docs
Write roxygen2 documentation for R package functions, datasets, and classes. Covers all standard tags, cross-references, examples, and generating NAMESPACE entries. Follows tidyverse documentation style. Use when adding documentation to new exported functions, documenting internal helpers or datasets, documenting S3/S4/R6 classes and methods, or fixing documentation-related R CMD check notes.
write-incident-runbook
Create structured incident runbooks with diagnostic steps, resolution procedures, escalation paths, and communication templates for effective incident response. Use when documenting response procedures for recurring alerts, standardizing incident response across an on-call rotation, reducing MTTR with clear diagnostic steps, creating training materials for new team members, or linking alert annotations directly to resolution procedures.
write-helm-chart
Create production-ready Helm charts for Kubernetes application deployment with templating, values management, chart dependencies, hooks, and testing. Covers chart structure, Go template syntax, values.yaml design, chart repositories, versioning, and best practices for maintainable and reusable charts. Use when packaging a Kubernetes application for repeatable deployments, parameterizing manifests for multiple environments, managing complex multi-component applications with dependencies, or standardizing deployment practices with versioned rollback capability across teams.
write-continue-here
Write a CONTINUE_HERE.md file capturing current session state so a fresh Claude Code session can pick up where this one left off. Covers assessing recent work, structuring the continuation file with objective, completed, in-progress, next-steps, and context sections, and verifying the file is actionable. Use when ending a session with unfinished work, handing off context between sessions, or preserving task state that git alone cannot capture.