// RFC and specification workflow for Dada language features. Use when working with RFCs, writing spec paragraphs, or tracking implementation progress.
Conventions for authoring Rust code in the Dada compiler. Use when writing or modifying Rust code, adding functions, or making implementation changes.
Track context across sessions for long-running features. Use when starting multi-session work, checkpointing progress, or resuming work on a feature tracked in a GitHub issue.
Run and interpret Dada test results. Use when running tests, debugging test failures, or understanding test output.
Write spec-aligned Dada tests. Use when creating new test files, organizing tests to match the specification, or adding test coverage for language features.
| name | rfc-workflow |
| description | RFC and specification workflow for Dada language features. Use when working with RFCs, writing spec paragraphs, or tracking implementation progress. |
This skill covers the practical RFC and spec integration workflow.
rfcs/src/NNNN-feature-name/
├── README.md # The RFC document (design, motivation, examples)
├── impl.md # Implementation progress tracking
└── todo.md # Session-specific work tracking and context
Create new RFCs with: cargo xtask rfc new feature-name
Spec paragraphs live in spec/src/ using MyST directive syntax.
:::{spec} local-name tag1 tag2
Paragraph content describing one testable behavior.
:::
Tags:
rfcNNNN — Links paragraph to an RFC (e.g., rfc0001)unimpl — Feature is specified but not yet implementedInside a block, mark sub-items with inline spec tags:
:::{spec} rfc0001
String literals support these escape sequences:
* {spec}`backslash` `\\` produces a literal backslash.
* {spec}`newline` `\n` produces a newline.
:::
Each {spec}`name` creates a sub-paragraph with its own ID. Tags like unimpl can follow the name: {spec}`triple-quoted unimpl`.
file-prefix.heading-segment.local-name.inline-name
syntax.string-literals):::{spec} local-name{spec}`name`Design is mature → Author directly in spec/src/ with rfcNNNN unimpl tags. This is the preferred approach — it validates the spec structure early.
Design is still evolving → Draft in the RFC's spec.md, then move to spec/src/ during implementation.
The key insight: if you know enough to write a spec paragraph, put it in the spec. The unimpl tag makes it clear it's not yet implemented.
Track implementation progress in the RFC's impl.md:
# Implementation Progress
## Status: In Progress
### Completed
- [x] Spec paragraphs drafted in spec/src/
- [x] Basic string literal parsing
### In Progress
- [ ] Triple-quoted string support
### Not Started
- [ ] String interpolation
Track session-specific context in todo.md:
# Current Session
## Focus
What we're working on right now
## Next Steps
- Specific actionable items
## Open Questions
- Things still being figured out
#:spec syntax.string-literals.escape-sequences.backslashrfc0001 tag on :::{spec} directivesKeep these synchronized. When adding a new spec paragraph, check if tests exist. When writing tests, add the #:spec annotation.
When implementing an RFC feature, follow this cycle for each piece of work:
#:spec annotationsunimpl from the spec paragraph tagimpl.md — check off completed items, add new items discovered during implementationKeep impl.md current as you go. It's the living record of what's done and what's next — don't wait until the end of a session to update it.