ref: 70304f799207e7dc84dbe877cbb9e3b8eeec2ee1
dir: /README.md/
## Task files # A synopsis of the task [ ] some item [ ] some other item [x] some finished item - /path/to/myproject/2 ## Commands `task/init` is use to create a new barebones project, with no tasks or namespace files. The project will be created with the basename of current directory, or `name` if given. (See [this post](https://hlfw.ca/blog/2024-08-24-more-setup.html) for inspiration, and further integration.) `task/add` is used to manage or add a task to the graph, usage is similar to git/commit - the hold editor will be used by default, ctrl+d is used to signal completion. `-c $tag` is used to change an existing task. Passing `-e` will use your default editor instead of hold mode. Any args afterwards will be passed along as the `synopsis` for the task `task/rm` removes a given completed task. With `-f`, all matching tags are removed. With `-a`, all completed tags are checked for removal. `task/walk` shows the status of tasks in the graph. It prints a list of tasks prefixed with the status character. The -c flag disables printing the status characters. The -p flag will only search within the given project. The -q option suppresses all output. The -f option filters tasks by status, and only matching items are printed. By default, the filters are DNS. The task status characters are as follows: - A This task has been attempted, but is blocked - B This task has not been attempted, and is blocked - D This task is completed - N This task has not been attempted - S This task has been attempted *Blocked tasks have a child task that requires completing before they can be completed `task/show` prints a formatted task to stdout, when passed -r it will print the raw task file ## TODO - make commands work from any child directory - `task/walk` implementation - multi-project awareness for all utils. A task should be able to reference another project via a tag, such as `projectname/tag` - Showcase plumbing integration - potential git integration (completed new task, git/commit could parse the .task/ directory, add the synopsis of the completed ones and/or a formatted task lists, and then finally task/rm the task after committing) ## Multi-project Thoughts A `task/fs` could be spun up, given a set of paths that your projects live somewhere within, by default the user $home, and could walk the paths looking for .task directories. - This would allow utilities to query the fs for valid tags and completion states outside of the current project.