SDD on OpenSpec for GigaCode workflow
sdd-gigacode
Spec-driven development on OpenSpec for a multi-repository product: a shared spec store, BA and SA roles and skills for GigaCode
- 0 ★ on the repository
- Last commit
Extended access
Why this level
- The `sdd init` script writes schema, configuration and skill files into each component repository
- The pre-push hook runs a check before changes are pushed
Install
- Works in
- Services
In your terminal, with SkillFoxx CLI
npx skillfoxx add workflows/sdd-gigacodeDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- The `sdd init` script writes schema, configuration and skill files into each component repository
- The pre-push hook runs a check before changes are pushed
This is third-party code. Review the repository files before installing.
What it does
A set of scripts and skills carries a feature from business requirements to archiving across several repositories. Requirements are written once in a shared spec repository called the store. Each component, backend or frontend, plans its implementation on its own, and the "scenario, task, test" trace is checked automatically with `sdd check`. The `scripts/sdd init` script finds or creates the store, adds repositories to `components.yaml`, installs the schema, `openspec/config.yaml` and skills into components, registers the store and sets a pre-push hook. Skills are split by role: `sdd-store-bootstrap`, `sdd-business-propose`, `sdd-system-design`, `sdd-initiative-status` and `sdd-business-archive` work in the store, while `sdd-impl-plan` and `sdd-impl-verify` work in a component. The agent is chosen with `SDD_TOOL`: `gigacode` by default, with `claude` and `qwen` also fitting. The `examples/shop` folder walks through a shop example of three repositories in the middle of work on a promo code feature.
Who it is for. Teams with separate backend and frontend repositories where business and system analysts keep the requirements and developers work with GigaCode.
Good fit when
- One feature touches backend and frontend and the plan of each component must follow the shared requirements
- An analyst describes a new feature in the store and teams derive tasks from it
- Before an MR it is checked that every scenario is covered by a task and a test
- A new developer clones repositories into one folder and sets up the environment with one command
Not a fit when
- The product lives in one repository: a shared store adds extra layers
- The team does not use OpenSpec and does not plan to switch to it
- A single skill is wanted for a one-off task instead of a process with several roles
Example request
Describe a new "promo codes in the cart" feature in the store with business scenarios and prepare requirements for backend and frontend.Limitations
The work needs OpenSpec 1.14.1, installed with `npm i -g @fission-ai/openspec@1.14.1`, Python with the PyYAML library and clones of components and the store in one folder. After `sdd init` each component gets a `GIGACODE.md` with service rules.
Schemas are built for a specific OpenSpec version: on update they must be rebuilt with `tools/build-schemas.py`. `sdd init` guesses a component type, backend or frontend, from build files and a person fixes a mistake. The repository states no license and the `examples/shop` example is a teaching one.
How to disable. Delete the `~/tools/sdd` directory, the pre-push hook in components and the `openspec/` and `.gigacode/` files created by `sdd init`.
FAQ
How do I install SDD on OpenSpec for GigaCode?
Install `npm i -g @fission-ai/openspec@1.14.1` and `pip install --user pyyaml`, clone the repository to `~/tools/sdd` and run `~/tools/sdd/scripts/sdd init` in the product repositories folder.
What is the store?
A shared spec repository where business requirements and system design are written once. Components plan their implementation from it on their own.
Does the set work with Claude Code?
Yes. The agent is chosen with the `SDD_TOOL` variable: `gigacode` by default, and `claude` and `qwen` are supported too, as skills use the `SKILL.md` format.
What does `sdd check` verify?
The "scenario, task, test" trace. The check is called by the pre-push hook when the `openspec/` directory changed in the branch.
Where can I see an example?
In the `examples/shop` folder: three repositories in the middle of work on a promo code feature, with a spec in the store and component plans.
Discussion
No questions or reviews yet.
Related
All GigaChat toolsThe agent writes code, people decide, and gates are held by hooks in Claude Code, Codex, Cursor, OpenCode, Qwen Code and GigaCode
GigaCode project flows with hooks, gates and OpenSpec
gigacodeAgents
A monorepo of flows for the GigaCode CLI: development with stages and hard gates, a work progress observer and reverse analysis of code into a spec
A Python runner executes tasks from tasks.md one GigaCode iteration at a time, then five reviewers and a finalize pass, with a separate commit per task
Process Kit for GigaCode
process-kit
A GigaCode workspace where the assistant takes a task in words, finds a ready process made of steps and runs it with a plan and a report in outputs
QA Agent for the GigaCode CLI: 14 roles and 6 skills for testing
QaAgentGigacodeCli
Requirements-based testing in GigaCode: from analysis and autotest review to a conclusion, with duplicate search before a bug is filed in Jira
GigaCode Bridge MCP
Gigacode-bridge-mcp
MCP server that delegates isolated code edits to GigaCode CLI in temporary Git worktrees and returns a patch for independent review
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Repository stars | Main difference |
|---|---|---|---|
| SDD on OpenSpec for GigaCode (this card) | no | 0 | |
| OpenSpec | no | 74,172 | OpenSpec itself without a shared `store` for several repositories |
| Spec-Driven Development | no | 158 | a spec skill for one repository without BA and SA roles |
README in short
The README explains the flow from business requirements to the archive, a quick start, a skill table by role, a shop example, the repository structure and the OpenSpec update procedure. The method is described in `docs/method.md`.