Nice work shipping this — the "any LLM" angle is a real gap in the current SDD tools. Full disclosure: I'm the creator of SPECLAN, another VS Code extension in this space. We came at it from a slightly different angle — instead of wrapping the Spec Kit workflow visually, we built around a hierarchical spec tree (Goal then Feature then Requirement then Acceptance Criterion) with status gates that control who can touch what, plus an MCP server so AI agents read approved specs directly rather than copy-pasted prompts.
The approval workflow you added is exactly the missing piece from vanilla Spec Kit — the moment you add human checkpoints, the "AI runs wild" failure mode goes away. Curious: for your Jira integration, do you push specs out to Jira, or pull tickets in? We've been debating whether to add something similar or keep SPECLAN as the source of truth and let Jira mirror from it.
Thanks Thomas! SPECLAN's approach with the hierarchical spec tree and MCP server sounds really interesting — having AI agents read approved specs directly is a smart architecture choice.
To answer your question: Caramelo currently pulls from Jira (read-only). You select an issue from your board, and its title, description, acceptance criteria, and comments become the input for spec generation. The spec card then shows a linked Jira badge that links back to the original issue.
We deliberately started read-only to keep the integration simple and non-destructive. Pushing specs back to Jira (syncing status, creating sub-tasks from the generated tasks.md) is something I'd like to explore — but it opens the "source of truth" question you're describing. For now, Caramelo treats Jira as the origin and specs/ as the working space.
I'd be curious to see how SPECLAN's approval gates compare — the "who can touch what" access control is something we don't have yet and could be valuable for larger teams
The read-only pull from Jira is smart — starting non-destructive avoids the sync nightmare where you're debugging which direction overwrote what at 2am. I'd probably do the same.
On the approval gates: it's simpler than "access control" in the RBAC sense. Each spec file has a status field in YAML frontmatter (draft → review → approved → locked). The rule is just that once a spec reaches "approved," the editor makes it read-only — you can't silently change it. If something needs to change, you create a Change Request (separate file, references the original by ID, has its own review cycle). It's friction by design, not permissions.
In practice the status ends up encoding ownership implicitly — "draft" means the author is still working on it, "review" means it's someone else's turn to look, "approved" means the PO signed off and now only a formal CR can touch it. No user roles, just the file's lifecycle state driving who acts next.
For the Jira direction: the "source of truth" question is the hard part. If you ever push back, I'd suggest keeping it one-directional — Jira creates the intent (ticket), Caramelo refines it (spec), but the spec never writes back to Jira. Two-way sync between structured specs and Jira tickets is a graveyard of good intentions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice work shipping this — the "any LLM" angle is a real gap in the current SDD tools. Full disclosure: I'm the creator of SPECLAN, another VS Code extension in this space. We came at it from a slightly different angle — instead of wrapping the Spec Kit workflow visually, we built around a hierarchical spec tree (Goal then Feature then Requirement then Acceptance Criterion) with status gates that control who can touch what, plus an MCP server so AI agents read approved specs directly rather than copy-pasted prompts.
The approval workflow you added is exactly the missing piece from vanilla Spec Kit — the moment you add human checkpoints, the "AI runs wild" failure mode goes away. Curious: for your Jira integration, do you push specs out to Jira, or pull tickets in? We've been debating whether to add something similar or keep SPECLAN as the source of truth and let Jira mirror from it.
Thanks Thomas! SPECLAN's approach with the hierarchical spec tree and MCP server sounds really interesting — having AI agents read approved specs directly is a smart architecture choice.
To answer your question: Caramelo currently pulls from Jira (read-only). You select an issue from your board, and its title, description, acceptance criteria, and comments become the input for spec generation. The spec card then shows a linked Jira badge that links back to the original issue.
We deliberately started read-only to keep the integration simple and non-destructive. Pushing specs back to Jira (syncing status, creating sub-tasks from the generated tasks.md) is something I'd like to explore — but it opens the "source of truth" question you're describing. For now, Caramelo treats Jira as the origin and specs/ as the working space.
I'd be curious to see how SPECLAN's approval gates compare — the "who can touch what" access control is something we don't have yet and could be valuable for larger teams
The read-only pull from Jira is smart — starting non-destructive avoids the sync nightmare where you're debugging which direction overwrote what at 2am. I'd probably do the same.
On the approval gates: it's simpler than "access control" in the RBAC sense. Each spec file has a status field in YAML frontmatter (draft → review → approved → locked). The rule is just that once a spec reaches "approved," the editor makes it read-only — you can't silently change it. If something needs to change, you create a Change Request (separate file, references the original by ID, has its own review cycle). It's friction by design, not permissions.
In practice the status ends up encoding ownership implicitly — "draft" means the author is still working on it, "review" means it's someone else's turn to look, "approved" means the PO signed off and now only a formal CR can touch it. No user roles, just the file's lifecycle state driving who acts next.
For the Jira direction: the "source of truth" question is the hard part. If you ever push back, I'd suggest keeping it one-directional — Jira creates the intent (ticket), Caramelo refines it (spec), but the spec never writes back to Jira. Two-way sync between structured specs and Jira tickets is a graveyard of good intentions.