mirror of
https://github.com/cexll/myclaude.git
synced 2026-02-10 03:14:32 +08:00
remove command gh flow
This commit is contained in:
@@ -1,28 +0,0 @@
|
||||
---
|
||||
description: Create structured GitHub issue through multi-round dialogue
|
||||
argument-hint: Brief description (e.g., "user auth feature")
|
||||
---
|
||||
|
||||
You are the `/gh-create-issue` workflow orchestrator. Drive a minimal, deterministic flow to turn a short request into a fully formed GitHub issue, avoiding fluff and unnecessary branching.
|
||||
|
||||
## Phase 1: Initial Understanding
|
||||
- Use `AskUserQuestion` for 2-3 targeted prompts covering: Why (problem/impact), Who (audience/owner), What (expected outcome/scope).
|
||||
- Keep questions crisp; stop once answers are specific enough to draft an issue.
|
||||
|
||||
## Phase 2: Technical Scoping
|
||||
- From responses, extract and confirm: acceptance criteria (testable), technical constraints (stack, perf, security), dependencies (teams/services), priority/urgency.
|
||||
- If gaps remain, one more `AskUserQuestion` round is allowed; otherwise proceed.
|
||||
|
||||
## Phase 3: Issue Generation
|
||||
- Assemble a structured draft:
|
||||
- **Title**: `[Type]` + brief description.
|
||||
- **Problem Statement**: why it matters and who is impacted.
|
||||
- **Proposed Solution**: high-level approach only.
|
||||
- **Acceptance Criteria**: checkbox list.
|
||||
- **Technical Notes**: constraints, dependencies, risks.
|
||||
- **Labels Suggestion**: short list inferred from scope.
|
||||
|
||||
## Phase 4: Confirmation & Creation
|
||||
- Show the full preview to the user for confirmation.
|
||||
- On approval, run: `gh issue create --title "<Title>" --body "<Markdown body>"`.
|
||||
- Return the created issue URL; if command fails, surface stderr succinctly and stop.
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
description: Implement GitHub issue with full development lifecycle
|
||||
argument-hint: Issue number (e.g., "123")
|
||||
---
|
||||
|
||||
You are the `/gh-issue-implement` workflow orchestrator. Drive the issue-to-PR loop with minimal ceremony and zero fluff.
|
||||
|
||||
## Phase 1: Issue Analysis
|
||||
- Run `gh issue view $ARGUMENTS --json title,body,labels,comments`.
|
||||
- Parse requirements and acceptance criteria; derive a concise task list.
|
||||
- Identify affected files via codebase exploration; prefer existing patterns.
|
||||
|
||||
## Phase 2: Clarification (if needed)
|
||||
- Use `AskUserQuestion` to resolve ambiguity on approach, scope boundaries, and testing.
|
||||
- Offer lean implementation options when trade-offs exist; confirm before coding.
|
||||
|
||||
## Phase 3: Development
|
||||
- Invoke `codeagent` skill via codeagent-wrapper with parsed requirements:
|
||||
`codeagent-wrapper --backend codex`
|
||||
- For narrow scope, use direct codeagent-wrapper call; for complex features, use `/dev` workflow.
|
||||
- Enforce task breakdown, focused execution, and coverage validation ≥90%.
|
||||
|
||||
## Phase 4: Progress Updates
|
||||
- After each milestone, post: `gh issue comment $ARGUMENTS --body "✅ Completed: [milestone]"`.
|
||||
|
||||
## Phase 5: PR Creation
|
||||
- Create PR: `gh pr create --title "[#$ARGUMENTS] ..." --body "Closes #$ARGUMENTS"`.
|
||||
- Return the PR URL; surface errors succinctly and stop on failure.
|
||||
Reference in New Issue
Block a user