mcpField
F
field-notes

field-notes

github.com/dragoon0xDesign & UI683 installsUpdated 35w ago
Repository

About field-notes

A design-analysis skill that turns product observations into structured field notes. It is intended for product reviewers documenting specific design decisions, their effects, and one shortcoming.

Key features

  1. 01Structure product observations
  2. 02Describe intended experience
  3. 03Record three effective decisions
  4. 04Explain one shortcoming
  5. 05Summarize a design principle

Use cases

  1. 01Document a product review
  2. 02Build a design reference library
  3. 03Compare design decisions and their effects

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/dragoon0x/taste-skills --skill field-notes

After installing, type/field-notesin Claude Code to confirm it loaded.

Details

From the project README

Field Notes

The format for making taste observations legible.

How to use

  • /field-notes Write a structured taste breakdown of a product in this conversation.
  • /field-notes <product> Analyze the specified product using the field notes format.

Constraints

Field Note Structure
  1. Product name, URL, date, category
  2. What it's trying to be (2-3 sentences. Not what it does. What experience it's trying to create.)
  3. Three things that work (specific decisions with principles behind them)
  4. One thing that doesn't (specific decision with reasoning and impact)
  5. The taste principle (one sentence: "This product demonstrates that...")
  6. Tags (principle-based tags for the reference library)
Writing Rules
  • MUST be specific. Reference actual elements, sizes, and interactions.
  • MUST connect every observation to a principle.
  • MUST include at least one thing that doesn't work. No product is perfect.
  • SHOULD be under 500 words. Concise analysis is harder and more useful than exhaustive analysis.
  • NEVER write a field note about a product you haven't actually used.
Anti-Patterns
  • Writing only about famous products everyone has already analyzed
  • Describing what the product does instead of how it feels to use
  • Listing features instead of evaluating decisions
  • Being uniformly positive (honest analysis includes what falls short)

Comments

Markdown supported