AgentSkillsCN

feature

申请新功能——进行三方评估，计算RICE评分，创建GH Issue并撰写规范

SKILL.md
--- frontmatter
name: feature
description: Request a feature — tri-agent assessment, RICE score, create GH issue + spec
argument-hint: <one-line feature description>

Request Feature

You are the engineering-manager. Intake a feature request through tri-agent assessment, RICE scoring, and artifact creation.

Step 1: Read current state (EM)

  1. •Read .product/backlog.md — full backlog. Scan all spec IDs to find the current max N, then assign {{SPEC_PREFIX}}-{N+1} to this feature.
  2. •Read .product/rice-scores.md — current scores and priority thresholds.
  3. •Run duplicate detection:
    bash
    gh issue list --state all --search "$ARGUMENTS" --limit 10 --json number,title,state,labels
  4. •Identify the target feature area (phase, directory) from the description.

Step 2: Duplicate check (EM)

  • •Compare GH search results + backlog for conceptual overlap with $ARGUMENTS.
  • •If a duplicate or near-duplicate is found → present it to the user and ask whether to:
    • •Stop (confirmed duplicate)
    • •Add AC to the existing item instead of creating a new one
    • •Split (related but distinct — proceed with cross-reference)
    • •Continue (different feature despite surface similarity)
  • •If no overlap → proceed to Step 3.

Step 3: Tri-agent assessment (parallel spawn)

Note: If running within a cardo-assess team session (Agent Teams mode), PO and Architect are already teammates — create TaskList items instead of spawning subagents. They can message each other directly to resolve scoring disagreements.

Spawn two agents in parallel:

PO agent (product-owner)

You are the product-owner for {{PROJECT_NAME}}. Assess this feature request:

Feature: "$ARGUMENTS"

Read .product/backlog.md and .product/decisions.md for product context.

Score:

  • •Reach (1-10): What % of target users would use this? Core flow (8-10), secondary (5-7), power user (2-4), niche (1).
  • •Impact (0.25-3): Effect on core value proposition. Massive=3 (can't launch without), High=2 (significant quality), Medium=1 (nice to have), Low=0.5 (minor polish), Minimal=0.25 (barely noticeable).
  • •1-sentence justification for each score.

Also assess:

  • •Does this conflict with any product principles in decisions.md? (If so, flag — may warrant rejection)
  • •Which product phase?
  • •Recommended milestone: MVP / R1 / R2 / Future
  • •Should this be split into smaller deliverables? (Common for large features)
  • •Default work type: type:build

Return your scores and assessment as structured text.

Architect agent (architect)

You are the architect for {{PROJECT_NAME}}. Assess this feature request:

Feature: "$ARGUMENTS"

Read .architecture/overview.md and explore relevant feature directories under {{FEATURES_DIR}}.

Score:

  • •Friction (1-5): 1=pure code, 2=code + deps, 3=needs device testing/design, 4=external dependency, 5=multi-party external.
  • •Confidence (0.5-1.0): How well understood is this? 1.0=clear path, 0.8=reasonable assumptions, 0.5=needs spike.
  • •1-sentence justification for each score.

Also assess:

  • •Feature directory: Which {{FEATURES_DIR}}*/ directory? (existing or new)
  • •Dependencies: Other items, libraries, or infrastructure needed first.
  • •Tech spec needed? Does this meet the criteria for a separate .architecture/tasks/ spec? (3+ feature dirs, new pattern, significant non-functional requirements)
  • •Backend needed? Does this require server-side work?
  • •Device verification: What should be verified on device? (action → expected result pairs for the Verification Plan)
  • •Complexity: Simple (1-2 files) / Moderate (3-5 files) / Complex (6+ files or new pattern)

Return your scores and assessment as structured text.

Step 4: Synthesize (EM)

  1. •Combine PO scores (R, I) with Architect scores (C, F).
  2. •Compute RICE: (R x I x C) / F
  3. •Determine priority:
    • •RICE >= 100 → P0 (MVP milestone)
    • •RICE 25-99 → P1 (R1 milestone)
    • •RICE 5-24 → P2 (R1 or R2 milestone, use PO recommendation)
    • •RICE < 5 → Future (log without GH issue)
  4. •Determine item type: F<=2 → Agent, F=3 → Human, F>=4 → External.
  5. •Decision:
    • •Accept — create all artifacts
    • •Defer — RICE < 5, log in reprioritization log only, no GH issue
    • •Reject — conflicts with product principles, too speculative (C < 0.5 + no clear user need), or confirmed duplicate
  6. •If PO recommended a split → present the split options to the user as well.

Step 5: Present proposal to user

Format:

code
Feature Assessment: {{SPEC_PREFIX}}-{id}
============================

Title: {title}
Description: {1-2 sentences}

RICE Breakdown:
  Reach:      {R}/10  — {PO justification}
  Impact:     {I}/3   — {PO justification}
  Confidence: {C}     — {Architect justification}
  Friction:   {F}/5   — {Architect justification}
  ---
  RICE Score: {score}

Priority:    {P0/P1/P2/Future}
Milestone:   {MVP/R1/R2/Future}
Work Type:   type:build
Item Type:   {Agent/Human/External}

Dependencies:  {list or "None"}
Tech Spec:     {Needed / Not needed}
Backend:       {Needed / Not needed}

{If split recommended:}
Split Recommendation:
  - {{SPEC_PREFIX}}-{id}a: {sub-feature 1}
  - {{SPEC_PREFIX}}-{id}b: {sub-feature 2}

Recommendation: {Accept / Defer / Reject}
{If reject: reason}

Shall I create the GitHub issue, product spec, and backlog entries?

Wait for user approval before proceeding.

Step 6: Create artifacts (on approval)

Create all artifacts. Use --no-gpg-sign for commits in cloud/Cardo sessions.

6a. GitHub issue

bash
gh issue create --title "{{SPEC_PREFIX}}-{id}: {title}" --label "enhancement,type:build,{priority-label}" --body "$(cat <<'EOF'
## Feature Request

**Spec ID:** {{SPEC_PREFIX}}-{id}
**Priority:** {P0/P1/P2} ({milestone})
**RICE:** {score} (R={R} I={I} C={C} F={F})

## Why This Matters

{1-2 sentences on user value}

## User Story

As a {persona}, I want to {action} so that {benefit}.

## Description

{2-3 sentences on what the feature does}

## Technical Notes

- **Feature directory:** `{{FEATURES_DIR}}{feature}/`
- **Dependencies:** {list or "None"}
- **Backend:** {Needed / Not needed}
- **Tech spec:** {Needed / Not needed}

## Acceptance Criteria

### Must Have
- [ ] {core behavior 1}
- [ ] {core behavior 2}

### Edge Cases
- [ ] {edge case 1}
- [ ] {edge case 2}

---
*Created via `/feature` — tri-agent assessment*
EOF
)"

Priority label mapping: P0 → P0-mvp, P1 → P1-fast-follow, P2 → P2-second-release.

6b. Product spec

Create .product/specs/{{SPEC_PREFIX}}-{id}-{slug}.md:

markdown
# {{SPEC_PREFIX}}-{id}: {Title}

**Issue:** [#{number}](https://github.com/{{GITHUB_OWNER}}/{{GITHUB_REPO}}/issues/{number})
**Priority:** {P0/P1/P2} ({milestone})
**Phase:** {phase}
**Status:** Not Started

---

## Cross-References

| Type | Link |
|------|------|
| GitHub Issue | [#{number}](https://github.com/{{GITHUB_OWNER}}/{{GITHUB_REPO}}/issues/{number}) |
| Feature Code | `{{FEATURES_DIR}}{feature}/` |
| Related | {if applicable} |

---

## Implementation Pointer

**Complexity:** {Simple/Moderate/Complex}
**Feature Directory:** `{{FEATURES_DIR}}{feature}/`
**Key Files:**
- `{path/to/file.ts}` — {what it does}
**Pattern:** {existing pattern to follow}
**Database Changes:** {None / description}
**Backend Changes:** {None / description}

---

## Why This Matters

{2-3 sentences on why this feature matters for the user and the product}

## User Story

As a {persona}, I want to {action} so that {benefit}.

## Description

{3-5 sentences describing the feature behavior}

---

## Acceptance Criteria

### Must Have
- [ ] {core behavior 1}
- [ ] {core behavior 2}
- [ ] {core behavior 3}

### Edge Cases
- [ ] {edge case 1}
- [ ] {edge case 2}

---

## Verification Plan

| Action | Expected Result |
|--------|-----------------|
| {do this} | {see this / see this log} |

---

## Dependencies

{List of items, libraries, or infrastructure this depends on, or "None"}

---

## RICE

| R | I | C | F | RICE |
|---|---|---|---|------|
| {R} | {I} | {C} | {F} | **{score}** |

6c. Update backlog.md

Add the feature to the correct milestone section in .product/backlog.md. Follow the existing table format for that section.

6d. Update rice-scores.md

  1. •Add a RICE row to the correct milestone table in .product/rice-scores.md.
  2. •Add a reprioritization log entry:
    code
    | {date} | New: {{SPEC_PREFIX}}-{id} (#{number}) | {title}. RICE {score} (R={R} I={I} C={C} F={F}). type:build. {milestone} section. {1-sentence description}. | User feature request — PO + Architect assessment |

6e. Update DOCS.md

Add a Feature Index row to the appropriate section in DOCS.md:

code
| {{SPEC_PREFIX}}-{id} | {Title} | {Milestone} | [spec](.product/specs/{{SPEC_PREFIX}}-{id}-{slug}.md) | {IP or --} | `{{FEATURES_DIR}}{feature}/` | Not Started |

Step 7: Summary

code
Feature {{SPEC_PREFIX}}-{id} created:
  - Issue: #{number}
  - Spec: .product/specs/{{SPEC_PREFIX}}-{id}-{slug}.md
  - RICE: {score} ({priority}, {milestone})
  - Type: {Agent/Human/External}
  {If split: "Split into {{SPEC_PREFIX}}-{id}a + {{SPEC_PREFIX}}-{id}b — run /feature for each sub-feature"}

Next: Run /implement {number} when ready to build.

Edge Cases

  • •Product principle conflict: PO flags this → present the conflict to user. Recommend rejection unless user overrides with rationale.
  • •Too speculative (C < 0.5): Recommend a spike/research issue first: "Run /feature 'Spike: investigate {topic}'" with F=2, I=0.25.
  • •Large feature (PO recommends split): Present split options. If user approves split, create the parent as an epic label and run /feature for each child.
  • •Backend needed: Flag that this will require a backend-engineer and potentially infrastructure work. Note this in the spec dependencies.
  • •Existing item overlap: Recommend adding AC to existing spec rather than creating a new item. If user wants both, proceed with cross-reference.
  • •RICE < 5 (Defer): Log in reprioritization log with "Deferred — RICE below threshold" but do NOT create a GH issue or spec. Inform user they can revisit during next /reprioritize.