Plan Issue - GitHub Issue to Implementation Plan

Fetch issue $ARGUMENTS from bbvch-ai/aihub-core and produce a scoped implementation plan.

Step 1: Fetch the Issue

Use the gh CLI (there is no GitHub MCP server) to gather structured issue data:

gh issue view $ISSUE_NUMBER -R bbvch-ai/aihub-core --json title,body,author,assignees,labels,milestone,comments
gh api repos/bbvch-ai/aihub-core/issues/$ISSUE_NUMBER/sub_issues
gh api repos/bbvch-ai/aihub-core/issues/$ISSUE_NUMBER/dependencies/blocked_by

Comments hold clarifications and decisions; sub-issues hold the task breakdown if present.

Optionally check the project board for priority and status context:

gh project item-list 13 --owner bbvch-ai --format json | jq '.items[] | select(.content.number == $ISSUE_NUMBER)'

Extract from the issue: Goal (what needs to be achieved), Constraints (requirements or limitations), Context (related issues, PRs, or decisions).

Step 2: Identify Affected Scopes

Map the issue requirements to monorepo scopes:

For each affected scope:

1. Read {scope}/CLAUDE.md to understand its architecture and patterns
2. Search for related code with Grep and Glob
3. Read key files that will need modification
4. Note existing patterns the implementation should follow

Step 3: Check Existing ADRs

ls docs/arc42/decisions/

Read any ADR that covers related technology choices. Flag if the implementation approach may need a new ADR (new dependency, new framework, fundamental pattern change).

Step 4: Identify Relevant Skills

Check if scaffold skills exist for the type of work needed:

• New agent → /scaffold-agent
• New pipeline → /scaffold-pipeline
• New API endpoint → /scaffold-api-endpoint + /scaffold-api-service + /scaffold-api-repository
• New frontend page → /scaffold-frontend-page + /scaffold-composable
• New bot handler → /scaffold-bot-handler
• New event type → /nats-events

Reference these in the plan so the implementer can invoke them.

Step 5: Create the Plan

Structure the plan with these sections:

1. Issue Summary — one-sentence goal
2. Affected Scopes — which scopes are touched and why
3. Implementation Steps — each step must reference:
   • Concrete file paths (not placeholders)
   • Existing pattern to follow (a real file in the codebase)
   • Relevant scaffold skill if applicable
4. Cross-Scope Impact — if packages/core changes, list downstream scopes that need testing
5. Event System Impact — new Control or Display events needed? Check packages/core/swiss_ai_hub/core/events/
6. Testing Strategy — which scopes need make test, new test files needed
7. ADR Needed? — yes/no with justification
8. Risks — ambiguities that need team input before starting

Rules

• Every step must reference concrete files from the codebase, not placeholders
• Follow existing patterns — read the scope's CLAUDE.md before proposing new abstractions
• Identify step dependencies (what must happen first — typically packages/core before downstream scopes)
• If packages/core is modified, list all downstream scopes that import from it

Troubleshooting

Done When

• Plan references concrete file paths from the codebase (no placeholders)
• All affected scopes identified with their CLAUDE.md consulted
• Relevant ADRs checked and referenced
• Applicable scaffold skills listed for the implementer
• Cross-scope dependencies mapped