Summary
This is a feature request to add a new command to the contextvibes CLI for closing GitHub issues, mirroring the functionality of gh issue close.
Problem Statement
Currently, the contextvibes CLI provides high-level wrappers for many daily workflow tasks, such as kickoff, commit, and finish. However, when a developer needs to close an issue that has been resolved (for example, a duplicate or an issue resolved by a different PR), they must drop out of the contextvibes workflow and use the lower-level gh command directly (gh issue close <number>).
This creates an inconsistency in the user experience and forces a context switch away from our primary command interface.
Proposed Solution
Introduce a new command, structured similarly to the existing factory or a new project pillar command. A logical structure would be:
contextvibes project issue close <issue-number> [--comment "An optional closing comment."]
This command would act as a direct wrapper around the gh issue close <issue-number> --comment "..." command, providing the same functionality within our standardized toolchain.
Benefits
- Consistent Workflow: Keeps developers within the
contextvibes ecosystem for all standard repository interactions.
- Reduced Cognitive Load: Developers would not need to remember the specific
gh syntax, as it would be handled by our high-level API.
- Completes the Issue Lifecycle: Complements the
finish command by providing a tool to manage the full lifecycle of an issue within the CLI.
Context
- CLI Version:
dev
- OS/Arch:
linux/amd64
- Filed by: @duizendstra
Summary
This is a feature request to add a new command to the
contextvibesCLI for closing GitHub issues, mirroring the functionality ofgh issue close.Problem Statement
Currently, the
contextvibesCLI provides high-level wrappers for many daily workflow tasks, such askickoff,commit, andfinish. However, when a developer needs to close an issue that has been resolved (for example, a duplicate or an issue resolved by a different PR), they must drop out of thecontextvibesworkflow and use the lower-levelghcommand directly (gh issue close <number>).This creates an inconsistency in the user experience and forces a context switch away from our primary command interface.
Proposed Solution
Introduce a new command, structured similarly to the existing
factoryor a newprojectpillar command. A logical structure would be:This command would act as a direct wrapper around the
gh issue close <issue-number> --comment "..."command, providing the same functionality within our standardized toolchain.Benefits
contextvibesecosystem for all standard repository interactions.ghsyntax, as it would be handled by our high-level API.finishcommand by providing a tool to manage the full lifecycle of an issue within the CLI.Context
devlinux/amd64