mcpField
T
taste

taste

github.com/gabriel-lafranceDevelopment074 installsUpdated 1d ago
Repository

About taste

taste is a coding skill for auditing or tightening code against the Taste and Architecture standards in AGENTS.md. It provides a focused review process with concrete evidence and behavior-preserving fixes.

Key features

  1. 01Audit code against Taste and Architecture
  2. 02Use principle keys when reporting findings
  3. 03Recommend minimal behavior-preserving fixes
  4. 04Apply checks during larger build workflows

Use cases

  1. 01Review a code lane for style issues
  2. 02Tighten a messy file before or after a small change
  3. 03Check taste standards before implementation or review

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/gabriel-lafrance/skills --skill taste

After installing, type/tastein Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

doctrine.md
examples.md
reference.md

Details

From the project README

Taste

Must read: ../pack-shared/standards.md. The rules are the Taste and Architecture sections of AGENTS.md. This skill holds the audit steps and the examples. Do not skip the rules because this skill was not invoked.

Ask style: ../pack-shared/asking.md

Read: the Taste section of AGENTS.md · examples.md · reference.md when verifying or touching UI · ../pack-shared/plain-language.md

Cite keys are the headings in the Taste section. When speaking to the user, cite principles as plain (Classic): keep this simple (KISS). Never acronym-only and never the paraphrase without the classic name. Placement and taste:keep-jobs-apart defects are taste failures too. Parents (/task, /analyze, /grill-me, /implement, /design) apply the Taste and Architecture sections before planning or writing code.

If this is a user one-off (audit or fix a lane)

Use when the user asks about coding style, keep-it-simple, don’t-repeat-yourself, principles, or “is this clean?”; when reviewing a lane without a full /task; or when tightening a messy file before or after a small change.

  1. Identify the lane (paths / symbols) and the ask.
  2. Apply the Taste section plus examples.md. Use cite keys (taste:keep-it-simple and Named principles).
  3. Report concrete violations with path evidence and the smallest fix (taste:leave-it-cleaner / taste:keep-it-simple: no speculative rewrite).
  4. If the user asks to fix, apply only behavior-preserving edits in that lane. Larger product scope → recommend /analyze or /task.
  5. Do not invent a parent wave, write tests, or start /create-test.

Hand-offs: structure / folders / services → /architecture. Build end-to-end → /task. Research first → /analyze.

If this skill is already loaded inside a build
  1. Apply the Taste and Architecture sections before grill close, plan contracts, or implement briefs.
  2. Carry relevant cite keys into Active Rules / acceptance when they are behavioral (example: taste:fail-fast at a boundary, taste:safe-to-retry on a webhook).
  3. Run the checklist in the Taste section before acceptance evidence and /code-review.
  4. /code-review Standards axis treats taste and architecture violations as hard unless repo docs contradict.

Comments

Markdown supported