* Create `nbd` tickets for each item including your plan, breaking the problem down into smaller tickets where it makes sense.
* Create `nbd` tickets for each item including your plan, breaking the problem down into smaller tickets where it makes sense.
* Include relevant source files, documentation, and context about each ticket so the work has the higest probability of success without additional context being required.
* Include relevant source files, documentation, and context about each ticket so the work has the higest probability of success without additional context being required.
* Commit these tickets in the `.nbd` directory with a concise summary of each ticket, probably using the title and ticket IDs.
* If a file was passed to this skill, remove items from the file which now have a ticket.
* Commit these tickets in the `.nbd` directory with a concise summary of each ticket, probably using the title and ticket IDs, and the file passed to this skill if one was passed.
`nbd init` should add `.nbd/cache.db` to `.nbd/.gitignore` since this should not be included in git commits.
---
Add a `.nbd/config.toml` config file that sets some defaults to start:
* All under the `[nbd]` header
* default output format: json=[true|false]
* default file type (default is json)
* default status (default is todo)
`nbd init` should create this file with default values populated.
---
Add the `triage` status to tickets for tickets which do not have enough information to be worked on.
An LLM will update the body of the ticket with implementation details and move it to `todo`.
claude-md should be updated to mention this workflow that `triage` tickets require more details to be worked on and that they should be updated with implementaiton detials before being moved to `todo`.
`triage` is also the new default state for tickets, so update claude-md to create tasks with `--status=todo` if the ticket is ready to be worked on.
---
To triage: need to investigate some way to filter tickets by project.
For example, you have two streams of work and you want to select tickets for one project only.
We have the `project` type of ticket, and we can add `deps` to support that... maybe?
---
To triage: What would be the implications of making `type` and `status` just strings?
I want to enforce a set of possible values, but I also want those to be user-set so we don't need to constantly update the code base to support additional types.
Some of these are "special" though like `done` and `archive` do not show up in `list` or `ready`; can we abstract those behaviors and have users set "Pre/During/Post" options for type and status to preserve the behavior we have while making the system ultimately more flexible?
Elijah Voigt
3 months ago