Skip to content

CONTRIBUTING.en.md

Latest commit

 

History

History
100 lines (59 loc) · 3.73 KB

CONTRIBUTING.en.md

File metadata and controls

100 lines (59 loc) · 3.73 KB
Raw

Contributing

中文版

Thanks for your interest in FylloCode. This document covers how to set up a local development environment, how to submit code, and a few basic conventions.

Development Setup

Requirements

  • Node.js 22+
  • pnpm 10+

Local setup

git clone https://github.com/Fioooooooo/FylloCode.git
cd FylloCode
pnpm install
pnpm run dev

Developing FylloCode with FylloCode

FylloCode is built using FylloCode itself. We recommend using the packaged version from Releases rather than pnpm run dev — the reason is straightforward: dev mode uses hot reload, and when Apply starts modifying source files, hot reload will interrupt the active workflow. The packaged version doesn't have this problem.

The workflow: download the latest release, open the FylloCode repository as a project, describe what you want to do in a Task, and walk through Proposal → Apply → Archive rather than writing code directly.

This isn't required, but it has two benefits: you'll understand the project's design intent much faster, and if anything in the workflow blocks you, that's itself a bug worth fixing.

Submitting Changes

Small changes (typos, docs, minor bugs): open a PR directly — no need to discuss first.

Large changes (new features, architectural shifts, behavior changes): open an Issue first to describe what you have in mind. Wait for rough consensus before starting. This avoids finishing a large PR only to find it's going in the wrong direction.

PR expectations:

  • Title should clearly describe what changed — no need for an essay
  • If the change affects user-visible behavior, describe the scope of impact in the PR description
  • Keep each PR focused on one thing

Issues

Bug reports: describe the steps to reproduce, the actual behavior, and the expected behavior. Include system info (OS, version) where possible.

Feature requests: describe the problem you're running into in a specific scenario — you don't need to propose a solution.

Search before opening — avoid duplicates.

Code Style

The project uses ESLint + Prettier. Run before committing:

pnpm run lint
pnpm run typecheck
pnpm run icon:check

Commit message format:

type(scope): summary

- Optional details, using bullets for key changes

Common types: feat · fix · refactor · docs · chore · perf · test

Scope corresponds to the module or feature area — for example: proposal, specs, archive, worktree, chat, acp. Summary should start with a verb and describe what changed in one sentence.

Maintainer Release Flow

When preparing a FylloCode Release, give the Agent the exact target application version and use the repository's prepare-release skill. The workflow:

  1. Uses the latest relevant semantic-version tag through HEAD as the release range, then verifies archived specs, implementation, and tests.
  2. Audits Chinese and English documentation for every shipped change and updates CHANGELOG.md, CHANGELOG.en.md, and package.json.
  3. Versions fyllo-specs and fyllo-cortex independently from their own change boundaries instead of synchronizing them with the application version.
  4. Prepares Chinese and English release notes and runs pnpm icon:check, pnpm lint, pnpm typecheck, and pnpm test.

pnpm build, documentation builds, and packaging commands require explicit authorization in the current conversation. The release commit, annotated tag, push, and GitHub Release publication are four separate approval checkpoints. A request to "prepare a release" does not authorize later transitions.

License

Contributions are licensed under the repository's MIT.