Contributing to jaan.to
Thank you for your interest in contributing to jaan.to! This document outlines how to contribute effectively to the project.
Table of Contents
- Branching Strategy
- Code of Conduct
- Ways to Contribute
- Adding New Skills
- Improving Learning Files
- Code Style & Conventions
- Testing Guidelines
- Submitting Changes
- Release Process
Branching Strategy
jaan.to uses a two-branch development model:
Branches
| Branch | Purpose | Version Format | Install Command |
|---|---|---|---|
main | Stable releases | 3.15.0 | /plugin marketplace add parhumm/jaan-to |
dev | Development/preview | 3.15.0 | /plugin marketplace add parhumm/jaan-to#dev |
Workflow
feature/* ───> dev ───> main
│ │
│ (PR + review)
│ │
│ (release tag)
│ │
└─────────┘
sync dev
- Daily development: Work on
devbranch (direct pushes allowed) - Feature work: Create feature branches from
dev, merge back todev - Releases: Create PR from
dev→main(requires review + CI checks) - After release: Sync
devfrommain, then bump to next version (e.g.,3.15.0→3.16.0)
Contributing to dev
# Clone and switch to dev
git clone https://github.com/parhumm/jaan-to.git
cd jaan-to
git checkout dev
# Make changes, test locally
claude --plugin-dir .
# Push to dev (no PR required for small changes)
git push origin dev
Hotfixes
All fixes go through dev first:
- Fix on
dev - Test
- Create expedited PR:
dev→main
Code of Conduct
- Be respectful: Treat everyone with respect and kindness
- Be collaborative: Work together to improve the project
- Be constructive: Provide helpful feedback and suggestions
- Be inclusive: Welcome contributors of all backgrounds and experience levels
Ways to Contribute
1. Report Bugs
Found a bug? Open an issue with:
- Description: What happened vs what you expected
- Steps to reproduce: Exact commands and inputs
- Environment: OS, Claude Code version, plugin version
- Logs: Error messages or relevant output
2. Suggest Features
Have an idea? Open an issue with:
- Use case: What problem does this solve?
- Proposed solution: How should it work?
- Alternatives: Other ways to solve the problem
- Impact: Who benefits and how?
3. Improve Documentation
Documentation improvements are always welcome:
- Fix typos or unclear explanations
- Add examples or use cases
- Update outdated information
- Improve README or skill descriptions
4. Add Skills
See Adding New Skills below.
5. Capture Lessons
After using a skill, share what you learned:
- Common mistakes you encountered
- Edge cases you discovered
- Improvements you'd suggest
See Improving Learning Files below.
Adding New Skills
Quick Start
The easiest way to create a new skill:
# From Claude Code
/jaan-to:skill-create
This wizard will guide you through:
- Choosing a role and domain
- Defining inputs and outputs
- Describing the skill behavior
- Creating the skill structure
Manual Process
If you prefer to create skills manually, follow the Creating Skills Guide.
Key Requirements:
-
SKILL.md file with YAML frontmatter:
---
name: skill-name
description: Brief description in third-person voice
--- -
Naming convention:
- Public skills:
{role}-{domain}-{action} - Internal skills:
{domain}-{action}
- Public skills:
-
Two-phase workflow:
- Phase 1: Read-only analysis (context, requirements, planning)
- HARD STOP: Confirm with user before proceeding
- Phase 2: Generation (write files, validate, preview)
-
LEARN.md file (optional but recommended):
- Location:
skills/{name}/LEARN.md - Format: See docs/learning/LESSON-TEMPLATE.md
- Location:
-
template.md file (if skill generates structured output):
- Location:
skills/{name}/template.md - Format: Markdown with
{{placeholders}}
- Location:
Skill Categories
| Role | Domain Examples | Action Examples |
|---|---|---|
pm | prd, story, research | write, update, analyze |
dev | fe, be, stack | breakdown, detect, generate |
data | gtm, analytics | datalayer, track, analyze |
ux | research, heatmap, microcopy | synthesize, analyze, write |
qa | test-cases, automation | generate, validate |
Testing Your Skill
-
Install plugin locally:
claude --plugin-dir /path/to/jaan-to -
Verify skill appears:
/help | grep your-skill-name -
Test execution:
/jaan-to:your-skill-name "test input" -
Run verification:
./scripts/verify-install.sh /path/to/test-project --plugin-dir /path/to/jaan-to
Improving Learning Files
Learning files (LEARN.md) capture accumulated wisdom from skill usage. These files make skills smarter over time.
Adding Lessons
Via Command (Recommended):
/jaan-to:learn-add "lesson content here"
Manual Edit:
- Edit
jaan-to/learn/{skill-name}.learn.mdin your project - Follow format from docs/learning/LESSON-TEMPLATE.md
Lesson Structure
## [Brief Title of Lesson]
**Date:** 2026-02-03
**Skill:** skill-name
**Severity:** [Low | Medium | High | Critical]
### Context
[What were you trying to do?]
### What Happened
[What went wrong or what was learned?]
### Root Cause
[Why did it happen?]
### Fix
[How was it resolved?]
### Prevention
[How to avoid this in the future?]
What Makes a Good Lesson
✅ Good:
- Specific: "PRD missing Security section for OAuth flows"
- Actionable: "Add validation: check for Security section when OAuth mentioned"
- Contextual: "User requested OAuth integration but PRD had no security considerations"
❌ Bad:
- Vague: "PRD was incomplete"
- Not actionable: "Should be better"
- No context: "It didn't work"
Code Style & Conventions
Naming
Skills:
- Directory:
skills/jaan-to:pm-prd-write/ - File:
SKILL.md(uppercase) - Command:
/jaan-to:pm-prd-write - Logical name:
jaan-to:pm-prd-write
Files:
- Markdown:
README.md,CHANGELOG.md,CONTRIBUTING.md(uppercase for root docs) - Scripts:
bootstrap.sh,learning-summary.sh(lowercase, kebab-case) - Templates:
template.md(lowercase)
Shell Scripts
- Use
#!/bin/bashor#!/usr/bin/env bash - Always include
set -euo pipefailfor safety - Use
${CLAUDE_PLUGIN_ROOT}for plugin-relative paths - Use
${CLAUDE_PROJECT_DIR}for project-relative paths - Exit 0 on success, non-zero on error
Example:
#!/bin/bash
set -euo pipefail
PROJECT_DIR="${CLAUDE_PROJECT_DIR:-.}"
PLUGIN_DIR="${CLAUDE_PLUGIN_ROOT:-$(dirname "$0")/..}"
# Your code here
exit 0
Markdown
- Use ATX headers (
#,##, not underlines) - Max line length: 120 characters (soft limit)
- Code blocks: Always specify language (
bash,json, ```yaml) - Links: Use reference-style for repeated URLs
YAML Frontmatter
- Always use
---delimiters - Required fields first (name, description)
- Optional fields after
- No custom fields without documentation
Example:
---
name: skill-name
description: Brief description
---
Testing Guidelines
Automated Tests
Currently, jaan.to uses manual testing. Automated tests coming in Phase 6 (see roadmap).
Manual Testing Checklist
Before submitting a PR with a new skill:
- Skill appears in
/helpoutput - Skill executes without errors
- Two-phase workflow works (HARD STOP between phases)
- Output written to correct location (
jaan-to/outputs/) - LEARN.md seed file exists
- Template file exists (if applicable)
- Context files are read correctly (
tech.md,team.md, etc.) - Quality checks pass (if applicable)
- Skill description uses third-person voice
- Command naming follows convention
Integration Testing
Test skills work together:
# Example: PRD → Stories → Tasks workflow
/jaan-to:pm-prd-write "user authentication"
/jaan-to:pm-story-write from prd
/jaan-to:dev-fe-task-breakdown from prd
Verify:
- Stories reference PRD correctly
- Tasks reference PRD and Stories correctly
- No broken file paths
- Cross-skill suggestions work
Submitting Changes
1. Fork and Clone
git clone https://github.com/YOUR-USERNAME/jaan-to.git
cd jaan-to
git remote add upstream https://github.com/parhumm/jaan-to.git
2. Create a Branch from dev
# Always branch from dev, not main
git checkout dev
git pull upstream dev
git checkout -b feature/your-skill-name
# or
git checkout -b fix/issue-description
Branch naming:
- Features:
feature/skill-nameorfeature/description - Fixes:
fix/issue-description - Docs:
docs/what-changed - Refactor:
refactor/what-changed
3. Make Changes
Follow guidelines above for code style, testing, and documentation.
4. Commit
Commit message format:
type(scope): brief description
Longer explanation if needed.
- Bullet points for details
- More details
Co-authored-by: Name <email@example.com>
Types:
feat: New feature (skill, command, hook)fix: Bug fixdocs: Documentation onlyrefactor: Code refactoring (no behavior change)test: Adding testschore: Maintenance (dependencies, build)
Examples:
feat(skill): Add /jaan-to:qa-test-cases skill
Generate BDD test cases from PRD acceptance criteria.
- Given/When/Then format
- Happy path + edge cases + errors
- Output to jaan-to/outputs/qa/
5. Push and Create PR
git push origin feature/your-skill-name
Then create a PR on GitHub with:
- Title: Same as commit message first line
- Description:
- What changed?
- Why was this change needed?
- How was it tested?
- Screenshots: If UI/output changes
- Related Issues: Link to issues this PR addresses
Release Process
Releases are managed by maintainers. If you're interested in the process:
Versioning
jaan.to follows Semantic Versioning:
- Major (v2.0.0): Breaking changes
- Minor (v1.1.0): New features (backward compatible)
- Patch (v1.0.1): Bug fixes
Both dev and main use the same X.Y.Z format (e.g., 3.15.0). No -dev suffix.
Release Checklist (Maintainers Only)
-
Ensure version and CHANGELOG are ready on
dev:- Version should already be bumped in all 3 places via
./scripts/bump-version.sh X.Y.Z - CHANGELOG.md should have an entry for the version
- Version should already be bumped in all 3 places via
-
Create PR:
dev→main- CI checks: all 3 versions match, CHANGELOG entry exists
- Requires review and approval
-
After merge, tag and push:
git checkout main
git pull origin main
git tag v3.15.0
git push origin main --tags -
Sync dev back from main:
git checkout dev
git merge main
git push origin dev -
Bump dev to next version (for next release cycle):
./scripts/bump-version.sh 3.16.0
git commit -m "chore: bump version to 3.16.0"
git push origin dev -
Verify installation works:
/plugin uninstall jaan-to
/plugin marketplace add parhumm/jaan-to
/plugin install jaan-toConfirm skills appear with
/jaan-to:pm-prd-write --helpor similar.
IMPORTANT: Version bump, CHANGELOG entry, and git tag are inseparable. Never do one without the others.
Questions?
- Documentation: docs/README.md
- Skills Reference: docs/skills/README.md
- Creating Skills: docs/extending/create-skill.md
- GitHub Issues: github.com/parhumm/jaan-to/issues
Thank you for contributing!
Give soul to your workflow.