jackin-project jackin-brainstorm
Turn an existing roadmap item's intent (and any gathered research) into concrete design decisions, through open back-and-forth with the operator, written incrementally into the item's ## Design section.
Judgment task — describe and decide; do not script it, do not write code, do not break work into tasks (that is plan, deferred).
When to use
- Operator runs
jackin-brainstorm <slug>to design an open roadmap item.
When NOT to use
- Creating the item →
jackin-propose. - Large external/codebase investigation →
jackin-research. - Implementing →
/goal Implement <slug>.md.
Arguments
--research— runjackin-researchfirst if the item looks thin.--resume— continue from the current## Designstate.
Process
- Load context. Read
docs/content/docs/roadmap/<slug>.mdx— Problem, Why It Matters, Design-so-far, Related Files — plus any research already linked. - Discuss freeform. Open back-and-forth: surface alternatives, trade-offs, open questions. Pull in jackin❯ design principles and the relevant rule files (
ENGINEERING.md,HOST_AND_CONTAINER.md, TUI/docs rules) as constraints. Prefer one question at a time; check in as each part settles. - Write incrementally. As each point settles, append or update the matching part of
## Designin the.mdx— the decision plus a one-line why.--resumepicks up from there. - Hit an unknown? Gather quickly (Explore/grep, or
deep-research). Large investigation → spin a separatejackin-researchdossier and link it from## Design. Then resume deciding. - Converge. When
## Designcovers the approach end to end, summarize and point at the implementation step (/goal Implement <slug>.md). - Commit + push.
docs:per settled chunk (push after every commit).
Common mistakes
- Writing code, or filling
## Tasks— out of scope. - Dumping a finished design without the back-and-forth, or asking many questions at once.
- Recording decisions only in chat instead of into
## Design(it must be resumable). - Restating rule-file content instead of referencing it by name.