-
Notifications
You must be signed in to change notification settings - Fork 2
FAQ
No. FeatherSpec is Markdown and folders. No CLI, no Node or Python package, no build step, no dependencies, no lock file. You copy files into a repository and open it in your assistant.
Partly, and it degrades gracefully. AGENTS.md is a widely-adopted convention, so most agentic
tools will read the constitution. The /sdd-* commands depend on each tool's own slash-command
mechanism — if your tool has one, add a loader for it the way .github/prompts/ does for
Copilot; the workflow bodies themselves are plain Markdown with no tool-specific syntax. That is
deliberate: see Design Decisions.
Both tools read every skill's name and description up front so the model can decide to load
it — which means nine workflow descriptions in the system prompt of every request. These
workflows have side effects and should run only when you type them, so they are commands
instead. Full reasoning: Design Decisions.
Yes. /sdd-setup asks for your documentation language first and stores it as DocLanguage in
AGENTS.md. From then on every interview, report, spec, plan and Memory Bank file is written in
that language. FeatherSpec's own wiring stays English.
No. Using one costs you nothing — the other tool's entry points are a handful of one-line files. If you want them gone entirely, Committing to One Tool has the mechanical conversion.
A prompt is gone when the session ends. A spec, a plan and a Memory Bank are files in your repository: reviewable in a pull request, readable by your teammates, resumable next week, and usable by a different assistant. The traceability table also gives you something a prompt never can — when a requirement changes, you can see which steps, which code paths and which tests that change reaches, before you edit anything.
Probably not on day one, and the honest framing matters here. Spec-driven development is a variance-reduction technique, not a velocity technique: fewer confident wrong turns, a written record of why the code looks the way it does, and a chain from every acceptance criterion to the test that decides it. Trust your own measurements over your own impressions — developers are documented to be quite bad at estimating this, in both directions.
No, and doing so would be a mistake. AGENTS.md says work spec-first for anything that changes
behaviour — deliberately not always — and documents a fast path for changes smaller than the
spec that would describe them. The only rule is that the assistant says it is taking the
fast path, so you can disagree.
A workflow that demands three Markdown files for a config value teaches people that the workflow is theatre, and then they stop using it for the changes that actually needed it.
Because the context that produced an ambiguity is structurally the worst placed to find it.
/sdd-specify checking its own output is a reviewer grading its own homework — it fills the gap
from the conversation it just had, which is exactly what makes the gap invisible. /sdd-clarify
reads the spec cold, with no conversation history, and that is its only real advantage. It also
deliberately lists problems instead of resolving them: a model asked to resolve an ambiguity
resolves it silently with whatever is statistically plausible.
Both. The constitution in AGENTS.md is loaded in every session, so the spec-first behaviour,
the style preferences and the automatic architecture/memory sync apply without you asking. The
/sdd-* commands are the explicit workflows — they never fire on their own, by design.
Change the spec, then run /sdd-plan again. It detects that the spec changed (Mode C), reads the
traceability table in reverse, and reports which steps and which files the change reaches
before editing anything. New steps get appended; existing step IDs are never renumbered,
because they are referenced from commits and reports.
Yes — two Markdown files, no registration. See Extending FeatherSpec.
It is a machine-local note store your teammates never see and Copilot cannot read — effectively a
second, invisible Memory Bank. FeatherSpec keeps one visible source of truth. Set
"autoMemoryEnabled": true in .claude/settings.json if you want it back.
Yes. It is git-ignored on purpose — Claude Code writes it when you grant a permission with
"don't ask again", so it is personal to your machine. Anything the team should share goes in
.claude/settings.json. See Configuration.
Two screen pages, maximum. It is a handoff context, not a changelog. If it outgrows that, the surplus belongs in a more permanent file — Memory Bank has the table of where each kind of content goes.
Start here
Reference
Design & interop
- Interop Matrix
- Design Decisions
- Specify Method
- Committing to One Tool
- Migrating from the predecessor
Help