Menü
Create implementation plan with cross-repo codebase analysis
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | plan |
| description | Create implementation plan with cross-repo codebase analysis |
| argument-hint | <issue-number | feature description | path/to/prd.md> [issue-number ...] [--research | --no-research] |
Input: $ARGUMENTS
Transform input into a context-rich, battle-tested implementation plan.
Core Principle: PLAN ONLY — no code written.
Order: CODEBASE FIRST. Solutions must fit existing patterns in both orbit-ui-mobile and orbit-api.
First strip any --research / --no-research flag from $ARGUMENTS (it controls Phase 2.5 only); the remainder is the plan input. Then parse $ARGUMENTS and count numeric tokens (123, #123) — split on whitespace OR commas.
| Numeric arg count | Mode |
|---|---|
| 0 or 1 (or any non-numeric input) | Single-plan — continue with the phases below. |
| ≥ 2 | Multi-plan — jump to the "Multi-plan mode" section. |
| Input | Action |
|---|---|
Numeric (123) or #123 | Fetch issue from orbit-ui-mobile via gh issue view |
.prd.md file | Read PRD, extract next pending phase |
Other .md file | Extract feature description |
| Free-form text | Use directly |
| Blank | Use conversation context |
gh issue view {N} --repo thomasluizon/orbit-ui-mobile --json number,title,body,labels,milestone
Extract:
Repos value from labels (repo:frontend, repo:backend, repo:both)parity-required label (if present, both web + mobile must be updated)/implement will close it after completion.Use the Explore subagent for breadth. Search areas based on Repos:
If frontend (or both):
apps/web/app/(app)/ and apps/mobile/app/apps/web/components/ and apps/mobile/components/apps/web/hooks/ and apps/mobile/hooks/apps/web/app/actions/packages/shared/src/types/packages/shared/src/query/keys.tspackages/shared/src/api/endpoints.tspackages/shared/src/i18n/en.json, pt-BR.jsonIf backend (or both):
C:\Users\thoma\Documents\Programming\Projects\orbit-api\src\Orbit.Application\C:\Users\thoma\Documents\Programming\Projects\orbit-api\src\Orbit.Domain\Orbit.Application\<Feature>\Validators\ and Orbit.Application\Habits\Validators\SharedHabitRules.csOrbit.Api\Controllers\tests\Orbit.Application.Tests\ (+ Orbit.Domain.Tests, Orbit.Infrastructure.Tests) — unit tests only, no integration suite| Category | Repo | File:Lines | Pattern |
|---|---|---|---|
| FRONTEND_NAMING | ui-mobile | apps/web/... | ... |
| FRONTEND_HOOK | ui-mobile | apps/mobile/hooks/... | ... |
| BACKEND_CQRS | api | src/Orbit.Application/... | ... |
| BACKEND_VALIDATOR | api | src/Orbit.Application/.../Validators/... | ... |
| TESTS | both | apps/web/__tests__/... + tests/Orbit.Application.Tests/... | ... |
Most plans need NO web research — /plan fits work into existing Orbit patterns, and Phase 2 already surfaces the pattern to mirror. Reach for /deep-research only when the task has a genuine open decision the codebase doesn't answer.
Trigger deep-research when EITHER:
--research was passed (force it), ORCLAUDE.md; or the issue itself asks an open "what's the best way to X."Skip (the common case) when Phase 2 found a clear pattern to mirror, the task is routine CRUD/feature/bugfix/parity work, or --no-research was passed. State in one line that research was skipped and why.
How: invoke /deep-research "<the specific open question>" scoped to the decision, not the whole feature (e.g. "best way to do optimistic offline sync for habit logs in Expo + TanStack Query", not "plan the habits feature"). Fold its recommendation into Phase 3 as the chosen approach, and cite its sources in the plan's Patterns/Risks. In multi-plan mode, run the research inline (apply the deep-research method directly) rather than nesting a /deep-research skill call.
Guardrail — Orbit conventions win. deep-research surfaces external best practice; it does not override Orbit's deliberate choices. When a finding conflicts with CLAUDE.md, DESIGN.md, an established codebase pattern, or cross-platform parity, the Orbit convention wins — note the deviation and why. Never let a generic recommendation pull the plan off-anchor.
repo:both: define the implementation order so each step is independently runnable (backend stub deployable before frontend consumes it)If touching apps/web, you almost always also touch apps/mobile. List the parallel files:
| Web | Mobile | Same logic? |
|---|---|---|
apps/web/hooks/use-foo.ts | apps/mobile/hooks/use-foo.ts | yes/no |
| Risk | Mitigation |
|---|---|
| {issue} | {handling} |
Output path: .claude/plans/{kebab-case-name}.plan.md
mkdir -p .claude/plans
# Plan: {Feature Name}
## Summary
{One paragraph: what we're building and the approach}
## User Story
As a {user type}
I want to {action}
So that {benefit}
## Metadata
| Field | Value |
|---|---|
| Type | NEW_CAPABILITY / ENHANCEMENT / REFACTOR / BUG_FIX |
| Complexity | LOW / MEDIUM / HIGH |
| Repos | frontend / backend / both |
| Parity Required | yes / no |
| GitHub Issue | #{N} (or "N/A") |
| Web Affected | yes / no |
| Mobile Affected | yes / no |
---
## Patterns to Follow
### Frontend (skip if backend-only)
#### Naming
// SOURCE: apps/web/.../file.ts:lines {actual snippet}
#### Hooks
// SOURCE: apps/mobile/hooks/use-X.ts:lines {actual snippet}
#### Server Action / API call
// SOURCE: apps/web/app/actions/X.ts:lines {actual snippet}
### Backend (skip if frontend-only)
#### Command / Query
```csharp
// SOURCE: orbit-api/src/Orbit.Application/Habits/Commands/CreateHabit.cs:lines
{actual snippet}
// SOURCE: orbit-api/src/Orbit.Application/Habits/Validators/CreateHabitValidator.cs:lines
{actual snippet}
// SOURCE: orbit-api/src/Orbit.Api/Controllers/HabitsController.cs:lines
{actual snippet}
// SOURCE: apps/web/__tests__/use-X.test.ts:lines (frontend unit) / orbit-api tests/.../CreateXHandlerTests.cs:lines (backend unit)
{actual snippet}
| Repo | File | Action | Purpose |
|---|---|---|---|
| ui-mobile | packages/shared/src/types/X.ts | CREATE | Zod type |
| ui-mobile | packages/shared/src/api/endpoints.ts | UPDATE | Add endpoint |
| ui-mobile | apps/web/app/actions/X.ts | CREATE | Server action |
| ui-mobile | apps/web/hooks/use-X.ts | CREATE | TanStack hook |
| ui-mobile | apps/mobile/hooks/use-X.ts | CREATE | Mobile hook (parity) |
| api | src/Orbit.Application/X/Commands/CreateX.cs | CREATE | CQRS command |
| api | src/Orbit.Api/Controllers/XController.cs | UPDATE | Add endpoint |
| api | src/Orbit.Infrastructure/Migrations/AddX.cs | CREATE | EF migration |
Execute in order. Each task is atomic and verifiable. Group by repo for clarity, but list cross-repo dependencies.
path/to/filepath/to/example:lines — follow this patternnpm run type-check (ui-mobile) / dotnet build (api){Continue for each task.}
npm run lint
npm run type-check
npm test
dotnet build
dotnet test
List concrete E2E steps /implement must execute. Examples:
dotnet run --project src/Orbit.Api in orbit-apinpm run web in orbit-ui-mobileparity-required: yesParity Required: yes (both web and mobile updated and behave the same)
---
## Phase 5: OUTPUT
```markdown
## Plan Created
**File**: `.claude/plans/{name}.plan.md`
**Repos**: frontend / backend / both
**Issue**: #{N} (or "N/A")
**Summary**: {2-3 sentences}
**Scope**:
- {N} files to CREATE
- {M} files to UPDATE
- {K} total tasks
- Affects: orbit-ui-mobile / orbit-api / both
**Key Patterns**:
- {Pattern 1 with file:line}
- {Pattern 2 with file:line}
**Next Step**: Review the plan, then `/implement .claude/plans/{name}.plan.md`
User passed 2+ issue numbers. Generate one plan per issue, in parallel via subagents in their paired worktrees.
For each issue N, check that the paired worktrees exist:
C:/Users/thoma/Documents/Programming/Projects/orbit-ui-mobile/.claude/worktrees/issue-<N>C:/Users/thoma/Documents/Programming/Projects/orbit-api/.claude/worktrees/issue-<N> (if applicable)If a worktree is missing, run /prime <N1> <N2> ... first (or surface the error and ask the user to do so).
Use the Agent tool to spawn ONE subagent per issue, in parallel. Each subagent:
cwd set to the orbit-ui-mobile worktree for that issue..claude/plans/issue-<N>.plan.md inside the worktree.Concurrency cap: 3 subagents at a time. Queue the rest.
Print one row per issue showing plan path + scope + complexity. Surface any subagent failures with the error message and the worktree path so the user can iterate manually.
Issue Plan Files Tasks Complexity
#100 .claude/worktrees/issue-100/.claude/plans/... 12 8 MEDIUM
#101 .claude/worktrees/issue-101/.claude/plans/... 4 3 LOW
#102 .claude/worktrees/issue-102/.claude/plans/... FAILED ...
Suggested next step: /implement <N1> <N2> <N3> (continues the parallel flow).
Deep code review of a diff across both Orbit repos against one shared rubric, orchestrating the five review subagents and a backward-compat guard. Use when the user asks to review a PR, file, folder, or staged changes in orbit-ui-mobile or orbit-api. Replaces /review and /security-review.
Get an independent cross-model second opinion (GLM-5.2 via opencode) on a specific, load-bearing technical claim or a Critical code-review finding — a different model reads the claim + code and returns AGREE / DISAGREE / UNSURE. Use to stress-test a single Critical finding, a risky assertion, or a close call before you commit to it. Auto-fired inside /pr-review on each Critical finding that survives the skeptic. Not for open-ended research (use /deep-research) or multi-lens judgement (use /llm-council).
Break a PRD into GitHub issues across orbit-ui-mobile + orbit-api
Answer an open-ended "what's the best way to…?" question with orchestrated multi-agent deep web research. Decompose the question, fan out narrow research subagents in parallel, verify the load-bearing claims adversarially, iterate to saturation, then synthesize ONE opinionated, source-backed, decision-ready recommendation. Orbit-aware (dual-repo stack, solo-dev cost calibration). Use for technology/vendor choices, architecture & tooling decisions, cost comparisons, migration approaches, or best-practice questions — anything whose answer needs current external evidence beyond the codebase. Not for code edits, single-fact lookups, or questions answerable from the repo alone.
Prime agent with Orbit project context (both repos + optional GitHub issue)
Repo-wide code-quality audit across both Orbit repos against the same rubric /pr-review uses. Reports dead/stale code, SOLID/clean-arch violations, comment-policy breaks, DRY, naming, function size, and DESIGN.md drift — each finding evidence-backed with file:line. Use when the user asks to audit code quality, find tech debt, or check the codebase against the standards. Not for a single diff (use /pr-review).