Nm Imbue Feature Review

Review and prioritize features using RICE, WSJF, or Kano scoring frameworks, then create GitHub issues for suggestions

Security Scan

Skill instructions match a feature‑review + GitHub issue workflow, but there is a mismatch around how GitHub (and other integrations) are authenticated and what configuration/credentials the skill will actually read or use.

Purpose & Capability

Name and description match the instructions: the skill inventories features, scores them (RICE/WSJF/Kano hybrid), optionally enriches scores via a 'tome' research plugin, and can create GitHub issues. The documented scan paths, scoring framework, tradeoff analysis, and issue template are coherent with a feature‑review purpose. Minor note: the config schema includes a full GitHub integration section which implies the skill will create issues and apply labels, but the package metadata and requirements do not declare any explicit credential (e.g., a GITHUB_TOKEN) — see environment_proportionality for implications.

Instruction Scope

SKILL.md explicitly instructs the agent to scan code artifacts, documentation, and git history; classify and score features; optionally call the tome research plugin via Skill() calls; and (optionally) create GitHub issues. All referenced files/paths (scan_paths, .feature-review.yaml, plugins/tome/) are within the stated domain of a repo-level feature review. There are no instructions that obviously request unrelated secrets or to exfiltrate data to unknown external endpoints.

Install Mechanism

Instruction-only skill with no install spec and no code files — lowest-risk install surface. Nothing will be downloaded or written to disk by an install step. Runtime behavior depends on the agent executing the documented commands and calling other skills/plugins.

Credentials

The skill supports GitHub integration (issue creation, auto-labeling) but the manifest declares no required env vars or primary credential. The SKILL.md documents environment overrides (FEATURE_REVIEW_*) and a github section in the config, implying auth is required at runtime. This is a mismatch: either issue creation is expected to use pre-existing project config (e.g., a repo-level token stored elsewhere) or the skill will attempt to use agent-level credentials/config paths not declared here. Additionally, the skill reads repository files, Git history, and may call the tome skill interfaces — those integrations could require access to other configs or tokens (not listed). Confirm where credentials live and whether the skill will access config keys that contain secrets.

Persistence & Privilege

The skill is not always:true and is user-invocable. It may create files (backlog file, issue bodies) and create GitHub issues if enabled, which is consistent with its purpose. It does not request persistent platform privileges or indicate it will modify other skills' configurations. Autonomous invocation is allowed by default (normal); pair that with the credential note above if you want to limit its blast radius.

What to consider before installing

This skill appears to do what it says (inventory, score, suggest, optionally create GitHub issues), but verify the following before installing or running it with real repositories: 1) Authentication: Ask the author/maintainer where GitHub authentication comes from. If the skill will create issues you should ensure a dedicated token is used and that the token's scope is limited (repo:issues or fine-grained app token), rather than granting full repo/admin rights. The skill's metadata does not declare a GH token env var — confirm whether credentials are expected in project config paths (e.g., night-market.*) or provided by the agent platform. 2) Config & Secrets: Inspect any .feature-review.yaml or the referenced config paths (night-market.imbue:scope-guard, night-market.imbue:review-core, night-market.tome:research) in your project to ensure they do not contain sensitive credentials you don't want the skill to read. If those configs live in a shared location, confirm access controls. 3) Repo Access: The skill will scan code, docs, and git history. Run it first on a test/sandbox repo to observe behavior and outputs before pointing it at production repos. 4) Tome Integration: If you use the --research flag the skill will try to call the tome plugin via Skill() interfaces; confirm that tome is installed and that its permissions/data access are acceptable. 5) Autonomy: Because the skill can be invoked autonomously by agents, consider disabling autonomous invocation or restricting when/which agents can call it until you confirm credentials and behavior. If the maintainer can confirm where authentication is obtained and that tokens/configs are scoped and separated from sensitive material, the remaining concerns are minor.

Night Market Skill — ported from claude-night-market/imbue. For the full experience with agents, hooks, and commands, install the Claude Code plugin.

Table of Contents

• Philosophy
• When to Use
• When NOT to Use
• Quick Start
• 1. Inventory Current Features
• 2. Score and Classify
• 3. Generate Suggestions

Verification

Run make test-feature-review to verify scoring logic after changes.

• 4. Upload to GitHub
• Workflow
• Phase 1: Feature Discovery (feature-review:inventory-complete)
• Phase 2: Classification (feature-review:classified)
• Phase 3: Scoring (feature-review:scored)
• Phase 4: Tradeoff Analysis (feature-review:tradeoffs-analyzed)
• Phase 5: Gap Analysis & Suggestions (feature-review:suggestions-generated)
• Phase 6: GitHub Integration (feature-review:issues-created)
• Configuration
• Configuration File
• Guardrails
• Required TodoWrite Items
• Integration Points
• Output Format
• Feature Inventory Table
• Suggestion Report
• Feature Suggestions
• High Priority (Score > 2.5)
• Related Skills
• Reference

Feature Review

Review implemented features and suggest new ones using evidence-based prioritization. Create GitHub issues for accepted suggestions.

Philosophy

Feature decisions rely on data. Every feature involves tradeoffs that require evaluation. This skill uses hybrid RICE+WSJF scoring with Kano classification to prioritize work and generates actionable GitHub issues for accepted suggestions.

When To Use

• Roadmap reviews (sprint planning, quarterly reviews).
• Retrospective evaluations.
• Planning new development cycles.

When NOT To Use

• Emergency bug fixes.
• Simple documentation updates.
• Active implementation (use scope-guard).

Quick Start

1. Inventory Current Features

Discover and categorize existing features:

/feature-review --inventory

2. Score and Classify

Evaluate features against the prioritization framework:

/feature-review

3. Generate Suggestions

Review gaps and suggest new features:

/feature-review --suggest

4. Research-Enriched Scoring

Use tome plugin to adjust scores with external evidence:

/feature-review --research

5. Upload to GitHub

Create issues for accepted suggestions:

/feature-review --suggest --create-issues

Workflow

Phase 1: Feature Discovery (feature-review:inventory-complete)

Identify features by analyzing:

1. Code artifacts: Entry points, public APIs, and configuration surfaces.
2. Documentation: README lists, CHANGELOG entries, and user docs.
3. Git history: Recent feature commits and branches.

Output: Feature inventory table.

Phase 2: Classification (feature-review:classified)

Classify each feature along two axes:

Axis 1: Proactive vs Reactive

Type	Definition	Examples
Proactive	Anticipates user needs.	Suggestions, prefetching.
Reactive	Responds to explicit input.	Form handling, click actions.

Axis 2: Static vs Dynamic

Type	Update Pattern	Storage Model
Static	Incremental, versioned.	File-based, cached.
Dynamic	Continuous, streaming.	Database, real-time.

See classification-system.md for details.

Phase 3: Scoring (feature-review:scored)

Apply hybrid RICE+WSJF scoring:

Feature Score = Value Score / Cost Score

Value Score = (Reach + Impact + Business Value + Time Criticality) / 4
Cost Score = (Effort + Risk + Complexity) / 3

Adjusted Score = Feature Score * Confidence

Scoring Scale: Fibonacci (1, 2, 3, 5, 8, 13).

Thresholds:

• > 2.5: High priority.
• 1.5 - 2.5: Medium priority.
• < 1.5: Low priority.

See scoring-framework.md for the framework.

Phase 4: Tradeoff Analysis (feature-review:tradeoffs-analyzed)

Evaluate each feature across quality dimensions:

Dimension	Question	Scale
Quality	Does it deliver correct results?	1-5
Latency	Does it meet timing requirements?	1-5
Token Usage	Is it context-efficient?	1-5
Resource Usage	Is CPU/memory reasonable?	1-5
Redundancy	Does it handle failures gracefully?	1-5
Readability	Can others understand it?	1-5
Scalability	Will it handle 10x load?	1-5
Integration	Does it play well with others?	1-5
API Surface	Is it backward compatible?	1-5

See tradeoff-dimensions.md for criteria.

Phase 4.5: Research Enrichment (feature-review:research-enriched)

Triggered by: --research flag. Requires tome plugin.

Use tome's multi-source research to adjust scoring factors with external evidence. This phase runs between tradeoff analysis and gap analysis.

1. Dispatch research: For each feature, construct research topics and dispatch tome channels (code-search, discourse, papers, triz) in parallel.
2. Synthesize findings: Merge results across channels using tome:synthesize.
3. Calculate deltas: Map findings to scoring factor adjustments using channel-to-factor mapping.
4. Apply deltas: Adjust initial scores by research deltas, clamp to Fibonacci scale, respect max_delta.
5. Present evidence: Show adjustment table with evidence sources and rationale.

See research-enrichment.md for the full enrichment protocol, delta calculation, and graceful degradation behavior.

Graceful degradation: If tome is not installed, prints a warning and proceeds with initial scores unchanged.

Phase 5: Gap Analysis & Suggestions (feature-review:suggestions-generated)

1. Identify gaps: Missing Kano basics.
2. Surface opportunities: High-value, low-effort features.
3. Flag technical debt: Features with declining scores.
4. Recommend actions: Build, improve, deprecate, or maintain.

Phase 6: GitHub Integration (feature-review:issues-created)

1. Generate issue title and body from suggestions.
2. Apply labels (feature, enhancement, priority/*).
3. Link to related issues.
4. Confirm with user before creation.

Deferred capture for high-scoring suggestions: After the user confirms which suggestions to act on, any high-scoring suggestion (score > 2.5) that is not acted on should be preserved as a deferred item. Run once per skipped high-scoring suggestion:

python3 scripts/deferred_capture.py \
  --title "<suggestion title>" \
  --source feature-review \
  --context "RICE score: <score>. <description>"

This runs automatically without prompting the user. Suggestions with scores of 2.5 or below do not need to be captured.

Configuration

Feature-review uses opinionated defaults but allows customization.

Configuration File

Create .feature-review.yaml in project root:

# .feature-review.yaml
version: 1

# Scoring weights (must sum to 1.0)
weights:
  value:
    reach: 0.25
    impact: 0.30
    business_value: 0.25
    time_criticality: 0.20
  cost:
    effort: 0.40
    risk: 0.30
    complexity: 0.30

# Score thresholds
thresholds:
  high_priority: 2.5
  medium_priority: 1.5

# Tradeoff dimension weights (0.0 to disable)
tradeoffs:
  quality: 1.0
  latency: 1.0
  token_usage: 1.0
  resource_usage: 0.8
  redundancy: 0.5
  readability: 1.0
  scalability: 0.8
  integration: 1.0
  api_surface: 1.0

See configuration.md for options.

Guardrails

These rules apply to all configurations:

1. Minimum dimensions: Evaluate at least 5 tradeoff dimensions.
2. Confidence requirement: Review scores below 50% confidence.
3. Breaking change warning: Require acknowledgment for API surface changes.
4. Backlog limit: Limit suggestion queue to 25 items.

Required TodoWrite Items

1. feature-review:inventory-complete
2. feature-review:classified
3. feature-review:scored
4. feature-review:tradeoffs-analyzed
5. feature-review:research-enriched (if --research)
6. feature-review:suggestions-generated
7. feature-review:issues-created (if requested)

Integration Points

• imbue:scope-guard: Provides Worthiness Scores for suggestions.
• sanctum:do-issue: Prioritizes issues with high scores.
• superpowers:brainstorming: Evaluates new ideas against existing features.
• tome:research: Multi-source research for score enrichment (optional, --research).

Output Format

Feature Inventory Table

| Feature | Type | Data | Score | Priority | Status |
|---------|------|------|-------|----------|--------|
| Auth middleware | Reactive | Dynamic | 2.8 | High | Stable |
| Skill loader | Reactive | Static | 2.3 | Medium | Needs improvement |

Research-Enriched Table (with --research)

| Feature | Type | Score | Adj. | Priority | Evidence |
|---------|------|-------|------|----------|----------|
| Auth    | R/D  | 2.8   | 3.1  | High     | 3 sources |
| Loader  | R/S  | 2.3   | 2.3  | Medium   | none      |

## Research Evidence

### Code Search (GitHub)
- 12 implementations, avg 340 stars
- **Reach**: +1 (broad adoption)

### Discourse (HN/Reddit)
- 47 mentions, 78% positive
- **Impact**: +1 (strong demand)

Suggestion Report

## Feature Suggestions

### High Priority (Score > 2.5)

1. **[Feature Name]** (Score: 2.7)
   - Classification: Proactive/Dynamic
   - Value: High reach
   - Cost: Moderate effort
   - Recommendation: Build in next sprint

Related Skills

• imbue:scope-guard: Prevent overengineering.
• imbue:review-core: Structured review methodology.
• sanctum:pr-review: Code-level feature review.

Reference

• scoring-framework.md: RICE+WSJF hybrid.
• classification-system.md: Axes definition.
• tradeoff-dimensions.md: Quality attributes.
• configuration.md: Customization options.

Troubleshooting

Common Issues

Command not found Ensure all dependencies are installed and in PATH

Permission errors Check file permissions and run with appropriate privileges

Unexpected behavior Enable verbose logging with --verbose flag