一键在 Manus 中运行任何 Skill

coca-spec

星标34

分支4

更新时间2026年3月25日 20:44

Clarify fuzzy or greenfield work into a COCA spec before implementation. Use when the user has intent, but the requirements are still incomplete.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

darknetopencv-alt

darknetopencv-alt/autodev

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

COCA Spec

Use this skill before implementation when the task is still underspecified.

COCA stands for:

Context: where the feature lives and what already exists
Outcome: what "done" looks like for users and stakeholders
Constraints: boundaries, non-goals, and hard requirements
Assertions: testable behaviors, edge cases, and anti-behaviors

Workflow

Restate your understanding of the request and call out assumptions.
Work through one COCA section at a time.
Ask only one focused question or a very small cluster at a time.
Push for specifics when answers are vague.
Keep Outcome focused on what, not how.
Make Assertions directly testable.
Once approved, write the final spec to docs/specs/<feature-name>-coca-spec.md.

Quality Bar

A new engineer should understand the landscape from Context alone.
A stakeholder should be able to validate Outcome from a demo.
Constraints should prevent scope creep without over-constraining implementation.
Assertions should be specific enough to become tests.

Output Shape

Use this structure for the final document:

# <Feature Name> - COCA Spec

## Context

## Outcome

## Constraints

## Assertions
### Happy Path
### Edge Cases
### Error States
### Anti-Behaviors
### Integration

同仓库更多 Skills

同仓库

pptx-agents

darknetopencv-alt/autodev

Agent role definitions for generating PPTX slides. Each .md file defines a specialized sub-agent persona (cover, TOC, content, section-divider, summary) that follows ppt-orchestra-skill to produce individual slide JS modules compiled into a final presentation.

2026-03-2834

autodev-runtime

darknetopencv-alt/autodev

Shared runtime references for autodev-managed projects. Use when you need the task lifecycle, MCP provisioning guidance, or the local skills-main integration notes.

2026-03-2534

minimax-xlsx

darknetopencv-alt/autodev

Open, create, read, analyze, edit, or validate Excel/spreadsheet files (.xlsx, .xlsm, .csv, .tsv). Use when the user asks to create, build, modify, analyze, read, validate, or format any Excel spreadsheet, financial model, pivot table, or tabular data file. Covers: creating new xlsx from scratch, reading and analyzing existing files, editing existing xlsx with zero format loss, formula recalculation and validation, and applying professional financial formatting standards. Triggers on 'spreadsheet', 'Excel', '.xlsx', '.csv', 'pivot table', 'financial model', 'formula', or any request to produce tabular data in Excel format.

2026-03-2534

spec-driven-develop

darknetopencv-alt/autodev

Lightweight spec-driven workflow for large rewrites, migrations, overhauls, or architecture-heavy work. Use when the task needs analysis, planning, progress tracking, and continuity across multiple sessions before coding.

2026-03-2534

name	coca-spec
description	Clarify fuzzy or greenfield work into a COCA spec before implementation. Use when the user has intent, but the requirements are still incomplete.
version	1.0.0

COCA Spec

Use this skill before implementation when the task is still underspecified.

COCA stands for:

Context: where the feature lives and what already exists
Outcome: what "done" looks like for users and stakeholders
Constraints: boundaries, non-goals, and hard requirements
Assertions: testable behaviors, edge cases, and anti-behaviors

Workflow

Restate your understanding of the request and call out assumptions.
Work through one COCA section at a time.
Ask only one focused question or a very small cluster at a time.
Push for specifics when answers are vague.
Keep Outcome focused on what, not how.
Make Assertions directly testable.
Once approved, write the final spec to docs/specs/<feature-name>-coca-spec.md.

Quality Bar

A new engineer should understand the landscape from Context alone.
A stakeholder should be able to validate Outcome from a demo.
Constraints should prevent scope creep without over-constraining implementation.
Assertions should be specific enough to become tests.

Output Shape

Use this structure for the final document:

# <Feature Name> - COCA Spec

## Context

## Outcome

## Constraints

## Assertions
### Happy Path
### Edge Cases
### Error States
### Anti-Behaviors
### Integration