add-feature

name

add-feature

description

Deliver an OSS platform-core feature end-to-end: context collection -> plan + approval -> implementation -> unit/integration tests -> e2e test cases + run -> fixes -> create-pr -> Jira transition (only on explicit ask) -> Slack notice. Fed by a work-order (from the consumer add-feature handoff) or an OSS ticket. Use on "add feature", "plan <work-order>", "deliver this OSS change", or /add-feature [path|ticket]. Read-only until the plan is approved; never pushes without explicit OK.

add-feature (oss)

Platform-core twin of the consumer add-feature skill. Use in this repo when a consumer feature needs @openora/* core changes (via a work-order) or for a standalone core feature. Owns the whole development + delivery cycle.

1 context (+ GRILL) -> 2 plan + approval -> 3 implement -> 4 unit/integration tests
-> 5 review -> 6 e2e cases + run -> 7 fix loop -> 8 regen/verify -> 9 create-pr
-> 10 reviewers -> 11 Jira (ONLY if asked) -> 12 Slack draft

Coordinates

• Repo: github.com/blurifycom/openora. PR target: dev (chain dev -> stage + tags). Tool: gh CLI.
• Codebase inspection: oss-dev MCP (read-only). Headless backend - contracts + Hono + oRPC + Drizzle + react SDK + plugins. No UI here.
• Issue tracker / chat: use whatever MCP integrations the session has (Jira/Confluence, Slack). Chat notices are draft only, to the team's agreed channel. No integration connected: skip those steps silently.

The contract

• Read-only until the plan is approved. No edits/commits/pushes/Jira writes before sign-off.
• Never write to Jira unless the user explicitly asks for that specific write. Approving the plan or opening the PR is NOT Jira authorization. Reading is always fine.
• Reuse create-pr, /regen, /pre-pr, /verify. Delegate to the roster subagents - don't hand-write their work.

Steps

1. Resolve input + collect context (read-only)

$ARGUMENTS is a work-order path (eg ~/.claude/plans/<ticket>-oss.md) or a ticket. Read it (goal, consumer feature it unblocks, core surface, contract/schema impact, acceptance), then gather in parallel: the ticket (tracker MCP if connected), docs/ ADRs + catalog.json + openapi.json, the rule docs (conventions, clean-architecture, messaging-and-microservices, db-conventions), the codebase (oss-dev MCP + Explore), chat/wiki for prior design discussion (search the ticket key). Run the enhance-prompt pre-step on the ask first, so this gather stays scoped and 1a grills against a clear brief.

1a. Grill the user before planning (MANDATORY)

Tickets under-specify. Before writing the plan, surface every decision that changes the build via AskUserQuestion (batch up to 4, multiple rounds) - never assume a default silently. Each option leads with your recommendation + trade-off. Cover at minimum: scope edges (in vs out), domain + seam placement (which module owns it; boundary risk), data-model forks (enum vs additive, history vs current, nullable/defaults), regulatory angle (jurisdiction, gating, idempotency, audit actor/resource), reuse vs build (existing helper/port/route), in-flight collisions, config surface (platform-config vs code). Fold answers into the plan's "Locked decisions".

2. Plan + approval (the gate)

Present: goal, AC, locked decisions with sources, exact core surface (packages, contracts, tables, events, adapter tokens), boundary/breaking-change impact, risks, task breakdown mapped to subagents. Require explicit approval before editing.

3. Implement

Pick the implementer per slice: expert (fuzzy -> requirements, advisory), module-author (new module), plugin-author (overlay), dev (cross-module logic, contracts, services, SDK).

4. Unit + integration tests

The implementer ships co-located Vitest tests with the slice (vi-mocked Drizzle for services; bootTestApp for integration) - part of the deliverable, not an afterthought.

5. E2E

Derive the checklist from the AC first: happy path, edge cases, authz negatives (401/403), money/idempotency, audit entry per mutation. Then qa executes it API-level. E2e failures go back to the step-3 implementer BEFORE any review - don't review code that doesn't work.

6. Review (findings only)

In parallel: contract-reviewer (boundaries, contract/schema drift, breaking changes) + security-reviewer (money, authz, PII) + quality-reviewer (performance, duplication, simplification, conventions). Pass each what the e2e run proved so reviewers dig where tests can't reach. Loop findings back to the implementer; re-review if the surface changed, and re-run the affected e2e checks if a fix changed behavior.

7. Fix loop

Every review/e2e finding goes back through the step-3 implementer until green; re-run the affected check after each fix.

8. Regen + verify

/regen if contracts/Drizzle changed; docs agent only if prose docs / agent surface changed; /pre-pr (pnpm verify + pnpm check:drift). Don't proceed on red or a catalog diff.

9. Open the PR

Invoke create-pr (target dev). It commits conventional, reports the SHA, asks for "yes push", then pushes and opens the PR. Never bypass the push-consent gate.

10. Reviewers from CODEOWNERS

Match changed paths against CODEOWNERS, then gh pr edit <num> --add-reviewer <owners>. PR description = plan summary + AC + bare ticket key (ABC-45, never a URL). No internal links/hostnames/secrets/PII.

11. Jira - ONLY on explicit user request

No transition, comment, worklog, or link by default. When the user asks in their own words (eg "move ABC-210 to Code Review"): fetch valid transitions via the tracker MCP, apply the matching one. Never post PR-link/status comments on the ticket.

12. Slack notice

Draft (never direct-send) a single line to the team's agreed notice channel: emoji + PR/task name as a link, eg 👉 RBAC backend - PR #11.

Rules

• Grill before you plan; read-only until approval; never push without a per-action "yes push".
• /pre-pr green before push; /regen after any contract/schema change.
• One PR = one concern; respect boundaries (no cross-module imports).