feature-intake

Reverse-engineers a Feature Intake Spec from HTML prototypes and backend API documentation.

1|Updated May 15, 2026
One-click install
npx skills add https://github.com/c2kaka/fancy-skills --skill feature-intake-c2kaka
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: feature-intake
Source: https://github.com/c2kaka/fancy-skills/tree/main/skills/feature-intake
Command: npx skills add https://github.com/c2kaka/fancy-skills --skill feature-intake-c2kaka

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve? When a product team delivers only an HTML prototype plus backend API documentation (no complete PRD), the gap between these two sources hides implicit business behavior—state transitions, field dependencies, orphan references, display-vs-submit mismatches—where most bugs live. AI coding agents tend to fill these gaps with plausible-looking assumptions instead of asking. This Skill forces every gap to become an explicit human decision with confidence labels, producing a single source of truth before coding starts. ## Core Features & Use Cases - Five-pattern gap scanning: Systematically probes entry differences (create vs edit mode), dynamic field candidates, orphan reference cleanup, display-value vs submit-value mismatches, and session draft retention, using a built-in checklist and real-case reference doc. - Confidence-labeled spec template: Ships a ready-to-copy Feature Intake Spec template where every conclusion is tagged [产品确认]/[接口确认]/[原型确认]/[实现现状]/[协议TODO], plus a field-by-state matrix and dependency chains as direct coding input. - Human-decision workflow: Separates business gaps from contract-level TODOs, routes ambiguous items to explicit human ruling, and defines clear boundaries for what AI may implement autonomously. - Use Case: You receive a prototype HTML and an API doc for a new frontend feature with no PRD. Run this Skill to produce a complete intake spec listing every inconsistency, each either resolved with evidence or marked as a specific searchable TODO for the backend or product owner. ## Quick Start Tell the agent: I have the prototype HTML and backend API docs for this new feature—run feature intake and produce the spec with all gaps listed for my review.

Frequently Asked Questions about feature-intake

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a spec when the product only gives a prototype and API docs?▼

Use the feature intake workflow: copy the spec template, fill a material-coverage table for each input, then scan five gap patterns to expose implicit behavior. Every conclusion gets a confidence label, and unresolved items become specific TODOs for human decision.

What are the common gaps between an HTML prototype and backend API documentation?▼

Five recurring patterns: create-vs-edit entry differences, dynamic field candidates from multiple sources, orphan references after deletions, values displayed in UI but submitted as null, and draft retention across mode switches. Contract-level issues like enum whitelists are tracked separately.

How do I stop an AI coding agent from assuming business rules?▼

Require every conclusion to carry a confidence label such as product-confirmed, API-confirmed, prototype-confirmed, or protocol-TODO. Anything not derivable from source materials must become an explicit, searchable TODO assigned to a human rather than a silent default.

Can I use feature intake if I only have the API documentation but no prototype?▼

Yes, but the visual contract sections cannot be completed. Fill what the API doc covers and mark all prototype-dependent fields as protocol TODOs until the prototype arrives, keeping gaps explicit rather than assumed.

What is the difference between a business gap and a protocol TODO?▼

Business gaps concern how the form state machine behaves across user actions and belong in the gap list. Protocol TODOs are unresolved contract issues like enum whitelists, naming inconsistencies, or missing fields, collected in a separate spec section.