Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/steerlabs/opensteer/llms.txt

Use this file to discover all available pages before exploring further.

Thanks for helping improve OpenSteer.

​
Prerequisites

  • Node.js >=20
  • pnpm (canonical maintainer workflow via Corepack)
  • npm or bun are also supported for local development

​
Local Setup

corepack enable
pnpm install --frozen-lockfile
pnpm-lock.yaml is the canonical lockfile used by CI/release workflows.

​
Validation Commands

Run these before opening a PR: 
pnpm run typecheck
pnpm run build
pnpm run test

​
Focused Test Suites

You can run specific test suites for faster iteration: 
pnpm run test:unit
pnpm run test:actions
pnpm run test:integration
pnpm run test:e2e
pnpm run test:ai
You can swap pnpm run with npm run or bun run for the same script names.

​
Live Web Tests

The live web suite is opt-in and requires explicit env setup: 
RUN_LIVE_WEB=1 pnpm run test:live-web

​
Contribution Guidelines

Each PR should address a single problem or feature. This makes code review easier and helps maintain a clean git history.
For behavior changes and bug fixes, always include tests that verify the fix or new functionality.
When public behavior, environment variables, or command usage changes, update the relevant documentation files.
For skill changes, keep content in skills/<skill-name>/ and ensure linked reference docs resolve with relative Markdown paths.
Do not include unrelated refactors in feature/fix PRs. Keep refactoring separate to make review easier.
Avoid new dependencies unless there is a clear need. Extra dependencies increase bundle size and maintenance burden.

​
Pull Request Template

Include this in your PR description:
  1. What changed - Brief summary of the changes
  2. Why it changed - Context and motivation
  3. How you validated it - Testing approach
  4. Risks, limitations, or follow-up items - Known issues or future work

​
Ownership And Governance

File ownership is defined in .github/CODEOWNERS.

​
Maintainers

​
Active Maintainers

  • Tim Jang (@timjang3) - Project lead and release manager

​
Maintainer Responsibilities

  • Review and merge pull requests
  • Maintain release quality and publish releases
  • Triage issues and security reports
  • Keep documentation, governance, and community policies up to date

​
Maintainer Availability

If a PR or issue has no response for 7+ days, comment with context and a maintainer will follow up.

​
Decision Model

We use lazy consensus for routine changes:
  • A maintainer proposes a change in an issue or pull request
  • If there is no substantiated objection within 72 hours, the change may proceed
  • Any maintainer may request more discussion for high-impact changes

​
What Requires Maintainer Approval

The following always require maintainer approval before merge:
  • Public API and CLI behavior changes
  • Dependency additions or major version upgrades
  • Security-related behavior and policy changes
  • Release workflow, publishing, and governance updates

​
Dispute Resolution

If contributors disagree:
  1. Discuss in the PR/issue with concrete tradeoffs and alternatives
  2. Escalate to maintainers for final decision if consensus is not reached
  3. For conduct issues, follow CODE_OF_CONDUCT.md

​
Release Authority

Only maintainers may create release tags and publish npm releases. Releases are created by GitHub Actions workflows from tagged commits. See the releasing documentation for detailed release steps.

​
Reporting Security Issues

Do not open public issues for security vulnerabilities.
Follow the process outlined in SECURITY.md.

​
Community

Discussions

Join the community discussion

Code of Conduct

Review our community guidelines

Security Policy

Report security vulnerabilities

Changelog

View release history

Build docs developers (and LLMs) love

Get started for freeTalk to us