• Report potential bugs.
• Suggest app enhancements.
• Increase our test coverage.
• Fix a bug.
• Implement a requested enhancement.
• Improve our documentation.
• Respond to questions about usage on the issue tracker or Discord Server.

Note: Issues on GitHub for CookCLI are intended to be related to bugs or feature requests. Questions should be directed to Discord Server or Spec Discussions.

• Check existing issues (both open and closed) to make sure it has not been reported previously.

• Provide a reproducible test case. If a contributor can't reproduce an issue, then it dramatically lowers the chances it'll get fixed.

• Aim to respond promptly to any questions made by the CookCLI team on your issue. Stale issues will be closed.

1. The issue is reported.

2. The issue is verified and categorized by a CookCLI maintainer. Categorization is done via tags. For example, bugs are tagged as "bug".

3. Unless it is critical, the issue is left for a period of time (sometimes many weeks), giving outside contributors a chance to address the issue.

4. The issue is addressed in a pull request or commit. The issue will be referenced in the commit message so that the code that fixes it is clearly linked. Any change a CookCLI user might need to know about will include a changelog entry in the PR.

5. The issue is closed.

If you wish to work on CookCLI itself, you'll first need to:

• install Rust for macOS, Linux or Windows.
• install NodeJS for building the web UI styles.
• fork the CookCLI repo

To build CookCLI:

# Install frontend dependencies (first time only)
npm install

# Build everything including CSS
make build

# Or build just the Rust binary
cargo build

In a few moments, you'll have a working cook executable in target/debug.

Note: make build will compile CSS and build for your local machine's os/architecture.

The web interface uses server-side rendering with Askama templates and Tailwind CSS.

# Setup
npm install              # Install Tailwind and dependencies
make css                 # Build CSS once

# Development workflow
npm run watch-css        # Terminal 1: Watch CSS changes
cargo run -- server      # Terminal 2: Run dev server

# Build for production
make release             # Builds everything including CSS

• Templates: Askama templates in templates/ directory
• Styling: Tailwind CSS with custom components
• JavaScript: Vanilla JS for interactivity (no framework dependency)
• Static Files: Served from static/ directory

Templates are in templates/ and use the Askama templating engine:

<!-- templates/recipe.html -->
{% extends "base.html" %}
{% block content %}
  <h1>{{ recipe.name }}</h1>
  <!-- Recipe content -->
{% endblock %}

Template data structures are defined in src/server/templates.rs.

The UI uses Tailwind CSS with custom components:

1. Edit styles in static/css/input.css
2. Run npm run build-css to compile
3. For development, use npm run watch-css for auto-rebuild

Custom component classes:

• .recipe-card - Recipe cards with gradient borders
• .ingredient-badge - Ingredient tags in recipes
• .metadata-pill - Clean metadata badges
• .nav-pill - Navigation items

1. Create template in templates/
2. Define data structure in src/server/templates.rs
3. Add handler in src/server/ui.rs
4. Add route to the router

├── templates/           # Askama HTML templates
│   ├── base.html       # Base layout
│   ├── recipes.html    # Recipe listing
│   └── recipe.html     # Single recipe view
├── static/             # Static assets
│   └── css/
│       ├── input.css   # Tailwind input with custom classes
│       └── output.css  # Compiled CSS (generated)
├── src/server/
│   ├── mod.rs         # Server setup and routing
│   ├── ui.rs          # UI request handlers
│   └── templates.rs   # Template data structures
├── tailwind.config.js  # Tailwind configuration
└── package.json        # NPM dependencies

• Templates are recompiled on each build, so you need to rebuild after template changes
• CSS changes with npm run watch-css are reflected immediately (just refresh browser)
• Use browser dev tools to inspect Tailwind classes
• Check static/css/output.css is being generated and served correctly

No tests at the moment 🤞.

Before writing any code, we recommend:

• Create a Github issue if none already exists for the code change you'd like to make.
• Write a comment on the Github issue indicating you're interested in contributing so maintainers can provide their perspective if needed.
• Use Semantic Commit Messages, so release automation can kick-in.

Keep your pull requests (PRs) small and open them early so you can get feedback on approach from maintainers before investing your time in larger changes.

When you're ready to submit a pull request:

1. Include evidence that your changes work as intended (e.g., add/modify unit tests; describe manual tests you ran, in what environment, and the results including screenshots or terminal output).
2. Open the PR from your fork against base repository cooklang/CookCLI and branch main.
   • Link the PR to its associated issue.
3. Include any specific questions that you have for the reviewer in the PR description or as a PR comment in Github.
   • If there's anything you find the need to explain or clarify in the PR, consider whether that explanation should be added in the source code as comments.
   • You can submit a draft PR if your changes aren't finalized but would benefit from in-process feedback.
4. After you submit, the CookCLI maintainers team needs time to carefully review your contribution and ensure it is production-ready, considering factors such as: correctness, backwards-compatibility, potential regressions, etc.
5. After you address CookCLI maintainer feedback and the PR is approved, a CookCLI maintainer will merge it. Your contribution will be available from the next minor release.