---
name: talentco-feature-planning
description: Runs pre-plan discovery for TalentCo (and related) work before Plan mode or a written plan. Asks about approach, code patterns (established vs emerging vs drift), UI adoption vs deprecations, agent-interactive concerns (tools, streaming, TanStack cache, artifacts), API/server, client-config, and TalentCo-only vs cross-tenant scope. Use when planning a feature, entering Plan mode for TalentCo, or scoping VITE_CLIENT_CONFIG / client-config work.
---

# TalentCo feature planning (pre-plan gate)

## When to apply

- **Before** switching to Plan mode or drafting a formal implementation plan.
- When the user names a new feature, slice, or refactor for **TalentCo** or **labs** in this monorepo.
- When it is unclear whether work is **tenant-specific** or should generalize to **all clients** selected via `CLIENT_CONFIG` / `api/client-config.json`.

Do **not** skip this pass for “small” features if they might touch routing, config, or shared backend patterns.

## Required discovery (ask the user)

Ask explicitly — use one message or a short structured list, not a lecture. Cover each bucket below when **relevant**; it is fine to combine related items.

### 1. Approach and considerations

- Preferred **direction** (e.g. extend existing flow vs new surface, reuse patterns vs net-new).
- **Constraints:** timeline, must-not-break, compliance, or dependencies on other teams or systems.
- **Risks or unknowns** the user already cares about.

### 2. Code patterns (when relevant)

The codebase mixes **mature, accepted** patterns, **newer** patterns still being established, and **rare** deprecation. Before planning:

- **Read** nearby code and shared layers to infer **evident** patterns (naming, folder layout, error shape, DDD/ports, Ninja vs other boundaries).
- **Ask** the user if unclear:
  - What patterns to **build on** (extend existing abstractions).
  - What is **emerging** and should stay consistent so it can become the new default.
  - Whether anything in touch range is **deprecated or slated for change** (unusual, but call it out if seen in comments or refactors in flight).

Aim to **reduce drift**: prefer extending established patterns over parallel styles unless the user wants a deliberate break for a listed reason.

### 3. UI / Labs and consistency

- **Surfaces in scope** (which app areas, new vs existing routes, navigation).
- **Reality check:** UI/UX and client theming are **not fully consistent** today; the goal is to **converge**. For this slice, ask what **approach to adopt** (and align with [docs/TALENTCO_UI_PATTERNS.md](../../../docs/TALENTCO_UI_PATTERNS.md) and current Labs patterns) and what **old styles or one-offs** to **stop extending** (deprecate or replace in scope vs later).
- **Client branding:** TalentCo-only UI vs behavior that should follow shared Labs patterns for other `VITE_CLIENT_CONFIG` values.
- If the slice is interaction-heavy, use [ui-ux-application-planning](../ui-ux-application-planning/SKILL.md) for a deeper UI audit **after** scope is clear.

### 4. Agent interactivity (when relevant)

Many features are **agent-interactive**. If the work touches the agent path, client tools, or streamed UI, **examine or ask** as needed:

- **Tool design** — contract with the agent (inputs/outputs, errors, idempotency) and how tools map in `client-config` / `toolMappings` when applicable.
- **Streaming** — Anthropic (or current stack) **streaming deltas** and how the UI consumes partial updates.
- **TanStack Query** — queries, mutations, and **cache invalidation** so agent-driven updates stay coherent in the client.
- **Human/agent artifacts** — **collaborative editing** of artifacts is an active direction; note if the feature should align with that trajectory or stay read-only for now.

### 5. API / server

- Whether the work needs **new or changed** Django/Ninja routes, models, migrations, background jobs, or permissions.
- **Data contracts:** new fields, events, or integrations (webhooks, external APIs).

### 6. Client config

- Whether the feature needs **`api/client-config.json`** (or env) changes: `toolMappings`, feature flags, tenant metadata, or Labs-only toggles.
- **Environment parity:** what must work under local `CLIENT_CONFIG` vs production for TalentCo (and other tenants if shared).

### 7. Scope: TalentCo vs all clients in config

Ask plainly:

- Is this **only for TalentCo** (accept tenant-specific branches where the codebase already does so)?
- Or should the design **benefit or apply to all clients** in the multi-tenant config (shared defaults, no TalentCo-only forks unless necessary)?

Capture **implications** for non-TalentCo tenants: breaking changes, opt-in flags, or documentation updates.

## After answers

- **If discovery is incomplete** — ask follow-ups until the relevant buckets are addressed or the user defers a bucket with an explicit “out of scope for now.”
- **Then** proceed to Plan mode or a written plan, aligned with the user’s answers.
- **Cross-link:** For full UI/UX and agent-surface planning, [ui-ux-application-planning](../ui-ux-application-planning/SKILL.md); for Linear issue hygiene, [linear-issues-talentco](../linear-issues-talentco/SKILL.md).

## Anti-patterns

- Entering Plan mode with **no** question about cross-tenant impact when the work might touch shared Labs or `client-config.json`.
- Assuming **API-only** or **UI-only** without asking; many features need both.
- **Skipping** client-config questions for anything that changes tools, features visible per tenant, or default behavior.
- **Adding a third UI pattern** for the same concern without asking whether to **converge** on an existing approach or **replace** a legacy one.
- Treating **agent-adjacent** work like plain CRUI without checking tools, streaming, and **cache coherence** (TanStack) when the feature is interactive.