Contributing
Arashi changes usually start in the arashi-arashi meta-repository, then land in the project repository that owns the code or docs. The goal is to keep work scoped, reviewable, and easy to coordinate across the Arashi workspace.
Contribution Flow
Section titled “Contribution Flow”- Start from the meta-repo. Check workspace state with
arashi status. If a repository is behind, pull the workspace forward before starting new work. - Find or open the issue. Use the issue to agree on the problem, expected outcome, and affected repositories.
- Create a coordinated worktree. Run
arashi create <branch-name>fromarashi-arashiso every Arashi repository gets the same branch/worktree shape. - Plan changes when the behavior or workflow shifts. For CLI behavior, cross-repo changes, or agent-facing workflows, use the OpenSpec proposal flow in
arashi-arashibefore implementation. - Make implementation changes in the owning repository. For example, docs site content belongs in
arashi-docs; CLI behavior belongs inarashi. - Validate locally. Run the affected repository’s validation commands before opening a PR.
- Open focused PRs. Keep PRs small, link related PRs across repositories when needed, and reference the originating
arashi-arashiissue.
What Goes Where
Section titled “What Goes Where”- Use
arashi-arashifor issues, OpenSpec proposals, workspace coordination, and cross-repo context. - Use
arashifor the CLI and workspace-management behavior. - Use
arashi-docsfor this documentation site. - Use
arashi-skillsandarashi-vscodefor their project-specific changes.
If a change spans multiple repositories, open one PR per repository and cross-link them so reviewers can follow the full change.
Docs-Site Notes
Section titled “Docs-Site Notes”Small documentation fixes can go directly through the docs repository. For larger docs restructuring, use the same contribution flow above and keep the page focused on user outcomes rather than internal site mechanics.
Docs maintainers may still need the site-maintenance references: