Дом

Skill

Производительность и рабочий процесс

product-capability

affaan-m/ECC

Превратите техническое задание на продукт, спецификации PRD или обсуждения дорожной карты в четкие, готовые к реализации планы функциональных возможностей с указанием ограничений, инвариантов, интерфейсов и открытых вопросов до начала межсервисной работы.

...Расширить все

Обновлено время 12 октября 2026 г.

# roadmap # prd # capability plan # constraints # engineering planning # product capability # srs

Возможности продукта

Этот навык позволяет преобразовать замысел продукта в четкие технические ограничения.

Используйте его, когда проблема заключается не в том, «что нам следует создать?», а в том, «что именно должно быть выполнено до начала реализации?».

Когда использовать

Имеется PRD, пункт дорожной карты, обсуждение или записка основателя, но ограничения реализации по-прежнему остаются неявными
Функция затрагивает несколько сервисов, репозиториев или команд и требует согласования возможностей перед началом программирования
Цель продукта ясна, но последствия для архитектуры, данных, жизненного цикла или политики по-прежнему неясны
Старшие инженеры постоянно повторяют одни и те же скрытые допущения во время ревью
Вам нужен многократно используемый артефакт, который сохранится при переходе между наборами тестов и сессиями

Канонический артефакт

Если в репозитории есть постоянный файл с контекстом продукта, например PRODUCT.md, каталог docs/product/ или каталог со спецификациями программы, обновите его там.

Если манифест возможностей ещё не существует, создайте его, используя шаблон по адресу:

docs/examples/product-capability-template.md

Цель не в том, чтобы создать ещё один стек планирования. Цель — сделать скрытые ограничения возможностей устойчивыми и многоразовыми.

Неподлежащие обсуждению правила

Не придумывайте «истину» о продукте. Явно отмечайте нерешенные вопросы.
Отделяйте видимые для пользователя обещания от деталей реализации.
Чётко указывайте, что является фиксированной политикой, что — архитектурным предпочтением, а что — вопросом, который ещё не решён.
Если запрос противоречит существующим ограничениям репозитория, четко об этом сообщите, а не пытайтесь сгладить ситуацию.
Отдавайте предпочтение одному многократно используемому артефакту функциональности, а не разрозненным ситуативным заметкам.

Входные данные

Читайте только то, что необходимо:

Цель продукта
- заявка, обсуждение, PRD, заметка о дорожной карте, сообщение основателя
Текущая архитектура
- соответствующая документация репозитория, контракты, схемы, маршруты, существующие рабочие процессы
Контекст существующих возможностей
- PRODUCT.md, проектная документация, RFC, примечания по миграции, документация по операционной модели
Ограничения по внедрению
- аутентификация, биллинговая система, соответствие нормативным требованиям, внедрение, обратная совместимость, производительность, политика проверки

Основной рабочий процесс

1. Переформулируйте функциональные возможности

Сформулируйте запрос в виде одного чёткого утверждения:

кто является пользователем или оператором
какие новые возможности появятся после запуска
какие результаты изменятся благодаря этому

Если это утверждение будет нечетким, реализация уйдет в сторону.

2. Определите ограничения возможностей

Выделите ограничения, которые должны соблюдаться до начала реализации:

бизнес-правила
границы области применения
инварианты
границы доверия
право собственности на данные
переходы жизненного цикла
требования к внедрению/миграции
ожидания в отношении сбоев и восстановления

Все это — вещи, которые зачастую хранятся только в памяти старших инженеров.

3. Определите договор, ориентированный на реализацию

Составьте план функциональных возможностей в стиле SRS, включающий:

краткое изложение функциональных возможностей
явно указанные нецели
участников и интерфейсов
требуемые состояния и переходы
интерфейсы / входы / выходы
последствия для модели данных
ограничения, связанные с безопасностью, биллингом и политиками
требования к наблюдаемости и требования к операторам
открытые вопросы, препятствующие реализации

4. Переход к реализации

Завершите точной передачей:

готово к непосредственной реализации
требуется сначала провести анализ архитектуры
требуется сначала уточнить требования к продукту

Если это полезно, укажите следующий этап, характерный для ECC:

project-flow-ops
workspace-surface-audit
создание-API-коннекторов
dashboard-builder
tdd-workflow
цикл-верификации

Формат вывода

Возвращайте результат в следующем порядке:

ВОЗМОЖНОСТИ
- переформулировка в одном абзаце

ОГРАНИЧЕНИЯ
- фиксированные правила, инварианты и границы

ДОГОВОР О РЕАЛИЗАЦИИ
- участники
- поверхности взаимодействия
- состояния и переходы
- последствия для интерфейса/данных

НЕЦЕЛИ
- что явно не входит в сферу ответственности данного направления

ОТКРЫТЫЕ ВОПРОСЫ
- препятствия или решения по продукту, которые ещё требуются

ПЕРЕДАЧА
- что должно произойти дальше и какое направление ECC должно это принять

Положительные результаты

Замысел продукта теперь достаточно конкретен для реализации без повторного обнаружения скрытых ограничений в середине PR.
Инженерный обзор имеет надёжный артефакт вместо того, чтобы полагаться на память или контекст в Slack.
Полученный план можно повторно использовать в рамках платформ планирования Claude Code, Codex, Cursor, OpenCode и ECC 2.0.

Посмотреть на GitHub

---
name: product-capability
description: Translate product intent, PRDs, or roadmap discussions into explicit, implementation-ready capability plans with constraints, invariants, interfaces, and open questions before multi-service work begins.
---

# Product Capability

This skill turns product intent into explicit engineering constraints.

Use it when the gap is not "what should we build?" but "what exactly must be true before implementation starts?"

## When to Use

- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit
- A feature crosses multiple services, repos, or teams and needs a capability contract before coding
- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy
- Senior engineers keep restating the same hidden assumptions during review
- You need a reusable artifact that can survive across harnesses and sessions

## Canonical Artifact

If the repo has a durable product-context file such as `PRODUCT.md`, `docs/product/`, or a program-spec directory, update it there.

If no capability manifest exists yet, create one using the template at:

- `docs/examples/product-capability-template.md`

The goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.

## Non-Negotiable Rules

- Do not invent product truth. Mark unresolved questions explicitly.
- Separate user-visible promises from implementation details.
- Call out what is fixed policy, what is architecture preference, and what is still open.
- If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.
- Prefer one reusable capability artifact over scattered ad hoc notes.

## Inputs

Read only what is needed:

1. Product intent
   - issue, discussion, PRD, roadmap note, founder message
2. Current architecture
   - relevant repo docs, contracts, schemas, routes, existing workflows
3. Existing capability context
   - `PRODUCT.md`, design docs, RFCs, migration notes, operating-model docs
4. Delivery constraints
   - auth, billing, compliance, rollout, backwards compatibility, performance, review policy

## Core Workflow

### 1. Restate the capability

Compress the ask into one precise statement:

- who the user or operator is
- what new capability exists after this ships
- what outcome changes because of it

If this statement is weak, the implementation will drift.

### 2. Resolve capability constraints

Extract the constraints that must hold before implementation:

- business rules
- scope boundaries
- invariants
- trust boundaries
- data ownership
- lifecycle transitions
- rollout / migration requirements
- failure and recovery expectations

These are the things that often live only in senior-engineer memory.

### 3. Define the implementation-facing contract

Produce an SRS-style capability plan with:

- capability summary
- explicit non-goals
- actors and surfaces
- required states and transitions
- interfaces / inputs / outputs
- data model implications
- security / billing / policy constraints
- observability and operator requirements
- open questions blocking implementation

### 4. Translate into execution

End with the exact handoff:

- ready for direct implementation
- needs architecture review first
- needs product clarification first

If useful, point to the next ECC-native lane:

- `project-flow-ops`
- `workspace-surface-audit`
- `api-connector-builder`
- `dashboard-builder`
- `tdd-workflow`
- `verification-loop`

## Output Format

Return the result in this order:

```text
CAPABILITY
- one-paragraph restatement

CONSTRAINTS
- fixed rules, invariants, and boundaries

IMPLEMENTATION CONTRACT
- actors
- surfaces
- states and transitions
- interface/data implications

NON-GOALS
- what this lane explicitly does not own

OPEN QUESTIONS
- blockers or product decisions still required

HANDOFF
- what should happen next and which ECC lane should take it
```

## Good Outcomes

- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.
- Engineering review has a durable artifact instead of relying on memory or Slack context.
- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.