-
Notifications
You must be signed in to change notification settings - Fork 0
Contributing
git clone https://github.com/prototypdigital/bluetemberg.git
cd bluetemberg
npm install
npm run build
npm test| Script | Purpose |
|---|---|
npm run build |
Compile TypeScript to dist/
|
npm run dev |
Watch mode compilation |
npm test |
Run tests (vitest) |
npm run test:watch |
Watch mode tests |
npm run lint |
ESLint check |
npm run lint:fix |
ESLint auto-fix |
npm run format |
Prettier format |
npm run format:check |
Prettier check |
npm run typecheck |
TypeScript type check |
src/
├── index.ts # Public API exports
├── types.ts # Shared TypeScript interfaces
├── utils/
│ └── fs.ts # File system helpers
├── sync/
│ ├── index.ts # Sync engine (read, transform, write)
│ └── transform.ts # Frontmatter transform logic
└── init/
├── index.ts # Init wizard orchestrator
├── prompts.ts # Inquirer prompt definitions
├── presets.ts # Available rule/agent/skill presets
└── scaffold.ts # File generation logic
This project uses Conventional Commits. All PR titles must follow the format:
type(scope): description
Common types:
-
feat— new feature (triggers minor version bump) -
fix— bug fix (triggers patch version bump) -
docs— documentation only -
chore— maintenance, dependencies -
refactor— code change that neither fixes a bug nor adds a feature
Breaking changes: add ! after the type, e.g. feat!: remove sync v1 API. This triggers a major version bump (or minor while pre-1.0).
- Create a feature branch from
main - Make your changes
- Ensure all checks pass:
npm run build && npm test && npm run lint && npm run format:check - Open a PR with a conventional commit title
- CODEOWNERS will be auto-requested for review
- After merge, Release Please will open/update a release PR
- When the release PR is merged, the package is published automatically
Releases are fully automated via Release Please:
- Conventional commits on
mainare analyzed - A "release PR" is opened with version bump and CHANGELOG update
- A maintainer reviews and merges the release PR
- A GitHub Release is created automatically
- The publish workflow triggers and pushes to GitHub Packages
No manual version bumping or tagging is needed.
Rules are always-on, passive context. See Writing Rules for format details.
Add a Markdown file to templates/rules/:
---
description: One-line description of what this rule enforces.
scope: '**'
---
# Rule title
Concise, actionable content the AI sees on every interaction.In src/init/presets.ts, add an entry to the RULE_PRESETS array:
{
id: 'my-new-rule', // must match the filename (minus .md)
name: 'My new rule', // displayed in the wizard
description: 'What it does', // shown next to the name
default: false, // true = pre-checked for tagged profiles
tags: ['backend', 'fullstack'], // which profiles pre-check this rule
},Add the rule to the table in Writing Rules and to any affected profile tables in Profiles. The docs-parity universal rule requires this — PRs that add templates without updating docs are not considered complete.
npm run build && npm testTry it locally in a throwaway directory:
mkdir /tmp/test-project && cd /tmp/test-project
npm init -y
node /path/to/bluetemberg/bin/cli.js initOpen a PR with title: feat: add <name> rule template
Agents are specialist AI personas. See Writing Agents for format details.
Add a Markdown file to templates/agents/:
---
name: my-agent
description: One-line description.
tools: ['read', 'search', 'edit']
---
# My Agent
You are a [role] specialist. Your job is to [responsibility].
## Responsibilities
- ...
## Constraints
- ...In src/init/presets.ts, add to AGENT_PRESETS:
{
id: 'my-agent',
name: 'My agent',
description: 'What it does',
default: false,
tags: ['backend', 'fullstack'],
},Add the agent to tables in Writing Agents and Profiles. PR title: feat: add <name> agent template
Skills are on-demand, multi-step workflows. See Writing Skills for format details and when to use a skill vs a rule.
templates/skills/my-skill/SKILL.md
In src/init/presets.ts, add to SKILL_PRESETS:
{
id: 'my-skill',
name: 'My skill',
description: 'What it does',
default: false,
tags: ['backend', 'fullstack'],
},Add the skill to tables in Writing Skills and Profiles. PR title: feat: add <name> skill template
Profiles set smart defaults for the init wizard. Adding a new one is a code change.
In src/types.ts:
export type TeamProfile = 'frontend' | 'backend' | 'fullstack' | 'devops' | 'my-profile' | 'custom';In src/init/presets.ts, add to TEAM_PROFILES:
{ id: 'my-profile', name: 'My Profile', description: 'Short description of the team type' },Add 'my-profile' to the tags array of every rule, agent, and skill that should be pre-checked for this profile.
Add a new section to Profiles with the rules/agents/skills matrix. Add the profile to the description in the Commands page.
PR title: feat: add <name> team profile
Every preset has a tags array listing which profiles consider it a default:
tags: ['frontend', 'backend', 'fullstack']When a user picks a profile, every preset tagged for that profile gets pre-checked in the wizard. The custom profile skips tag-based defaults — nothing is pre-checked.
The universal flag overrides everything:
universal: true // always selected, shown as "(required)", cannot be deselectedUniversal presets are included regardless of profile, even custom. Use this sparingly — only for hard requirements that every project needs. Currently 7 rules are universal. No agents or skills are universal.
Bluetemberg enforces a docs-parity universal rule: documentation must ship in the same commit as every user-facing change. This applies to the tool itself.
When your PR changes behavior — a new template, a new flag, a config schema change — update the relevant wiki pages in docs/wiki/ as part of the same commit. CI won't catch a missing doc update, but code reviewers will, and the rule exists to remind you.