Skip to content

git-tasks open points #13

Description

@DiTo97

dumping notes on things to improve for git-tasks:

  • the git tasks skill which AI assistants read must clarify the correct granularity of what stories, sprints and epics are for the AI coding era. The time has shrunk massively, and so the way in which is split in stories and the time frame must be thought of for AI coding agents rather than humans (stories must be self-atomic pieces, but atomic for agents is much larger than atomic for users, still they should have correct dependencies, but should take max a few hours to a day, sprints have shrunk to a max three days, see Anthropic / Open AI, epics are now max two weeks). At the moment with the wording / resources the git tasks skill has, decomposition feels too anacronist for the AI era

  • some more attributes must be made mandatory when opening stories, sprints or epics, now the agent too often skips too many attributes. Think of which should always be necessary and make them mandatory

  • must improve the wiki usage. The wiki msut be used in two ways, and the both the CLI engine as well as the git tasks skills should better instruct on this: user can simply speak with his AI coding assistants with the skill loaded or dump notes, and when the assistant starts decomposing work to update / add / pause, first it dumps the new knowledge in the wiki, and then does the decompsoitok / PM work, using the wiki as a reference and source of truth for audit. Viceversa, the user may simply dump notes directly in the wiki, maybe in a specific notes / user / home whatever name subfolder, and when the AI assistant PM is started it should take those, elaborate them in the wiki and then start decomposing. This means the wiki has a raw space, where the user can contribute, and it has processed space made by the AI PM only, that works as an append only log, which helps with differnet source and channels of knowledge. The processed wiki must be ordered by time of arrival. Make sure both the command line tool and the skill foster that behavior. Everything must be auditable. See this for inspiration on the wiki: https://www.thetypicalset.com/blog/your-agent-framework-is-a-chatbot

  • the tool must ensure some stuff. But this could be done building hooks for the skill that trigger on specific events once loaded, think Claude Code way: when a task / story is picked up by the agent must always do so in it's worktree with an attached branch and an attached draft pull request, in isolation, may be nice if it spinner up in a local sandbox (docker sbx would great IMHO); when the story is updated with units of work, the draft pull request must be updated with comments, so its history can be reviewed as a story log. When a story goes from running to review, always make sure the draft pull request becomes a concrete pull request asking for review of the repo owner. The repo owner is among the repository card attributes git tasks should ask at the beginning if not set.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions