Skip to content

Project

SiftCoder is an open-source Claude Code plugin maintained by Sam Alameh (@ialameh). The repository lives at github.com/ialameh/sift-coder. It is MIT-licensed.

The project started as a personal scratchpad — a way to give Claude Code persistent memory and a domain-specific Salesforce flavour for the author's day job. It was opened up because the same shape was useful to other engineers working in the same patterns.

Where the project lives

How to participate

A few ways, in rough order of effort.

Open an issue. Bugs, papercuts, things that read like marketing copy in the docs (this guide is meant to be human-written; if a page reads like it was generated by a model, that's a bug worth flagging). The issue template asks for the version, the OS, and the reproduction steps; please fill those in.

Try a recipe and report back. The Cookbook recipes are tested in real use but the surface area is large. If a recipe doesn't work on your setup, that's useful feedback — open an issue with what diverged.

Contribute a skill. The plugin's value comes from accumulated skill files. If you have a workflow that's saved you time and you think it'd help others, the contributing guide explains how to add one. Skills are markdown — no compilation step, no registration friction, just a SKILL.md with the right frontmatter.

Contribute code. The TypeScript core is at src/. Tests are at tests/. The architecture is documented in detail at the architecture chapter. Pull requests welcome; CI runs on every PR (lint, typecheck, tests, coverage gates).

Sponsor specific work. Some features are blocked on sustained engineering time rather than ideas — the cross-machine sync work in particular. If your team would benefit from a specific roadmap item, opening an issue with that context helps prioritisation.

What ships in this section

  • Roadmap — what's planned, what's in progress, what's been recently shipped, and what's not planned.
  • The changelog, contributing guide, security policy, and licence are auto-staged into this section by the documentation build. They're maintained at the repository root.

A note on tone for contributors

The documentation in this guide is written by a human and the contributing guidelines ask the same of contributions. No template marketing copy. No "comprehensive solution" or "leverage" or "robust framework." If a section reads like a model wrote it, the maintainer will rewrite it before merging. This is a stylistic choice with a practical reason: documentation that reads like marketing is documentation people stop trusting.

The same principle applies to code comments and commit messages. Specifics over generalities. Reasons over restatements.