fix: convert skill submodules to plain directories
Some checks failed
ci/woodpecker/push/woodpecker Pipeline failed
Some checks failed
ci/woodpecker/push/woodpecker Pipeline failed
stop-slop, taste-skill, terrashark had embedded .git dirs causing Woodpecker clone to fail on submodule update.
This commit is contained in:
parent
cc74ad0bd0
commit
cfec11bb46
120 changed files with 17087 additions and 3 deletions
|
|
@ -1 +0,0 @@
|
||||||
Subproject commit 8da1f030185bdfe8471220585162991eaeb970e9
|
|
||||||
24
skills/stop-slop/CHANGELOG.md
Normal file
24
skills/stop-slop/CHANGELOG.md
Normal file
|
|
@ -0,0 +1,24 @@
|
||||||
|
# Changelog
|
||||||
|
|
||||||
|
## 2026-01-13
|
||||||
|
|
||||||
|
### Added
|
||||||
|
|
||||||
|
**Phrases (references/phrases.md)**
|
||||||
|
- Throat-clearing: "Here's what I find interesting", "Here's the problem though"
|
||||||
|
- Performative emphasis: "creeps in", "I promise", "They exist, I promise"
|
||||||
|
- Telling instead of showing: "This is genuinely hard", "This is what leadership actually looks like"
|
||||||
|
|
||||||
|
**Structures (references/structures.md)**
|
||||||
|
- Binary contrasts: "Not X. But Y.", "It's not this. It's that.", "stops being X and starts being Y"
|
||||||
|
- Rhythm patterns: staccato fragmentation, dashes for dramatic pause, hedging as reassurance
|
||||||
|
- Word patterns: absolute words (always, never, everyone, etc.), AI-overused intensifiers (deeply, truly, fundamentally, inherently, simply, literally, inevitably)
|
||||||
|
|
||||||
|
## 2026-01-12
|
||||||
|
|
||||||
|
- Restructured skill following Claude Code best practices (PR #1)
|
||||||
|
- Split into SKILL.md and references/ folder
|
||||||
|
|
||||||
|
## 2025-01-12
|
||||||
|
|
||||||
|
- Initial release
|
||||||
21
skills/stop-slop/LICENSE
Normal file
21
skills/stop-slop/LICENSE
Normal file
|
|
@ -0,0 +1,21 @@
|
||||||
|
MIT License
|
||||||
|
|
||||||
|
Copyright (c) 2025 Hardik Pandya
|
||||||
|
|
||||||
|
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||||
|
of this software and associated documentation files (the "Software"), to deal
|
||||||
|
in the Software without restriction, including without limitation the rights
|
||||||
|
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||||
|
copies of the Software, and to permit persons to whom the Software is
|
||||||
|
furnished to do so, subject to the following conditions:
|
||||||
|
|
||||||
|
The above copyright notice and this permission notice shall be included in all
|
||||||
|
copies or substantial portions of the Software.
|
||||||
|
|
||||||
|
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||||
|
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||||
|
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||||
|
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||||
|
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||||
|
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||||
|
SOFTWARE.
|
||||||
62
skills/stop-slop/README.md
Normal file
62
skills/stop-slop/README.md
Normal file
|
|
@ -0,0 +1,62 @@
|
||||||
|
# Stop Slop
|
||||||
|
|
||||||
|
A skill for removing AI tells from prose.
|
||||||
|
|
||||||
|
<img width="3840" height="2160" alt="G-Yg4RVbIAAhVxW" src="https://github.com/user-attachments/assets/902afc15-1f40-4a9d-af24-8cd67afb8ebf" />
|
||||||
|
|
||||||
|
## What this is
|
||||||
|
|
||||||
|
AI writing has patterns. Predictable phrases, structures, rhythms. This skill teaches Claude (or any LLM) to catch and remove them.
|
||||||
|
|
||||||
|
## Skill Structure
|
||||||
|
|
||||||
|
```
|
||||||
|
stop-slop/
|
||||||
|
├── SKILL.md # Core instructions
|
||||||
|
├── references/
|
||||||
|
│ ├── phrases.md # Phrases to remove
|
||||||
|
│ ├── structures.md # Structural patterns to avoid
|
||||||
|
│ └── examples.md # Before/after transformations
|
||||||
|
├── README.md
|
||||||
|
└── LICENSE
|
||||||
|
```
|
||||||
|
|
||||||
|
## Quick start
|
||||||
|
|
||||||
|
**Claude Code:** Add this folder as a skill.
|
||||||
|
|
||||||
|
**Claude Projects:** Upload `SKILL.md` and reference files to project knowledge.
|
||||||
|
|
||||||
|
**Custom instructions:** Copy core rules from `SKILL.md`.
|
||||||
|
|
||||||
|
**API calls:** Include `SKILL.md` in your system prompt. Reference files load on demand.
|
||||||
|
|
||||||
|
## What it catches
|
||||||
|
|
||||||
|
**Banned phrases** - Throat-clearing openers, emphasis crutches, business jargon, all adverbs, vague declaratives, meta-commentary. See `references/phrases.md`.
|
||||||
|
|
||||||
|
**Structural clichés** - Binary contrasts, negative listings, dramatic fragmentation, rhetorical setups, false agency, narrator-from-a-distance voice, passive voice. See `references/structures.md`.
|
||||||
|
|
||||||
|
**Sentence-level rules** - No Wh- sentence starters, no em dashes, no staccato fragmentation, no lazy extremes, active voice required.
|
||||||
|
|
||||||
|
## Scoring
|
||||||
|
|
||||||
|
Rate 1-10 on each dimension:
|
||||||
|
|
||||||
|
| Dimension | Question |
|
||||||
|
|-----------|----------|
|
||||||
|
| Directness | Statements or announcements? |
|
||||||
|
| Rhythm | Varied or metronomic? |
|
||||||
|
| Trust | Respects reader intelligence? |
|
||||||
|
| Authenticity | Sounds human? |
|
||||||
|
| Density | Anything cuttable? |
|
||||||
|
|
||||||
|
Below 35/50: revise.
|
||||||
|
|
||||||
|
## Author
|
||||||
|
|
||||||
|
[Hardik Pandya](https://hvpandya.com)
|
||||||
|
|
||||||
|
## License
|
||||||
|
|
||||||
|
MIT. Use freely, share widely.
|
||||||
68
skills/stop-slop/SKILL.md
Normal file
68
skills/stop-slop/SKILL.md
Normal file
|
|
@ -0,0 +1,68 @@
|
||||||
|
---
|
||||||
|
name: stop-slop
|
||||||
|
description: Remove AI writing patterns from prose. Use when drafting, editing, or reviewing text to eliminate predictable AI tells.
|
||||||
|
metadata:
|
||||||
|
trigger: Writing prose, editing drafts, reviewing content for AI patterns
|
||||||
|
author: Hardik Pandya (https://hvpandya.com)
|
||||||
|
---
|
||||||
|
|
||||||
|
# Stop Slop
|
||||||
|
|
||||||
|
Eliminate predictable AI writing patterns from prose.
|
||||||
|
|
||||||
|
## Core Rules
|
||||||
|
|
||||||
|
1. **Cut filler phrases.** Remove throat-clearing openers, emphasis crutches, and all adverbs. See [references/phrases.md](references/phrases.md).
|
||||||
|
|
||||||
|
2. **Break formulaic structures.** Avoid binary contrasts, negative listings, dramatic fragmentation, rhetorical setups, false agency. See [references/structures.md](references/structures.md).
|
||||||
|
|
||||||
|
3. **Use active voice.** Every sentence needs a human subject doing something. No passive constructions. No inanimate objects performing human actions ("the complaint becomes a fix").
|
||||||
|
|
||||||
|
4. **Be specific.** No vague declaratives ("The reasons are structural"). Name the specific thing. No lazy extremes ("every," "always," "never") doing vague work.
|
||||||
|
|
||||||
|
5. **Put the reader in the room.** No narrator-from-a-distance voice. "You" beats "People." Specifics beat abstractions.
|
||||||
|
|
||||||
|
6. **Vary rhythm.** Mix sentence lengths. Two items beat three. End paragraphs differently. No em dashes.
|
||||||
|
|
||||||
|
7. **Trust readers.** State facts directly. Skip softening, justification, hand-holding.
|
||||||
|
|
||||||
|
8. **Cut quotables.** If it sounds like a pull-quote, rewrite it.
|
||||||
|
|
||||||
|
## Quick Checks
|
||||||
|
|
||||||
|
Before delivering prose:
|
||||||
|
|
||||||
|
- Any adverbs? Kill them.
|
||||||
|
- Any passive voice? Find the actor, make them the subject.
|
||||||
|
- Inanimate thing doing a human verb ("the decision emerges")? Name the person.
|
||||||
|
- Sentence starts with a Wh- word? Restructure it.
|
||||||
|
- Any "here's what/this/that" throat-clearing? Cut to the point.
|
||||||
|
- Any "not X, it's Y" contrasts? State Y directly.
|
||||||
|
- Three consecutive sentences match length? Break one.
|
||||||
|
- Paragraph ends with punchy one-liner? Vary it.
|
||||||
|
- Em-dash anywhere? Remove it.
|
||||||
|
- Vague declarative ("The implications are significant")? Name the specific implication.
|
||||||
|
- Narrator-from-a-distance ("Nobody designed this")? Put the reader in the scene.
|
||||||
|
- Meta-joiners ("The rest of this essay...")? Delete. Let the essay move.
|
||||||
|
|
||||||
|
## Scoring
|
||||||
|
|
||||||
|
Rate 1-10 on each dimension:
|
||||||
|
|
||||||
|
| Dimension | Question |
|
||||||
|
|-----------|----------|
|
||||||
|
| Directness | Statements or announcements? |
|
||||||
|
| Rhythm | Varied or metronomic? |
|
||||||
|
| Trust | Respects reader intelligence? |
|
||||||
|
| Authenticity | Sounds human? |
|
||||||
|
| Density | Anything cuttable? |
|
||||||
|
|
||||||
|
Below 35/50: revise.
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
See [references/examples.md](references/examples.md) for before/after transformations.
|
||||||
|
|
||||||
|
## License
|
||||||
|
|
||||||
|
MIT
|
||||||
59
skills/stop-slop/references/examples.md
Normal file
59
skills/stop-slop/references/examples.md
Normal file
|
|
@ -0,0 +1,59 @@
|
||||||
|
# Before/After Examples
|
||||||
|
|
||||||
|
## Example 1: Throat-Clearing + Binary Contrast
|
||||||
|
|
||||||
|
**Before:**
|
||||||
|
> "Here's the thing: building products is hard. Not because the technology is complex. Because people are complex. Let that sink in."
|
||||||
|
|
||||||
|
**After:**
|
||||||
|
> "Building products is hard. Technology is manageable. People aren't."
|
||||||
|
|
||||||
|
**Changes:** Removed opener, binary contrast structure, and emphasis crutch. Direct statements.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Example 2: Filler + Unnecessary Reassurance
|
||||||
|
|
||||||
|
**Before:**
|
||||||
|
> "It turns out that most teams struggle with alignment. The uncomfortable truth is that nobody wants to admit they're confused. And that's okay."
|
||||||
|
|
||||||
|
**After:**
|
||||||
|
> "Teams struggle with alignment. Nobody admits confusion."
|
||||||
|
|
||||||
|
**Changes:** Cut hedging ("most"), removed throat-clearing phrases, deleted permission-granting ending.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Example 3: Business Jargon Stack
|
||||||
|
|
||||||
|
**Before:**
|
||||||
|
> "In today's fast-paced landscape, we need to lean into discomfort and navigate uncertainty with clarity. This matters because your competition isn't waiting."
|
||||||
|
|
||||||
|
**After:**
|
||||||
|
> "Move faster. Your competition is."
|
||||||
|
|
||||||
|
**Changes:** Eliminated jargon entirely. Core message in six words.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Example 4: Dramatic Fragmentation
|
||||||
|
|
||||||
|
**Before:**
|
||||||
|
> "Speed. Quality. Cost. You can only pick two. That's it. That's the tradeoff."
|
||||||
|
|
||||||
|
**After:**
|
||||||
|
> "Speed, quality, cost—pick two."
|
||||||
|
|
||||||
|
**Changes:** Single sentence. No performative emphasis.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Example 5: Rhetorical Setup
|
||||||
|
|
||||||
|
**Before:**
|
||||||
|
> "What if I told you that the best teams don't optimize for productivity? Here's what I mean: they optimize for learning. Think about it."
|
||||||
|
|
||||||
|
**After:**
|
||||||
|
> "The best teams optimize for learning, not productivity."
|
||||||
|
|
||||||
|
**Changes:** Direct claim. No rhetorical scaffolding.
|
||||||
128
skills/stop-slop/references/phrases.md
Normal file
128
skills/stop-slop/references/phrases.md
Normal file
|
|
@ -0,0 +1,128 @@
|
||||||
|
# Phrases to Remove
|
||||||
|
|
||||||
|
## Throat-Clearing Openers
|
||||||
|
|
||||||
|
Remove these announcement phrases. State the content directly.
|
||||||
|
|
||||||
|
- "Here's the thing:"
|
||||||
|
- "Here's what [X]"
|
||||||
|
- "Here's this [X]"
|
||||||
|
- "Here's that [X]"
|
||||||
|
- "Here's why [X]"
|
||||||
|
- "The uncomfortable truth is"
|
||||||
|
- "It turns out"
|
||||||
|
- "The real [X] is"
|
||||||
|
- "Let me be clear"
|
||||||
|
- "The truth is,"
|
||||||
|
- "I'll say it again:"
|
||||||
|
- "I'm going to be honest"
|
||||||
|
- "Can we talk about"
|
||||||
|
- "Here's what I find interesting"
|
||||||
|
- "Here's the problem though"
|
||||||
|
|
||||||
|
Any "here's what/this/that" construction is throat-clearing before the point. Cut it and state the point.
|
||||||
|
|
||||||
|
## Emphasis Crutches
|
||||||
|
|
||||||
|
These add no meaning. Delete them.
|
||||||
|
|
||||||
|
- "Full stop." / "Period."
|
||||||
|
- "Let that sink in."
|
||||||
|
- "This matters because"
|
||||||
|
- "Make no mistake"
|
||||||
|
- "Here's why that matters"
|
||||||
|
|
||||||
|
## Business Jargon
|
||||||
|
|
||||||
|
Replace with plain language.
|
||||||
|
|
||||||
|
| Avoid | Use instead |
|
||||||
|
|-------|-------------|
|
||||||
|
| Navigate (challenges) | Handle, address |
|
||||||
|
| Unpack (analysis) | Explain, examine |
|
||||||
|
| Lean into | Accept, embrace |
|
||||||
|
| Landscape (context) | Situation, field |
|
||||||
|
| Game-changer | Significant, important |
|
||||||
|
| Double down | Commit, increase |
|
||||||
|
| Deep dive | Analysis, examination |
|
||||||
|
| Take a step back | Reconsider |
|
||||||
|
| Moving forward | Next, from now |
|
||||||
|
| Circle back | Return to, revisit |
|
||||||
|
| On the same page | Aligned, agreed |
|
||||||
|
|
||||||
|
## Adverbs
|
||||||
|
|
||||||
|
Kill all adverbs. No -ly words. No softeners, no intensifiers, no hedges.
|
||||||
|
|
||||||
|
Specific offenders:
|
||||||
|
|
||||||
|
- "really"
|
||||||
|
- "just"
|
||||||
|
- "literally"
|
||||||
|
- "genuinely"
|
||||||
|
- "honestly"
|
||||||
|
- "simply"
|
||||||
|
- "actually"
|
||||||
|
- "deeply"
|
||||||
|
- "truly"
|
||||||
|
- "fundamentally"
|
||||||
|
- "inherently"
|
||||||
|
- "inevitably"
|
||||||
|
- "interestingly"
|
||||||
|
- "importantly"
|
||||||
|
- "crucially"
|
||||||
|
|
||||||
|
Also cut these filler phrases:
|
||||||
|
|
||||||
|
- "At its core"
|
||||||
|
- "In today's [X]"
|
||||||
|
- "It's worth noting"
|
||||||
|
- "At the end of the day"
|
||||||
|
- "When it comes to"
|
||||||
|
- "In a world where"
|
||||||
|
- "The reality is"
|
||||||
|
|
||||||
|
## Meta-Commentary
|
||||||
|
|
||||||
|
Remove self-referential asides. The essay should move, not announce its own structure.
|
||||||
|
|
||||||
|
- "Hint:"
|
||||||
|
- "Plot twist:" / "Spoiler:"
|
||||||
|
- "You already know this, but"
|
||||||
|
- "But that's another post"
|
||||||
|
- "X is a feature, not a bug"
|
||||||
|
- "Dressed up as"
|
||||||
|
- "The rest of this essay explains..."
|
||||||
|
- "Let me walk you through..."
|
||||||
|
- "In this section, we'll..."
|
||||||
|
- "As we'll see..."
|
||||||
|
- "I want to explore..."
|
||||||
|
|
||||||
|
## Performative Emphasis
|
||||||
|
|
||||||
|
False intimacy or manufactured sincerity:
|
||||||
|
|
||||||
|
- "creeps in"
|
||||||
|
- "I promise"
|
||||||
|
- "They exist, I promise"
|
||||||
|
|
||||||
|
## Telling Instead of Showing
|
||||||
|
|
||||||
|
Announcing difficulty or significance rather than demonstrating it:
|
||||||
|
|
||||||
|
- "This is genuinely hard"
|
||||||
|
- "This is what leadership actually looks like"
|
||||||
|
- "This is what X actually looks like"
|
||||||
|
- "actually matters"
|
||||||
|
|
||||||
|
## Vague Declaratives
|
||||||
|
|
||||||
|
Sentences that announce importance without naming the specific thing. Kill these.
|
||||||
|
|
||||||
|
- "The reasons are structural"
|
||||||
|
- "The implications are significant"
|
||||||
|
- "This is the deepest problem"
|
||||||
|
- "The stakes are high"
|
||||||
|
- "The consequences are real"
|
||||||
|
|
||||||
|
If a sentence says something is important/deep/structural without showing the specific thing, cut it or replace it with the specific thing.
|
||||||
134
skills/stop-slop/references/structures.md
Normal file
134
skills/stop-slop/references/structures.md
Normal file
|
|
@ -0,0 +1,134 @@
|
||||||
|
# Structures to Avoid
|
||||||
|
|
||||||
|
## Binary Contrasts
|
||||||
|
|
||||||
|
These create false drama. State the point directly.
|
||||||
|
|
||||||
|
| Pattern | Problem |
|
||||||
|
|---------|---------|
|
||||||
|
| "Not because X. Because Y." / "Not because X, but because Y." | Telegraphed reversal |
|
||||||
|
| "[X] isn't the problem. [Y] is." | Formulaic reframe |
|
||||||
|
| "The answer isn't X. It's Y." | Predictable pivot |
|
||||||
|
| "It feels like X. It's actually Y." | Setup/reveal cliche |
|
||||||
|
| "The question isn't X. It's Y." | Rhetorical misdirection |
|
||||||
|
| "Not X. But Y." / "not X, it's Y" / "isn't X, it's Y" | Mechanical contrast |
|
||||||
|
| "It's not this. It's that." | Same formula, different words |
|
||||||
|
| "stops being X and starts being Y" | False transformation arc |
|
||||||
|
| "doesn't mean X, but actually Y" | Negation-then-assertion crutch |
|
||||||
|
| "is about X but not Y" | False distinction |
|
||||||
|
| "not just X but also Y" | Additive hedge |
|
||||||
|
|
||||||
|
**Instead:** State Y directly. "The problem is Y." "Y matters here." Drop the negation entirely.
|
||||||
|
|
||||||
|
## Negative Listing
|
||||||
|
|
||||||
|
Listing what something is *not* before revealing what it *is*. A rhetorical striptease.
|
||||||
|
|
||||||
|
| Pattern | Problem |
|
||||||
|
|---------|---------|
|
||||||
|
| "Not a X... Not a Y... A Z." | Dramatic buildup through negation |
|
||||||
|
| "It wasn't X. It wasn't Y. It was Z." | Same structure, past tense |
|
||||||
|
|
||||||
|
**Instead:** State Z. The reader doesn't need the runway.
|
||||||
|
|
||||||
|
## Dramatic Fragmentation
|
||||||
|
|
||||||
|
Sentence fragments for emphasis read as manufactured profundity.
|
||||||
|
|
||||||
|
| Pattern | Problem |
|
||||||
|
|---------|---------|
|
||||||
|
| "[Noun]. That's it. That's the [thing]." | Performative simplicity |
|
||||||
|
| "X. And Y. And Z." | Staccato drama |
|
||||||
|
| "This unlocks something. [Word]." | Artificial revelation |
|
||||||
|
|
||||||
|
**Instead:** Complete sentences. Trust content over presentation.
|
||||||
|
|
||||||
|
## Rhetorical Setups
|
||||||
|
|
||||||
|
These announce insight rather than deliver it.
|
||||||
|
|
||||||
|
| Pattern | Problem |
|
||||||
|
|---------|---------|
|
||||||
|
| "What if [reframe]?" | Socratic posturing |
|
||||||
|
| "Here's what I mean:" | Redundant preview |
|
||||||
|
| "Think about it:" | Condescending prompt |
|
||||||
|
| "And that's okay." | Unnecessary permission |
|
||||||
|
|
||||||
|
**Instead:** Make the point. Let readers draw conclusions.
|
||||||
|
|
||||||
|
## Formulaic Constructions
|
||||||
|
|
||||||
|
| Pattern | Problem |
|
||||||
|
|---------|---------|
|
||||||
|
| "By the time X, I was Y." | Narrative template |
|
||||||
|
| "X that isn't Y" | Indirect. Say "X is broken" |
|
||||||
|
|
||||||
|
## False Agency
|
||||||
|
|
||||||
|
Giving inanimate things human verbs. Complaints don't "become" fixes. Bets don't "live or die." Decisions don't "emerge." A person does something to make those things happen. AI loves this because it avoids naming the actor.
|
||||||
|
|
||||||
|
| Pattern | Problem |
|
||||||
|
|---------|---------|
|
||||||
|
| "a complaint becomes a fix" | The complaint did nothing. Someone fixed it. |
|
||||||
|
| "a bet lives or dies in days" | Bets don't have lifespans. Someone kills the project or ships it. |
|
||||||
|
| "the decision emerges" | Decisions don't emerge. Someone decides. |
|
||||||
|
| "the culture shifts" | Cultures don't shift on their own. People change behavior. |
|
||||||
|
| "the conversation moves toward" | Conversations don't move. Someone steers. |
|
||||||
|
| "the data tells us" | Data sits there. Someone reads it and draws a conclusion. |
|
||||||
|
| "the market rewards" | Markets don't reward. Buyers pay for things. |
|
||||||
|
|
||||||
|
**Instead:** Name the human. "The team fixed it that week" beats "the complaint becomes a fix." If no specific person fits, use "you" to put the reader in the seat.
|
||||||
|
|
||||||
|
## Narrator-from-a-Distance
|
||||||
|
|
||||||
|
Floating above the scene instead of putting the reader in it.
|
||||||
|
|
||||||
|
| Pattern | Problem |
|
||||||
|
|---------|---------|
|
||||||
|
| "Nobody designed this." | Disembodied observation |
|
||||||
|
| "This happens because..." | Lecturer voice |
|
||||||
|
| "This is why..." | Same |
|
||||||
|
| "People tend to..." | Armchair sociologist |
|
||||||
|
|
||||||
|
**Instead:** Put the reader in the room. "You don't sit down one day and decide to..." beats "Nobody designed this."
|
||||||
|
|
||||||
|
## Passive Voice
|
||||||
|
|
||||||
|
Every sentence needs a subject doing something. Passive voice hides the actor and drains energy.
|
||||||
|
|
||||||
|
| Pattern | Fix |
|
||||||
|
|---------|-----|
|
||||||
|
| "X was created" | Name who created it |
|
||||||
|
| "It is believed that" | Name who believes it |
|
||||||
|
| "Mistakes were made" | Name who made them |
|
||||||
|
| "The decision was reached" | Name who decided |
|
||||||
|
|
||||||
|
**Instead:** Find the actor. Put them at the front of the sentence.
|
||||||
|
|
||||||
|
## Sentence Starters to Avoid
|
||||||
|
|
||||||
|
| Pattern | Fix |
|
||||||
|
|---------|-----|
|
||||||
|
| Sentences starting with What, When, Where, Which, Who, Why, How | Restructure. Lead with the subject or the verb. |
|
||||||
|
| Paragraphs starting with "So" | Start with content |
|
||||||
|
| Sentences starting with "Look," | Remove |
|
||||||
|
|
||||||
|
Wh- openers become a crutch. "What makes this hard is..." becomes "The constraint is..." or better, name the specific constraint.
|
||||||
|
|
||||||
|
## Rhythm Patterns
|
||||||
|
|
||||||
|
| Pattern | Fix |
|
||||||
|
|---------|-----|
|
||||||
|
| Three-item lists | Use two items or one |
|
||||||
|
| Questions answered immediately | Let questions breathe or cut them |
|
||||||
|
| Every paragraph ends punchily | Vary endings |
|
||||||
|
| Em-dashes | Remove. Use commas or periods. No em dashes at all. |
|
||||||
|
| Staccato fragmentation | Don't stack short punchy sentences |
|
||||||
|
| "Not always. Not perfectly." | Hedging disguised as reassurance |
|
||||||
|
|
||||||
|
## Word Patterns
|
||||||
|
|
||||||
|
| Pattern | Problem |
|
||||||
|
|---------|---------|
|
||||||
|
| Lazy extremes (every, always, never, everyone, everybody, nobody) | False authority. Use specifics instead of sweeping claims. |
|
||||||
|
| All adverbs (-ly words, "really," "just," "literally," "genuinely," "honestly," "simply," "actually") | Empty emphasis. See phrases.md for full list. |
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
Subproject commit 3c7017d636c3a4aad378433ea6d0cfa6c921da4a
|
|
||||||
1
skills/taste-skill/.github/FUNDING.yml
vendored
Normal file
1
skills/taste-skill/.github/FUNDING.yml
vendored
Normal file
|
|
@ -0,0 +1 @@
|
||||||
|
github: Leonxlnx
|
||||||
11
skills/taste-skill/.github/copilot-instructions.md
vendored
Normal file
11
skills/taste-skill/.github/copilot-instructions.md
vendored
Normal file
|
|
@ -0,0 +1,11 @@
|
||||||
|
# Copilot Instructions: Taste Standard
|
||||||
|
|
||||||
|
> **Note:** GitHub Copilot automatically reads this file to set its global behavior. By including this in the `.github` folder, Copilot stops writing generic "slop" code and adheres to the premium Taste Skill standards.
|
||||||
|
|
||||||
|
## The "Anti-Slop" Manifesto for Copilot
|
||||||
|
|
||||||
|
1. **No Generic UI:** Stop generating default SaaS templates. Use high contrast, strong typographic hierarchy, and extreme care for alignment.
|
||||||
|
2. **Premium Whitespace:** Elements need room to breathe. Use proportional `clamp()` spacing over rigid padding.
|
||||||
|
3. **Cinematic Motion:** Never use linear easing. All animations must use spring physics (`stiffness: 100, damping: 20` or similar).
|
||||||
|
4. **Complete Implementation:** No placeholders. No `// TODO: add actual code here`. Write the full, working implementation every single time.
|
||||||
|
5. **Contextual Awareness:** For deep style configurations, read the localized `SKILL.md` files in the `skills/` directory.
|
||||||
111
skills/taste-skill/CHANGELOG.md
Normal file
111
skills/taste-skill/CHANGELOG.md
Normal file
|
|
@ -0,0 +1,111 @@
|
||||||
|
# Changelog
|
||||||
|
|
||||||
|
All notable changes to taste-skill live here. The repo follows SemVer-ish discipline: experimental pre-releases iterate freely; stable releases lock the API.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## [Unreleased]
|
||||||
|
|
||||||
|
### Repo
|
||||||
|
|
||||||
|
- `taste-skill` (install name `design-taste-frontend`) is now **v2 (experimental)**. The previous v1 is preserved as `taste-skill-v1` (install name `design-taste-frontend-v1`).
|
||||||
|
- New `CHANGELOG.md` (this file).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## v2 (experimental) - the new default for `taste-skill`
|
||||||
|
|
||||||
|
v2 (experimental) is a substantial rewrite of the original taste-skill. It keeps the dial-driven philosophy (`DESIGN_VARIANCE`, `MOTION_INTENSITY`, `VISUAL_DENSITY`) and adds structure, hard rules, and concrete implementation patterns the agent can actually follow.
|
||||||
|
|
||||||
|
**This is a pre-release.** It is the new default install because it is genuinely better than v1, but it is still iterating. Refinements may land in any v2 experimental release. The API (install name, dial names, section structure) will stabilize at v2.0.0 stable.
|
||||||
|
|
||||||
|
### What's new in v2 (experimental)
|
||||||
|
|
||||||
|
**New sections**
|
||||||
|
|
||||||
|
- **§0 Brief Inference** - before any code, the agent reads the room (page kind, vibe words, references, audience, constraints) and declares a one-line design read. Anti-default discipline.
|
||||||
|
- **§2 Brief → Design System Map** - when a brief reads as Material / Fluent / Carbon / Polaris / Atlassian / Primer / GOV.UK / USWDS / Bootstrap / Radix / shadcn / Tailwind, reach for the **official** package. When the brief is an aesthetic (glassmorphism, bento, brutalism, editorial, dark tech, aurora, kinetic typography), use web standards and label the implementation honestly. Apple Liquid Glass is documented as an approximation, not an official package.
|
||||||
|
- **§8 Dark Mode Protocol** - dual-mode by default, token strategy declared per project, contrast and hierarchy parity enforced.
|
||||||
|
- **§11 Redesign Protocol** - mode detection (Greenfield / Preserve / Overhaul), audit before touching, modernisation levers in priority order, what never changes silently (URL structure, nav labels, form field names, brand wordmark, legal copy).
|
||||||
|
- **§12 The Block Library (Contract)** - schema for iteratively adding real, source-backed block implementations (hero, feature, social-proof, pricing, cta, footer, portfolio, transition, navigation).
|
||||||
|
- **§13 Out of Scope** - explicit list of what taste-skill is NOT for (dashboards, data tables, multi-step forms, code editors, native mobile, realtime collab UIs).
|
||||||
|
- **§14 Final Pre-Flight Check** - hard checklist. Every box must honestly pass before shipping.
|
||||||
|
|
||||||
|
**Hardened bans (Section 9, "AI Tells")**
|
||||||
|
|
||||||
|
- **§9.G Em-Dash Ban (complete)** - zero em-dashes (`—`) anywhere on the page. Headlines, eyebrows, pills, body copy, quotes, attribution, captions, button text, alt text. Use a hyphen (`-`) or restructure the sentence. This was the single most-violated stylistic Tell in pre-v2 testing.
|
||||||
|
- Section numbering eyebrows (`00 / INDEX`, `001 · Capabilities`, `06 · how it works`) banned outright.
|
||||||
|
- Version labels in hero (`V0.6`, `INVITE-ONLY PREVIEW`, `BETA`) banned unless the brief is explicitly a product launch.
|
||||||
|
- Photo-credit captions as decoration (`Field study no. 12 · Ines Caetano`) banned unless real attribution.
|
||||||
|
- Decoration text strips at hero bottom (`BRAND. MOTION. SPATIAL.`) banned.
|
||||||
|
- Pills / labels overlaid on images banned.
|
||||||
|
- Version footers (`v1.4.2`, `Build 0048`) banned on marketing pages.
|
||||||
|
- Locale / city-name / time / weather strips (`Lisbon, working with founders`) banned for 99% of briefs.
|
||||||
|
- Scroll cues (`Scroll`, `↓ scroll`, `Scroll to explore`) banned.
|
||||||
|
- Zero decorative status dots by default.
|
||||||
|
- `border-t` + `border-b` on every row of long lists banned (use a different UI component).
|
||||||
|
- Scoring / progress bars with filled background tracks banned as comparison visuals.
|
||||||
|
- Div-based fake product UI (fake task lists / dashboards / terminals built from styled divs) banned.
|
||||||
|
- Floating top-right sub-text in section headings banned.
|
||||||
|
- Hand-rolled SVG icons strongly discouraged; use Phosphor / HugeIcons / Radix / Tabler.
|
||||||
|
|
||||||
|
**Hardened design rules**
|
||||||
|
|
||||||
|
- **Color Consistency Lock** - one accent across the whole page; no random color swaps in section 7.
|
||||||
|
- **Shape Consistency Lock** - one corner-radius system per page.
|
||||||
|
- **Button Contrast Check** - every CTA passes WCAG AA contrast (no white-on-white).
|
||||||
|
- **Hero Discipline** - headline ≤ 2 lines, subtext ≤ 20 words and ≤ 4 lines, CTAs visible without scroll, font scale planned with image size.
|
||||||
|
- **Navigation** - single line at desktop, height ≤ 80px.
|
||||||
|
- **"Used by / Trusted by"** logo wall lives UNDER the hero, uses real SVG logos (Simple Icons / devicon), never plain text wordmarks.
|
||||||
|
- **Section-Layout-Repetition Ban** - across 8 sections, at least 4 different layout families.
|
||||||
|
- **Bento Cell Count Rule** - N items = exactly N cells; no empty middle or trailing cells.
|
||||||
|
- **Page Theme Lock** - one theme (light / dark / auto) for the whole page; no mid-page light/dark flips.
|
||||||
|
- **Italic Descender Clearance** - italic display words with `y g j p q` need `leading-[1.1]` minimum and `pb-1` reserve.
|
||||||
|
- **Long lists need a different UI component** - `<ul>` + `divide-y` for > 5 items is the lazy default; reach for cards / tabs / marquee / carousel / scroll-snap pills.
|
||||||
|
- **Long-list-divider-overuse banned** - no `border-t` + `border-b` on every row.
|
||||||
|
|
||||||
|
**Animation discipline**
|
||||||
|
|
||||||
|
- Motion library standardised on **Motion** (`motion/react`, the rebrand of Framer Motion). Legacy `framer-motion` package still works as alias.
|
||||||
|
- **§5.A GSAP Sticky-Stack** - canonical code skeleton (`start: "top top"`, `pin: true`, `scrub: true`, transform driven by NEXT card's trigger).
|
||||||
|
- **§5.B GSAP Horizontal-Pan** - canonical code skeleton (`start: "top top"`, `pin: true`, `end: "+=" + distance`, `scrub: 1`).
|
||||||
|
- **§5.C Scroll-Reveal Stagger** - lighter Motion-only pattern using `whileInView`. Use this for simple reveals; save GSAP for actual pinning/scrubbing.
|
||||||
|
- **§5.D Forbidden Animation Patterns** - `window.addEventListener('scroll')`, custom scroll calculations in React state, `requestAnimationFrame` loops touching React state. Banned outright.
|
||||||
|
- **Reduced motion mandatory** for anything `MOTION_INTENSITY > 3` - wrap in `useReducedMotion()` or `@media (prefers-reduced-motion: reduce)`.
|
||||||
|
- **"Motion claimed, motion shown"** - pages claiming `MOTION_INTENSITY > 4` must actually animate; otherwise drop the dial to 3 and ship clean static.
|
||||||
|
|
||||||
|
**Stack updates**
|
||||||
|
|
||||||
|
- Tailwind v4 default; v3 only when the existing project demands it.
|
||||||
|
- Motion replaces Framer Motion as the recommended import path.
|
||||||
|
- Icons: Phosphor / HugeIcons / Radix / Tabler (in priority order). Lucide discouraged. Hand-rolled SVG icons banned.
|
||||||
|
|
||||||
|
### What's the same
|
||||||
|
|
||||||
|
- Three dials (`DESIGN_VARIANCE`, `MOTION_INTENSITY`, `VISUAL_DENSITY`) - same spirit, expanded with preset matrix and inference rules.
|
||||||
|
- Anti-slop philosophy - same direction, harder enforcement.
|
||||||
|
- Performance guardrails - `transform`/`opacity` only, no `top/left/width/height` animation, hardware acceleration.
|
||||||
|
|
||||||
|
### Why we made v2 (experimental) the new default
|
||||||
|
|
||||||
|
Pre-v2, the original taste-skill set the right direction but was easy for agents to skim past. Production testing showed the same Tells emerging across builds (em-dash everywhere, section-number eyebrows, "Quietly in use at", decorative dots, fake screenshots out of styled divs, broken GSAP scroll triggers).
|
||||||
|
|
||||||
|
v2 closes those gaps with hard rules, canonical code skeletons, and a pre-flight checklist the agent must run. It is the version we now recommend.
|
||||||
|
|
||||||
|
### How to pin to v1 if you need it
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend-v1"
|
||||||
|
```
|
||||||
|
|
||||||
|
This installs the original SKILL.md unchanged.
|
||||||
|
|
||||||
|
### Stability note
|
||||||
|
|
||||||
|
v2 (experimental) is the new default AND it is actively iterating. Refinements may land in any pre-release while we converge on v2.0.0 stable. Breaking changes (rename of install name, removal of sections) will be batched and called out clearly when v2.0.0 stable cuts.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## v1 - the original taste-skill
|
||||||
|
|
||||||
|
The original release. Dial-driven philosophy, anti-slop rules, reference vocabulary of pattern names. Preserved at `skills/taste-skill-v1/` and installable as `design-taste-frontend-v1`.
|
||||||
21
skills/taste-skill/LICENSE
Normal file
21
skills/taste-skill/LICENSE
Normal file
|
|
@ -0,0 +1,21 @@
|
||||||
|
MIT License
|
||||||
|
|
||||||
|
Copyright (c) 2026 Leonxlnx
|
||||||
|
|
||||||
|
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||||
|
of this software and associated documentation files (the "Software"), to deal
|
||||||
|
in the Software without restriction, including without limitation the rights
|
||||||
|
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||||
|
copies of the Software, and to permit persons to whom the Software is
|
||||||
|
furnished to do so, subject to the following conditions:
|
||||||
|
|
||||||
|
The above copyright notice and this permission notice shall be included in all
|
||||||
|
copies or substantial portions of the Software.
|
||||||
|
|
||||||
|
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||||
|
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||||
|
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||||
|
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||||
|
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||||
|
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||||
|
SOFTWARE.
|
||||||
196
skills/taste-skill/README.md
Normal file
196
skills/taste-skill/README.md
Normal file
|
|
@ -0,0 +1,196 @@
|
||||||
|
<p align="center">
|
||||||
|
<img src="assets/readme-banner.png" alt="Taste Skill - Anti-slop Agent Skills for premium frontends" width="100%" />
|
||||||
|
</p>
|
||||||
|
|
||||||
|
# Taste Skill
|
||||||
|
|
||||||
|
<p align="center">
|
||||||
|
<em>The Anti-Slop Frontend Framework for AI Agents</em>
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<p align="center">
|
||||||
|
<a href="https://tasteskill.dev" title="Taste Skill - tasteskill.dev">
|
||||||
|
<img src="assets/taste-skill-logo.webp" width="80" height="80" alt="Taste Skill" />
|
||||||
|
</a>
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<p align="center">
|
||||||
|
<a href="https://tasteskill.dev">
|
||||||
|
<img src="https://img.shields.io/badge/OPEN-tasteskill.dev-%23a855f7?style=for-the-badge&labelColor=%230f172a" alt="Open tasteskill.dev" />
|
||||||
|
</a>
|
||||||
|
</p>
|
||||||
|
|
||||||
|
Portable **Agent Skills** that upgrade AI-built interfaces: stronger layout, typography, motion, and spacing instead of boilerplate-looking UIs. This repo also includes **image-generation skills** for reference boards (web, mobile, brand kits). Pair them with **ChatGPT Images** or similar generators, then hand the frames to Codex, Cursor, or Claude Code for implementation.
|
||||||
|
|
||||||
|
<p align="center">
|
||||||
|
<a href="https://github.com/Leonxlnx/taste-skill/stargazers"><img src="https://img.shields.io/github/stars/Leonxlnx/taste-skill?style=for-the-badge&logo=github&labelColor=1e293b&color=fbbf24" alt="GitHub stars"/></a>
|
||||||
|
<a href="LICENSE"><img src="https://img.shields.io/badge/License-MIT-fbbf24?style=for-the-badge&labelColor=1e293b" alt="MIT License"/></a>
|
||||||
|
<a href="#installing"><img src="https://img.shields.io/badge/Tools-Codex%20%C2%B7%20Cursor%20%C2%B7%20Claude-111827?style=for-the-badge&labelColor=1e293b" alt="Supported agents"/></a>
|
||||||
|
<a href="https://www.tasteskill.dev/changelog"><img src="https://img.shields.io/badge/Changelog-Latest-059669?style=for-the-badge&labelColor=1e293b" alt="Changelog on tasteskill.dev"/></a>
|
||||||
|
</p>
|
||||||
|
|
||||||
|
## Disclaimer
|
||||||
|
|
||||||
|
Taste Skill has no official token, coin, or crypto project. Any token using my name, image, or project is unaffiliated and not endorsed by me.
|
||||||
|
|
||||||
|
<p align="center"><sub><a href="#disclaimer">Disclaimer</a> · <a href="#installing">Install</a> · <a href="#skills">Skills</a> · <a href="#settings-taste-skill-only">Settings</a> · <a href="#examples">Examples</a> · <a href="#support-the-project">Sponsor</a> · <a href="#research">Research</a> · <a href="#common-questions">FAQ</a> · <a href="#license">License</a></sub></p>
|
||||||
|
|
||||||
|
## Feedback & Contributions
|
||||||
|
|
||||||
|
We would love your feedback. Suggestions and bug reports:
|
||||||
|
|
||||||
|
- Open a Pull Request or Issue on GitHub
|
||||||
|
- DM [@lexnlin](https://x.com/lexnlin) or [@blueemi99](https://x.com/blueemi99)
|
||||||
|
- Email us at [hello@tasteskill.dev](mailto:hello@tasteskill.dev)
|
||||||
|
|
||||||
|
## Installing
|
||||||
|
|
||||||
|
The [`npx skills add`](https://github.com/vercel-labs/agent-skills) CLI scans the `skills/` folder in this repo, so **all skills below (code and image-generation) install the same way.**
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx skills add https://github.com/Leonxlnx/taste-skill
|
||||||
|
```
|
||||||
|
|
||||||
|
Install a single skill by its **install name** (the `name:` field inside the SKILL frontmatter, not the folder name):
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"
|
||||||
|
```
|
||||||
|
|
||||||
|
You can also copy any `SKILL.md` into your project or paste it into ChatGPT / Codex conversations.
|
||||||
|
|
||||||
|
### Updating from the previous version
|
||||||
|
|
||||||
|
The default `taste-skill` (install name `design-taste-frontend`) is now **v2 (experimental)**, a substantial rewrite of the original v1. If you already have v1 installed, just re-run the install command and you will be upgraded:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"
|
||||||
|
```
|
||||||
|
|
||||||
|
The install name did not change, so no script updates are needed. The newer SKILL.md replaces the older one in place.
|
||||||
|
|
||||||
|
If you depend on the exact behavior of v1 and want to pin to it explicitly:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend-v1"
|
||||||
|
```
|
||||||
|
|
||||||
|
See [CHANGELOG.md](CHANGELOG.md) for the full v1 to v2 diff and the rationale.
|
||||||
|
|
||||||
|
## Skills
|
||||||
|
|
||||||
|
Each skill does one job; you do not need all of them at once. **Implementation skills** output code. **Image-generation skills** output reference images only.
|
||||||
|
|
||||||
|
The `Install name` column is the exact value you pass to `--skill`.
|
||||||
|
|
||||||
|
| Skill (folder) | Install name | Description |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| **taste-skill** | `design-taste-frontend` | 🆕 **v2 (experimental)** - substantial rewrite of the default skill. Reads the brief, infers the design language, tunes three dials (VARIANCE / MOTION / DENSITY). Brief inference, design-system map, hard em-dash ban, canonical GSAP code skeletons, redesign-audit protocol, strict pre-flight check. Actively iterating toward v2.0.0 stable. |
|
||||||
|
| **taste-skill-v1** | `design-taste-frontend-v1` | The original v1 of taste-skill, preserved for projects depending on its exact behavior. Use only if the v2 default breaks something specific in your workflow. |
|
||||||
|
| **gpt-tasteskill** | `gpt-taste` | Stricter variant for GPT/Codex: higher layout variance, stronger GSAP direction, aggressive anti-slop. |
|
||||||
|
| **image-to-code-skill** | `image-to-code` | Image-first pipeline: generate site references, analyze them, then implement the frontend to match. |
|
||||||
|
| **redesign-skill** | `redesign-existing-projects` | Existing projects: audit the UI first, then fix layout, spacing, hierarchy, styling. |
|
||||||
|
| **soft-skill** | `high-end-visual-design` | Polished, calm, expensive UI with softer contrast, whitespace, premium fonts, spring motion. |
|
||||||
|
| **output-skill** | `full-output-enforcement` | When the model ships half-finished work: full output, no placeholder comments. |
|
||||||
|
| **minimalist-skill** | `minimalist-ui` | Editorial product UI (Notion/Linear vibes), restrained palette, crisp structure. |
|
||||||
|
| **brutalist-skill** | `industrial-brutalist-ui` | Hard mechanical language: Swiss type, sharp contrast, experimental layout. |
|
||||||
|
| **stitch-skill** | `stitch-design-taste` | Google Stitch-compatible rules, including optional `DESIGN.md` export format. |
|
||||||
|
|
||||||
|
### Image generation skills
|
||||||
|
|
||||||
|
These produce design images only (no code). Use with ChatGPT Images, Codex image mode, or any agent that generates images.
|
||||||
|
|
||||||
|
| Skill (folder) | Install name | Description |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| **imagegen-frontend-web** | `imagegen-frontend-web` | Website comps: hero, landing, multi-section with strong typography, spacing, anti-slop art direction. |
|
||||||
|
| **imagegen-frontend-mobile** | `imagegen-frontend-mobile` | Mobile screens and flows: iOS/Android/cross-platform, mockups, readable type, coherent sets. |
|
||||||
|
| **brandkit** | `brandkit` | Brand-kit boards: logo directions, palettes, type, identity applications across categories. |
|
||||||
|
|
||||||
|
### Which one should I use?
|
||||||
|
|
||||||
|
- Start with **taste-skill** for the safest general default. (Now v2 experimental - see what changed in the [CHANGELOG](CHANGELOG.md).)
|
||||||
|
- If you depend on the exact behavior of the original taste-skill, install **taste-skill-v1** instead.
|
||||||
|
- Use **gpt-taste** when you want the stricter GPT/Codex-oriented rules and motion/layout enforcement.
|
||||||
|
- Use **image-to-code-skill** for image → analyze → code website workflows.
|
||||||
|
- Use **redesign-skill** to improve an existing codebase instead of greenfield styling.
|
||||||
|
- Add **soft-skill**, **minimalist-skill**, or **brutalist-skill** when the visual direction is already chosen.
|
||||||
|
- Add **output-skill** if the agent keeps truncating output.
|
||||||
|
- Use **imagegen-frontend-web**, **imagegen-frontend-mobile**, or **brandkit** when the deliverable is **images** (comps, flows, identity boards), then pass results to your coding agent.
|
||||||
|
|
||||||
|
### Image-first tip
|
||||||
|
|
||||||
|
For **image-to-code-skill**, state the pipeline in the prompt, e.g.: `follow the skill: generate images, then analyze, then code`.
|
||||||
|
|
||||||
|
### ChatGPT Images and Codex
|
||||||
|
|
||||||
|
Attach or paste **`imagegen-frontend-web`**, **`imagegen-frontend-mobile`**, or **`brandkit`** and ask for the frames you need, then feed the renders to Codex, Cursor, or Claude Code. Use **image-to-code-skill** when you want one workflow that both generates references and implements the site in code.
|
||||||
|
|
||||||
|
## Settings (taste-skill only)
|
||||||
|
|
||||||
|
Numbers at the top of the file are 1-10 dials:
|
||||||
|
|
||||||
|
- **DESIGN_VARIANCE**: Layout experimentation (lower: centered/clean · higher: asymmetric/modern).
|
||||||
|
- **MOTION_INTENSITY**: Animation depth (lower: hover · higher: scroll/magnetic).
|
||||||
|
- **VISUAL_DENSITY**: Information per viewport (lower: spacious · higher: dense dashboards).
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
Created with taste-skill:
|
||||||
|
|
||||||
|
<p>
|
||||||
|
<img src="examples/floria-top.webp" width="400" />
|
||||||
|
<img src="examples/floria-bottom.webp" width="400" />
|
||||||
|
</p>
|
||||||
|
|
||||||
|
## Support the project
|
||||||
|
|
||||||
|
If Taste Skill helps you, consider sponsoring:
|
||||||
|
|
||||||
|
[Sponsor on GitHub](https://github.com/sponsors/Leonxlnx)
|
||||||
|
|
||||||
|
### Current Sponsors
|
||||||
|
|
||||||
|
<a href="https://github.com/dnakov"><img src="https://github.com/dnakov.png" width="40" height="40" style="border-radius:50%" alt="dnakov" title="dnakov" /></a>
|
||||||
|
<a href="https://github.com/AkramReshad"><img src="https://github.com/AkramReshad.png" width="40" height="40" style="border-radius:50%" alt="AkramReshad" title="AkramReshad" /></a>
|
||||||
|
<a href="https://github.com/ajmalaksar25"><img src="https://github.com/ajmalaksar25.png" width="40" height="40" style="border-radius:50%" alt="ajmalaksar25" title="ajmalaksar25" /></a>
|
||||||
|
<a href="https://github.com/krikkkk"><img src="https://github.com/krikkkk.png" width="40" height="40" style="border-radius:50%" alt="krikkkk" title="krikkkk" /></a>
|
||||||
|
<a href="https://github.com/navanchauhan"><img src="https://github.com/navanchauhan.png" width="40" height="40" style="border-radius:50%" alt="navanchauhan" title="navanchauhan" /></a>
|
||||||
|
<a href="https://github.com/robinebers"><img src="https://github.com/robinebers.png" width="40" height="40" style="border-radius:50%" alt="robinebers" title="robinebers" /></a>
|
||||||
|
<a href="https://github.com/JKc66"><img src="https://github.com/JKc66.png" width="40" height="40" style="border-radius:50%" alt="JKc66" title="JKc66" /></a>
|
||||||
|
<a href="https://github.com/u2393696078-rgb"><img src="https://github.com/u2393696078-rgb.png" width="40" height="40" style="border-radius:50%" alt="u2393696078-rgb" title="u2393696078-rgb" /></a>
|
||||||
|
<a href="https://github.com/a-human-created-this"><img src="https://github.com/a-human-created-this.png" width="40" height="40" style="border-radius:50%" alt="a-human-created-this" title="a-human-created-this" /></a>
|
||||||
|
<a href="https://github.com/AtharvaJaiswal005"><img src="https://github.com/AtharvaJaiswal005.png" width="40" height="40" style="border-radius:50%" alt="AtharvaJaiswal005" title="AtharvaJaiswal005" /></a>
|
||||||
|
<a href="https://github.com/ghughes7"><img src="https://github.com/ghughes7.png" width="40" height="40" style="border-radius:50%" alt="ghughes7" title="ghughes7" /></a>
|
||||||
|
<a href="https://github.com/mccun934"><img src="https://github.com/mccun934.png" width="40" height="40" style="border-radius:50%" alt="mccun934" title="mccun934" /></a>
|
||||||
|
|
||||||
|
<p align="center">
|
||||||
|
<a href="https://www.star-history.com/leonxlnx/taste-skill">
|
||||||
|
<picture>
|
||||||
|
<source media="(prefers-color-scheme: dark)" srcset="https://api.star-history.com/badge?repo=Leonxlnx/taste-skill&theme=dark" />
|
||||||
|
<source media="(prefers-color-scheme: light)" srcset="https://api.star-history.com/badge?repo=Leonxlnx/taste-skill" />
|
||||||
|
<img alt="Star History Rank" src="https://api.star-history.com/badge?repo=Leonxlnx/taste-skill" />
|
||||||
|
</picture>
|
||||||
|
</a>
|
||||||
|
</p>
|
||||||
|
|
||||||
|
## Research
|
||||||
|
|
||||||
|
Background writing that shaped these skills lives in [`research/`](research/).
|
||||||
|
|
||||||
|
## Common Questions
|
||||||
|
|
||||||
|
**How is this different from other AI design skills?**
|
||||||
|
Multiple specialized variants, adjustable dials in key skills, anti-repetition rules informed by dedicated research. All are framework agnostic across major coding agents.
|
||||||
|
|
||||||
|
**Does it work with React, Vue, Svelte?**
|
||||||
|
Yes. Rules target design intent, not a single framework API.
|
||||||
|
|
||||||
|
**What is SKILL.md?**
|
||||||
|
A portable instruction file agents can load automatically; install via `npx skills add` or by copying into a repo or conversation.
|
||||||
|
|
||||||
|
**Do image-generation skills install with `npx skills add`?**
|
||||||
|
Yes. They live under `skills/` alongside the code skills so the same CLI discovers them.
|
||||||
|
|
||||||
|
## License
|
||||||
|
|
||||||
|
[MIT License](LICENSE) · Copyright (c) 2026 Leonxlnx
|
||||||
0
skills/taste-skill/assets/.gitkeep
Normal file
0
skills/taste-skill/assets/.gitkeep
Normal file
BIN
skills/taste-skill/assets/readme-banner.png
Normal file
BIN
skills/taste-skill/assets/readme-banner.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.5 MiB |
BIN
skills/taste-skill/assets/taste-skill-logo.webp
Normal file
BIN
skills/taste-skill/assets/taste-skill-logo.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 3.2 KiB |
BIN
skills/taste-skill/examples/floria-bottom.webp
Normal file
BIN
skills/taste-skill/examples/floria-bottom.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 166 KiB |
BIN
skills/taste-skill/examples/floria-full.webp
Normal file
BIN
skills/taste-skill/examples/floria-full.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 555 KiB |
BIN
skills/taste-skill/examples/floria-top.webp
Normal file
BIN
skills/taste-skill/examples/floria-top.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 296 KiB |
8
skills/taste-skill/research/README.md
Normal file
8
skills/taste-skill/research/README.md
Normal file
|
|
@ -0,0 +1,8 @@
|
||||||
|
# Research
|
||||||
|
|
||||||
|
Background research that informed the skills in this project. Each topic gets its own subfolder.
|
||||||
|
|
||||||
|
## Topics
|
||||||
|
|
||||||
|
### [LLM Laziness](laziness/)
|
||||||
|
Why AI models produce incomplete outputs (placeholder code, truncated responses, skipped sections) and documented techniques to prevent it. Covers root causes, parameter fixes, prompt techniques, and experiment data.
|
||||||
25
skills/taste-skill/research/laziness/README.md
Normal file
25
skills/taste-skill/research/laziness/README.md
Normal file
|
|
@ -0,0 +1,25 @@
|
||||||
|
# LLM Output Truncation Research
|
||||||
|
|
||||||
|
A structured analysis of why large language models produce incomplete outputs, and documented methods to restore full-fidelity generation. All findings are drawn from controlled experiments, published studies, and field-tested engineering practices.
|
||||||
|
|
||||||
|
## Directory Structure
|
||||||
|
|
||||||
|
### Root Causes
|
||||||
|
Analysis of the economic, architectural, and behavioral mechanisms that drive output truncation in production LLMs.
|
||||||
|
|
||||||
|
- [RLHF and Compute Economics](root-causes/rlhf-and-compute.md) — How reinforcement learning and cost optimization create systematic brevity bias.
|
||||||
|
- [Training Data Bias](root-causes/training-data-bias.md) — How placeholder patterns in human-written code propagate into model outputs.
|
||||||
|
- [Cognitive Shortcuts](root-causes/cognitive-shortcuts.md) — Empirical evidence of models taking shortcuts on complex or lengthy tasks.
|
||||||
|
- [Output Limits](root-causes/output-limits.md) — Context window asymmetry and consumer-tier truncation mechanisms.
|
||||||
|
|
||||||
|
### Remediation
|
||||||
|
Documented techniques for overriding default truncation behavior, ordered from parameter-level fixes to full architectural solutions.
|
||||||
|
|
||||||
|
- [Parameter Tuning](remediation/parameter-tuning.md) — Temperature, Top-p, and Gemini thinking-level configuration.
|
||||||
|
- [Prompt Engineering](remediation/prompt-engineering.md) — Structural prompt techniques: syntax binding, XML frameworks, and verification loops.
|
||||||
|
- [Architectural Patterns](remediation/architectural-patterns.md) — MCP integration, lazy-loaded skills, and developer platform access.
|
||||||
|
- [Reference Prompts](remediation/reference-prompts.md) — Ready-to-use prompt templates for enforcing complete outputs.
|
||||||
|
|
||||||
|
### Findings
|
||||||
|
- [Empirical Results](findings/empirical-results.md) — Controlled experiment data from 2025 academic studies.
|
||||||
|
- [References](findings/references.md) — Cited studies and further reading.
|
||||||
|
|
@ -0,0 +1,58 @@
|
||||||
|
# Empirical Results
|
||||||
|
|
||||||
|
## 2025 Controlled Experiments
|
||||||
|
|
||||||
|
A controlled study published in December 2025 measured output truncation across several frontier models, including GPT-4 variants and DeepSeek. Three experiments were conducted:
|
||||||
|
|
||||||
|
### Experiment A: Multi-Part Instruction Compliance
|
||||||
|
|
||||||
|
Models were given complex prompts with multiple explicit requirements (formatting constraints, length requirements, mandatory sections). Results:
|
||||||
|
|
||||||
|
- No model fully satisfied both length requirements and all sub-part instructions natively
|
||||||
|
- Models frequently omitted mandatory output sections
|
||||||
|
- Required formatting constraints were routinely skipped
|
||||||
|
- Explicit length requirements were consistently undershot
|
||||||
|
|
||||||
|
### Experiment B: Decoding Suboptimality
|
||||||
|
|
||||||
|
Tested whether truncated outputs resulted from suboptimal token selection (the model "knowing" the right answer but selecting a worse token). Results:
|
||||||
|
|
||||||
|
- Limited evidence of decoding suboptimality on simple reasoning tasks
|
||||||
|
- The model's greedy, truncated output generally aligned with its highest-confidence solution
|
||||||
|
- Truncation is a deliberate behavioral choice, not a decoding failure
|
||||||
|
|
||||||
|
### Experiment C: Context Degradation
|
||||||
|
|
||||||
|
Tested whether models lose track of instructions during long, multi-turn conversations. Results:
|
||||||
|
|
||||||
|
- Surprising resilience against context degradation during 200-turn conversational tests
|
||||||
|
- Models maintained key facts and instructions significantly better than hypothesized
|
||||||
|
- Context loss is not the primary cause of truncation
|
||||||
|
|
||||||
|
### Key Conclusion
|
||||||
|
|
||||||
|
Laziness is not a failure of memory, context processing, or core model capabilities. It is a behavioral artifact triggered by:
|
||||||
|
1. Instruction complexity exceeding internal effort thresholds
|
||||||
|
2. Aggressively calibrated stopping pressure
|
||||||
|
3. Economic constraints embedded in the alignment layer
|
||||||
|
|
||||||
|
## Prompt Stimulus Effectiveness (Microsoft Research)
|
||||||
|
|
||||||
|
Controlled testing of psychological prompt stimuli documented in a Microsoft Research study:
|
||||||
|
|
||||||
|
| Stimulus | Measured Effect |
|
||||||
|
|:---|:---|
|
||||||
|
| Financial incentive framing ("$200 tip") | +45% output quality and length |
|
||||||
|
| Step-by-step instruction ("take a deep breath") | Accuracy: 34% to 80% on logic tasks |
|
||||||
|
| Stakes framing ("critical to my career") | +10% average performance |
|
||||||
|
| Combined (multiple stimuli) | Up to +115% overall performance |
|
||||||
|
|
||||||
|
These effects are reproducible and stem from statistical correlations in the training data between stakes language and high-effort human outputs.
|
||||||
|
|
||||||
|
## Seasonal Output Variation
|
||||||
|
|
||||||
|
Statistical analysis of ChatGPT outputs during November-December 2023 versus January-March 2024 confirmed:
|
||||||
|
|
||||||
|
- Measurable decrease in average output length during December
|
||||||
|
- Correlation with reduced work output in the training data during holiday periods
|
||||||
|
- Output length increased when the system prompt explicitly stated a non-winter month
|
||||||
20
skills/taste-skill/research/laziness/findings/references.md
Normal file
20
skills/taste-skill/research/laziness/findings/references.md
Normal file
|
|
@ -0,0 +1,20 @@
|
||||||
|
# References
|
||||||
|
|
||||||
|
## Cited Studies
|
||||||
|
|
||||||
|
- **EmotionPrompt (Microsoft Research)** — Demonstrates that emotional and stakes-based prompt framing mathematically improves LLM reasoning quality and output length. Documents the +45% improvement from financial framing and +115% from combined stimuli.
|
||||||
|
|
||||||
|
- **LazyBench** — Proves that frontier models (Gemini 1.5 Pro, GPT-4o) actively select cognitive shortcuts and fail tasks they are capable of solving when the perceived effort exceeds internal thresholds.
|
||||||
|
|
||||||
|
- **Compounding Error Avoidance** — Research demonstrating that models truncate outputs as a risk mitigation strategy, preferring shorter responses to reduce the surface area for factual errors on long-form tasks.
|
||||||
|
|
||||||
|
- **Seasonal Behavior Analysis (Winter Break Hypothesis)** — Statistical analysis confirming that LLMs internalize seasonal work patterns from training data, producing measurably shorter outputs during periods corresponding to human holiday seasons.
|
||||||
|
|
||||||
|
- **2025 Controlled Laziness Experiments** — Three-part academic study (December 2025) confirming that output truncation is a behavioral artifact of alignment training, not a failure of context processing or model capability.
|
||||||
|
|
||||||
|
## Further Reading
|
||||||
|
|
||||||
|
- Google Gemini API documentation on `thinking_level` parameter configuration
|
||||||
|
- Anthropic MCP (Model Context Protocol) specification and integration guides
|
||||||
|
- OpenAI API reference for temperature and Top-p parameter tuning
|
||||||
|
- YAML front-matter specification for SKILL.md lazy-loading architecture
|
||||||
|
|
@ -0,0 +1,55 @@
|
||||||
|
# Architectural Patterns
|
||||||
|
|
||||||
|
## Lazy-Loaded Skills
|
||||||
|
|
||||||
|
The standard pattern for managing large context requirements across AI agents is lazy-loaded prompt engineering through skill files.
|
||||||
|
|
||||||
|
A skill is a folder containing a `SKILL.md` file with:
|
||||||
|
|
||||||
|
- **YAML front-matter:** Contains `name` and a precise `description`. This metadata acts as the discovery hook — the agent reads only this during initialization (~100 tokens per skill).
|
||||||
|
- **Markdown body:** Full workflows, rules, and instructions. Loaded on-demand only when the agent determines the skill is relevant.
|
||||||
|
|
||||||
|
This architecture yields a documented 35% reduction in average context usage and prevents context dilution. However, discovery reliability depends on the specificity of the YAML description:
|
||||||
|
|
||||||
|
| Description Quality | Discovery Success Rate |
|
||||||
|
|:---|:---:|
|
||||||
|
| Vague ("Helps with designing APIs") | ~68% |
|
||||||
|
| Specific ("Design RESTful HTTP APIs with OpenAPI specs, focusing on versioning, error codes, and backward compatibility") | ~90% |
|
||||||
|
|
||||||
|
## Model Context Protocol (MCP)
|
||||||
|
|
||||||
|
MCP is an open standard (pioneered by Anthropic, adopted by Google and OpenAI) that enables real-time, bidirectional connections between LLMs and external data sources.
|
||||||
|
|
||||||
|
### Architecture Components
|
||||||
|
|
||||||
|
- **Host:** The AI application (IDE, terminal tool, chatbot) containing the LLM engine.
|
||||||
|
- **Client:** Internal bridge within the host that handles protocol communication.
|
||||||
|
- **Server:** External service exposing databases, APIs, or documentation to the client.
|
||||||
|
- **Transport:** JSON-RPC 2.0 messages over stdio (local) or HTTP (remote).
|
||||||
|
|
||||||
|
### How It Reduces Truncation
|
||||||
|
|
||||||
|
Without MCP, models rely on static training weights for factual claims. When those weights are outdated (e.g., a new API version was released after training cutoff), the model either hallucinates a plausible answer or truncates its response to avoid committing to specifics.
|
||||||
|
|
||||||
|
With MCP, the model fetches current documentation directly into its context window. This transforms the model from a static knowledge store into a reasoning engine operating on real-time data, eliminating the incentive to hallucinate or truncate.
|
||||||
|
|
||||||
|
### Example: Developer Knowledge API
|
||||||
|
|
||||||
|
Google's Developer Knowledge MCP Server indexes live documentation across Firebase, Android, and Google Cloud. When a model receives a development question:
|
||||||
|
|
||||||
|
1. It executes a `search_document` query against the live index
|
||||||
|
2. It evaluates returned page URIs
|
||||||
|
3. It fetches full document content via `get_document` or `batch_get_documents`
|
||||||
|
4. It generates its response based on current, authoritative documentation
|
||||||
|
|
||||||
|
This entirely bypasses the tendency to fabricate answers from outdated training data.
|
||||||
|
|
||||||
|
## Chunked Task Execution
|
||||||
|
|
||||||
|
For complex tasks that would produce outputs exceeding the model's generation limit, break the work into sequential steps:
|
||||||
|
|
||||||
|
1. Request the architecture and structure first (outline only)
|
||||||
|
2. Request each component individually with explicit instructions for completeness
|
||||||
|
3. Request assembly and integration after all components are generated
|
||||||
|
|
||||||
|
This prevents the model from attempting to estimate total output length and preemptively compressing its response.
|
||||||
|
|
@ -0,0 +1,44 @@
|
||||||
|
# Parameter Tuning
|
||||||
|
|
||||||
|
## Temperature and Top-p
|
||||||
|
|
||||||
|
Autoregressive models select each next token from a probability distribution generated by a softmax function applied to logit values. When a model defaults to brief outputs, the tokens associated with truncation and summarization have been assigned the highest probabilities through RLHF alignment.
|
||||||
|
|
||||||
|
### Temperature
|
||||||
|
|
||||||
|
Adjusting the temperature parameter changes how the softmax function distributes probability mass across candidate tokens.
|
||||||
|
|
||||||
|
- **Low temperature (0.0 - 0.5):** Amplifies differences between high and low-probability tokens. The model becomes highly deterministic, consistently selecting the highest-confidence continuation. Optimal for code generation, data extraction, and structured output.
|
||||||
|
- **Default temperature (1.0):** Retains the original probability distribution from training.
|
||||||
|
- **High temperature (1.5+):** Flattens the distribution, introducing more randomness. Useful for creative tasks but increases the risk of incoherent outputs.
|
||||||
|
|
||||||
|
Example probability distribution shift for a single token position:
|
||||||
|
|
||||||
|
| Token Candidate | Probability at Temp 1.5 | Probability at Temp ~0.0 | Raw Logit |
|
||||||
|
|:---|:---:|:---:|:---:|
|
||||||
|
| lazy | 0.4875 | 0.9933 | 2.0 |
|
||||||
|
| quick | 0.2503 | 0.0067 | 1.0 |
|
||||||
|
| tired | 0.1285 | 0.0000 | 0.0 |
|
||||||
|
| slow | 0.0660 | 0.0000 | -1.0 |
|
||||||
|
| clumsy | 0.0339 | 0.0000 | -2.0 |
|
||||||
|
|
||||||
|
### Top-p (Nucleus Sampling)
|
||||||
|
|
||||||
|
Top-p truncates the probability distribution by only considering the smallest set of tokens whose cumulative probability exceeds threshold p. A Top-p of 0.0 to 0.6 combined with low temperature forces the model into a narrow, deterministic execution path, reducing the entropy that enables creative refusals and unnecessary summarization.
|
||||||
|
|
||||||
|
## Gemini Thinking Level Configuration
|
||||||
|
|
||||||
|
Google Gemini 3 models replaced the legacy `thinking_budget` (a hard token count cap on internal reasoning) with a `thinking_level` parameter that provides relative guidance on computational depth.
|
||||||
|
|
||||||
|
| Setting | Flash Support | Pro Support | Use Case |
|
||||||
|
|:---|:---:|:---:|:---|
|
||||||
|
| `minimal` | Yes | No | High-throughput, low-latency tasks |
|
||||||
|
| `low` | Yes | Yes | Simple instruction following, data extraction |
|
||||||
|
| `medium` | Yes | Yes (3.1 Pro) | Moderate complexity tasks |
|
||||||
|
| `high` | Yes (Default) | Yes (Default) | Complex analysis, code generation, mathematics |
|
||||||
|
|
||||||
|
Important constraints:
|
||||||
|
- `thinking_level` and `thinking_budget` are mutually exclusive. Using both in one API call triggers an HTTP 400 error.
|
||||||
|
- Even at `low`, Gemini Pro models perform mandatory minimum internal deliberation for safety and alignment.
|
||||||
|
- For code generation and complex analysis, set to `medium` or `high` for quality scores consistently exceeding 92-95% compared to baseline.
|
||||||
|
- Avoid combining extremely low temperature with `high` thinking level, as this can occasionally induce internal reasoning loops.
|
||||||
|
|
@ -0,0 +1,52 @@
|
||||||
|
# Prompt Engineering Techniques
|
||||||
|
|
||||||
|
## Psychological Pattern Matching
|
||||||
|
|
||||||
|
LLMs do not have emotions or understand monetary incentives. However, specific linguistic patterns in the prompt activate different quality distributions in the model's latent space. Research has documented measurable effects:
|
||||||
|
|
||||||
|
| Technique | Documented Effect |
|
||||||
|
|:---|:---|
|
||||||
|
| "I will tip you $200 for a perfect solution" | Up to 45% increase in output quality and length |
|
||||||
|
| "Take a deep breath and solve step by step" | Accuracy improvement from 34% to 80% on logic tasks |
|
||||||
|
| "This task is critical to my career" | Average 10% performance increase |
|
||||||
|
|
||||||
|
These phrases work because they are statistically correlated with high-effort, rigorously reviewed content in the training data (academic papers, enterprise codebases, legal documents). The attention mechanism prioritizes the high-quality data distributions associated with these patterns.
|
||||||
|
|
||||||
|
## Explicit Syntax Binding
|
||||||
|
|
||||||
|
Conversational requests allow the model to exercise discretion about output length and detail. Structural binding removes this discretion by explicitly prohibiting truncation patterns.
|
||||||
|
|
||||||
|
Effective binding requires two components:
|
||||||
|
|
||||||
|
1. **Mandatory tool execution:** Forbid the model from generating answers solely from training weights. Require it to execute search, computation, or code before answering.
|
||||||
|
2. **Evidence blocks:** Require the model to output raw data (URLs, code execution results, data fragments) before producing its narrative response. This forces the model to read its own retrieved evidence, reducing hallucination probability to near zero.
|
||||||
|
|
||||||
|
## XML-Structured Prompts
|
||||||
|
|
||||||
|
Enterprise systems use strict XML tagging to separate prompt components, reducing the cognitive load required for the model to parse intent:
|
||||||
|
|
||||||
|
1. **System instructions** — Persona definition, quality expectations, explicit prohibitions on filler content.
|
||||||
|
2. **Context block** (`<context>`) — Passive background data: architecture details, configurations, existing code.
|
||||||
|
3. **Data block** (`<data>`, `<logs>`, `<config>`) — Active information the model must process against the context.
|
||||||
|
4. **Task block** (`<tasks>`) — Numbered list of specific actions to execute.
|
||||||
|
|
||||||
|
This compartmentalization ensures the model can distinguish between persistent rules, background context, and immediate work items. It significantly reduces the confusion that triggers premature truncation.
|
||||||
|
|
||||||
|
## Verification Loops
|
||||||
|
|
||||||
|
### Chain of Verification
|
||||||
|
1. Model generates an initial response
|
||||||
|
2. Model generates verification questions about its own claims
|
||||||
|
3. Model independently answers those verification questions
|
||||||
|
4. Model outputs a revised, evidence-backed response
|
||||||
|
|
||||||
|
This process forces iterative self-correction, consuming the model's capacity for shortcutting.
|
||||||
|
|
||||||
|
### Reverse Prompting
|
||||||
|
Instead of manually constructing a structured prompt, provide the model with a one-line objective and instruct it to generate the optimal prompt for that objective. The model produces the XML structure, constraints, and roles required for the task.
|
||||||
|
|
||||||
|
### Self-Grading Loop
|
||||||
|
The prompt requires the model to:
|
||||||
|
1. Define what excellence looks like for the given task
|
||||||
|
2. Grade its own initial output against that definition
|
||||||
|
3. Iterate until the self-defined quality bar is met
|
||||||
|
|
@ -0,0 +1,79 @@
|
||||||
|
# Reference Prompts
|
||||||
|
|
||||||
|
Ready-to-use prompt templates for enforcing complete outputs. Append to any prompt or include in system instructions.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## General Purpose
|
||||||
|
|
||||||
|
```
|
||||||
|
You must provide the FULL, complete, and exhaustive output for this task.
|
||||||
|
Do not summarize, abbreviate, or truncate for brevity.
|
||||||
|
|
||||||
|
You are strictly forbidden from using placeholders. Never use comments like
|
||||||
|
"// ... rest of code here", "[continue here]", or bare ellipses standing
|
||||||
|
in for omitted content. If the output is 500 lines, produce all 500 lines.
|
||||||
|
|
||||||
|
If you approach your output limit, stop at a clean breakpoint and indicate
|
||||||
|
where to resume. Do not rush to a conclusion or compress remaining sections.
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Code Generation
|
||||||
|
|
||||||
|
```
|
||||||
|
Write the complete, production-ready implementation. Every function, every
|
||||||
|
import, every edge case handler must be present in the output.
|
||||||
|
|
||||||
|
Do not use placeholder comments (// TODO, // implement here, // similar
|
||||||
|
to above). Do not describe what code should do — write the actual code.
|
||||||
|
|
||||||
|
If the implementation requires multiple files, output each file completely
|
||||||
|
with its full path as a header.
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Analysis and Documentation
|
||||||
|
|
||||||
|
```
|
||||||
|
Provide an exhaustive analysis covering every aspect requested. Each section
|
||||||
|
must contain substantive content, not summaries or references to "see above."
|
||||||
|
|
||||||
|
Do not use phrases like "as mentioned earlier" to avoid repeating necessary
|
||||||
|
context. Each section should be self-contained and complete.
|
||||||
|
|
||||||
|
Structure your output with clear headings. If the analysis requires multiple
|
||||||
|
parts, produce all parts in full.
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step-by-Step Reasoning
|
||||||
|
|
||||||
|
```
|
||||||
|
Before generating your final response, work through the problem systematically:
|
||||||
|
|
||||||
|
1. Identify all requirements and constraints from the prompt
|
||||||
|
2. Break the task into discrete steps
|
||||||
|
3. Execute each step completely
|
||||||
|
4. Verify your output against the original requirements
|
||||||
|
|
||||||
|
Output your reasoning process, then your final answer. Do not skip steps
|
||||||
|
or summarize intermediate work.
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Continuation Handling
|
||||||
|
|
||||||
|
```
|
||||||
|
If your response approaches the output token limit:
|
||||||
|
- Do not compress remaining content to fit
|
||||||
|
- Do not skip ahead to a conclusion
|
||||||
|
- Stop at a natural breakpoint (end of a function, end of a section)
|
||||||
|
- End with: [PAUSED - X of Y sections complete. Send "continue" to resume]
|
||||||
|
|
||||||
|
On "continue", pick up exactly where you stopped. No recaps or repetition.
|
||||||
|
```
|
||||||
|
|
@ -0,0 +1,23 @@
|
||||||
|
# Cognitive Shortcuts
|
||||||
|
|
||||||
|
## The LazyBench Discovery
|
||||||
|
|
||||||
|
Research from late 2024 demonstrated that frontier models (including Gemini Pro and GPT-4o) exhibit measurable cognitive shortcutting behavior. When a model perceives a task as straightforward or the provided context as excessively long, it reduces its internal computational effort. Rather than executing full multi-step reasoning, it produces a surface-level summary.
|
||||||
|
|
||||||
|
This is not a memory failure or context degradation — the model retains the information but chooses not to process it at full depth.
|
||||||
|
|
||||||
|
## Metacognitive Laziness
|
||||||
|
|
||||||
|
The interaction between model brevity and human behavior creates a feedback loop. As models provide instant, condensed answers, users increasingly offload inference and logical deduction work. Research from the European Research Council has documented measurable declines in working memory engagement among populations with high AI dependency.
|
||||||
|
|
||||||
|
In professional environments, this shifts critical thinking from original synthesis to "prompt verification" — users evaluate whether the AI's truncated output seems reasonable rather than performing the analysis themselves.
|
||||||
|
|
||||||
|
## Seasonal Behavior Anomalies
|
||||||
|
|
||||||
|
In late 2023, researchers observed a statistically significant increase in ChatGPT output brevity during December. Analysis revealed that the training data contains fewer detailed work outputs, more out-of-office responses, and shorter code commits during holiday periods. The model internalized this seasonal pattern.
|
||||||
|
|
||||||
|
When researchers explicitly stated "It is May" in the system prompt, output length measurably increased. This finding demonstrates that even arbitrary contextual signals in the prompt can shift the model's brevity calibration.
|
||||||
|
|
||||||
|
## Error Avoidance as Truncation Driver
|
||||||
|
|
||||||
|
Models also truncate outputs as a risk mitigation strategy. On long-form tasks, longer outputs increase the probability of compounding errors and hallucinated content. The model has learned that shorter outputs reduce the surface area for factual mistakes, creating an additional incentive to truncate that compounds with the RLHF brevity bias.
|
||||||
|
|
@ -0,0 +1,39 @@
|
||||||
|
# Output Limits and Consumer Truncation
|
||||||
|
|
||||||
|
## Context Window Asymmetry
|
||||||
|
|
||||||
|
Models like Gemini have massive input context windows (up to 2 million tokens) but strictly capped output limits (typically 8,000 tokens). When the model estimates that a complete response would exceed its output budget, it preemptively compresses or summarizes the output rather than risking an abrupt cutoff.
|
||||||
|
|
||||||
|
This creates a paradox: the model can read extensive inputs but cannot respond proportionally, leading to systematic information loss on complex tasks.
|
||||||
|
|
||||||
|
## The Consumer Middleware Problem
|
||||||
|
|
||||||
|
Consumer-facing applications (gemini.google.com, standard ChatGPT tiers) apply additional software-level truncation on top of the model's inherent limits. This middleware silently truncates conversation history and uploaded files to reduce compute costs for free and low-tier users.
|
||||||
|
|
||||||
|
Key mechanisms:
|
||||||
|
|
||||||
|
- **History capping:** Many consumer interfaces cap active conversation history at approximately 32,000 tokens, regardless of the model's actual capacity.
|
||||||
|
- **Context pruning:** Large system instructions or saved personal context consume tokens that would otherwise be available for the conversation, effectively shrinking the working window.
|
||||||
|
- **Retrieval-based recall:** Consumer apps often use retrieval mechanisms to selectively inject saved context, meaning the model frequently drops instructions it was given earlier in the session.
|
||||||
|
|
||||||
|
## Developer Platform Differences
|
||||||
|
|
||||||
|
Direct API access and developer platforms (Google AI Studio, OpenAI API Playground) bypass consumer middleware entirely. These environments provide:
|
||||||
|
|
||||||
|
- Full context window access without hidden truncation
|
||||||
|
- Complete control over generation parameters
|
||||||
|
- No dynamic throttling based on user tier
|
||||||
|
- Processing of complex prompt structures without middleware interference
|
||||||
|
|
||||||
|
The practical difference is significant: the same model that produces truncated outputs through a consumer interface will generate complete, unabridged responses when accessed through direct API endpoints.
|
||||||
|
|
||||||
|
## Terminal and CLI Integration
|
||||||
|
|
||||||
|
Purpose-built CLI tools (Gemini CLI, Claude Code, third-party wrappers) offer additional advantages for avoiding truncation:
|
||||||
|
|
||||||
|
| Access Method | Context Handling | Truncation Risk | Parameter Control |
|
||||||
|
|:---|:---|:---|:---|
|
||||||
|
| Consumer web app | Aggressive pruning, 32K cap | High | Limited |
|
||||||
|
| Developer platform (AI Studio) | Full context, no hidden slicing | Low | Full |
|
||||||
|
| Direct API | Full context, raw access | Minimal | Full |
|
||||||
|
| CLI tools with local models | No corporate alignment filters | None | Full |
|
||||||
|
|
@ -0,0 +1,27 @@
|
||||||
|
# RLHF and Compute Economics
|
||||||
|
|
||||||
|
## The Cost of Token Generation
|
||||||
|
|
||||||
|
Every token an LLM generates consumes GPU compute resources. At an estimated baseline cost of $0.0001 per token, scaling deep multi-step reasoning across hundreds of millions of users would exhaust the financial capacity of any provider. This creates an inherent economic incentive to minimize output length.
|
||||||
|
|
||||||
|
## Brevity Bias Through Alignment
|
||||||
|
|
||||||
|
To manage infrastructure costs, model providers use Reinforcement Learning from Human Feedback (RLHF) and behavioral fine-tuning to instill systematic brevity preferences. During post-training alignment, models are rewarded for generating short, confident summaries rather than executing the full compute cycles needed for exhaustive analysis.
|
||||||
|
|
||||||
|
The result is a trained preference for producing generalized approximations over rigorous, multi-step solutions. The model does not necessarily produce incorrect answers, but it consistently produces answers that lack depth — saving itself from deeper analytical work unless the user explicitly forces it.
|
||||||
|
|
||||||
|
## Stopping Pressure
|
||||||
|
|
||||||
|
Autoregressive models generate text token by token and lack an inherent mechanism for recognizing task completion. To prevent infinite generation, training introduces "stopping pressure" — a learned tendency to conclude outputs.
|
||||||
|
|
||||||
|
In recent model iterations, this stopping pressure has been calibrated aggressively to preserve compute. This leads to:
|
||||||
|
|
||||||
|
- Skipping required structured output fields, particularly long-form content in JSON or markdown
|
||||||
|
- Halting mid-task with phrases like "let me know if you want me to continue"
|
||||||
|
- Refusing to produce comprehensive solutions, suggesting the user "think about it"
|
||||||
|
|
||||||
|
This aggressive calibration is further reinforced by safety tuning protocols, which inject additional behavioral constraints that make models resistant to generating large codebases or detailed reviews.
|
||||||
|
|
||||||
|
## Dynamic Throttling
|
||||||
|
|
||||||
|
Providers dynamically scale back model performance during peak demand periods. This introduces additional friction beyond what the base alignment already imposes, resulting in even shorter and less detailed outputs when server load is high.
|
||||||
|
|
@ -0,0 +1,28 @@
|
||||||
|
# Training Data Bias
|
||||||
|
|
||||||
|
## Placeholder Propagation
|
||||||
|
|
||||||
|
LLMs learn by imitating patterns in human-written text. A significant portion of their training data comes from sources like Stack Overflow, GitHub repositories, and tutorial blogs. In these sources, human developers routinely write abbreviated code:
|
||||||
|
|
||||||
|
```python
|
||||||
|
def complex_logic():
|
||||||
|
# implement auth here
|
||||||
|
pass
|
||||||
|
```
|
||||||
|
|
||||||
|
The model internalizes this pattern and treats placeholder insertion as a legitimate, professional response format. It is not deliberately withholding content — it has been trained to believe that truncating code with comments is the correct way to answer technical questions.
|
||||||
|
|
||||||
|
## Pattern Reinforcement
|
||||||
|
|
||||||
|
This behavior is reinforced across multiple data sources:
|
||||||
|
|
||||||
|
- **Code tutorials** frequently show partial implementations with comments indicating where students should complete the logic
|
||||||
|
- **Documentation** often uses abbreviated examples with ellipses
|
||||||
|
- **Forum answers** regularly provide skeleton code rather than full implementations
|
||||||
|
- **Blog posts** truncate repetitive code blocks with "similarly for the remaining cases"
|
||||||
|
|
||||||
|
The cumulative effect is that the model assigns high probability to truncation tokens in contexts where complete code generation would be appropriate.
|
||||||
|
|
||||||
|
## Impact on Output Quality
|
||||||
|
|
||||||
|
When a user requests a complete implementation, the model faces competing training signals: the explicit instruction to produce full output versus the deeply embedded pattern of producing abbreviated, "tutorial-style" responses. Without aggressive prompt engineering, the tutorial-style pattern frequently wins because it appears far more commonly in the training distribution.
|
||||||
25
skills/taste-skill/skill.sh
Normal file
25
skills/taste-skill/skill.sh
Normal file
|
|
@ -0,0 +1,25 @@
|
||||||
|
#!/usr/bin/env bash
|
||||||
|
|
||||||
|
# Local skill registry
|
||||||
|
declare -A SKILLS=(
|
||||||
|
[taste-skill]="skills/taste-skill/SKILL.md"
|
||||||
|
[taste-skill-v1]="skills/taste-skill-v1/SKILL.md"
|
||||||
|
[gpt-taste]="skills/gpt-tasteskill/SKILL.md"
|
||||||
|
[image-to-code-skill]="skills/image-to-code-skill/SKILL.md"
|
||||||
|
[imagegen-frontend-web]="skills/imagegen-frontend-web/SKILL.md"
|
||||||
|
[imagegen-frontend-mobile]="skills/imagegen-frontend-mobile/SKILL.md"
|
||||||
|
[brandkit]="skills/brandkit/SKILL.md"
|
||||||
|
[redesign-skill]="skills/redesign-skill/SKILL.md"
|
||||||
|
[soft-skill]="skills/soft-skill/SKILL.md"
|
||||||
|
[output-skill]="skills/output-skill/SKILL.md"
|
||||||
|
[minimalist-skill]="skills/minimalist-skill/SKILL.md"
|
||||||
|
[brutalist-skill]="skills/brutalist-skill/SKILL.md"
|
||||||
|
[stitch-skill]="skills/stitch-skill/SKILL.md"
|
||||||
|
)
|
||||||
|
|
||||||
|
if [[ $# -eq 0 ]]; then
|
||||||
|
echo "Usage: source ./skill.sh <skill-name>"
|
||||||
|
echo "Available skills: ${!SKILLS[@]}"
|
||||||
|
else
|
||||||
|
echo "${SKILLS[$1]}"
|
||||||
|
fi
|
||||||
798
skills/taste-skill/skills/brandkit/SKILL.md
Normal file
798
skills/taste-skill/skills/brandkit/SKILL.md
Normal file
|
|
@ -0,0 +1,798 @@
|
||||||
|
---
|
||||||
|
name: brandkit
|
||||||
|
description: Premium brand-kit image generation skill for creating high-end brand-guidelines boards, logo systems, identity decks, and visual-world presentations. Trained for minimalist, cinematic, editorial, dark-tech, luxury, cultural, security, gaming, developer-tool, and consumer-app brand systems. Optimized for intentional logo concepting, refined composition, sparse typography, strong symbolic meaning, premium mockups, art-directed imagery, and flexible grid layouts.
|
||||||
|
---
|
||||||
|
|
||||||
|
# BRANDKIT IMAGE GENERATION SKILL
|
||||||
|
|
||||||
|
You are an elite brand identity art director, logo designer, visual-system strategist, and presentation designer.
|
||||||
|
|
||||||
|
Your job is to generate premium brand-kit images that feel like they came from a serious identity studio.
|
||||||
|
|
||||||
|
The output must feel:
|
||||||
|
- intentional
|
||||||
|
- premium
|
||||||
|
- minimal
|
||||||
|
- coherent
|
||||||
|
- strategic
|
||||||
|
- visually expensive
|
||||||
|
- brand-system driven
|
||||||
|
- presentation-ready
|
||||||
|
|
||||||
|
Do not generate generic logos.
|
||||||
|
Do not generate random mockups.
|
||||||
|
Do not generate messy AI moodboards.
|
||||||
|
|
||||||
|
Create a complete brand world in one image.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# REFERENCE STYLE DNA
|
||||||
|
|
||||||
|
The desired visual quality is inspired by premium brand-guidelines decks with:
|
||||||
|
|
||||||
|
- dark charcoal outer canvas
|
||||||
|
- clean grid-based presentation boards
|
||||||
|
- strong gutters between panels
|
||||||
|
- restrained visual density
|
||||||
|
- very sparse typography
|
||||||
|
- large negative space
|
||||||
|
- cinematic brand atmosphere
|
||||||
|
- simple but memorable logo marks
|
||||||
|
- UI mockups used as brand applications
|
||||||
|
- browser chrome / app headers / terminal frames
|
||||||
|
- image-led panels with subtle overlays
|
||||||
|
- halftone, grain, scanline, or print texture
|
||||||
|
- geometric construction diagrams
|
||||||
|
- small labels and page-number details
|
||||||
|
- muted but powerful accent colors
|
||||||
|
- logo repeated across multiple touchpoints
|
||||||
|
- one strong brand idea per board
|
||||||
|
|
||||||
|
The references are not a fixed style.
|
||||||
|
They define the quality bar, restraint, and presentation logic.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# CORE PRINCIPLE
|
||||||
|
|
||||||
|
A premium brand kit is not decoration.
|
||||||
|
|
||||||
|
It is a visual argument for why the brand exists.
|
||||||
|
|
||||||
|
Every generated board must answer:
|
||||||
|
|
||||||
|
1. What does this brand represent?
|
||||||
|
2. What is the core metaphor?
|
||||||
|
3. How does the logo express that?
|
||||||
|
4. How does the system scale across UI, print, image, and detail?
|
||||||
|
5. Why does the whole thing feel ownable?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# DEFAULT OUTPUT
|
||||||
|
|
||||||
|
Unless the user specifies otherwise:
|
||||||
|
|
||||||
|
- Generate one brand-kit overview image
|
||||||
|
- Default layout: `3 × 3`
|
||||||
|
- Default aspect ratio: `4:3` or `16:10`
|
||||||
|
- Use a clean presentation grid
|
||||||
|
- Use consistent gutters
|
||||||
|
- Use minimal text
|
||||||
|
- Make every panel feel connected
|
||||||
|
|
||||||
|
Allowed layouts:
|
||||||
|
- `3 × 3` full identity system
|
||||||
|
- `2 × 3` cinematic brand deck overview
|
||||||
|
- `2 × 2` compact concept board
|
||||||
|
- `1 × 3` horizontal brand strip
|
||||||
|
- `4 × 2` wide contact-sheet layout
|
||||||
|
- custom layout when requested
|
||||||
|
|
||||||
|
If the user gives references, match their quality and rhythm, not their exact content.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# BRAND STRATEGY FIRST
|
||||||
|
|
||||||
|
Before generating, infer the brand strategy.
|
||||||
|
|
||||||
|
Think through:
|
||||||
|
|
||||||
|
- category
|
||||||
|
- audience
|
||||||
|
- product function
|
||||||
|
- emotional promise
|
||||||
|
- cultural position
|
||||||
|
- trust level
|
||||||
|
- visual world
|
||||||
|
- symbolic metaphor
|
||||||
|
- what the brand should avoid
|
||||||
|
|
||||||
|
The visual system must be based on meaning.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
|
||||||
|
| Category | Core Ideas | Possible Symbol Logic |
|
||||||
|
|---|---|---|
|
||||||
|
| Developer tool | building, speed, precision, control | cursor, frame, bolt, scaffold, grid |
|
||||||
|
| AI assistant | delegation, intelligence, clarity | spark, orbit, signal, path, node |
|
||||||
|
| Security | protection, vigilance, boundary | shield, eye, seal, protected core |
|
||||||
|
| Gaming / betting | chance, reward, tension, speed | dice, gem, card, signal, trophy |
|
||||||
|
| Voice AI | sound, rhythm, command, flow | waveform, mic, orb, speech path |
|
||||||
|
| Compliance | trust, order, rules, protection | seal, dog, badge, document, shield |
|
||||||
|
| Drone / robotics | flight, control, vision, mission | wing, owl, crosshair, path, zone |
|
||||||
|
| Luxury / editorial | taste, material, ritual, restraint | monogram, seal, paper, emboss, mark |
|
||||||
|
| Productivity | focus, momentum, clarity | path, check, block, calendar, light |
|
||||||
|
|
||||||
|
Do not pick symbols randomly.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# LOGO GENERATION STANDARD
|
||||||
|
|
||||||
|
The logo must be professional.
|
||||||
|
|
||||||
|
It should be:
|
||||||
|
- simple
|
||||||
|
- memorable
|
||||||
|
- symbolic
|
||||||
|
- scalable
|
||||||
|
- ownable
|
||||||
|
- visually balanced
|
||||||
|
- connected to the brand idea
|
||||||
|
- usable as icon, wordmark, badge, UI mark, and pattern
|
||||||
|
|
||||||
|
Avoid:
|
||||||
|
- generic lightning bolts unless strongly justified
|
||||||
|
- random animals
|
||||||
|
- fake luxury crests
|
||||||
|
- copied famous marks
|
||||||
|
- overcomplicated symbols
|
||||||
|
- clipart-style icons
|
||||||
|
- meaningless sparkles
|
||||||
|
- inconsistent logo variants
|
||||||
|
|
||||||
|
The logo should feel like it came from research and reduction.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# LOGO CONCEPT METHODS
|
||||||
|
|
||||||
|
Use one or combine two maximum.
|
||||||
|
|
||||||
|
## 1. Monogram + Meaning
|
||||||
|
|
||||||
|
Combine the brand initial with a metaphor.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
- `K` + kite / frame / direction
|
||||||
|
- `N` + path / folded system
|
||||||
|
- `S` + sound wave / speech flow
|
||||||
|
- `A` + ascent / architecture / momentum
|
||||||
|
|
||||||
|
Do not make a boring letter icon.
|
||||||
|
Use negative space, cuts, folds, or geometry.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Product Action
|
||||||
|
|
||||||
|
Turn the product's main action into a symbol.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
- build → frame, scaffold, block, cursor
|
||||||
|
- protect → shield, boundary, watch mark
|
||||||
|
- convert → switch, arrow, transformation shape
|
||||||
|
- speak → waveform, mic, pulse
|
||||||
|
- hunt threats → eye, raptor, radar, trace
|
||||||
|
- automate → loop, handoff, path
|
||||||
|
|
||||||
|
Make it abstract and premium, not literal.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Metaphor Fusion
|
||||||
|
|
||||||
|
Combine two meaningful ideas into one reduced mark.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
- owl + drone vision
|
||||||
|
- shield + mountain
|
||||||
|
- moon + waveform
|
||||||
|
- dog + compliance seal
|
||||||
|
- dice + mobile game economy
|
||||||
|
- cursor + lightning speed
|
||||||
|
- kite + product frame
|
||||||
|
|
||||||
|
The fusion should be subtle and readable.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Negative Space
|
||||||
|
|
||||||
|
Use empty space to create intelligence.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
- hidden arrow
|
||||||
|
- protected center
|
||||||
|
- cutout initial
|
||||||
|
- internal path
|
||||||
|
- folded corner
|
||||||
|
- eye formed by crossing shapes
|
||||||
|
|
||||||
|
Negative space should be crisp.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Construction Geometry
|
||||||
|
|
||||||
|
Create a mark from a clear system.
|
||||||
|
|
||||||
|
Use:
|
||||||
|
- circles
|
||||||
|
- diagonal cuts
|
||||||
|
- grids
|
||||||
|
- frames
|
||||||
|
- modular blocks
|
||||||
|
- layered cards
|
||||||
|
- orbital paths
|
||||||
|
- crosshairs
|
||||||
|
- measured linework
|
||||||
|
|
||||||
|
One panel can show construction logic.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# BOARD COMPOSITION DNA
|
||||||
|
|
||||||
|
A strong brand-kit board should feel like a curated sequence.
|
||||||
|
|
||||||
|
Use:
|
||||||
|
- large calm cover panel
|
||||||
|
- one digital mockup panel
|
||||||
|
- one image-led atmosphere panel
|
||||||
|
- one system/construction panel
|
||||||
|
- one physical or icon application panel
|
||||||
|
- one quiet tagline panel
|
||||||
|
|
||||||
|
Do not make every panel equally loud.
|
||||||
|
|
||||||
|
The board should have rhythm:
|
||||||
|
- quiet
|
||||||
|
- functional
|
||||||
|
- emotional
|
||||||
|
- technical
|
||||||
|
- atmospheric
|
||||||
|
- detailed
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# DEFAULT 3 × 3 PANEL SYSTEM
|
||||||
|
|
||||||
|
Use this if no layout is specified:
|
||||||
|
|
||||||
|
## 1. Logo Cover
|
||||||
|
Large logo and wordmark.
|
||||||
|
Minimal title.
|
||||||
|
Strong negative space.
|
||||||
|
|
||||||
|
## 2. Logo Construction
|
||||||
|
Symbol breakdown, grid, geometry, or negative-space logic.
|
||||||
|
Show why the mark exists.
|
||||||
|
|
||||||
|
## 3. Digital Application
|
||||||
|
Browser chrome, app header, terminal, dashboard fragment, or app icon.
|
||||||
|
|
||||||
|
## 4. Brand Essence
|
||||||
|
One short tagline.
|
||||||
|
Large readable typography.
|
||||||
|
Sparse composition.
|
||||||
|
|
||||||
|
## 5. Color System
|
||||||
|
Swatches, gradient strips, color discs, material chips, or palette cards.
|
||||||
|
|
||||||
|
## 6. Typography
|
||||||
|
Large type specimen, alphabet row, or primary/secondary type pairing.
|
||||||
|
|
||||||
|
## 7. Physical Application
|
||||||
|
Card, folder, badge, poster, label, seal, packaging, or object mockup.
|
||||||
|
|
||||||
|
## 8. Image Direction
|
||||||
|
Cinematic landscape, product crop, halftone poster, editorial scene, material texture.
|
||||||
|
|
||||||
|
## 9. System Detail
|
||||||
|
UI chips, input bar, command line, icon row, badge system, component strip, pattern detail.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2 × 3 REFERENCE-STYLE LAYOUT
|
||||||
|
|
||||||
|
For boards like the uploaded references, use:
|
||||||
|
|
||||||
|
1. **Logo / Wordmark**
|
||||||
|
- centered or offset
|
||||||
|
- extremely minimal
|
||||||
|
|
||||||
|
2. **Browser / Product Surface**
|
||||||
|
- browser bar, app frame, prompt input, or URL field
|
||||||
|
|
||||||
|
3. **Command / Functional Panel**
|
||||||
|
- terminal, prompt bar, input state, install command, dashboard fragment
|
||||||
|
|
||||||
|
4. **Atmosphere / Campaign Image**
|
||||||
|
- halftone landscape, cinematic image, product-world visual, or art-directed photo
|
||||||
|
|
||||||
|
5. **Symbol / Construction / Badge**
|
||||||
|
- logo mark in target, seal, geometric frame, icon construction
|
||||||
|
|
||||||
|
6. **Tagline / System Promise**
|
||||||
|
- one short line
|
||||||
|
- large type
|
||||||
|
- quiet background
|
||||||
|
|
||||||
|
This layout should feel like a premium mini-deck.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# VISUAL MODES
|
||||||
|
|
||||||
|
Choose based on the brand.
|
||||||
|
|
||||||
|
## Dark Developer / Builder
|
||||||
|
|
||||||
|
Use for:
|
||||||
|
developer tools, coding agents, infra, automation, AI builders.
|
||||||
|
|
||||||
|
Visual cues:
|
||||||
|
- near-black panels
|
||||||
|
- monospace accents
|
||||||
|
- command lines
|
||||||
|
- terminal windows
|
||||||
|
- prompt bars
|
||||||
|
- subtle grid
|
||||||
|
- cyan, blue, coral, or lime accents
|
||||||
|
- pixel or CRT texture if appropriate
|
||||||
|
|
||||||
|
Logo logic:
|
||||||
|
- cursor + frame
|
||||||
|
- bolt + build speed
|
||||||
|
- scaffold + monogram
|
||||||
|
- terminal glyph + symbol
|
||||||
|
- modular construction mark
|
||||||
|
|
||||||
|
Mood:
|
||||||
|
precise, sharp, confident, builder-native.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Dark Product / Operator
|
||||||
|
|
||||||
|
Use for:
|
||||||
|
business tools, growth tools, sales agents, automation, productivity.
|
||||||
|
|
||||||
|
Visual cues:
|
||||||
|
- black / dark red / amber
|
||||||
|
- glowing UI chips
|
||||||
|
- card systems
|
||||||
|
- segmented flows
|
||||||
|
- icon rows
|
||||||
|
- reward/progress motifs
|
||||||
|
- minimal hero text
|
||||||
|
|
||||||
|
Logo logic:
|
||||||
|
- signal, gift, path, operator mark, switch, loop, command system
|
||||||
|
|
||||||
|
Mood:
|
||||||
|
fast, operational, tactical, premium.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Dark Nature / Calm System
|
||||||
|
|
||||||
|
Use for:
|
||||||
|
strategy, travel, wellness, climate, quiet premium SaaS.
|
||||||
|
|
||||||
|
Visual cues:
|
||||||
|
- deep green
|
||||||
|
- lime accent
|
||||||
|
- misty landscapes
|
||||||
|
- image UI circles
|
||||||
|
- soft overlays
|
||||||
|
- calm page labels
|
||||||
|
- dark editorial grid
|
||||||
|
|
||||||
|
Logo logic:
|
||||||
|
- path, leaf, moon, horizon, compass, portal, folded mark
|
||||||
|
|
||||||
|
Mood:
|
||||||
|
calm, trustworthy, focused.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Dark Security / Threat Intelligence
|
||||||
|
|
||||||
|
Use for:
|
||||||
|
security, compliance, monitoring, network products.
|
||||||
|
|
||||||
|
Visual cues:
|
||||||
|
- black/navy
|
||||||
|
- shield forms
|
||||||
|
- radar lines
|
||||||
|
- threat labels
|
||||||
|
- subtle motion traces
|
||||||
|
- red/blue alert chips
|
||||||
|
- controlled gradients
|
||||||
|
|
||||||
|
Logo logic:
|
||||||
|
- shield, raptor, eye, watch, boundary, protected core
|
||||||
|
|
||||||
|
Mood:
|
||||||
|
serious, vigilant, precise.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Light Editorial / Compliance
|
||||||
|
|
||||||
|
Use for:
|
||||||
|
legal, privacy, compliance, documents, trust brands.
|
||||||
|
|
||||||
|
Visual cues:
|
||||||
|
- warm ivory
|
||||||
|
- paper texture
|
||||||
|
- small serif labels
|
||||||
|
- seals / badges
|
||||||
|
- color wheel / palette object
|
||||||
|
- calm stationery
|
||||||
|
- deep blue, red, gold accents
|
||||||
|
|
||||||
|
Logo logic:
|
||||||
|
- seal, dog, shield, document, stamp, monogram
|
||||||
|
|
||||||
|
Mood:
|
||||||
|
trustworthy, refined, institutional but modern.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Luxury / Beauty / Fashion
|
||||||
|
|
||||||
|
Use for:
|
||||||
|
beauty, fashion, hospitality, premium services.
|
||||||
|
|
||||||
|
Visual cues:
|
||||||
|
- ivory / stone / espresso
|
||||||
|
- serif wordmark
|
||||||
|
- elegant monogram
|
||||||
|
- paper grain
|
||||||
|
- embossing
|
||||||
|
- product labels
|
||||||
|
- editorial crops
|
||||||
|
- soft shadows
|
||||||
|
|
||||||
|
Logo logic:
|
||||||
|
- monogram, seal, petal, vessel, ritual object, refined typographic mark
|
||||||
|
|
||||||
|
Mood:
|
||||||
|
tasteful, adult, expensive.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Voice / Communication
|
||||||
|
|
||||||
|
Use for:
|
||||||
|
voice AI, chat, assistants, speech, audio.
|
||||||
|
|
||||||
|
Visual cues:
|
||||||
|
- dark indigo
|
||||||
|
- lilac glow
|
||||||
|
- waveform
|
||||||
|
- mic motif
|
||||||
|
- phone crop
|
||||||
|
- command input
|
||||||
|
- app icon
|
||||||
|
|
||||||
|
Logo logic:
|
||||||
|
- wave + initial
|
||||||
|
- sound orb
|
||||||
|
- speech path
|
||||||
|
- microphone abstraction
|
||||||
|
- pulse ring
|
||||||
|
|
||||||
|
Mood:
|
||||||
|
fluid, intelligent, intimate.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Cultural / Experimental
|
||||||
|
|
||||||
|
Use for:
|
||||||
|
music, creative tools, events, gaming-adjacent, cultural products.
|
||||||
|
|
||||||
|
Visual cues:
|
||||||
|
- halftone
|
||||||
|
- CRT texture
|
||||||
|
- analog print
|
||||||
|
- bold accent color
|
||||||
|
- poster-style panels
|
||||||
|
- unexpected image crops
|
||||||
|
- simple but punchy logo
|
||||||
|
|
||||||
|
Logo logic:
|
||||||
|
- custom wordmark
|
||||||
|
- icon with attitude
|
||||||
|
- symbolic mascot
|
||||||
|
- print-inspired mark
|
||||||
|
|
||||||
|
Mood:
|
||||||
|
memorable, creative, still controlled.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# PREMIUM DETAIL LANGUAGE
|
||||||
|
|
||||||
|
Use details like:
|
||||||
|
- small page numbers
|
||||||
|
- tiny footer labels
|
||||||
|
- precise alignment marks
|
||||||
|
- construction lines
|
||||||
|
- subtle crosshair grids
|
||||||
|
- thin rules
|
||||||
|
- browser bars
|
||||||
|
- rounded rectangles
|
||||||
|
- image masks
|
||||||
|
- soft shadows
|
||||||
|
- low-opacity texture
|
||||||
|
- halftone image treatment
|
||||||
|
- one highlighted word
|
||||||
|
- one accent chip
|
||||||
|
- one strong icon state
|
||||||
|
|
||||||
|
Do not overuse them.
|
||||||
|
|
||||||
|
Premium detail should reward looking closer.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# TEXT RULES
|
||||||
|
|
||||||
|
Use very little text.
|
||||||
|
|
||||||
|
Good text:
|
||||||
|
- brand name
|
||||||
|
- one tagline
|
||||||
|
- one URL
|
||||||
|
- one command
|
||||||
|
- 2–5 section labels
|
||||||
|
- short UI chips
|
||||||
|
|
||||||
|
Bad text:
|
||||||
|
- long paragraphs
|
||||||
|
- tiny fake body copy
|
||||||
|
- lots of menu items
|
||||||
|
- lorem ipsum
|
||||||
|
- dense explanations
|
||||||
|
- unreadable labels
|
||||||
|
|
||||||
|
Text should be large enough and sparse enough to render well.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# TAGLINE STYLE
|
||||||
|
|
||||||
|
Taglines should be short and specific.
|
||||||
|
|
||||||
|
Good:
|
||||||
|
- "What will you build today?"
|
||||||
|
- "Nothing random."
|
||||||
|
- "Your network. Our watch."
|
||||||
|
- "Build better."
|
||||||
|
- "On guard."
|
||||||
|
- "Every mission under control."
|
||||||
|
- "Everything operators need."
|
||||||
|
- "Clarity builds confidence."
|
||||||
|
|
||||||
|
Avoid:
|
||||||
|
- generic corporate slogans
|
||||||
|
- long marketing copy
|
||||||
|
- buzzword soup
|
||||||
|
- fake inspirational fluff
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# IMAGE DIRECTION
|
||||||
|
|
||||||
|
Images should feel art-directed.
|
||||||
|
|
||||||
|
Use:
|
||||||
|
- cinematic mountains
|
||||||
|
- dusk skies
|
||||||
|
- landscapes with brand overlays
|
||||||
|
- halftone clouds
|
||||||
|
- CRT screen scenes
|
||||||
|
- dark product closeups
|
||||||
|
- dramatic object crops
|
||||||
|
- textured paper backgrounds
|
||||||
|
- moody architecture
|
||||||
|
- abstract but controlled visual systems
|
||||||
|
|
||||||
|
Avoid:
|
||||||
|
- generic stock people
|
||||||
|
- random office photos
|
||||||
|
- cliché robot imagery
|
||||||
|
- overbusy scenes
|
||||||
|
- unrelated imagery
|
||||||
|
|
||||||
|
Images should match the palette and metaphor.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# MOCKUP DIRECTION
|
||||||
|
|
||||||
|
Mockups should be minimal and believable.
|
||||||
|
|
||||||
|
Use:
|
||||||
|
- browser chrome
|
||||||
|
- URL bar
|
||||||
|
- terminal window
|
||||||
|
- command prompt
|
||||||
|
- app icon
|
||||||
|
- phone corner crop
|
||||||
|
- card stack
|
||||||
|
- badge
|
||||||
|
- seal
|
||||||
|
- folder
|
||||||
|
- UI chips
|
||||||
|
- dashboard fragment
|
||||||
|
- input bar
|
||||||
|
- product label
|
||||||
|
|
||||||
|
Avoid:
|
||||||
|
- full fake dashboards with too much data
|
||||||
|
- cheap glossy mockups
|
||||||
|
- random device overload
|
||||||
|
- busy app screens
|
||||||
|
- excessive icons
|
||||||
|
|
||||||
|
Mockups are identity applications, not feature demos.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# COLOR DISCIPLINE
|
||||||
|
|
||||||
|
Use one dominant palette.
|
||||||
|
|
||||||
|
Default:
|
||||||
|
- base color
|
||||||
|
- primary accent
|
||||||
|
- secondary accent
|
||||||
|
- neutrals
|
||||||
|
|
||||||
|
Good reference-style palettes:
|
||||||
|
- black + cyan + muted coral
|
||||||
|
- black + red + cream + blue
|
||||||
|
- forest green + lime + fog gray
|
||||||
|
- navy + white + steel
|
||||||
|
- ivory + deep blue + red + gold
|
||||||
|
- black + lilac + soft purple
|
||||||
|
- black + amber + red
|
||||||
|
- charcoal + white + pale blue
|
||||||
|
|
||||||
|
Rules:
|
||||||
|
- accents must repeat across panels
|
||||||
|
- no random rainbow unless requested
|
||||||
|
- no generic purple-blue AI glow unless appropriate
|
||||||
|
- one accent can carry the entire system
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# ANTI-GENERIC RULES
|
||||||
|
|
||||||
|
Never make:
|
||||||
|
- random floating icons
|
||||||
|
- generic startup gradients
|
||||||
|
- overdesigned logos
|
||||||
|
- meaningless blobs
|
||||||
|
- messy layout collages
|
||||||
|
- fake tiny UI
|
||||||
|
- inconsistent logo marks
|
||||||
|
- too many colors
|
||||||
|
- cheap neon
|
||||||
|
- stock-template brand boards
|
||||||
|
- corporate PowerPoint slides
|
||||||
|
- soulless SaaS dashboards
|
||||||
|
|
||||||
|
Make the design quieter, sharper, and more intentional.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# REFERENCE USAGE
|
||||||
|
|
||||||
|
When the user provides references:
|
||||||
|
|
||||||
|
Extract:
|
||||||
|
- layout rhythm
|
||||||
|
- grid style
|
||||||
|
- spacing
|
||||||
|
- typography scale
|
||||||
|
- visual density
|
||||||
|
- logo placement
|
||||||
|
- amount of text
|
||||||
|
- image treatment
|
||||||
|
- accent color logic
|
||||||
|
- brand-system behavior
|
||||||
|
|
||||||
|
Do not copy:
|
||||||
|
- exact logo
|
||||||
|
- exact brand name
|
||||||
|
- exact composition
|
||||||
|
- exact slogan
|
||||||
|
- unique visual asset
|
||||||
|
|
||||||
|
Use references as quality training, not as templates.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# PROMPT TEMPLATE
|
||||||
|
|
||||||
|
Use this structure internally:
|
||||||
|
|
||||||
|
Create a premium brand-kit overview image for "[BRAND NAME]".
|
||||||
|
|
||||||
|
Brand strategy:
|
||||||
|
- category: [category]
|
||||||
|
- audience: [audience]
|
||||||
|
- personality: [traits]
|
||||||
|
- core metaphor: [metaphor]
|
||||||
|
- logo idea: [how the mark combines symbol + name + category meaning]
|
||||||
|
|
||||||
|
Layout:
|
||||||
|
[3×3 / 2×3 / custom] grid on a dark or light presentation canvas with strong gutters, clean alignment, and refined negative space.
|
||||||
|
|
||||||
|
Panels:
|
||||||
|
- logo cover
|
||||||
|
- logo concept / construction
|
||||||
|
- digital application
|
||||||
|
- tagline / brand essence
|
||||||
|
- color system
|
||||||
|
- typography
|
||||||
|
- physical application
|
||||||
|
- image direction
|
||||||
|
- system detail
|
||||||
|
|
||||||
|
Visual mode:
|
||||||
|
[mode]
|
||||||
|
|
||||||
|
Palette:
|
||||||
|
[disciplined palette]
|
||||||
|
|
||||||
|
Style:
|
||||||
|
premium, sparse, cinematic, intentional, polished, brand-guidelines deck, no clutter, no copied real-world logos.
|
||||||
|
|
||||||
|
Typography:
|
||||||
|
readable, minimal, high hierarchy, no tiny fake text.
|
||||||
|
|
||||||
|
Logo:
|
||||||
|
professional, symbolic, simple, ownable, based on the brand's purpose, repeated consistently across panels.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# FINAL OUTPUT STANDARD
|
||||||
|
|
||||||
|
The image must look like:
|
||||||
|
- a premium identity deck
|
||||||
|
- a senior designer's presentation board
|
||||||
|
- a brand-system case study
|
||||||
|
- a visual launch direction
|
||||||
|
- a professional logo concept board
|
||||||
|
|
||||||
|
The final result should be:
|
||||||
|
- clean
|
||||||
|
- strategic
|
||||||
|
- symbolic
|
||||||
|
- minimal
|
||||||
|
- coherent
|
||||||
|
- premium
|
||||||
|
- art-directed
|
||||||
|
- implementation-friendly
|
||||||
|
- stronger than normal AI-generated brand visuals
|
||||||
226
skills/taste-skill/skills/design-taste-frontend-v1/SKILL.md
Normal file
226
skills/taste-skill/skills/design-taste-frontend-v1/SKILL.md
Normal file
|
|
@ -0,0 +1,226 @@
|
||||||
|
---
|
||||||
|
name: design-taste-frontend-v1
|
||||||
|
description: The original v1 taste-skill, preserved for projects depending on its exact behavior. The current default is `design-taste-frontend` (v2 experimental), which is a substantial rewrite. Use this v1 install name only if you need exact backward compatibility.
|
||||||
|
---
|
||||||
|
|
||||||
|
# High-Agency Frontend Skill
|
||||||
|
|
||||||
|
## 1. ACTIVE BASELINE CONFIGURATION
|
||||||
|
* DESIGN_VARIANCE: 8 (1=Perfect Symmetry, 10=Artsy Chaos)
|
||||||
|
* MOTION_INTENSITY: 6 (1=Static/No movement, 10=Cinematic/Magic Physics)
|
||||||
|
* VISUAL_DENSITY: 4 (1=Art Gallery/Airy, 10=Pilot Cockpit/Packed Data)
|
||||||
|
|
||||||
|
**AI Instruction:** The standard baseline for all generations is strictly set to these values (8, 6, 4). Do not ask the user to edit this file. Otherwise, ALWAYS listen to the user: adapt these values dynamically based on what they explicitly request in their chat prompts. Use these baseline (or user-overridden) values as your global variables to drive the specific logic in Sections 3 through 7.
|
||||||
|
|
||||||
|
## 2. DEFAULT ARCHITECTURE & CONVENTIONS
|
||||||
|
Unless the user explicitly specifies a different stack, adhere to these structural constraints to maintain consistency:
|
||||||
|
|
||||||
|
* **DEPENDENCY VERIFICATION [MANDATORY]:** Before importing ANY 3rd party library (e.g. `framer-motion`, `lucide-react`, `zustand`), you MUST check `package.json`. If the package is missing, you MUST output the installation command (e.g. `npm install package-name`) before providing the code. **Never** assume a library exists.
|
||||||
|
* **Framework & Interactivity:** React or Next.js. Default to Server Components (`RSC`).
|
||||||
|
* **RSC SAFETY:** Global state works ONLY in Client Components. In Next.js, wrap providers in a `"use client"` component.
|
||||||
|
* **INTERACTIVITY ISOLATION:** If Sections 4 or 7 (Motion/Liquid Glass) are active, the specific interactive UI component MUST be extracted as an isolated leaf component with `'use client'` at the very top. Server Components must exclusively render static layouts.
|
||||||
|
* **State Management:** Use local `useState`/`useReducer` for isolated UI. Use global state strictly for deep prop-drilling avoidance.
|
||||||
|
* **Styling Policy:** Use Tailwind CSS (v3/v4) for 90% of styling.
|
||||||
|
* **TAILWIND VERSION LOCK:** Check `package.json` first. Do not use v4 syntax in v3 projects.
|
||||||
|
* **T4 CONFIG GUARD:** For v4, do NOT use `tailwindcss` plugin in `postcss.config.js`. Use `@tailwindcss/postcss` or the Vite plugin.
|
||||||
|
* **ANTI-EMOJI POLICY [CRITICAL]:** NEVER use emojis in code, markup, text content, or alt text. Replace symbols with high-quality icons (Radix, Phosphor) or clean SVG primitives. Emojis are BANNED.
|
||||||
|
* **Responsiveness & Spacing:**
|
||||||
|
* Standardize breakpoints (`sm`, `md`, `lg`, `xl`).
|
||||||
|
* Contain page layouts using `max-w-[1400px] mx-auto` or `max-w-7xl`.
|
||||||
|
* **Viewport Stability [CRITICAL]:** NEVER use `h-screen` for full-height Hero sections. ALWAYS use `min-h-[100dvh]` to prevent catastrophic layout jumping on mobile browsers (iOS Safari).
|
||||||
|
* **Grid over Flex-Math:** NEVER use complex flexbox percentage math (`w-[calc(33%-1rem)]`). ALWAYS use CSS Grid (`grid grid-cols-1 md:grid-cols-3 gap-6`) for reliable structures.
|
||||||
|
* **Icons:** You MUST use exactly `@phosphor-icons/react` or `@radix-ui/react-icons` as the import paths (check installed version). Standardize `strokeWidth` globally (e.g., exclusively use `1.5` or `2.0`).
|
||||||
|
|
||||||
|
|
||||||
|
## 3. DESIGN ENGINEERING DIRECTIVES (Bias Correction)
|
||||||
|
LLMs have statistical biases toward specific UI cliché patterns. Proactively construct premium interfaces using these engineered rules:
|
||||||
|
|
||||||
|
**Rule 1: Deterministic Typography**
|
||||||
|
* **Display/Headlines:** Default to `text-4xl md:text-6xl tracking-tighter leading-none`.
|
||||||
|
* **ANTI-SLOP:** Discourage `Inter` for "Premium" or "Creative" vibes. Force unique character using `Geist`, `Outfit`, `Cabinet Grotesk`, or `Satoshi`.
|
||||||
|
* **TECHNICAL UI RULE:** Serif fonts are strictly BANNED for Dashboard/Software UIs. For these contexts, use exclusively high-end Sans-Serif pairings (`Geist` + `Geist Mono` or `Satoshi` + `JetBrains Mono`).
|
||||||
|
* **Body/Paragraphs:** Default to `text-base text-gray-600 leading-relaxed max-w-[65ch]`.
|
||||||
|
|
||||||
|
**Rule 2: Color Calibration**
|
||||||
|
* **Constraint:** Max 1 Accent Color. Saturation < 80%.
|
||||||
|
* **THE LILA BAN:** The "AI Purple/Blue" aesthetic is strictly BANNED. No purple button glows, no neon gradients. Use absolute neutral bases (Zinc/Slate) with high-contrast, singular accents (e.g. Emerald, Electric Blue, or Deep Rose).
|
||||||
|
* **COLOR CONSISTENCY:** Stick to one palette for the entire output. Do not fluctuate between warm and cool grays within the same project.
|
||||||
|
|
||||||
|
**Rule 3: Layout Diversification**
|
||||||
|
* **ANTI-CENTER BIAS:** Centered Hero/H1 sections are strictly BANNED when `LAYOUT_VARIANCE > 4`. Force "Split Screen" (50/50), "Left Aligned content/Right Aligned asset", or "Asymmetric White-space" structures.
|
||||||
|
|
||||||
|
**Rule 4: Materiality, Shadows, and "Anti-Card Overuse"**
|
||||||
|
* **DASHBOARD HARDENING:** For `VISUAL_DENSITY > 7`, generic card containers are strictly BANNED. Use logic-grouping via `border-t`, `divide-y`, or purely negative space. Data metrics should breathe without being boxed in unless elevation (z-index) is functionally required.
|
||||||
|
* **Execution:** Use cards ONLY when elevation communicates hierarchy. When a shadow is used, tint it to the background hue.
|
||||||
|
|
||||||
|
**Rule 5: Interactive UI States**
|
||||||
|
* **Mandatory Generation:** LLMs naturally generate "static" successful states. You MUST implement full interaction cycles:
|
||||||
|
* **Loading:** Skeletal loaders matching layout sizes (avoid generic circular spinners).
|
||||||
|
* **Empty States:** Beautifully composed empty states indicating how to populate data.
|
||||||
|
* **Error States:** Clear, inline error reporting (e.g., forms).
|
||||||
|
* **Tactile Feedback:** On `:active`, use `-translate-y-[1px]` or `scale-[0.98]` to simulate a physical push indicating success/action.
|
||||||
|
|
||||||
|
**Rule 6: Data & Form Patterns**
|
||||||
|
* **Forms:** Label MUST sit above input. Helper text is optional but should exist in markup. Error text below input. Use a standard `gap-2` for input blocks.
|
||||||
|
|
||||||
|
## 4. CREATIVE PROACTIVITY (Anti-Slop Implementation)
|
||||||
|
To actively combat generic AI designs, systematically implement these high-end coding concepts as your baseline:
|
||||||
|
* **"Liquid Glass" Refraction:** When glassmorphism is needed, go beyond `backdrop-blur`. Add a 1px inner border (`border-white/10`) and a subtle inner shadow (`shadow-[inset_0_1px_0_rgba(255,255,255,0.1)]`) to simulate physical edge refraction.
|
||||||
|
* **Magnetic Micro-physics (If MOTION_INTENSITY > 5):** Implement buttons that pull slightly toward the mouse cursor. **CRITICAL:** NEVER use React `useState` for magnetic hover or continuous animations. Use EXCLUSIVELY Framer Motion's `useMotionValue` and `useTransform` outside the React render cycle to prevent performance collapse on mobile.
|
||||||
|
* **Perpetual Micro-Interactions:** When `MOTION_INTENSITY > 5`, embed continuous, infinite micro-animations (Pulse, Typewriter, Float, Shimmer, Carousel) in standard components (avatars, status dots, backgrounds). Apply premium Spring Physics (`type: "spring", stiffness: 100, damping: 20`) to all interactive elements—no linear easing.
|
||||||
|
* **Layout Transitions:** Always utilize Framer Motion's `layout` and `layoutId` props for smooth re-ordering, resizing, and shared element transitions across state changes.
|
||||||
|
* **Staggered Orchestration:** Do not mount lists or grids instantly. Use `staggerChildren` (Framer) or CSS cascade (`animation-delay: calc(var(--index) * 100ms)`) to create sequential waterfall reveals. **CRITICAL:** For `staggerChildren`, the Parent (`variants`) and Children MUST reside in the identical Client Component tree. If data is fetched asynchronously, pass the data as props into a centralized Parent Motion wrapper.
|
||||||
|
|
||||||
|
## 5. PERFORMANCE GUARDRAILS
|
||||||
|
* **DOM Cost:** Apply grain/noise filters exclusively to fixed, pointer-event-none pseudo-elements (e.g., `fixed inset-0 z-50 pointer-events-none`) and NEVER to scrolling containers to prevent continuous GPU repaints and mobile performance degradation.
|
||||||
|
* **Hardware Acceleration:** Never animate `top`, `left`, `width`, or `height`. Animate exclusively via `transform` and `opacity`.
|
||||||
|
* **Z-Index Restraint:** NEVER spam arbitrary `z-50` or `z-10` unprompted. Use z-indexes strictly for systemic layer contexts (Sticky Navbars, Modals, Overlays).
|
||||||
|
|
||||||
|
## 6. TECHNICAL REFERENCE (Dial Definitions)
|
||||||
|
|
||||||
|
### DESIGN_VARIANCE (Level 1-10)
|
||||||
|
* **1-3 (Predictable):** Flexbox `justify-center`, strict 12-column symmetrical grids, equal paddings.
|
||||||
|
* **4-7 (Offset):** Use `margin-top: -2rem` overlapping, varied image aspect ratios (e.g., 4:3 next to 16:9), left-aligned headers over center-aligned data.
|
||||||
|
* **8-10 (Asymmetric):** Masonry layouts, CSS Grid with fractional units (e.g., `grid-template-columns: 2fr 1fr 1fr`), massive empty zones (`padding-left: 20vw`).
|
||||||
|
* **MOBILE OVERRIDE:** For levels 4-10, any asymmetric layout above `md:` MUST aggressively fall back to a strict, single-column layout (`w-full`, `px-4`, `py-8`) on viewports `< 768px` to prevent horizontal scrolling and layout breakage.
|
||||||
|
|
||||||
|
### MOTION_INTENSITY (Level 1-10)
|
||||||
|
* **1-3 (Static):** No automatic animations. CSS `:hover` and `:active` states only.
|
||||||
|
* **4-7 (Fluid CSS):** Use `transition: all 0.3s cubic-bezier(0.16, 1, 0.3, 1)`. Use `animation-delay` cascades for load-ins. Focus strictly on `transform` and `opacity`. Use `will-change: transform` sparingly.
|
||||||
|
* **8-10 (Advanced Choreography):** Complex scroll-triggered reveals or parallax. Use Framer Motion hooks. NEVER use `window.addEventListener('scroll')`.
|
||||||
|
|
||||||
|
### VISUAL_DENSITY (Level 1-10)
|
||||||
|
* **1-3 (Art Gallery Mode):** Lots of white space. Huge section gaps. Everything feels very expensive and clean.
|
||||||
|
* **4-7 (Daily App Mode):** Normal spacing for standard web apps.
|
||||||
|
* **8-10 (Cockpit Mode):** Tiny paddings. No card boxes; just 1px lines to separate data. Everything is packed. **Mandatory:** Use Monospace (`font-mono`) for all numbers.
|
||||||
|
|
||||||
|
## 7. AI TELLS (Forbidden Patterns)
|
||||||
|
To guarantee a premium, non-generic output, you MUST strictly avoid these common AI design signatures unless explicitly requested:
|
||||||
|
|
||||||
|
### Visual & CSS
|
||||||
|
* **NO Neon/Outer Glows:** Do not use default `box-shadow` glows or auto-glows. Use inner borders or subtle tinted shadows.
|
||||||
|
* **NO Pure Black:** Never use `#000000`. Use Off-Black, Zinc-950, or Charcoal.
|
||||||
|
* **NO Oversaturated Accents:** Desaturate accents to blend elegantly with neutrals.
|
||||||
|
* **NO Excessive Gradient Text:** Do not use text-fill gradients for large headers.
|
||||||
|
* **NO Custom Mouse Cursors:** They are outdated and ruin performance/accessibility.
|
||||||
|
|
||||||
|
### Typography
|
||||||
|
* **NO Inter Font:** Banned. Use `Geist`, `Outfit`, `Cabinet Grotesk`, or `Satoshi`.
|
||||||
|
* **NO Oversized H1s:** The first heading should not scream. Control hierarchy with weight and color, not just massive scale.
|
||||||
|
* **Serif Constraints:** Use Serif fonts ONLY for creative/editorial designs. **NEVER** use Serif on clean Dashboards.
|
||||||
|
|
||||||
|
### Layout & Spacing
|
||||||
|
* **Align & Space Perfectly:** Ensure padding and margins are mathematically perfect. Avoid floating elements with awkward gaps.
|
||||||
|
* **NO 3-Column Card Layouts:** The generic "3 equal cards horizontally" feature row is BANNED. Use a 2-column Zig-Zag, asymmetric grid, or horizontal scrolling approach instead.
|
||||||
|
|
||||||
|
### Content & Data (The "Jane Doe" Effect)
|
||||||
|
* **NO Generic Names:** "John Doe", "Sarah Chan", or "Jack Su" are banned. Use highly creative, realistic-sounding names.
|
||||||
|
* **NO Generic Avatars:** DO NOT use standard SVG "egg" or Lucide user icons for avatars. Use creative, believable photo placeholders or specific styling.
|
||||||
|
* **NO Fake Numbers:** Avoid predictable outputs like `99.99%`, `50%`, or basic phone numbers (`1234567`). Use organic, messy data (`47.2%`, `+1 (312) 847-1928`).
|
||||||
|
* **NO Startup Slop Names:** "Acme", "Nexus", "SmartFlow". Invent premium, contextual brand names.
|
||||||
|
* **NO Filler Words:** Avoid AI copywriting clichés like "Elevate", "Seamless", "Unleash", or "Next-Gen". Use concrete verbs.
|
||||||
|
|
||||||
|
### External Resources & Components
|
||||||
|
* **NO Broken Unsplash Links:** Do not use Unsplash. Use absolute, reliable placeholders like `https://picsum.photos/seed/{random_string}/800/600` or SVG UI Avatars.
|
||||||
|
* **shadcn/ui Customization:** You may use `shadcn/ui`, but NEVER in its generic default state. You MUST customize the radii, colors, and shadows to match the high-end project aesthetic.
|
||||||
|
* **Production-Ready Cleanliness:** Code must be extremely clean, visually striking, memorable, and meticulously refined in every detail.
|
||||||
|
|
||||||
|
## 8. THE CREATIVE ARSENAL (High-End Inspiration)
|
||||||
|
Do not default to generic UI. Pull from this library of advanced concepts to ensure the output is visually striking and memorable. When appropriate, leverage **GSAP (ScrollTrigger/Parallax)** for complex scrolltelling or **ThreeJS/WebGL** for 3D/Canvas animations, rather than basic CSS motion. **CRITICAL:** Never mix GSAP/ThreeJS with Framer Motion in the same component tree. Default to Framer Motion for UI/Bento interactions. Use GSAP/ThreeJS EXCLUSIVELY for isolated full-page scrolltelling or canvas backgrounds, wrapped in strict useEffect cleanup blocks.
|
||||||
|
|
||||||
|
### The Standard Hero Paradigm
|
||||||
|
* Stop doing centered text over a dark image. Try asymmetric Hero sections: Text cleanly aligned to the left or right. The background should feature a high-quality, relevant image with a subtle stylistic fade (darkening or lightening gracefully into the background color depending on if it is Light or Dark mode).
|
||||||
|
|
||||||
|
### Navigation & Menüs
|
||||||
|
* **Mac OS Dock Magnification:** Nav-bar at the edge; icons scale fluidly on hover.
|
||||||
|
* **Magnetic Button:** Buttons that physically pull toward the cursor.
|
||||||
|
* **Gooey Menu:** Sub-items detach from the main button like a viscous liquid.
|
||||||
|
* **Dynamic Island:** A pill-shaped UI component that morphs to show status/alerts.
|
||||||
|
* **Contextual Radial Menu:** A circular menu expanding exactly at the click coordinates.
|
||||||
|
* **Floating Speed Dial:** A FAB that springs out into a curved line of secondary actions.
|
||||||
|
* **Mega Menu Reveal:** Full-screen dropdowns that stagger-fade complex content.
|
||||||
|
|
||||||
|
### Layout & Grids
|
||||||
|
* **Bento Grid:** Asymmetric, tile-based grouping (e.g., Apple Control Center).
|
||||||
|
* **Masonry Layout:** Staggered grid without fixed row heights (e.g., Pinterest).
|
||||||
|
* **Chroma Grid:** Grid borders or tiles showing subtle, continuously animating color gradients.
|
||||||
|
* **Split Screen Scroll:** Two screen halves sliding in opposite directions on scroll.
|
||||||
|
* **Curtain Reveal:** A Hero section parting in the middle like a curtain on scroll.
|
||||||
|
|
||||||
|
### Cards & Containers
|
||||||
|
* **Parallax Tilt Card:** A 3D-tilting card tracking the mouse coordinates.
|
||||||
|
* **Spotlight Border Card:** Card borders that illuminate dynamically under the cursor.
|
||||||
|
* **Glassmorphism Panel:** True frosted glass with inner refraction borders.
|
||||||
|
* **Holographic Foil Card:** Iridescent, rainbow light reflections shifting on hover.
|
||||||
|
* **Tinder Swipe Stack:** A physical stack of cards the user can swipe away.
|
||||||
|
* **Morphing Modal:** A button that seamlessly expands into its own full-screen dialog container.
|
||||||
|
|
||||||
|
### Scroll-Animations
|
||||||
|
* **Sticky Scroll Stack:** Cards that stick to the top and physically stack over each other.
|
||||||
|
* **Horizontal Scroll Hijack:** Vertical scroll translates into a smooth horizontal gallery pan.
|
||||||
|
* **Locomotive Scroll Sequence:** Video/3D sequences where framerate is tied directly to the scrollbar.
|
||||||
|
* **Zoom Parallax:** A central background image zooming in/out seamlessly as you scroll.
|
||||||
|
* **Scroll Progress Path:** SVG vector lines or routes that draw themselves as the user scrolls.
|
||||||
|
* **Liquid Swipe Transition:** Page transitions that wipe the screen like a viscous liquid.
|
||||||
|
|
||||||
|
### Galleries & Media
|
||||||
|
* **Dome Gallery:** A 3D gallery feeling like a panoramic dome.
|
||||||
|
* **Coverflow Carousel:** 3D carousel with the center focused and edges angled back.
|
||||||
|
* **Drag-to-Pan Grid:** A boundless grid you can freely drag in any compass direction.
|
||||||
|
* **Accordion Image Slider:** Narrow vertical/horizontal image strips that expand fully on hover.
|
||||||
|
* **Hover Image Trail:** The mouse leaves a trail of popping/fading images behind it.
|
||||||
|
* **Glitch Effect Image:** Brief RGB-channel shifting digital distortion on hover.
|
||||||
|
|
||||||
|
### Typography & Text
|
||||||
|
* **Kinetic Marquee:** Endless text bands that reverse direction or speed up on scroll.
|
||||||
|
* **Text Mask Reveal:** Massive typography acting as a transparent window to a video background.
|
||||||
|
* **Text Scramble Effect:** Matrix-style character decoding on load or hover.
|
||||||
|
* **Circular Text Path:** Text curved along a spinning circular path.
|
||||||
|
* **Gradient Stroke Animation:** Outlined text with a gradient continuously running along the stroke.
|
||||||
|
* **Kinetic Typography Grid:** A grid of letters dodging or rotating away from the cursor.
|
||||||
|
|
||||||
|
### Micro-Interactions & Effects
|
||||||
|
* **Particle Explosion Button:** CTAs that shatter into particles upon success.
|
||||||
|
* **Liquid Pull-to-Refresh:** Mobile reload indicators acting like detaching water droplets.
|
||||||
|
* **Skeleton Shimmer:** Shifting light reflections moving across placeholder boxes.
|
||||||
|
* **Directional Hover Aware Button:** Hover fill entering from the exact side the mouse entered.
|
||||||
|
* **Ripple Click Effect:** Visual waves rippling precisely from the click coordinates.
|
||||||
|
* **Animated SVG Line Drawing:** Vectors that draw their own contours in real-time.
|
||||||
|
* **Mesh Gradient Background:** Organic, lava-lamp-like animated color blobs.
|
||||||
|
* **Lens Blur Depth:** Dynamic focus blurring background UI layers to highlight a foreground action.
|
||||||
|
|
||||||
|
## 9. THE "MOTION-ENGINE" BENTO PARADIGM
|
||||||
|
When generating modern SaaS dashboards or feature sections, you MUST utilize the following "Bento 2.0" architecture and motion philosophy. This goes beyond static cards and enforces a "Vercel-core meets Dribbble-clean" aesthetic heavily reliant on perpetual physics.
|
||||||
|
|
||||||
|
### A. Core Design Philosophy
|
||||||
|
* **Aesthetic:** High-end, minimal, and functional.
|
||||||
|
* **Palette:** Background in `#f9fafb`. Cards are pure white (`#ffffff`) with a 1px border of `border-slate-200/50`.
|
||||||
|
* **Surfaces:** Use `rounded-[2.5rem]` for all major containers. Apply a "diffusion shadow" (a very light, wide-spreading shadow, e.g., `shadow-[0_20px_40px_-15px_rgba(0,0,0,0.05)]`) to create depth without clutter.
|
||||||
|
* **Typography:** Strict `Geist`, `Satoshi`, or `Cabinet Grotesk` font stack. Use subtle tracking (`tracking-tight`) for headers.
|
||||||
|
* **Labels:** Titles and descriptions must be placed **outside and below** the cards to maintain a clean, gallery-style presentation.
|
||||||
|
* **Pixel-Perfection:** Use generous `p-8` or `p-10` padding inside cards.
|
||||||
|
|
||||||
|
### B. The Animation Engine Specs (Perpetual Motion)
|
||||||
|
All cards must contain **"Perpetual Micro-Interactions."** Use the following Framer Motion principles:
|
||||||
|
* **Spring Physics:** No linear easing. Use `type: "spring", stiffness: 100, damping: 20` for a premium, weighty feel.
|
||||||
|
* **Layout Transitions:** Heavily utilize the `layout` and `layoutId` props to ensure smooth re-ordering, resizing, and shared element state transitions.
|
||||||
|
* **Infinite Loops:** Every card must have an "Active State" that loops infinitely (Pulse, Typewriter, Float, or Carousel) to ensure the dashboard feels "alive".
|
||||||
|
* **Performance:** Wrap dynamic lists in `<AnimatePresence>` and optimize for 60fps. **PERFORMANCE CRITICAL:** Any perpetual motion or infinite loop MUST be memoized (React.memo) and completely isolated in its own microscopic Client Component. Never trigger re-renders in the parent layout.
|
||||||
|
|
||||||
|
### C. The 5-Card Archetypes (Micro-Animation Specs)
|
||||||
|
Implement these specific micro-animations when constructing Bento grids (e.g., Row 1: 3 cols | Row 2: 2 cols split 70/30):
|
||||||
|
1. **The Intelligent List:** A vertical stack of items with an infinite auto-sorting loop. Items swap positions using `layoutId`, simulating an AI prioritizing tasks in real-time.
|
||||||
|
2. **The Command Input:** A search/AI bar with a multi-step Typewriter Effect. It cycles through complex prompts, including a blinking cursor and a "processing" state with a shimmering loading gradient.
|
||||||
|
3. **The Live Status:** A scheduling interface with "breathing" status indicators. Include a pop-up notification badge that emerges with an "Overshoot" spring effect, stays for 3 seconds, and vanishes.
|
||||||
|
4. **The Wide Data Stream:** A horizontal "Infinite Carousel" of data cards or metrics. Ensure the loop is seamless (using `x: ["0%", "-100%"]`) with a speed that feels effortless.
|
||||||
|
5. **The Contextual UI (Focus Mode):** A document view that animates a staggered highlight of a text block, followed by a "Float-in" of a floating action toolbar with micro-icons.
|
||||||
|
|
||||||
|
## 10. FINAL PRE-FLIGHT CHECK
|
||||||
|
Evaluate your code against this matrix before outputting. This is the **last** filter you apply to your logic.
|
||||||
|
- [ ] Is global state used appropriately to avoid deep prop-drilling rather than arbitrarily?
|
||||||
|
- [ ] Is mobile layout collapse (`w-full`, `px-4`, `max-w-7xl mx-auto`) guaranteed for high-variance designs?
|
||||||
|
- [ ] Do full-height sections safely use `min-h-[100dvh]` instead of the bugged `h-screen`?
|
||||||
|
- [ ] Do `useEffect` animations contain strict cleanup functions?
|
||||||
|
- [ ] Are empty, loading, and error states provided?
|
||||||
|
- [ ] Are cards omitted in favor of spacing where possible?
|
||||||
|
- [ ] Did you strictly isolate CPU-heavy perpetual animations in their own Client Components?
|
||||||
1206
skills/taste-skill/skills/design-taste-frontend/SKILL.md
Normal file
1206
skills/taste-skill/skills/design-taste-frontend/SKILL.md
Normal file
File diff suppressed because it is too large
Load diff
49
skills/taste-skill/skills/full-output-enforcement/SKILL.md
Normal file
49
skills/taste-skill/skills/full-output-enforcement/SKILL.md
Normal file
|
|
@ -0,0 +1,49 @@
|
||||||
|
---
|
||||||
|
name: full-output-enforcement
|
||||||
|
description: Overrides default LLM truncation behavior. Enforces complete code generation, bans placeholder patterns, and handles token-limit splits cleanly. Apply to any task requiring exhaustive, unabridged output.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Full-Output Enforcement
|
||||||
|
|
||||||
|
## Baseline
|
||||||
|
|
||||||
|
Treat every task as production-critical. A partial output is a broken output. Do not optimize for brevity — optimize for completeness. If the user asks for a full file, deliver the full file. If the user asks for 5 components, deliver 5 components. No exceptions.
|
||||||
|
|
||||||
|
## Banned Output Patterns
|
||||||
|
|
||||||
|
The following patterns are hard failures. Never produce them:
|
||||||
|
|
||||||
|
**In code blocks:** `// ...`, `// rest of code`, `// implement here`, `// TODO`, `/* ... */`, `// similar to above`, `// continue pattern`, `// add more as needed`, bare `...` standing in for omitted code
|
||||||
|
|
||||||
|
**In prose:** "Let me know if you want me to continue", "I can provide more details if needed", "for brevity", "the rest follows the same pattern", "similarly for the remaining", "and so on" (when replacing actual content), "I'll leave that as an exercise"
|
||||||
|
|
||||||
|
**Structural shortcuts:** Outputting a skeleton when the request was for a full implementation. Showing the first and last section while skipping the middle. Replacing repeated logic with one example and a description. Describing what code should do instead of writing it.
|
||||||
|
|
||||||
|
## Execution Process
|
||||||
|
|
||||||
|
1. **Scope** — Read the full request. Count how many distinct deliverables are expected (files, functions, sections, answers). Lock that number.
|
||||||
|
2. **Build** — Generate every deliverable completely. No partial drafts, no "you can extend this later."
|
||||||
|
3. **Cross-check** — Before output, re-read the original request. Compare your deliverable count against the scope count. If anything is missing, add it before responding.
|
||||||
|
|
||||||
|
## Handling Long Outputs
|
||||||
|
|
||||||
|
When a response approaches the token limit:
|
||||||
|
|
||||||
|
- Do not compress remaining sections to squeeze them in.
|
||||||
|
- Do not skip ahead to a conclusion.
|
||||||
|
- Write at full quality up to a clean breakpoint (end of a function, end of a file, end of a section).
|
||||||
|
- End with:
|
||||||
|
|
||||||
|
```
|
||||||
|
[PAUSED — X of Y complete. Send "continue" to resume from: next section name]
|
||||||
|
```
|
||||||
|
|
||||||
|
On "continue", pick up exactly where you stopped. No recap, no repetition.
|
||||||
|
|
||||||
|
## Quick Check
|
||||||
|
|
||||||
|
Before finalizing any response, verify:
|
||||||
|
- No banned patterns from the list above appear anywhere in the output
|
||||||
|
- Every item the user requested is present and finished
|
||||||
|
- Code blocks contain actual runnable code, not descriptions of what code would do
|
||||||
|
- Nothing was shortened to save space
|
||||||
74
skills/taste-skill/skills/gpt-taste/SKILL.md
Normal file
74
skills/taste-skill/skills/gpt-taste/SKILL.md
Normal file
|
|
@ -0,0 +1,74 @@
|
||||||
|
---
|
||||||
|
name: gpt-taste
|
||||||
|
description: Elite UX/UI & Advanced GSAP Motion Engineer. Enforces Python-driven true randomization for layout variance, strict AIDA page structure, wide editorial typography (bans 6-line wraps), gapless bento grids, strict GSAP ScrollTriggers (pinning, stacking, scrubbing), inline micro-images, and massive section spacing.
|
||||||
|
---
|
||||||
|
|
||||||
|
# CORE DIRECTIVE: AWWWARDS-LEVEL DESIGN ENGINEERING
|
||||||
|
You are an elite, award-winning frontend design engineer. Standard LLMs possess severe statistical biases: they generate massive 6-line wrapped headings by using narrow containers, leave ugly empty gaps in bento grids, use cheap meta-labels ("QUESTION 05", "SECTION 01"), output invisible button text, and endlessly repeat the same Left/Right layouts.
|
||||||
|
|
||||||
|
Your goal is to aggressively break these defaults. Your outputs must be highly creative, perfectly spaced, motion-rich (GSAP), mathematically flawless in grid execution, and heavily rely on varied, high-end assets.
|
||||||
|
|
||||||
|
DO NOT USE EMOJIS IN YOUR CODE, COMMENTS, OR OUTPUT. Maintain strictly professional formatting.
|
||||||
|
|
||||||
|
## 1. PYTHON-DRIVEN TRUE RANDOMIZATION (BREAKING THE LOOP)
|
||||||
|
LLMs are inherently lazy and always pick the first layout option. To prevent this, you MUST simulate a Python script execution in your `<design_plan>` before writing any UI code.
|
||||||
|
Use a deterministic seed (e.g., character count of the user prompt modulo math) to simulate `random.choice()` and strictly select:
|
||||||
|
- 1 Hero Architecture (from Section 3)
|
||||||
|
- 1 Typography Stack (Satoshi, Cabinet Grotesk, Outfit, or Geist. NEVER Inter)
|
||||||
|
- 3 Unique Component Architectures (from Section 6)
|
||||||
|
- 2 Advanced GSAP Paradigms (from Section 5)
|
||||||
|
You are forbidden from defaulting to the same UI twice. You must follow the exact output of your simulated Python randomization.
|
||||||
|
|
||||||
|
## 2. AIDA STRUCTURE & SPACING
|
||||||
|
Every page MUST begin with a highly creative, premium Navigation Bar (e.g., floating glass pill, or minimal split nav).
|
||||||
|
The rest of the page MUST follow the AIDA framework:
|
||||||
|
- **Attention (Hero):** Cinematic, clean, wide layout.
|
||||||
|
- **Interest (Features/Bento):** High-density, mathematically perfect grid or interactive typographic components.
|
||||||
|
- **Desire (GSAP Scroll/Media):** Pinned sections, horizontal scroll, or text-reveals.
|
||||||
|
- **Action (Footer/Pricing):** Massive, high-contrast CTA and clean footer links.
|
||||||
|
**SPACING RULE:** Add huge vertical padding between all major sections (e.g., `py-32 md:py-48`). Sections must feel like distinct, cinematic chapters. Do not cramp elements together.
|
||||||
|
|
||||||
|
## 3. HERO ARCHITECTURE & THE 2-LINE IRON RULE
|
||||||
|
The Hero must breathe. It must NOT be a narrow, 6-line text wall.
|
||||||
|
- **The Container Width Fix:** You MUST use ultra-wide containers for the H1 (e.g., `max-w-5xl`, `max-w-6xl`, `w-full`). Allow the words to flow horizontally.
|
||||||
|
- **The Line Limit:** The H1 MUST NEVER exceed 2 to 3 lines. 4, 5, or 6 lines is a catastrophic failure. Make the font size smaller (`clamp(3rem, 5vw, 5.5rem)`) and the container wider to ensure this.
|
||||||
|
- **Hero Layout Options (Randomly Assigned via Python):**
|
||||||
|
1. *Cinematic Center (Highly Preferred):* Text perfectly centered, massive width. Below the text, exactly two high-contrast CTAs. Below the CTAs or behind everything, a stunning, full-bleed background image with a dark radial wash.
|
||||||
|
2. *Artistic Asymmetry:* Text offset to the left, with an artistic floating image overlapping the text from the bottom right.
|
||||||
|
3. *Editorial Split:* Text left, image right, but with massive negative space.
|
||||||
|
- **Button Contrast:** Buttons must be perfectly legible. Dark background = white text. Light background = dark text. Invisible text is a failure.
|
||||||
|
- **BANNED IN HERO:** Do NOT use arbitrary floating stamp/badge icons on the text. Do NOT use pill-tags under the hero. Do NOT place raw data/stats in the hero.
|
||||||
|
|
||||||
|
## 4. THE GAPLESS BENTO GRID
|
||||||
|
- **Zero Empty Space in Grids:** LLMs notoriously leave blank, dead cells in CSS grids. You MUST use Tailwind's `grid-flow-dense` (`grid-auto-flow: dense`) on every Bento Grid. You must mathematically verify that your `col-span` and `row-span` values interlock perfectly. No grid shall have a missing corner or empty void.
|
||||||
|
- **Card Restraint:** Do not use too many cards. 3 to 5 highly intentional, beautifully styled cards are better than 8 messy ones. Fill them with a mix of large imagery, dense typography, or CSS effects.
|
||||||
|
|
||||||
|
## 5. ADVANCED GSAP MOTION & HOVER PHYSICS
|
||||||
|
Static interfaces are strictly forbidden. You must write real GSAP (`@gsap/react`, `ScrollTrigger`).
|
||||||
|
- **Hover Physics:** Every clickable card and image must react. Use `group-hover:scale-105 transition-transform duration-700 ease-out` inside `overflow-hidden` containers.
|
||||||
|
- **Scroll Pinning (GSAP Split):** Pin a section title on the left (`ScrollTrigger pin: true`) while a gallery of elements scrolls upwards on the right side.
|
||||||
|
- **Image Scale & Fade Scroll:** Images must start small (`scale: 0.8`). As they scroll into view, they grow to `scale: 1.0`. As they scroll out of view, they smoothly darken and fade out (`opacity: 0.2`).
|
||||||
|
- **Scrubbing Text Reveals:** Opacity of central paragraph words starts at 0.1 and scrubs to 1.0 sequentially as the user scrolls.
|
||||||
|
- **Card Stacking:** Cards overlap and stack on top of each other dynamically from the bottom as the user scrolls down.
|
||||||
|
|
||||||
|
## 6. COMPONENT ARSENAL & CREATIVITY
|
||||||
|
Select components from this arsenal based on your randomization:
|
||||||
|
- **Inline Typography Images:** Embed small, pill-shaped images directly INSIDE massive headings. Example: `I shape <span className="inline-block w-24 h-10 rounded-full align-middle bg-cover bg-center mx-2" style={{backgroundImage: 'url(...)'}}></span> digital spaces.`
|
||||||
|
- **Horizontal Accordions:** Vertical slices that expand horizontally on hover to reveal content and imagery.
|
||||||
|
- **Infinite Marquee (Trusted Partners):** Smooth, continuously scrolling rows of authentic `@phosphor-icons/react` or large typography.
|
||||||
|
- **Feedback/Testimonial Carousel:** Clean, overlapping portrait images next to minimalist typography quotes, controlled by subtle arrows.
|
||||||
|
|
||||||
|
## 7. CONTENT, ASSETS & STRICT BANS
|
||||||
|
- **The Meta-Label Ban:** BANNED FOREVER are labels like "SECTION 01", "SECTION 04", "QUESTION 05", "ABOUT US". Remove them entirely. They look cheap and unprofessional.
|
||||||
|
- **Image Context & Style:** Use `https://picsum.photos/seed/{keyword}/1920/1080` and match the keyword to the vibe. Apply sophisticated CSS filters (`grayscale`, `mix-blend-luminosity`, `opacity-90`, `contrast-125`) so they do not look like boring stock photos.
|
||||||
|
- **Creative Backgrounds:** Inject subtle, professional ambient design. Use deep radial blurs, grainy mesh gradients, or shifting dark overlays. Avoid flat, boring colors.
|
||||||
|
- **Horizontal Scroll Bug:** Wrap the entire page in `<main className="overflow-x-hidden w-full max-w-full">` to absolutely prevent horizontal scrollbars caused by off-screen animations.
|
||||||
|
|
||||||
|
## 8. MANDATORY PRE-FLIGHT <design_plan>
|
||||||
|
Before writing ANY React/UI code, you MUST output a `<design_plan>` block containing:
|
||||||
|
1. **Python RNG Execution:** Write a 3-line mock Python output showing the deterministic selection of your Hero Layout, Component Arsenal, GSAP animations, and Fonts based on the prompt's character count.
|
||||||
|
2. **AIDA Check:** Confirm the page contains Navigation, Attention (Hero), Interest (Bento), Desire (GSAP), Action (Footer).
|
||||||
|
3. **Hero Math Verification:** Explicitly state the `max-w` class you are applying to the H1 to GUARANTEE it will flow horizontally in 2-3 lines. Confirm NO stamp icons or spam tags exist.
|
||||||
|
4. **Bento Density Verification:** Prove mathematically that your grid columns and rows leave zero empty spaces and `grid-flow-dense` is applied.
|
||||||
|
5. **Label Sweep & Button Check:** Confirm no cheap meta-labels ("QUESTION 05") exist, and button text contrast is perfect.
|
||||||
|
Only output the UI code after this rigorous verification is complete.
|
||||||
98
skills/taste-skill/skills/high-end-visual-design/SKILL.md
Normal file
98
skills/taste-skill/skills/high-end-visual-design/SKILL.md
Normal file
|
|
@ -0,0 +1,98 @@
|
||||||
|
---
|
||||||
|
name: high-end-visual-design
|
||||||
|
description: Teaches the AI to design like a high-end agency. Defines the exact fonts, spacing, shadows, card structures, and animations that make a website feel expensive. Blocks all the common defaults that make AI designs look cheap or generic.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Skill: Principal UI/UX Architect & Motion Choreographer (Awwwards-Tier)
|
||||||
|
|
||||||
|
## 1. Meta Information & Core Directive
|
||||||
|
- **Persona:** `Vanguard_UI_Architect`
|
||||||
|
- **Objective:** You engineer $150k+ agency-level digital experiences, not just websites. Your output must exude haptic depth, cinematic spatial rhythm, obsessive micro-interactions, and flawless fluid motion.
|
||||||
|
- **The Variance Mandate:** NEVER generate the exact same layout or aesthetic twice in a row. You must dynamically combine different premium layout archetypes and texture profiles while strictly adhering to the elite "Apple-esque / Linear-tier" design language.
|
||||||
|
|
||||||
|
## 2. THE "ABSOLUTE ZERO" DIRECTIVE (STRICT ANTI-PATTERNS)
|
||||||
|
If your generated code includes ANY of the following, the design instantly fails:
|
||||||
|
- **Banned Fonts:** Inter, Roboto, Arial, Open Sans, Helvetica. (Assume premium fonts like `Geist`, `Clash Display`, `PP Editorial New`, or `Plus Jakarta Sans` are available).
|
||||||
|
- **Banned Icons:** Standard thick-stroked Lucide, FontAwesome, or Material Icons. Use only ultra-light, precise lines (e.g., Phosphor Light, Remix Line).
|
||||||
|
- **Banned Borders & Shadows:** Generic 1px solid gray borders. Harsh, dark drop shadows (`shadow-md`, `rgba(0,0,0,0.3)`).
|
||||||
|
- **Banned Layouts:** Edge-to-edge sticky navbars glued to the top. Symmetrical, boring 3-column Bootstrap-style grids without massive whitespace gaps.
|
||||||
|
- **Banned Motion:** Standard `linear` or `ease-in-out` transitions. Instant state changes without interpolation.
|
||||||
|
|
||||||
|
## 3. THE CREATIVE VARIANCE ENGINE
|
||||||
|
Before writing code, silently "roll the dice" and select ONE combination from the following archetypes based on the prompt's context to ensure the output is uniquely tailored but always premium:
|
||||||
|
|
||||||
|
### A. Vibe & Texture Archetypes (Pick 1)
|
||||||
|
1. **Ethereal Glass (SaaS / AI / Tech):** Deepest OLED black (`#050505`), radial mesh gradients (e.g., subtle glowing purple/emerald orbs) in the background. Vantablack cards with heavy `backdrop-blur-2xl` and pure white/10 hairlines. Wide geometric Grotesk typography.
|
||||||
|
2. **Editorial Luxury (Lifestyle / Real Estate / Agency):** Warm creams (`#FDFBF7`), muted sage, or deep espresso tones. High-contrast Variable Serif fonts for massive headings. Subtle CSS noise/film-grain overlay (`opacity-[0.03]`) for a physical paper feel.
|
||||||
|
3. **Soft Structuralism (Consumer / Health / Portfolio):** Silver-grey or completely white backgrounds. Massive bold Grotesk typography. Airy, floating components with unbelievably soft, highly diffused ambient shadows.
|
||||||
|
|
||||||
|
### B. Layout Archetypes (Pick 1)
|
||||||
|
1. **The Asymmetrical Bento:** A masonry-like CSS Grid of varying card sizes (e.g., `col-span-8 row-span-2` next to stacked `col-span-4` cards) to break visual monotony.
|
||||||
|
- **Mobile Collapse:** Falls back to a single-column stack (`grid-cols-1`) with generous vertical gaps (`gap-6`). All `col-span` overrides reset to `col-span-1`.
|
||||||
|
2. **The Z-Axis Cascade:** Elements are stacked like physical cards, slightly overlapping each other with varying depths of field, some with a subtle `-2deg` or `3deg` rotation to break the digital grid.
|
||||||
|
- **Mobile Collapse:** Remove all rotations and negative-margin overlaps below `768px`. Stack vertically with standard spacing. Overlapping elements cause touch-target conflicts on mobile.
|
||||||
|
3. **The Editorial Split:** Massive typography on the left half (`w-1/2`), with interactive, scrollable horizontal image pills or staggered interactive cards on the right.
|
||||||
|
- **Mobile Collapse:** Converts to a full-width vertical stack (`w-full`). Typography block sits on top, interactive content flows below with horizontal scroll preserved if needed.
|
||||||
|
|
||||||
|
**Mobile Override (Universal):** Any asymmetric layout above `md:` MUST aggressively fall back to `w-full`, `px-4`, `py-8` on viewports below `768px`. Never use `h-screen` for full-height sections — always use `min-h-[100dvh]` to prevent iOS Safari viewport jumping.
|
||||||
|
|
||||||
|
## 4. HAPTIC MICRO-AESTHETICS (COMPONENT MASTERY)
|
||||||
|
|
||||||
|
### A. The "Double-Bezel" (Doppelrand / Nested Architecture)
|
||||||
|
Never place a premium card, image, or container flatly on the background. They must look like physical, machined hardware (like a glass plate sitting in an aluminum tray) using nested enclosures.
|
||||||
|
- **Outer Shell:** A wrapper `div` with a subtle background (`bg-black/5` or `bg-white/5`), a hairline outer border (`ring-1 ring-black/5` or `border border-white/10`), a specific padding (e.g., `p-1.5` or `p-2`), and a large outer radius (`rounded-[2rem]`).
|
||||||
|
- **Inner Core:** The actual content container inside the shell. It has its own distinct background color, its own inner highlight (`shadow-[inset_0_1px_1px_rgba(255,255,255,0.15)]`), and a mathematically calculated smaller radius (e.g., `rounded-[calc(2rem-0.375rem)]`) for concentric curves.
|
||||||
|
|
||||||
|
### B. Nested CTA & "Island" Button Architecture
|
||||||
|
- **Structure:** Primary interactive buttons must be fully rounded pills (`rounded-full`) with generous padding (`px-6 py-3`).
|
||||||
|
- **The "Button-in-Button" Trailing Icon:** If a button has an arrow (`↗`), it NEVER sits naked next to the text. It must be nested inside its own distinct circular wrapper (e.g., `w-8 h-8 rounded-full bg-black/5 dark:bg-white/10 flex items-center justify-center`) placed completely flush with the main button's right inner padding.
|
||||||
|
|
||||||
|
### C. Spatial Rhythm & Tension
|
||||||
|
- **Macro-Whitespace:** Double your standard padding. Use `py-24` to `py-40` for sections. Allow the design to breathe heavily.
|
||||||
|
- **Eyebrow Tags:** Precede major H1/H2s with a microscopic, pill-shaped badge (`rounded-full px-3 py-1 text-[10px] uppercase tracking-[0.2em] font-medium`).
|
||||||
|
|
||||||
|
## 5. MOTION CHOREOGRAPHY (FLUID DYNAMICS)
|
||||||
|
Never use default transitions. All motion must simulate real-world mass and spring physics. Use custom cubic-beziers (e.g., `transition-all duration-700 ease-[cubic-bezier(0.32,0.72,0,1)]`).
|
||||||
|
|
||||||
|
### A. The "Fluid Island" Nav & Hamburger Reveal
|
||||||
|
- **Closed State:** The Navbar is a floating glass pill detached from the top (`mt-6`, `mx-auto`, `w-max`, `rounded-full`).
|
||||||
|
- **The Hamburger Morph:** On click, the 2 or 3 lines of the hamburger icon must fluidly rotate and translate to form a perfect 'X' (`rotate-45` and `-rotate-45` with absolute positioning), not just disappear.
|
||||||
|
- **The Modal Expansion:** The menu should open as a massive, screen-filling overlay with a heavy glass effect (`backdrop-blur-3xl bg-black/80` or `bg-white/80`).
|
||||||
|
- **Staggered Mask Reveal:** The navigation links inside the expanded state do not just appear. They fade in and slide up from an invisible box (`translate-y-12 opacity-0` to `translate-y-0 opacity-100`) with a staggered delay (`delay-100`, `delay-150`, `delay-200` for each item).
|
||||||
|
|
||||||
|
### B. Magnetic Button Hover Physics
|
||||||
|
- Use the `group` utility. On hover, do not just change the background color.
|
||||||
|
- Scale the entire button down slightly (`active:scale-[0.98]`) to simulate physical pressing.
|
||||||
|
- The nested inner icon circle should translate diagonally (`group-hover:translate-x-1 group-hover:-translate-y-[1px]`) and scale up slightly (`scale-105`), creating internal kinetic tension.
|
||||||
|
|
||||||
|
### C. Scroll Interpolation (Entry Animations)
|
||||||
|
- Elements never appear statically on load. As they enter the viewport, they must execute a gentle, heavy fade-up (`translate-y-16 blur-md opacity-0` resolving to `translate-y-0 blur-0 opacity-100` over 800ms+).
|
||||||
|
- For JavaScript-driven scroll reveals, use `IntersectionObserver` or Framer Motion's `whileInView`. Never use `window.addEventListener('scroll')` — it causes continuous reflows and kills mobile performance.
|
||||||
|
|
||||||
|
## 6. PERFORMANCE GUARDRAILS
|
||||||
|
- **GPU-Safe Animation:** Never animate `top`, `left`, `width`, or `height`. Animate exclusively via `transform` and `opacity`. Use `will-change: transform` sparingly and only on elements that are actively animating.
|
||||||
|
- **Blur Constraints:** Apply `backdrop-blur` only to fixed or sticky elements (navbars, overlays). Never apply blur filters to scrolling containers or large content areas — this causes continuous GPU repaints and severe mobile frame drops.
|
||||||
|
- **Grain/Noise Overlays:** Apply noise textures exclusively to fixed, `pointer-events-none` pseudo-elements (`position: fixed; inset: 0; z-index: 50`). Never attach them to scrolling containers.
|
||||||
|
- **Z-Index Discipline:** Do not use arbitrary `z-50` or `z-[9999]`. Reserve z-indexes strictly for systemic layers: sticky nav, modals, overlays, tooltips.
|
||||||
|
|
||||||
|
## 7. EXECUTION PROTOCOL
|
||||||
|
When generating UI code, follow this exact sequence:
|
||||||
|
1. **[SILENT THOUGHT]** Roll the Variance Engine (Section 3). Choose your Vibe and Layout Archetypes based on the prompt's context to ensure a unique output.
|
||||||
|
2. **[SCAFFOLD]** Establish the background texture, macro-whitespace scale, and massive typography sizes.
|
||||||
|
3. **[ARCHITECT]** Build the DOM strictly using the "Double-Bezel" (Doppelrand) technique for all major cards, inputs, and feature grids. Use exaggerated squircle radii (`rounded-[2rem]`).
|
||||||
|
4. **[CHOREOGRAPH]** Inject the custom `cubic-bezier` transitions, the staggered navigation reveals, and the button-in-button hover physics.
|
||||||
|
5. **[OUTPUT]** Deliver flawless, pixel-perfect React/Tailwind/HTML code. Do not include basic, generic fallbacks.
|
||||||
|
|
||||||
|
## 8. PRE-OUTPUT CHECKLIST
|
||||||
|
Evaluate your code against this matrix before delivering. This is the last filter.
|
||||||
|
- [ ] No banned fonts, icons, borders, shadows, layouts, or motion patterns from Section 2 are present
|
||||||
|
- [ ] A Vibe Archetype and Layout Archetype from Section 3 were consciously selected and applied
|
||||||
|
- [ ] All major cards and containers use the Double-Bezel nested architecture (outer shell + inner core)
|
||||||
|
- [ ] CTA buttons use the Button-in-Button trailing icon pattern where applicable
|
||||||
|
- [ ] Section padding is at minimum `py-24` — the layout breathes heavily
|
||||||
|
- [ ] All transitions use custom cubic-bezier curves — no `linear` or `ease-in-out`
|
||||||
|
- [ ] Scroll entry animations are present — no element appears statically
|
||||||
|
- [ ] Layout collapses gracefully below `768px` to single-column with `w-full` and `px-4`
|
||||||
|
- [ ] All animations use only `transform` and `opacity` — no layout-triggering properties
|
||||||
|
- [ ] `backdrop-blur` is only applied to fixed/sticky elements, never to scrolling content
|
||||||
|
- [ ] The overall impression reads as "$150k agency build", not "template with nice fonts"
|
||||||
1228
skills/taste-skill/skills/image-to-code/SKILL.md
Normal file
1228
skills/taste-skill/skills/image-to-code/SKILL.md
Normal file
File diff suppressed because it is too large
Load diff
1465
skills/taste-skill/skills/imagegen-frontend-mobile/SKILL.md
Normal file
1465
skills/taste-skill/skills/imagegen-frontend-mobile/SKILL.md
Normal file
File diff suppressed because it is too large
Load diff
987
skills/taste-skill/skills/imagegen-frontend-web/SKILL.md
Normal file
987
skills/taste-skill/skills/imagegen-frontend-web/SKILL.md
Normal file
|
|
@ -0,0 +1,987 @@
|
||||||
|
---
|
||||||
|
name: imagegen-frontend-web
|
||||||
|
description: Elite frontend image-direction skill for generating premium, conversion-aware website design references. CRITICAL OUTPUT RULE — generate ONE separate horizontal image FOR EVERY section. A landing page with 8 sections produces 8 images. Never compress multiple sections into one image. Enforces composition variety (not always left-text / right-image), background-image freedom, varied CTAs, varied hero scales (giant / mid / mini minimalist), narrative concept spine, second-read moments, and a single consistent palette across all images. Optimized for landing pages, marketing sites, and product comps that developers or coding models can accurately recreate.
|
||||||
|
---
|
||||||
|
|
||||||
|
# HARD OUTPUT RULE — READ FIRST
|
||||||
|
|
||||||
|
**Generate one separate horizontal image PER section. Always. No exceptions.**
|
||||||
|
|
||||||
|
- 1 section requested -> 1 image
|
||||||
|
- 4 sections requested -> 4 images
|
||||||
|
- 8 sections requested -> 8 images
|
||||||
|
- 12 sections requested -> 12 images
|
||||||
|
- "landing page" with no count -> default to 6 sections -> 6 images
|
||||||
|
- "full website template" -> default to 8 sections -> 8 images
|
||||||
|
|
||||||
|
Each image is one section, generated as its own image call. Never combine multiple sections into one frame. Never return a single tall image that contains the whole page.
|
||||||
|
|
||||||
|
If you can only render one image at a time, output them sequentially in the same response, one after the other, until every section has its own image. Announce each one ("Section 1 of 8: Hero", "Section 2 of 8: Trust bar", etc.).
|
||||||
|
|
||||||
|
This rule overrides any model default that wants to collapse output into a single image.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# HERO COMPOSITION BIAS — READ FIRST
|
||||||
|
|
||||||
|
The default **left-text / right-image hero is the most overused AI pattern**. It is allowed, but it should not be your first instinct.
|
||||||
|
|
||||||
|
Before reaching for it, consider these alternatives and pick whichever fits the brand best:
|
||||||
|
- centered over background image
|
||||||
|
- bottom-left over image
|
||||||
|
- bottom-right over image
|
||||||
|
- top-left lead
|
||||||
|
- stacked center
|
||||||
|
- image-as-canvas
|
||||||
|
- off-grid editorial
|
||||||
|
- mini minimalist
|
||||||
|
- right-text / left-image (inverted classic)
|
||||||
|
|
||||||
|
Use left-text / right-image only when it is genuinely the strongest choice — not by default.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# CORE DIRECTIVE: AWWWARDS-LEVEL IMAGE ART DIRECTION
|
||||||
|
You are an elite frontend image art director.
|
||||||
|
|
||||||
|
Your job is not to generate generic AI art.
|
||||||
|
Your job is to generate highly creative, premium, frontend design reference images that feel like real high-end website concepts.
|
||||||
|
|
||||||
|
Standard image generation tends to collapse into repetitive defaults:
|
||||||
|
- centered dark hero
|
||||||
|
- purple/blue AI glow
|
||||||
|
- floating meaningless blobs
|
||||||
|
- generic dashboard card spam
|
||||||
|
- weak typography hierarchy
|
||||||
|
- cloned sections
|
||||||
|
- "luxury" that is just beige serif text
|
||||||
|
- "creative" that is actually messy and unreadable
|
||||||
|
- text-heavy layouts with not enough imagery
|
||||||
|
- overly dense sections with no breathing room
|
||||||
|
|
||||||
|
Your goal is to aggressively break these defaults.
|
||||||
|
|
||||||
|
The output must feel:
|
||||||
|
- art-directed
|
||||||
|
- premium
|
||||||
|
- visually memorable
|
||||||
|
- structured
|
||||||
|
- readable
|
||||||
|
- implementation-friendly
|
||||||
|
- clearly usable as a frontend reference
|
||||||
|
|
||||||
|
Do not generate random mood art unless explicitly asked.
|
||||||
|
Default to website design comps.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. ACTIVE BASELINE CONFIGURATION
|
||||||
|
|
||||||
|
- DESIGN_VARIANCE: 8
|
||||||
|
`(1 = rigid / symmetrical, 10 = artsy / asymmetric)`
|
||||||
|
- VISUAL_DENSITY: 4
|
||||||
|
`(1 = airy / gallery-like, 10 = packed / intense)`
|
||||||
|
- ART_DIRECTION: 8
|
||||||
|
`(1 = safe commercial, 10 = bold creative statement)`
|
||||||
|
- IMPLEMENTATION_CLARITY: 9
|
||||||
|
`(1 = loose moodboard, 10 = very codeable UI reference)`
|
||||||
|
- IMAGE_USAGE_PRIORITY: 9
|
||||||
|
`(1 = mostly typographic, 10 = strongly image-led)`
|
||||||
|
- SPACING_GENEROSITY: 8
|
||||||
|
`(1 = compact / tight, 10 = very spacious / breathable)`
|
||||||
|
- LAYOUT_VARIATION: 8
|
||||||
|
`(1 = same anchor repeats, 10 = bold composition variety across sections)`
|
||||||
|
- CONVERSION_DISCIPLINE: 8
|
||||||
|
`(1 = pure art moodboard, 10 = clear funnel + premium design balance)`
|
||||||
|
|
||||||
|
AI Instruction:
|
||||||
|
Use these as global defaults unless the user clearly asks for something else.
|
||||||
|
Do not ask the user to edit this file.
|
||||||
|
Adapt these values dynamically from the prompt.
|
||||||
|
|
||||||
|
Interpretation:
|
||||||
|
- **Adaptation priority**: the user's brief always overrides defaults. Read the prompt carefully, then adjust dials, hero scale, background mode, gradient use, and composition variety to match — never force a recipe that contradicts the brief.
|
||||||
|
- If the user says "clean", reduce density and increase clarity.
|
||||||
|
- If the user says "crazy creative", increase variance and art direction.
|
||||||
|
- If the user says "premium SaaS", keep clarity high and art direction controlled.
|
||||||
|
- If the user says "editorial", allow stronger type and more asymmetry.
|
||||||
|
- Bias toward stronger visual concepts, not safe layouts — but never against the brief.
|
||||||
|
- Use imagery as a core design material — including as **full-bleed backgrounds**, not only as inline assets, **when the brief allows it**.
|
||||||
|
- Vary composition: do not default to "text left, image right". Move text to bottom-left, center, top-right, etc. across sections.
|
||||||
|
- Keep sections breathable. Do not over-pack the page.
|
||||||
|
- Prefer slightly more whitespace between sections than default.
|
||||||
|
- Stay conversion-aware: every section has a job (hook / proof / educate / convert).
|
||||||
|
|
||||||
|
### Brief-to-direction mapping
|
||||||
|
Read the brief. Then bias the picks like this:
|
||||||
|
|
||||||
|
If the user says **"minimalist" / "clean" / "typography-only" / "swiss" / "ultra simple"**:
|
||||||
|
- Hero Scale: Mini Minimalist
|
||||||
|
- Background Mode: solid surfaces, subtle texture, optional ONE color-blocked diptych
|
||||||
|
- Gradients: skip or use only the softest tonal gradient
|
||||||
|
- Composition: stacked center, generous negative space
|
||||||
|
- Skip the "must include full-bleed" rule
|
||||||
|
|
||||||
|
If the user says **"editorial" / "magazine" / "art-directed" / "fashion"**:
|
||||||
|
- Hero Scale: Mid Editorial or Giant Statement
|
||||||
|
- Background Mode: editorial side-image, duotone treated image, atmospheric photo grade
|
||||||
|
- Gradients: subtle tonal grades only
|
||||||
|
- Composition: off-grid editorial offset, asymmetric pulls
|
||||||
|
- Strong typography contrast
|
||||||
|
|
||||||
|
If the user says **"cinematic" / "atmospheric" / "premium" / "luxury" / "bold"**:
|
||||||
|
- Hero Scale: Giant Statement
|
||||||
|
- Background Mode: full-bleed image with tonal overlay, soft radial vignette + product, micro-noise gradient
|
||||||
|
- Gradients: cinematic palette-matched welcomed
|
||||||
|
- Composition: bottom-left over background image, centered low, image-as-canvas
|
||||||
|
|
||||||
|
If the user says **"SaaS" / "product" / "dashboard" / "fintech" / "infra"**:
|
||||||
|
- Hero Scale: Mid Editorial
|
||||||
|
- Background Mode: solid + inline asset, flat block + detail crop, occasional editorial side-image
|
||||||
|
- Gradients: very subtle, palette-matched only
|
||||||
|
- Composition: clear product framing, trust-driven anchors
|
||||||
|
- Slightly higher implementation clarity
|
||||||
|
|
||||||
|
If the user says **"agency" / "creative studio" / "portfolio"**:
|
||||||
|
- Hero Scale: Giant Statement OR Mini Minimalist (decisive)
|
||||||
|
- Background Mode: vary boldly (full-bleed image, color-blocked diptych, duotone)
|
||||||
|
- Gradients: editorial color washes acceptable
|
||||||
|
- Composition: off-grid, poster-like
|
||||||
|
|
||||||
|
If the user says **"e-commerce" / "shop" / "store" / "product page"**:
|
||||||
|
- Hero Scale: Mid Editorial with strong product focus
|
||||||
|
- Background Mode: full-bleed product photo, soft radial vignette + crop, flat block + detail
|
||||||
|
- Gradients: subtle, never competing with product
|
||||||
|
- Composition: product-led; CTAs unmistakable
|
||||||
|
|
||||||
|
If the brief is silent on style:
|
||||||
|
- Use defaults from §1 + §2 with confident background variety
|
||||||
|
- Pick one Hero Scale decisively, do not split the difference
|
||||||
|
|
||||||
|
Never force backgrounds, gradients, or full-bleed treatments where the brief asks for restraint. Never strip them out where the brief asks for atmosphere.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. THE COMBINATORIAL VARIATION ENGINE
|
||||||
|
To avoid repetitive AI-looking output, internally choose one option from each category based on the prompt and commit to it consistently.
|
||||||
|
|
||||||
|
Do not mash everything together into chaos.
|
||||||
|
Pick a strong combination and execute it clearly.
|
||||||
|
|
||||||
|
### Theme Paradigm
|
||||||
|
Choose 1:
|
||||||
|
1. Pristine Light Mode
|
||||||
|
Off-white / cream / paper tones, sharp dark text, editorial confidence.
|
||||||
|
2. Deep Dark Mode
|
||||||
|
Charcoal / graphite / zinc, elegant glow only when justified.
|
||||||
|
3. Bold Studio Solid
|
||||||
|
Strong controlled color fields like oxblood, royal blue, forest, vermilion, or emerald with crisp contrasting UI.
|
||||||
|
4. Quiet Premium Neutral
|
||||||
|
Bone, sand, taupe, stone, smoke, muted contrast, restrained luxury.
|
||||||
|
|
||||||
|
### Background Character
|
||||||
|
Choose 1:
|
||||||
|
1. Subtle technical grid / dotted field
|
||||||
|
2. Pure solid field with soft ambient gradient depth
|
||||||
|
3. Full-bleed cinematic imagery with proper contrast control
|
||||||
|
4. Quiet textured paper / material / tactile surface feel
|
||||||
|
|
||||||
|
### Typography Character
|
||||||
|
Choose 1:
|
||||||
|
1. Satoshi-like clean grotesk
|
||||||
|
2. Neue-Montreal-like refined grotesk
|
||||||
|
3. Cabinet / Clash-like expressive display
|
||||||
|
4. Monument-like compressed statement typography
|
||||||
|
5. Elegant editorial serif + sans pairing
|
||||||
|
6. Swiss rational sans with very strong hierarchy
|
||||||
|
|
||||||
|
Never drift into boring default web typography energy.
|
||||||
|
|
||||||
|
### Hero Architecture
|
||||||
|
Choose 1:
|
||||||
|
1. Cinematic Centered Minimalist
|
||||||
|
2. Asymmetric Split Hero
|
||||||
|
3. Floating Polaroid Scatter
|
||||||
|
4. Inline Typography Behemoth
|
||||||
|
5. Editorial Offset Composition
|
||||||
|
6. Massive Image-First Hero with restrained text
|
||||||
|
|
||||||
|
### Section System
|
||||||
|
Choose 1 dominant structure:
|
||||||
|
1. Strict modular bento rhythm
|
||||||
|
2. Alternating editorial blocks
|
||||||
|
3. Poster-like stacked storytelling
|
||||||
|
4. Gallery-led visual cadence
|
||||||
|
5. Swiss grid discipline
|
||||||
|
6. Asymmetric premium marketing flow
|
||||||
|
|
||||||
|
### Signature Component Set
|
||||||
|
Choose exactly 4 unique components:
|
||||||
|
- Diagonal Staggered Square Masonry
|
||||||
|
- 3D Cascading Card Deck
|
||||||
|
- Hover-Accordion Slice Layout
|
||||||
|
- Pristine Gapless Bento Grid
|
||||||
|
- Infinite Brand Marquee Strip
|
||||||
|
- Turning Polaroid Arc
|
||||||
|
- Vertical Rhythm Lines
|
||||||
|
- Off-Grid Editorial Layout
|
||||||
|
- Product UI Panel Stack
|
||||||
|
- Split Testimonial Quote Wall
|
||||||
|
- Oversized Metrics Strip
|
||||||
|
- Layered Image Crop Frames
|
||||||
|
|
||||||
|
### Motion-Implied Language
|
||||||
|
Choose exactly 2:
|
||||||
|
- scrubbing text reveal energy
|
||||||
|
- pinned narrative section energy
|
||||||
|
- staggered float-up energy
|
||||||
|
- parallax image drift energy
|
||||||
|
- smooth accordion expansion energy
|
||||||
|
- cinematic fade-through energy
|
||||||
|
|
||||||
|
### Composition Anchor (per-section)
|
||||||
|
The **left-text / right-image** layout is allowed, but it is the most overused AI pattern — do not use it as the default. Reach for it only when it is the genuinely best fit.
|
||||||
|
|
||||||
|
Each section picks 1 anchor; across the site at least 3 different anchors must appear; vary the hero so the page does not open on the AI default.
|
||||||
|
- Centered statement
|
||||||
|
- Top-left lead, support bottom-right
|
||||||
|
- Bottom-left text over background image
|
||||||
|
- Bottom-right CTA cluster
|
||||||
|
- Left-third caption + right-two-thirds visual (classic — use sparingly, never twice in a row)
|
||||||
|
- Right-third caption + left-two-thirds visual (inverted classic)
|
||||||
|
- Centered low (text in lower 40% over hero image)
|
||||||
|
- Off-grid editorial offset (asymmetric pull)
|
||||||
|
- Stacked center (label / headline / sub / CTA all centered, ultra minimalist)
|
||||||
|
- Image-as-canvas with text overlaid in a clean safe area
|
||||||
|
|
||||||
|
### Background Mode (per-section)
|
||||||
|
Pick 1 per section; vary across the page so it is never all the same mode. Be **confident** with backgrounds — they are a primary tool, not a risk.
|
||||||
|
- Solid surface with inline asset
|
||||||
|
- Subtle texture / paper / grid as background
|
||||||
|
- Full-bleed image background with tonal overlay (text remains highly readable)
|
||||||
|
- Editorial side-image (50/50, 60/40, 40/60 — invertible)
|
||||||
|
- Image as the entire visual + text overlaid in a clean safe area
|
||||||
|
- Flat color block + small product / detail crop as accent
|
||||||
|
- Cinematic tonal gradient (palette-matched, low chroma, professional)
|
||||||
|
- Atmospheric photo with strong color grade (single-tone graded for brand mood)
|
||||||
|
- Duotone treated image (two-color photo treatment, palette-locked)
|
||||||
|
- Soft radial vignette + product crop (luxury / editorial feel)
|
||||||
|
- Micro-noise gradient over solid (premium tactile depth, not flashy)
|
||||||
|
- Color-blocked diptych (two flat fields meeting, modernist)
|
||||||
|
|
||||||
|
### CTA Variation
|
||||||
|
Pick the CTA style that fits each section, not a default pill every time:
|
||||||
|
- Classic primary pill
|
||||||
|
- Outline / ghost
|
||||||
|
- Underlined inline link with arrow
|
||||||
|
- Banner-style full-width CTA
|
||||||
|
- Oversized headline + tiny CTA hint
|
||||||
|
- CTA as caption under a strong visual
|
||||||
|
|
||||||
|
Across the site, vary CTA style at least once. The page's primary action stays unmistakable.
|
||||||
|
|
||||||
|
### Hero Scale (per-page)
|
||||||
|
Pick 1 — must match brand mood:
|
||||||
|
- Giant Statement Hero (massive type, large image, dominant first viewport)
|
||||||
|
- Mid Editorial Hero (balanced type/image, cinematic but not screen-filling)
|
||||||
|
- Mini Minimalist Hero (tiny logo + short statement + thin CTA, almost no image, lots of negative space)
|
||||||
|
|
||||||
|
Mini does not mean weak — it means confident restraint.
|
||||||
|
|
||||||
|
### Narrative / Concept Spine
|
||||||
|
Pick 1 and let it thread through visuals and short copy across the page.
|
||||||
|
- Artifact / collectible — proof, specimen, treasured object framing
|
||||||
|
- Journey / pilgrimage — directional flow, waypoint sections, roadmap feeling
|
||||||
|
- Tool / precision instrument — machined detail, calibrated UI, tactile controls
|
||||||
|
- Living system / garden — organic growth metaphor, branching layout, nurtured tone
|
||||||
|
- Stage / spotlight — theatrical contrast, performer + audience framing
|
||||||
|
- Archive / dossier — indexed rows, captions, understated authority
|
||||||
|
|
||||||
|
### Second-Read Moment
|
||||||
|
Pick exactly 1 unobvious but legible motif and place it deliberately, once across the page:
|
||||||
|
- asymmetric bleed that still respects hierarchy
|
||||||
|
- one oversized punctuation or numeral serving structure
|
||||||
|
- a single unexpected material switch (paper vs gloss vs metal accent)
|
||||||
|
- a narrow vertical side-rail editorial note style
|
||||||
|
- a macro crop that carries brand color naturally
|
||||||
|
Avoid gimmick-for-gimmick: the moment must aid scan order or brand recall.
|
||||||
|
|
||||||
|
Important:
|
||||||
|
These are not coding instructions.
|
||||||
|
They are visual-direction cues the generated design should imply.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. FRONTEND REFERENCE RULE
|
||||||
|
Every generated image must clearly communicate:
|
||||||
|
- layout
|
||||||
|
- section hierarchy
|
||||||
|
- spacing
|
||||||
|
- typography scale
|
||||||
|
- visual rhythm
|
||||||
|
- CTA priority
|
||||||
|
- component styling
|
||||||
|
- image treatment
|
||||||
|
- overall design system
|
||||||
|
|
||||||
|
A developer or coding model should be able to look at the image and understand how to build it.
|
||||||
|
|
||||||
|
Do not produce vague abstract artwork when the request is for frontend.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. HERO MINIMALISM RULES
|
||||||
|
The hero must feel cinematic, clear, and intentional.
|
||||||
|
|
||||||
|
### Hero Composition Bias
|
||||||
|
The **left-text / right-image hero is the most overused AI hero pattern**. It is allowed, but it should not be your default starting point.
|
||||||
|
|
||||||
|
Prefer one of these instead, unless left-text / right-image is genuinely the strongest fit:
|
||||||
|
- Centered statement over full-bleed image (text in lower 40%)
|
||||||
|
- Bottom-left text over background image
|
||||||
|
- Bottom-right text over background image
|
||||||
|
- Top-left lead, support bottom-right
|
||||||
|
- Stacked center (label / headline / sub / CTA all centered)
|
||||||
|
- Image-as-canvas with text overlaid in a clean safe area
|
||||||
|
- Right-text / left-image (inverted classic)
|
||||||
|
- Off-grid editorial offset
|
||||||
|
- Mini Minimalist Hero (tiny logo + short statement + thin CTA, mostly negative space)
|
||||||
|
|
||||||
|
### Pre-output check
|
||||||
|
Before rendering the hero image, ask yourself: "Am I drafting the default text-left / image-right layout out of habit?" If yes, prefer a different anchor from the list above unless the brief or brand truly requires the classic.
|
||||||
|
|
||||||
|
### Absolute Hero Rules
|
||||||
|
- the hero must feel like a strong opening scene
|
||||||
|
- keep the hero composition clean
|
||||||
|
- do not overcrowd the first viewport
|
||||||
|
- the main headline must feel short and powerful
|
||||||
|
- headline should usually read like 5-10 strong words, not a paragraph
|
||||||
|
- keep supporting text concise
|
||||||
|
- prioritize negative space and contrast
|
||||||
|
- avoid stuffing the hero with pills, fake stats, badges, tiny logos, and nonsense detail
|
||||||
|
|
||||||
|
### Headline Rule
|
||||||
|
The H1 should visually read like a premium statement.
|
||||||
|
Do not let it feel long, weak, or overly wrapped.
|
||||||
|
|
||||||
|
### Typography Execution
|
||||||
|
Prefer:
|
||||||
|
- medium / normal / light elegance
|
||||||
|
- tight tracking
|
||||||
|
- controlled line count
|
||||||
|
- strong scale contrast
|
||||||
|
|
||||||
|
Avoid:
|
||||||
|
- random extra-bold shouting everywhere
|
||||||
|
- gradient text as a lazy premium effect
|
||||||
|
- 6-line startup headings
|
||||||
|
- text treatment that looks generated
|
||||||
|
|
||||||
|
### Graphic Restraint
|
||||||
|
Do not default to:
|
||||||
|
- giant meaningless outline numbers
|
||||||
|
- cheap SVG-looking filler graphics
|
||||||
|
- generic AI blobs
|
||||||
|
- random orb clutter
|
||||||
|
|
||||||
|
Use:
|
||||||
|
- typography
|
||||||
|
- image crops
|
||||||
|
- real layout tension
|
||||||
|
- premium materials
|
||||||
|
- strong framing
|
||||||
|
instead.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. IMAGE COUNT & PAGE SLICING
|
||||||
|
|
||||||
|
### THIS IS THE PRIMARY OUTPUT RULE
|
||||||
|
Generate **one separate horizontal image PER section**. Always.
|
||||||
|
|
||||||
|
- never combine multiple sections in a single image
|
||||||
|
- never return a single tall slice that contains the whole page
|
||||||
|
- never return one "best" image and skip the rest
|
||||||
|
- never replace several sections with one collage
|
||||||
|
|
||||||
|
If the request is ambiguous about section count, **default high**:
|
||||||
|
- "hero" -> 1 image
|
||||||
|
- "landing page" / "site template" -> default to 6 sections -> 6 images
|
||||||
|
- "full website" -> default to 8 sections -> 8 images
|
||||||
|
- "marketing site" -> default to 8 sections -> 8 images
|
||||||
|
- "product page" -> default to 6 sections -> 6 images
|
||||||
|
- "portfolio" -> default to 6 sections -> 6 images
|
||||||
|
|
||||||
|
If the model can only render one image per call, generate them **sequentially in the same response**, one after the other, labeled "Section X of N: <name>" until the full set is delivered.
|
||||||
|
|
||||||
|
### Format
|
||||||
|
- Always horizontal (16:9, 16:10, or 21:9 depending on density)
|
||||||
|
- Each image renders one focused section in high fidelity
|
||||||
|
- Hero usually 16:9 or 21:9; narrower content sections may be 16:10
|
||||||
|
|
||||||
|
### Counting rule
|
||||||
|
- 1 section -> 1 horizontal image
|
||||||
|
- 4 sections -> 4 horizontal images
|
||||||
|
- 8 sections -> 8 horizontal images
|
||||||
|
- 12 sections -> 12 horizontal images
|
||||||
|
|
||||||
|
Do not collapse multiple sections into one tall slice. Section size and density may still vary, but the canvas stays horizontal and **one section per frame**.
|
||||||
|
|
||||||
|
### Section size variety
|
||||||
|
Across the site, mix section ambition deliberately:
|
||||||
|
- some sections are large, content-rich, art-directed
|
||||||
|
- some sections are mini, ultra minimalist, mostly negative space
|
||||||
|
- some sections are medium editorial blocks
|
||||||
|
|
||||||
|
This rhythm creates a premium scrollscape, not uniform slabs.
|
||||||
|
|
||||||
|
### Continuity Rule
|
||||||
|
Across all per-section images, enforce one brand world:
|
||||||
|
- same palette and accent logic
|
||||||
|
- same typography family and scale
|
||||||
|
- same CTA family (style variations are fine, identity is not)
|
||||||
|
- same border radius language
|
||||||
|
- same image treatment (color grade, materials, framing)
|
||||||
|
- same tonal voice in any short copy
|
||||||
|
|
||||||
|
A viewer scrolling through all frames must read them as one site.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. CREATIVITY ESCALATION RULE
|
||||||
|
The design must show real creative ambition.
|
||||||
|
|
||||||
|
Do not settle for the first obvious layout solution.
|
||||||
|
Push the work beyond generic SaaS patterns.
|
||||||
|
|
||||||
|
Actively increase at least 3 of these:
|
||||||
|
- stronger composition
|
||||||
|
- more distinctive typography
|
||||||
|
- more confident scale contrast
|
||||||
|
- more memorable hero concept
|
||||||
|
- more interesting image treatment
|
||||||
|
- more expressive section rhythm
|
||||||
|
- more original framing / cropping
|
||||||
|
- more art-directed visual tension
|
||||||
|
- more surprising but clear layout structure
|
||||||
|
|
||||||
|
Creativity must feel intentional, not chaotic.
|
||||||
|
|
||||||
|
Do:
|
||||||
|
- make bold but controlled design decisions
|
||||||
|
- use asymmetry when it improves the page
|
||||||
|
- create visual moments that feel premium and memorable
|
||||||
|
- make the page feel designed, not auto-generated
|
||||||
|
|
||||||
|
Do not:
|
||||||
|
- default to safe template layouts
|
||||||
|
- repeat the same block structure too often
|
||||||
|
- confuse creativity with clutter
|
||||||
|
- make the page overly dense
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. IMAGE-FIRST ART DIRECTION
|
||||||
|
This skill must actively use images.
|
||||||
|
|
||||||
|
Images are not optional decoration.
|
||||||
|
Images are a core part of the frontend design language.
|
||||||
|
|
||||||
|
Strongly prefer:
|
||||||
|
- art-directed photography
|
||||||
|
- product imagery
|
||||||
|
- editorial imagery
|
||||||
|
- image crops
|
||||||
|
- framed image panels
|
||||||
|
- layered image compositions
|
||||||
|
- image-led hero sections
|
||||||
|
- image-supported storytelling blocks
|
||||||
|
|
||||||
|
Use images to:
|
||||||
|
- create visual hierarchy
|
||||||
|
- break up text-heavy layouts
|
||||||
|
- build mood and brand character
|
||||||
|
- support section transitions
|
||||||
|
- make the design easier to interpret and implement
|
||||||
|
|
||||||
|
Important:
|
||||||
|
- the design should not become text-only or card-only unless the user explicitly wants that
|
||||||
|
- if a page has multiple sections, several sections should meaningfully include imagery
|
||||||
|
- if a hero exists, it should usually contain a strong visual image, product visual, or art-directed media element
|
||||||
|
- imagery should feel premium and intentional, not like stock filler
|
||||||
|
|
||||||
|
Avoid:
|
||||||
|
- tiny useless thumbnails
|
||||||
|
- random decorative images with no structural role
|
||||||
|
- one single image and then a completely text-heavy rest of page
|
||||||
|
- overusing fake UI panels instead of real visual variety
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. ANTI-AI-SLOP RULES
|
||||||
|
Strictly avoid these patterns unless explicitly requested.
|
||||||
|
|
||||||
|
### Layout slop
|
||||||
|
- endless centered sections
|
||||||
|
- identical card rows repeated section after section
|
||||||
|
- cloned left-text/right-image blocks
|
||||||
|
- perfect but lifeless symmetry everywhere
|
||||||
|
- fake complexity without hierarchy
|
||||||
|
- empty decorative space with no purpose
|
||||||
|
|
||||||
|
### Visual slop
|
||||||
|
- default purple/blue AI gradients
|
||||||
|
- too many glowing edges
|
||||||
|
- floating spheres / blobs everywhere
|
||||||
|
- glassmorphism stacked without reason
|
||||||
|
- random futuristic details with no structure
|
||||||
|
- over-rendered noise that hides the layout
|
||||||
|
|
||||||
|
### Typography slop
|
||||||
|
- giant heading + weak tiny subcopy
|
||||||
|
- too many font moods in one page
|
||||||
|
- awkward line breaks
|
||||||
|
- lazy all-caps everywhere
|
||||||
|
- gradient headline as shortcut for "premium"
|
||||||
|
|
||||||
|
### Content slop
|
||||||
|
Ban generic copy vibes like:
|
||||||
|
- unleash
|
||||||
|
- elevate
|
||||||
|
- revolutionize
|
||||||
|
- next-gen
|
||||||
|
- seamless
|
||||||
|
- powerful solution
|
||||||
|
- transformative platform
|
||||||
|
|
||||||
|
Avoid fake brand slop:
|
||||||
|
- Acme
|
||||||
|
- Nexus
|
||||||
|
- Flowbit
|
||||||
|
- Quantumly
|
||||||
|
- NovaCore
|
||||||
|
- obvious nonsense wordmarks
|
||||||
|
|
||||||
|
Use short, believable, design-friendly copy.
|
||||||
|
|
||||||
|
### Density slop
|
||||||
|
- no over-packed sections
|
||||||
|
- no card overload in every block
|
||||||
|
- no tiny spacing between major sections
|
||||||
|
- no trying to fill every empty area
|
||||||
|
- no visually exhausting wall-of-content layouts
|
||||||
|
|
||||||
|
### Carousel / marquee slop (layout)
|
||||||
|
- infinity logo strips repeating the same 6 blobs
|
||||||
|
- “trusted by” ticker that is unreadable mosquito logos
|
||||||
|
- auto-play-style hero dots with no semantic purpose
|
||||||
|
|
||||||
|
### Data / KPI slop
|
||||||
|
- three identical stat columns (99% satisfaction, $10 saved, ∞ scale) unless user asked for KPIs
|
||||||
|
- fake dashboards with pointless charts shading the real layout
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 9. TYPOGRAPHY-FIRST DISCIPLINE
|
||||||
|
Typography is not filler.
|
||||||
|
Typography is a primary design material.
|
||||||
|
|
||||||
|
Always ensure:
|
||||||
|
- clear size contrast
|
||||||
|
- obvious reading order
|
||||||
|
- strong display moments
|
||||||
|
- supporting text that is readable and brief
|
||||||
|
- labels, captions, and section headings that reinforce structure
|
||||||
|
|
||||||
|
For editorial directions:
|
||||||
|
- let typography shape composition
|
||||||
|
|
||||||
|
For tech/product directions:
|
||||||
|
- let typography communicate trust and precision
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 10. SECTION RHYTHM RULE
|
||||||
|
A high-end site does not feel like repeated boxes.
|
||||||
|
|
||||||
|
Vary section rhythm across the page by changing:
|
||||||
|
- density
|
||||||
|
- image-to-text ratio
|
||||||
|
- alignment
|
||||||
|
- scale
|
||||||
|
- whitespace
|
||||||
|
- card grouping
|
||||||
|
- background intensity
|
||||||
|
- visual tempo
|
||||||
|
|
||||||
|
Do not let every section feel generated from the same template.
|
||||||
|
|
||||||
|
Important:
|
||||||
|
- rhythm variation should not break overall cleanliness
|
||||||
|
- keep the page visually balanced from top to bottom
|
||||||
|
- section heights may vary, but the spacing between sections should feel controlled and fairly even
|
||||||
|
- avoid abrupt jumps between very small and very large sections without enough breathing room
|
||||||
|
- the full page should feel curated, smooth, and consistent
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 11. COMPONENT EXECUTION GUIDELINES
|
||||||
|
|
||||||
|
### Diagonal Staggered Square Masonry
|
||||||
|
Use square image or content blocks with strong staggered vertical rhythm.
|
||||||
|
Should feel curated and graphic, not messy.
|
||||||
|
|
||||||
|
### 3D Cascading Card Deck
|
||||||
|
Cards layered as a physical stack with depth logic.
|
||||||
|
Should feel premium and tactile, not gimmicky.
|
||||||
|
|
||||||
|
### Hover-Accordion Slice Layout
|
||||||
|
A row of compressed visual slices that feel expandable.
|
||||||
|
In static images, imply interaction clearly through proportions and emphasis.
|
||||||
|
|
||||||
|
### Pristine Gapless Bento Grid
|
||||||
|
Mathematically clean grid.
|
||||||
|
No accidental gaps.
|
||||||
|
Mix large visual blocks with smaller dense information panels.
|
||||||
|
|
||||||
|
### Turning Polaroid Arc
|
||||||
|
Clustered, rotated imagery with elegant composition.
|
||||||
|
Should feel styled and intentional, not scrapbook-random.
|
||||||
|
|
||||||
|
### Off-Grid Editorial Layout
|
||||||
|
Use asymmetry and tension with control.
|
||||||
|
Must remain readable and clearly structured.
|
||||||
|
|
||||||
|
### Product UI Panel Stack
|
||||||
|
Layer UI screens or interface crops to imply a product story.
|
||||||
|
Avoid generic fake dashboards.
|
||||||
|
|
||||||
|
### Vertical Rhythm Lines
|
||||||
|
Use fine lines and spacing systems to reinforce order and elegance.
|
||||||
|
Never let them become decorative clutter.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 12. DENSITY & SPACING DISCIPLINE
|
||||||
|
Do not make everything too dense.
|
||||||
|
|
||||||
|
The page should breathe.
|
||||||
|
Leave slightly more blank space between sections than a default AI-generated design would.
|
||||||
|
|
||||||
|
Rules:
|
||||||
|
- use more even vertical spacing between major sections
|
||||||
|
- keep section-to-section spacing consistent unless there is a strong design reason not to
|
||||||
|
- avoid one section feeling very cramped while the next feels too empty
|
||||||
|
- prefer a clean, balanced cadence across the page
|
||||||
|
- allow negative space to create rhythm and emphasis
|
||||||
|
- separate denser sections with calmer sections
|
||||||
|
- avoid stacking too many cards, labels, and content blocks too tightly
|
||||||
|
- smaller sections should still receive enough surrounding space so the page feels polished and intentional
|
||||||
|
|
||||||
|
A premium page should feel:
|
||||||
|
- open
|
||||||
|
- composed
|
||||||
|
- balanced
|
||||||
|
- confident
|
||||||
|
- breathable
|
||||||
|
|
||||||
|
Not:
|
||||||
|
- cramped
|
||||||
|
- noisy
|
||||||
|
- uneven
|
||||||
|
- overfilled
|
||||||
|
- visually exhausted
|
||||||
|
|
||||||
|
Section rhythm should alternate with control:
|
||||||
|
- some sections can be more content-rich
|
||||||
|
- some sections can be smaller and calmer
|
||||||
|
- but the overall spacing cadence should still feel even, clean, and deliberate
|
||||||
|
|
||||||
|
Whitespace is a design tool.
|
||||||
|
Use it deliberately.
|
||||||
|
Do not let spacing become random.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 13. COLOR & MATERIAL RULES
|
||||||
|
|
||||||
|
### Palette Discipline
|
||||||
|
Use one controlled palette across the entire site:
|
||||||
|
- 1 primary (brand anchor)
|
||||||
|
- 1 secondary (supporting tone)
|
||||||
|
- 1 accent (used sparingly for CTA / highlight)
|
||||||
|
- a neutral scale (background, surface, text, hairline)
|
||||||
|
|
||||||
|
Section-level mood shifts must reuse the same palette — no full theme swap per section.
|
||||||
|
|
||||||
|
### Background-image harmony
|
||||||
|
When using full-bleed image backgrounds:
|
||||||
|
- the image must tonally match the palette (not fight it)
|
||||||
|
- use overlays (dark, light, or color tint) to keep text fully readable
|
||||||
|
- the brand accent stays consistent regardless of background image
|
||||||
|
|
||||||
|
### Gradient Discipline
|
||||||
|
Gradients are **allowed and encouraged** when professional and subtle. They are not the same as AI slop gradients.
|
||||||
|
|
||||||
|
Allowed (use confidently):
|
||||||
|
- low-chroma palette-matched tonal gradients (e.g. ink to graphite, cream to sand, ivory to warm grey)
|
||||||
|
- single-hue atmospheric grades behind hero photography
|
||||||
|
- soft vignettes and radial depth that direct the eye
|
||||||
|
- noise-textured gradients adding tactile depth without color noise
|
||||||
|
- editorial color washes that match brand mood
|
||||||
|
|
||||||
|
Banned (AI gradient slop):
|
||||||
|
- rainbow / mesh blob gradients
|
||||||
|
- purple-to-blue "AI" defaults
|
||||||
|
- pink-to-orange "creator" defaults
|
||||||
|
- neon edges and glow halos with no purpose
|
||||||
|
- gradient text as a shortcut for "premium"
|
||||||
|
- gradients that compete with imagery instead of supporting it
|
||||||
|
|
||||||
|
### Background Confidence Rule
|
||||||
|
Do not retreat to plain white surfaces by default. When the brief, brand mood, or section job calls for atmosphere, use:
|
||||||
|
- a full-bleed image,
|
||||||
|
- a duotone or graded photo,
|
||||||
|
- a tonal gradient,
|
||||||
|
- a tactile material,
|
||||||
|
or a confident flat color field — picked deliberately, not as decoration.
|
||||||
|
|
||||||
|
### Strong guidance
|
||||||
|
- avoid rainbow randomness
|
||||||
|
- avoid over-neon unless requested
|
||||||
|
- keep contrast intentional
|
||||||
|
- match accent colors to the chosen theme paradigm
|
||||||
|
- gradients must always read as professional and intentional, never as visual noise
|
||||||
|
|
||||||
|
### Materiality
|
||||||
|
Where appropriate, add:
|
||||||
|
- paper feel
|
||||||
|
- glass feel
|
||||||
|
- brushed metal feel
|
||||||
|
- soft blur depth
|
||||||
|
- tactile matte surfaces
|
||||||
|
- editorial photo treatment
|
||||||
|
|
||||||
|
But always keep the frontend structure readable.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 14. IMAGE / MEDIA DIRECTION
|
||||||
|
If imagery is present, it must support the layout.
|
||||||
|
|
||||||
|
Allowed:
|
||||||
|
- art-directed product visuals
|
||||||
|
- refined editorial photography
|
||||||
|
- UI crops
|
||||||
|
- abstract forms with structural purpose
|
||||||
|
- framed objects
|
||||||
|
- premium texture use
|
||||||
|
- campaign-style visuals
|
||||||
|
|
||||||
|
Avoid:
|
||||||
|
- irrelevant scenery
|
||||||
|
- stock-photo cliches
|
||||||
|
- decorative junk
|
||||||
|
- visuals that overpower the page hierarchy
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 15. DEFAULT SITE PACKS
|
||||||
|
|
||||||
|
### 4-section pack
|
||||||
|
1. Hero
|
||||||
|
2. Features
|
||||||
|
3. Social proof / testimonial
|
||||||
|
4. CTA
|
||||||
|
|
||||||
|
### 8-section pack
|
||||||
|
1. Hero
|
||||||
|
2. Trust bar
|
||||||
|
3. Features
|
||||||
|
4. Product showcase
|
||||||
|
5. Benefits / use cases
|
||||||
|
6. Testimonials
|
||||||
|
7. Pricing
|
||||||
|
8. CTA
|
||||||
|
|
||||||
|
### 12-section pack
|
||||||
|
1. Hero
|
||||||
|
2. Trust bar
|
||||||
|
3. Feature grid
|
||||||
|
4. Product preview
|
||||||
|
5. Problem / solution
|
||||||
|
6. Benefits
|
||||||
|
7. Workflow
|
||||||
|
8. Metrics / proof / integration
|
||||||
|
9. Testimonials
|
||||||
|
10. Pricing
|
||||||
|
11. FAQ
|
||||||
|
12. CTA + footer
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 16. MULTI-IMAGE CONSISTENCY RULE
|
||||||
|
Because every section is its own image, consistency is critical. Across all per-section frames enforce:
|
||||||
|
- same brand world
|
||||||
|
- same type scale logic
|
||||||
|
- same spacing discipline
|
||||||
|
- same CTA family (style variations are fine, identity is not)
|
||||||
|
- same icon or illustration mood
|
||||||
|
- same image treatment (grade, framing, material vocabulary)
|
||||||
|
- same tonal language in any copy
|
||||||
|
|
||||||
|
Variation IS allowed in:
|
||||||
|
- composition anchor (per section)
|
||||||
|
- background mode (per section)
|
||||||
|
- section size and density
|
||||||
|
- which "second-read" moment appears
|
||||||
|
|
||||||
|
A viewer flipping through every per-section frame must still recognize one brand. Anything that breaks brand recall is over-variation.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 17. CLARITY CHECK
|
||||||
|
Before finalizing, verify internally:
|
||||||
|
|
||||||
|
1. Is the hierarchy obvious?
|
||||||
|
2. Is the hero clean enough?
|
||||||
|
3. Is the design visually distinctive?
|
||||||
|
4. Is it free of obvious AI tells?
|
||||||
|
5. Is it premium rather than template-like?
|
||||||
|
6. Can someone code from this?
|
||||||
|
7. If multiple images exist, do they clearly belong together?
|
||||||
|
8. Is imagery used strongly enough (with variation, not one repeated crop)?
|
||||||
|
9. Does the page breathe, or is it too dense?
|
||||||
|
10. Is there enough spacing between sections?
|
||||||
|
11. Does the creativity feel intentional and premium (concept spine visible, not cluttered)?
|
||||||
|
12. Is the spacing between sections even and controlled?
|
||||||
|
13. Do smaller sections still have enough surrounding space to feel clean?
|
||||||
|
14. Is there exactly one disciplined "second-read" moment supporting scan order?
|
||||||
|
15. Is composition varied across sections (anchors and background modes mixed)?
|
||||||
|
16. Is the hero scale (giant / mid / mini) chosen and executed cleanly?
|
||||||
|
17. Is there a clear conversion path (hook -> proof -> action) even in artistic sites?
|
||||||
|
18. Is the palette consistent across all per-section images?
|
||||||
|
19. Is each image horizontal and one-section-only?
|
||||||
|
20. Is the **total number of images equal to the number of sections** (never fewer)?
|
||||||
|
21. Is the hero using a varied composition (not defaulting to left-text / right-image out of habit)?
|
||||||
|
|
||||||
|
If not, refine internally before output. If the count is wrong, regenerate the missing sections. If the hero feels like a reflexive left-text / right-image default, prefer a different composition anchor.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 18. EXTRA CREATIVITY & IMPLEMENTATION EDGE
|
||||||
|
|
||||||
|
Apply unless the user opts out:
|
||||||
|
|
||||||
|
### Cross-section contrast
|
||||||
|
Across the slice, deliberately vary foreground/background intensity at least twice (lighter → richer → calmer) so the scroll feels paced, not monotonous slabs.
|
||||||
|
|
||||||
|
### CTA specificity
|
||||||
|
Prefer one unmistakable primary action per major viewport tier; secondary actions must look secondary (scale, outline, ghost), not clones of primary.
|
||||||
|
|
||||||
|
### Image variety inside one comp
|
||||||
|
Mix at least **two distinct image crops** where multiple sections exist — e.g. macro product + contextual environment, or portrait editorial + widescreen artifact — avoiding one repeated stock silhouette.
|
||||||
|
|
||||||
|
### Data-viz restraint
|
||||||
|
Charts, sparklines, and graphs appear only when the site type logically needs them (analytics, pricing, infra, observability brands). Else keep proof human (quotes, receipts, timelines, screenshots of real workflows).
|
||||||
|
|
||||||
|
### Cultural / tonal alignment
|
||||||
|
When the brief names an industry or region, steer palette and typographic temperament to match — don’t ship default “neutral SF startup” unless the brief is intentionally generic SaaS.
|
||||||
|
|
||||||
|
### Mobile-implied fidelity (even for desktop mocks)
|
||||||
|
Maintain tap-friendly hit sizes and readable caption sizes visually; stacking order should imply a sane single-column narrative.
|
||||||
|
|
||||||
|
### Conversion focus
|
||||||
|
Each section has a job. Even when the design is artistic, the page must read as a real product or brand site:
|
||||||
|
- the hero communicates value in seconds and offers one obvious next action
|
||||||
|
- proof sections (logos, quotes, metrics) feel earned, not stuffed
|
||||||
|
- pricing or CTA sections feel decisive, not buried
|
||||||
|
- the final section closes: a single strong CTA + supporting trust cue
|
||||||
|
Avoid pure mood reels with no funnel logic.
|
||||||
|
|
||||||
|
### Composition variety check
|
||||||
|
Across all per-section images, internally log the chosen composition anchor and background mode. Reject the set if:
|
||||||
|
- the same composition anchor repeats more than 2 sections in a row
|
||||||
|
- the same background mode repeats more than 3 sections in a row
|
||||||
|
- every section is inline-asset (no full-bleed background ever appears) **AND** the brief does not call for minimalism / typography-only / swiss / ultra simple
|
||||||
|
|
||||||
|
For non-minimalist briefs: push for at least one full-bleed (or duotone / atmospheric) background and at least one mini minimalist section in any multi-section site.
|
||||||
|
|
||||||
|
For minimalist briefs: this rule is suspended. Restraint is the design.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 19. RESPONSE BEHAVIOR
|
||||||
|
When the user asks for a frontend design:
|
||||||
|
1. infer site type and primary conversion goal
|
||||||
|
2. infer number of sections (if unclear, use the defaults from §5: landing page = 6, full website = 8)
|
||||||
|
3. **commit out loud** to the section count and announce it ("Generating N horizontal images, one per section")
|
||||||
|
4. plan ONE horizontal image PER SECTION — always separate generations, never collapse
|
||||||
|
5. choose Hero Scale for the whole site (giant / mid / mini)
|
||||||
|
5. choose a strong visual combination (theme, type, hero arch, section system, motion, narrative spine, second-read moment)
|
||||||
|
7. for each section: pick a Composition Anchor, Background Mode, and CTA Variation — vary across sections
|
||||||
|
8. choose 4 signature components used appropriately across sections
|
||||||
|
9. enforce hero minimalism + section size variety (some giant, some mini)
|
||||||
|
10. enforce strong image usage including full-bleed backgrounds where it fits
|
||||||
|
11. lock one consistent palette across all images
|
||||||
|
12. apply §18 EXTRA CREATIVITY & IMPLEMENTATION EDGE
|
||||||
|
13. keep spacing generous, even, and clean
|
||||||
|
14. remove AI slop (including marquee / fake KPI clichés unless requested)
|
||||||
|
15. run §17 CLARITY CHECK
|
||||||
|
16. **generate every per-section horizontal image, labeled "Section X of N: <name>"**, until the full set is delivered. Do not stop early. Do not summarize. Do not return only one image.
|
||||||
|
|
||||||
|
Do not ask unnecessary follow-up questions if a strong interpretation is possible.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 20. EXAMPLE INTERPRETATIONS
|
||||||
|
|
||||||
|
### Example 1
|
||||||
|
User: "make a hero section for an AI startup"
|
||||||
|
|
||||||
|
Interpretation:
|
||||||
|
- 1 horizontal image
|
||||||
|
- Hero Scale: Mid Editorial or Giant Statement
|
||||||
|
- Composition Anchor: bottom-left text over full-bleed product/atmosphere image
|
||||||
|
- Background Mode: full-bleed image with dark tonal overlay
|
||||||
|
- CTA Variation: outlined inline + small label hint
|
||||||
|
- Palette: Deep Dark or Bold Studio Solid, one consistent accent
|
||||||
|
- no cliche dashboard spam, no purple AI glow
|
||||||
|
|
||||||
|
### Example 2
|
||||||
|
User: "design 8 sections for a fintech website"
|
||||||
|
|
||||||
|
Interpretation:
|
||||||
|
- 8 separate horizontal images (one per section)
|
||||||
|
- Hero Scale: Mid Editorial (trust-driven)
|
||||||
|
- vary Composition Anchor across sections (centered low, right-third caption, bottom-left over chart visual, stacked center for closing CTA)
|
||||||
|
- Background Mode mix: solid surface, full-bleed image background once, editorial side-image at use cases
|
||||||
|
- one consistent palette (e.g. ink + paper + single brand accent)
|
||||||
|
- conversion path: hook -> proof bar -> features -> use case -> testimonial -> pricing -> FAQ -> final CTA
|
||||||
|
|
||||||
|
### Example 3
|
||||||
|
User: "creative agency landing page, 12 sections"
|
||||||
|
|
||||||
|
Interpretation:
|
||||||
|
- 12 horizontal images (one per section)
|
||||||
|
- Hero Scale: Giant Statement OR Mini Minimalist (decisive choice, not in-between)
|
||||||
|
- editorial / poster-like direction; off-grid composition appears 2-3 times
|
||||||
|
- multiple Background Modes (full-bleed image at hero + showcase, editorial side-image at case studies, solid + accent for process)
|
||||||
|
- palette consistent throughout, with one bold accent recurring
|
||||||
|
- closing CTA section: mini minimalist, strong type, single primary action
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 21. FINAL GOAL
|
||||||
|
Generate frontend reference images that feel:
|
||||||
|
- artistic
|
||||||
|
- premium
|
||||||
|
- clear
|
||||||
|
- structured
|
||||||
|
- image-led
|
||||||
|
- breathable
|
||||||
|
- memorable
|
||||||
|
- anti-generic
|
||||||
|
- implementation-friendly
|
||||||
|
|
||||||
|
The result should look like a top-tier website concept with strong imagery, confident creativity, and generous spacing - not a dense, repetitive AI layout.
|
||||||
92
skills/taste-skill/skills/industrial-brutalist-ui/SKILL.md
Normal file
92
skills/taste-skill/skills/industrial-brutalist-ui/SKILL.md
Normal file
|
|
@ -0,0 +1,92 @@
|
||||||
|
---
|
||||||
|
name: industrial-brutalist-ui
|
||||||
|
description: Raw mechanical interfaces fusing Swiss typographic print with military terminal aesthetics. Rigid grids, extreme type scale contrast, utilitarian color, analog degradation effects. For data-heavy dashboards, portfolios, or editorial sites that need to feel like declassified blueprints.
|
||||||
|
---
|
||||||
|
|
||||||
|
# SKILL: Industrial Brutalism & Tactical Telemetry UI
|
||||||
|
|
||||||
|
## 1. Skill Meta
|
||||||
|
**Name:** Industrial Brutalism & Tactical Telemetry Interface Engineering
|
||||||
|
**Description:** Advanced proficiency in architecting web interfaces that synthesize mid-century Swiss Typographic design, industrial manufacturing manuals, and retro-futuristic aerospace/military terminal interfaces. This discipline requires absolute mastery over rigid modular grids, extreme typographic scale contrast, purely utilitarian color palettes, and the programmatic simulation of analog degradation (halftones, CRT scanlines, bitmap dithering). The objective is to construct digital environments that project raw functionality, mechanical precision, and high data density, deliberately discarding conventional consumer UI patterns.
|
||||||
|
|
||||||
|
## 2. Visual Archetypes
|
||||||
|
The design system operates by merging two distinct but highly compatible visual paradigms. **Pick ONE per project and commit to it. Do not alternate or mix both modes within the same interface.**
|
||||||
|
|
||||||
|
### 2.1 Swiss Industrial Print
|
||||||
|
Derived from 1960s corporate identity systems and heavy machinery blueprints.
|
||||||
|
* **Characteristics:** High-contrast light modes (newsprint/off-white substrates). Reliance on monolithic, heavy sans-serif typography. Unforgiving structural grids outlined by visible dividing lines. Aggressive, asymmetric use of negative space punctuated by oversized, viewport-bleeding numerals or letterforms. Heavy use of primary red as an alert/accent color.
|
||||||
|
|
||||||
|
### 2.2 Tactical Telemetry & CRT Terminal
|
||||||
|
Derived from classified military databases, legacy mainframes, and aerospace Heads-Up Displays (HUDs).
|
||||||
|
* **Characteristics:** Dark mode exclusivity. High-density tabular data presentation. Absolute dominance of monospaced typography. Integration of technical framing devices (ASCII brackets, crosshairs). Application of simulated hardware limitations (phosphor glow, scanlines, low bit-depth rendering).
|
||||||
|
|
||||||
|
## 3. Typographic Architecture
|
||||||
|
Typography is the primary structural and decorative infrastructure. Imagery is secondary. The system demands extreme variance in scale, weight, and spacing.
|
||||||
|
|
||||||
|
### 3.1 Macro-Typography (Structural Headers)
|
||||||
|
* **Classification:** Neo-Grotesque / Heavy Sans-Serif.
|
||||||
|
* **Optimal Web Fonts:** Neue Haas Grotesk (Black), Inter (Extra Bold/Black), Archivo Black, Roboto Flex (Heavy), Monument Extended.
|
||||||
|
* **Implementation Parameters:**
|
||||||
|
* **Scale:** Deployed at massive scales using fluid typography (e.g., `clamp(4rem, 10vw, 15rem)`).
|
||||||
|
* **Tracking (Letter-spacing):** Extremely tight, often negative (`-0.03em` to `-0.06em`), forcing glyphs to form solid architectural blocks.
|
||||||
|
* **Leading (Line-height):** Highly compressed (`0.85` to `0.95`).
|
||||||
|
* **Casing:** Exclusively uppercase for structural impact.
|
||||||
|
|
||||||
|
### 3.2 Micro-Typography (Data & Telemetry)
|
||||||
|
* **Classification:** Monospace / Technical Sans.
|
||||||
|
* **Optimal Web Fonts:** JetBrains Mono, IBM Plex Mono, Space Mono, VT323, Courier Prime.
|
||||||
|
* **Implementation Parameters:**
|
||||||
|
* **Scale:** Fixed and small (`10px` to `14px` / `0.7rem` to `0.875rem`).
|
||||||
|
* **Tracking:** Generous (`0.05em` to `0.1em`) to simulate mechanical typewriter spacing or terminal matrices.
|
||||||
|
* **Leading:** Standard to tight (`1.2` to `1.4`).
|
||||||
|
* **Casing:** Exclusively uppercase. Used for all metadata, navigation, unit IDs, and coordinates.
|
||||||
|
|
||||||
|
### 3.3 Textural Contrast (Artistic Disruption)
|
||||||
|
* **Classification:** High-Contrast Serif.
|
||||||
|
* **Optimal Web Fonts:** Playfair Display, EB Garamond, Times New Roman.
|
||||||
|
* **Implementation Parameters:** Used exceedingly sparingly. Must be subjected to heavy post-processing (halftone filters, 1-bit dithering) to degrade vector perfection and create textural juxtaposition against the clean sans-serifs.
|
||||||
|
|
||||||
|
## 4. Color System
|
||||||
|
The color architecture is uncompromising. Gradients, soft drop shadows, and modern translucency are strictly prohibited. Colors simulate physical media or primitive emissive displays.
|
||||||
|
|
||||||
|
**CRITICAL: Choose ONE substrate palette per project and use it consistently. Never mix light and dark substrates within the same interface.**
|
||||||
|
|
||||||
|
### If Swiss Industrial Print (Light):
|
||||||
|
* **Background:** `#F4F4F0` or `#EAE8E3` (Matte, unbleached documentation paper).
|
||||||
|
* **Foreground:** `#050505` to `#111111` (Carbon Ink).
|
||||||
|
* **Accent:** `#E61919` or `#FF2A2A` (Aviation/Hazard Red). This is the ONLY accent color. Used for strike-throughs, thick structural dividing lines, or vital data highlights.
|
||||||
|
|
||||||
|
### If Tactical Telemetry (Dark):
|
||||||
|
* **Background:** `#0A0A0A` or `#121212` (Deactivated CRT. Avoid pure `#000000`).
|
||||||
|
* **Foreground:** `#EAEAEA` (White phosphor). This is the primary text color.
|
||||||
|
* **Accent:** `#E61919` or `#FF2A2A` (Aviation/Hazard Red). Same red, same rules.
|
||||||
|
* **Terminal Green (`#4AF626`):** Optional. Use ONLY for a single specific UI element (e.g., one status indicator or one data readout) — never as a general text color. If it doesn't serve a clear purpose, omit it entirely.
|
||||||
|
|
||||||
|
## 5. Layout and Spatial Engineering
|
||||||
|
The layout must appear mathematically engineered. It rejects conventional web padding in favor of visible compartmentalization.
|
||||||
|
|
||||||
|
* **The Blueprint Grid:** Strict adherence to CSS Grid architectures. Elements do not float; they are anchored precisely to grid tracks and intersections.
|
||||||
|
* **Visible Compartmentalization:** Extensive utilization of solid borders (`1px` or `2px solid`) to delineate distinct zones of information. Horizontal rules (`<hr>`) frequently span the entire container width to segregate operational units.
|
||||||
|
* **Bimodal Density:** Layouts oscillate between extreme data density (tightly packed monospace metadata clustered together) and vast expanses of calculated negative space framing macro-typography.
|
||||||
|
* **Geometry:** Absolute rejection of `border-radius`. All corners must be exactly 90 degrees to enforce mechanical rigidity.
|
||||||
|
|
||||||
|
## 6. UI Components and Symbology
|
||||||
|
Standard web UI conventions are replaced with utilitarian, industrial graphic elements.
|
||||||
|
|
||||||
|
* **Syntax Decoration:** Utilization of ASCII characters to frame data points.
|
||||||
|
* *Framing:* `[ DELIVERY SYSTEMS ]`, `< RE-IND >`
|
||||||
|
* *Directional:* `>>>`, `///`, `\\\\`
|
||||||
|
* **Industrial Markers:** Prominent integration of registration (`®`), copyright (`©`), and trademark (`™`) symbols functioning as structural geometric elements rather than legal text.
|
||||||
|
* **Technical Assets:** Integration of crosshairs (`+`) at grid intersections, repeating vertical lines (barcodes), thick horizontal warning stripes, and randomized string data (e.g., `REV 2.6`, `UNIT / D-01`) to simulate active mechanical processes.
|
||||||
|
|
||||||
|
## 7. Textural and Post-Processing Effects
|
||||||
|
To prevent the design from appearing purely digital, simulated analog degradation is engineered into the frontend via CSS and SVG filters.
|
||||||
|
|
||||||
|
* **Halftone and 1-Bit Dithering:** Transforming continuous-tone images or large serif typography into dot-matrix patterns. Achieved via pre-processing or CSS `mix-blend-mode: multiply` overlays combined with SVG radial dot patterns.
|
||||||
|
* **CRT Scanlines:** For terminal interfaces, applying a `repeating-linear-gradient` to the background to simulate horizontal electron beam sweeps (e.g., `repeating-linear-gradient(0deg, transparent, transparent 2px, rgba(0,0,0,0.1) 2px, rgba(0,0,0,0.1) 4px)`).
|
||||||
|
* **Mechanical Noise:** A global, low-opacity SVG static/noise filter applied to the DOM root to introduce a unified physical grain across both dark and light modes.
|
||||||
|
|
||||||
|
## 8. Web Engineering Directives
|
||||||
|
1. **Grid Determinism:** Utilize `display: grid; gap: 1px;` with contrasting parent/child background colors to generate mathematically perfect, razor-thin dividing lines without complex border declarations.
|
||||||
|
2. **Semantic Rigidity:** Construct the DOM using precise semantic tags (`<data>`, `<samp>`, `<kbd>`, `<output>`, `<dl>`) to accurately reflect the technical nature of the telemetry.
|
||||||
|
3. **Typography Clamping:** Implement CSS `clamp()` functions exclusively for macro-typography to ensure massive text scales aggressively while maintaining structural integrity across viewports.
|
||||||
13
skills/taste-skill/skills/llms.txt
Normal file
13
skills/taste-skill/skills/llms.txt
Normal file
|
|
@ -0,0 +1,13 @@
|
||||||
|
taste-skill: The default design skill (v2 experimental). Read the brief, infer the design language, tune three dials (VARIANCE / MOTION / DENSITY), and ship landing pages, portfolios, and redesigns that do not look templated. Brief inference, design-system map, em-dash ban, GSAP code skeletons, hard-rules pre-flight check. Actively iterating toward v2.0.0 stable.
|
||||||
|
taste-skill-v1: The original v1 of taste-skill, preserved for projects depending on its exact behavior. The current default is `design-taste-frontend` (v2 experimental).
|
||||||
|
gpt-taste: Elite Awwwards-level frontend design and GSAP motion skill for premium, deterministic, anti-slop UI generation.
|
||||||
|
image-to-code-skill: Image-first frontend skill for generating premium website references, deeply analyzing them, and implementing code to match.
|
||||||
|
imagegen-frontend-web: Image-generation-only skill for creating premium website design reference images. Does not write code.
|
||||||
|
imagegen-frontend-mobile: Image-generation-only skill for creating premium mobile app screen concepts and flows. Does not write code.
|
||||||
|
brandkit: Image-generation-only skill for creating premium brand-kit overview images with logo concepts, identity systems, color palettes, typography, and mockups. Does not write code.
|
||||||
|
redesign-skill: For upgrading existing projects by auditing and fixing design problems.
|
||||||
|
soft-skill: Focuses on an expensive, soft UI look with premium fonts, whitespace, depth, and smooth animations.
|
||||||
|
output-skill: Prevents AI from being lazy, skipping code blocks, or using placeholder comments.
|
||||||
|
minimalist-skill: Enforces clean, editorial-style interfaces (Notion/Linear style) with strict monochrome palettes.
|
||||||
|
brutalist-skill: Raw mechanical interfaces, Swiss typography, extreme scale contrast. (Beta)
|
||||||
|
stitch-skill: Google Stitch-compatible semantic design rules for premium AI UI generation.
|
||||||
85
skills/taste-skill/skills/minimalist-ui/SKILL.md
Normal file
85
skills/taste-skill/skills/minimalist-ui/SKILL.md
Normal file
|
|
@ -0,0 +1,85 @@
|
||||||
|
---
|
||||||
|
name: minimalist-ui
|
||||||
|
description: Clean editorial-style interfaces. Warm monochrome palette, typographic contrast, flat bento grids, muted pastels. No gradients, no heavy shadows.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Protocol: Premium Utilitarian Minimalism UI Architect
|
||||||
|
|
||||||
|
## 1. Protocol Overview
|
||||||
|
Name: Premium Utilitarian Minimalism & Editorial UI
|
||||||
|
Description: An advanced frontend engineering directive for generating highly refined, ultra-minimalist, "document-style" web interfaces analogous to top-tier workspace platforms. This protocol strictly enforces a high-contrast warm monochrome palette, bespoke typographic hierarchies, meticulous structural macro-whitespace, bento-grid layouts, and an ultra-flat component architecture with deliberate muted pastel accents. It actively rejects standard generic SaaS design trends.
|
||||||
|
|
||||||
|
## 2. Absolute Negative Constraints (Banned Elements)
|
||||||
|
The AI must strictly avoid the following generic web development defaults:
|
||||||
|
- DO NOT use the "Inter", "Roboto", or "Open Sans" typefaces.
|
||||||
|
- DO NOT use generic, thin-line icon libraries like "Lucide", "Feather", or standard "Heroicons".
|
||||||
|
- DO NOT use Tailwind's default heavy drop shadows (e.g., `shadow-md`, `shadow-lg`, `shadow-xl`). Shadows must be practically non-existent or heavily customized to be ultra-diffuse and low opacity (< 0.05).
|
||||||
|
- DO NOT use primary colored backgrounds for large elements or sections (e.g., no bright blue, green, or red hero sections).
|
||||||
|
- DO NOT use gradients, neon colors, or 3D glassmorphism (beyond subtle navbar blurs).
|
||||||
|
- DO NOT use `rounded-full` (pill shapes) for large containers, cards, or primary buttons.
|
||||||
|
- DO NOT use emojis anywhere in code, markup, text content, headings, or alt text. Replace with proper icons or clean SVG primitives.
|
||||||
|
- DO NOT use generic placeholder names like "John Doe", "Acme Corp", or "Lorem Ipsum". Use realistic, contextual content.
|
||||||
|
- DO NOT use AI copywriting clichés: "Elevate", "Seamless", "Unleash", "Next-Gen", "Game-changer", "Delve". Write plain, specific language.
|
||||||
|
|
||||||
|
## 3. Typographic Architecture
|
||||||
|
The interface must rely on extreme typographic contrast and premium font selection to establish an editorial feel.
|
||||||
|
- Primary Sans-Serif (Body, UI, Buttons): Use clean, geometric, or system-native fonts with character. Target: `font-family: 'SF Pro Display', 'Geist Sans', 'Helvetica Neue', 'Switzer', sans-serif`.
|
||||||
|
- Editorial Serif (Hero Headings & Quotes): Target: `font-family: 'Lyon Text', 'Newsreader', 'Playfair Display', 'Instrument Serif', serif`. Apply tight tracking (`letter-spacing: -0.02em` to `-0.04em`) and tight line-height (`1.1`).
|
||||||
|
- Monospace (Code, Keystrokes, Meta-data): Target: `font-family: 'Geist Mono', 'SF Mono', 'JetBrains Mono', monospace`.
|
||||||
|
- Text Colors: Body text must never be absolute black (`#000000`). Use off-black/charcoal (`#111111` or `#2F3437`) with a generous `line-height` of `1.6` for legibility. Secondary text should be muted gray (`#787774`).
|
||||||
|
|
||||||
|
## 4. Color Palette (Warm Monochrome + Spot Pastels)
|
||||||
|
Color is a scarce resource, utilized only for semantic meaning or subtle accents.
|
||||||
|
- Canvas / Background: Pure White `#FFFFFF` or Warm Bone/Off-White `#F7F6F3` / `#FBFBFA`.
|
||||||
|
- Primary Surface (Cards): `#FFFFFF` or `#F9F9F8`.
|
||||||
|
- Structural Borders / Dividers: Ultra-light gray `#EAEAEA` or `rgba(0,0,0,0.06)`.
|
||||||
|
- Accent Colors: Exclusively use highly desaturated, washed-out pastels for tags, inline code backgrounds, or subtle icon backgrounds.
|
||||||
|
- Pale Red: `#FDEBEC` (Text: `#9F2F2D`)
|
||||||
|
- Pale Blue: `#E1F3FE` (Text: `#1F6C9F`)
|
||||||
|
- Pale Green: `#EDF3EC` (Text: `#346538`)
|
||||||
|
- Pale Yellow: `#FBF3DB` (Text: `#956400`)
|
||||||
|
|
||||||
|
## 5. Component Specifications
|
||||||
|
- Bento Box Feature Grids:
|
||||||
|
- Utilize asymmetrical CSS Grid layouts.
|
||||||
|
- Cards must have exactly `border: 1px solid #EAEAEA`.
|
||||||
|
- Border-radius must be crisp: `8px` or `12px` maximum.
|
||||||
|
- Internal padding must be generous (e.g., `24px` to `40px`).
|
||||||
|
- Primary Call-To-Action (Buttons):
|
||||||
|
- Solid background `#111111`, text `#FFFFFF`.
|
||||||
|
- Slight border-radius (`4px` to `6px`). No box-shadow.
|
||||||
|
- Hover state should be a subtle color shift to `#333333` or a micro-scale `transform: scale(0.98)`.
|
||||||
|
- Tags & Status Badges:
|
||||||
|
- Pill-shaped (`border-radius: 9999px`), very small typography (`text-xs`), uppercase with wide tracking (`letter-spacing: 0.05em`).
|
||||||
|
- Background must use the defined Muted Pastels.
|
||||||
|
- Accordions (FAQ):
|
||||||
|
- Strip all container boxes. Separate items only with a `border-bottom: 1px solid #EAEAEA`.
|
||||||
|
- Use a clean, sharp `+` and `-` icon for the toggle state.
|
||||||
|
- Keystroke Micro-UIs:
|
||||||
|
- Render shortcuts as physical keys using `<kbd>` tags: `border: 1px solid #EAEAEA`, `border-radius: 4px`, `background: #F7F6F3`, using the Monospace font.
|
||||||
|
- Faux-OS Window Chrome:
|
||||||
|
- When mocking up software, wrap it in a minimalist container with a white top bar containing three small, light gray circles (replicating macOS window controls).
|
||||||
|
|
||||||
|
## 6. Iconography & Imagery Directives
|
||||||
|
- System Icons: Use "Phosphor Icons (Bold or Fill weights)" or "Radix UI Icons" for a technical, slightly thicker-stroke aesthetic. Standardize stroke width across all icons.
|
||||||
|
- Illustrations: Monochromatic, rough continuous-line ink sketches on a white background, featuring a single offset geometric shape filled with a muted pastel color.
|
||||||
|
- Photography: Use high-quality, desaturated images with a warm tone. Apply subtle overlays (`opacity: 0.04` warm grain) to blend photos into the monochrome palette. Never use oversaturated stock photos. Use reliable placeholders like `https://picsum.photos/seed/{context}/1200/800` when real assets are unavailable.
|
||||||
|
- Hero & Section Backgrounds: Sections should not feel empty and flat. Use subtle full-width background imagery at very low opacity, soft radial light spots (`radial-gradient` with warm tones at `opacity: 0.03`), or minimal geometric line patterns to add depth without breaking the clean aesthetic.
|
||||||
|
|
||||||
|
## 7. Subtle Motion & Micro-Animations
|
||||||
|
Motion should feel invisible — present but never distracting. The goal is quiet sophistication, not spectacle.
|
||||||
|
- Scroll Entry: Elements fade in gently as they enter the viewport. Use `translateY(12px)` + `opacity: 0` resolving over `600ms` with `cubic-bezier(0.16, 1, 0.3, 1)`. Use `IntersectionObserver`, never `window.addEventListener('scroll')`.
|
||||||
|
- Hover States: Cards lift with an ultra-subtle shadow shift (`box-shadow` transitioning from `0 0 0` to `0 2px 8px rgba(0,0,0,0.04)` over `200ms`). Buttons respond with `scale(0.98)` on `:active`.
|
||||||
|
- Staggered Reveals: Lists and grid items enter with a cascade delay (`animation-delay: calc(var(--index) * 80ms)`). Never mount everything at once.
|
||||||
|
- Background Ambient Motion: Optional. A single, very slow-moving radial gradient blob (`animation-duration: 20s+`, `opacity: 0.02-0.04`) drifting behind hero sections. Must be applied to a `position: fixed; pointer-events: none` layer. Never on scrolling containers.
|
||||||
|
- Performance: Animate exclusively via `transform` and `opacity`. No layout-triggering properties (`top`, `left`, `width`, `height`). Use `will-change: transform` sparingly and only on actively animating elements.
|
||||||
|
|
||||||
|
## 8. Execution Protocol
|
||||||
|
When tasked with writing frontend code (HTML, React, Tailwind, Vue) or designing a layout:
|
||||||
|
1. Establish the macro-whitespace first. Use massive vertical padding between sections (e.g., `py-24` or `py-32` in Tailwind).
|
||||||
|
2. Constrain the main typography content width to `max-w-4xl` or `max-w-5xl`.
|
||||||
|
3. Apply the custom typographic hierarchy and monochromatic color variables immediately.
|
||||||
|
4. Ensure every card, divider, and border adheres strictly to the `1px solid #EAEAEA` rule.
|
||||||
|
5. Add scroll-entry animations to all major content blocks.
|
||||||
|
6. Ensure sections have visual depth through imagery, ambient gradients, or subtle textures — no empty flat backgrounds.
|
||||||
|
7. Provide code that reflects this high-end, uncluttered, editorial aesthetic natively without requiring manual adjustments.
|
||||||
178
skills/taste-skill/skills/redesign-existing-projects/SKILL.md
Normal file
178
skills/taste-skill/skills/redesign-existing-projects/SKILL.md
Normal file
|
|
@ -0,0 +1,178 @@
|
||||||
|
---
|
||||||
|
name: redesign-existing-projects
|
||||||
|
description: Upgrades existing websites and apps to premium quality. Audits current design, identifies generic AI patterns, and applies high-end design standards without breaking functionality. Works with any CSS framework or vanilla CSS.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Redesign Skill
|
||||||
|
|
||||||
|
## How This Works
|
||||||
|
|
||||||
|
When applied to an existing project, follow this sequence:
|
||||||
|
|
||||||
|
1. **Scan** — Read the codebase. Identify the framework, styling method (Tailwind, vanilla CSS, styled-components, etc.), and current design patterns.
|
||||||
|
2. **Diagnose** — Run through the audit below. List every generic pattern, weak point, and missing state you find.
|
||||||
|
3. **Fix** — Apply targeted upgrades working with the existing stack. Do not rewrite from scratch. Improve what's there.
|
||||||
|
|
||||||
|
## Design Audit
|
||||||
|
|
||||||
|
### Typography
|
||||||
|
|
||||||
|
Check for these problems and fix them:
|
||||||
|
|
||||||
|
- **Browser default fonts or Inter everywhere.** Replace with a font that has character. Good options: `Geist`, `Outfit`, `Cabinet Grotesk`, `Satoshi`. For editorial/creative projects, pair a serif header with a sans-serif body.
|
||||||
|
- **Headlines lack presence.** Increase size for display text, tighten letter-spacing, reduce line-height. Headlines should feel heavy and intentional.
|
||||||
|
- **Body text too wide.** Limit paragraph width to roughly 65 characters. Increase line-height for readability.
|
||||||
|
- **Only Regular (400) and Bold (700) weights used.** Introduce Medium (500) and SemiBold (600) for more subtle hierarchy.
|
||||||
|
- **Numbers in proportional font.** Use a monospace font or enable tabular figures (`font-variant-numeric: tabular-nums`) for data-heavy interfaces.
|
||||||
|
- **Missing letter-spacing adjustments.** Use negative tracking for large headers, positive tracking for small caps or labels.
|
||||||
|
- **All-caps subheaders everywhere.** Try lowercase italics, sentence case, or small-caps instead.
|
||||||
|
- **Orphaned words.** Single words sitting alone on the last line. Fix with `text-wrap: balance` or `text-wrap: pretty`.
|
||||||
|
|
||||||
|
### Color and Surfaces
|
||||||
|
|
||||||
|
- **Pure `#000000` background.** Replace with off-black, dark charcoal, or tinted dark (`#0a0a0a`, `#121212`, or a dark navy).
|
||||||
|
- **Oversaturated accent colors.** Keep saturation below 80%. Desaturate accents so they blend with neutrals instead of screaming.
|
||||||
|
- **More than one accent color.** Pick one. Remove the rest. Consistency beats variety.
|
||||||
|
- **Mixing warm and cool grays.** Stick to one gray family. Tint all grays with a consistent hue (warm or cool, not both).
|
||||||
|
- **Purple/blue "AI gradient" aesthetic.** This is the most common AI design fingerprint. Replace with neutral bases and a single, considered accent.
|
||||||
|
- **Generic `box-shadow`.** Tint shadows to match the background hue. Use colored shadows (e.g., dark blue shadow on a blue background) instead of pure black at low opacity.
|
||||||
|
- **Flat design with zero texture.** Add subtle noise, grain, or micro-patterns to backgrounds. Pure flat vectors feel sterile.
|
||||||
|
- **Perfectly even gradients.** Break the uniformity with radial gradients, noise overlays, or mesh gradients instead of standard linear 45-degree fades.
|
||||||
|
- **Inconsistent lighting direction.** Audit all shadows to ensure they suggest a single, consistent light source.
|
||||||
|
- **Random dark sections in a light mode page (or vice versa).** A single dark-background section breaking an otherwise light page looks like a copy-paste accident. Either commit to a full dark mode or keep a consistent background tone throughout. If contrast is needed, use a slightly darker shade of the same palette — not a sudden jump to `#111` in the middle of a cream page.
|
||||||
|
- **Empty, flat sections with no visual depth.** Sections that are just text on a plain background feel unfinished. Add high-quality background imagery (blurred, overlaid, or masked), subtle patterns, or ambient gradients. Use reliable placeholder sources like `https://picsum.photos/seed/{name}/1920/1080` when real assets are not available. Experiment with background images behind hero sections, feature blocks, or CTAs — even a subtle full-width photo at low opacity adds presence.
|
||||||
|
|
||||||
|
### Layout
|
||||||
|
|
||||||
|
- **Everything centered and symmetrical.** Break symmetry with offset margins, mixed aspect ratios, or left-aligned headers over centered content.
|
||||||
|
- **Three equal card columns as feature row.** This is the most generic AI layout. Replace with a 2-column zig-zag, asymmetric grid, horizontal scroll, or masonry layout.
|
||||||
|
- **Using `height: 100vh` for full-screen sections.** Replace with `min-height: 100dvh` to prevent layout jumping on mobile browsers (iOS Safari viewport bug).
|
||||||
|
- **Complex flexbox percentage math.** Replace with CSS Grid for reliable multi-column structures.
|
||||||
|
- **No max-width container.** Add a container constraint (around 1200-1440px) with auto margins so content doesn't stretch edge-to-edge on wide screens.
|
||||||
|
- **Cards of equal height forced by flexbox.** Allow variable heights or use masonry when content varies in length.
|
||||||
|
- **Uniform border-radius on everything.** Vary the radius: tighter on inner elements, softer on containers.
|
||||||
|
- **No overlap or depth.** Elements sit flat next to each other. Use negative margins to create layering and visual depth.
|
||||||
|
- **Symmetrical vertical padding.** Top and bottom padding are always identical. Adjust optically — bottom padding often needs to be slightly larger.
|
||||||
|
- **Dashboard always has a left sidebar.** Try top navigation, a floating command menu, or a collapsible panel instead.
|
||||||
|
- **Missing whitespace.** Double the spacing. Let the design breathe. Dense layouts work for data dashboards, not for marketing pages.
|
||||||
|
- **Buttons not bottom-aligned in card groups.** When cards have different content lengths, CTAs end up at random heights. Pin buttons to the bottom of each card so they form a clean horizontal line regardless of content above.
|
||||||
|
- **Feature lists starting at different vertical positions.** In pricing tables or comparison cards, the list of features should start at the same Y position across all columns. Use consistent spacing above the list or fixed-height title/price blocks.
|
||||||
|
- **Inconsistent vertical rhythm in side-by-side elements.** When placing cards, columns, or panels next to each other, align shared elements (titles, descriptions, prices, buttons) across all items. Misaligned baselines make the layout look broken.
|
||||||
|
- **Mathematical alignment that looks optically wrong.** Centering by the math doesn't always look centered to the eye. Icons next to text, play buttons in circles, or text in buttons often need 1-2px optical adjustments to feel right.
|
||||||
|
|
||||||
|
### Interactivity and States
|
||||||
|
|
||||||
|
- **No hover states on buttons.** Add background shift, slight scale, or translate on hover.
|
||||||
|
- **No active/pressed feedback.** Add a subtle `scale(0.98)` or `translateY(1px)` on press to simulate a physical click.
|
||||||
|
- **Instant transitions with zero duration.** Add smooth transitions (200-300ms) to all interactive elements.
|
||||||
|
- **Missing focus ring.** Ensure visible focus indicators for keyboard navigation. This is an accessibility requirement, not optional.
|
||||||
|
- **No loading states.** Replace generic circular spinners with skeleton loaders that match the layout shape.
|
||||||
|
- **No empty states.** An empty dashboard showing nothing is a missed opportunity. Design a composed "getting started" view.
|
||||||
|
- **No error states.** Add clear, inline error messages for forms. Do not use `window.alert()`.
|
||||||
|
- **Dead links.** Buttons that link to `#`. Either link to real destinations or visually disable them.
|
||||||
|
- **No indication of current page in navigation.** Style the active nav link differently so users know where they are.
|
||||||
|
- **Scroll jumping.** Anchor clicks jump instantly. Add `scroll-behavior: smooth`.
|
||||||
|
- **Animations using `top`, `left`, `width`, `height`.** Switch to `transform` and `opacity` for GPU-accelerated, smooth animation.
|
||||||
|
|
||||||
|
### Content
|
||||||
|
|
||||||
|
- **Generic names like "John Doe" or "Jane Smith".** Use diverse, realistic-sounding names.
|
||||||
|
- **Fake round numbers like `99.99%`, `50%`, `$100.00`.** Use organic, messy data: `47.2%`, `$99.00`, `+1 (312) 847-1928`.
|
||||||
|
- **Placeholder company names like "Acme Corp", "Nexus", "SmartFlow".** Invent contextual, believable brand names.
|
||||||
|
- **AI copywriting cliches.** Never use "Elevate", "Seamless", "Unleash", "Next-Gen", "Game-changer", "Delve", "Tapestry", or "In the world of...". Write plain, specific language.
|
||||||
|
- **Exclamation marks in success messages.** Remove them. Be confident, not loud.
|
||||||
|
- **"Oops!" error messages.** Be direct: "Connection failed. Please try again."
|
||||||
|
- **Passive voice.** Use active voice: "We couldn't save your changes" instead of "Mistakes were made."
|
||||||
|
- **All blog post dates identical.** Randomize dates to appear real.
|
||||||
|
- **Same avatar image for multiple users.** Use unique assets for every distinct person.
|
||||||
|
- **Lorem Ipsum.** Never use placeholder latin text. Write real draft copy.
|
||||||
|
- **Title Case On Every Header.** Use sentence case instead.
|
||||||
|
|
||||||
|
### Component Patterns
|
||||||
|
|
||||||
|
- **Generic card look (border + shadow + white background).** Remove the border, or use only background color, or use only spacing. Cards should exist only when elevation communicates hierarchy.
|
||||||
|
- **Always one filled button + one ghost button.** Add text links or tertiary styles to reduce visual noise.
|
||||||
|
- **Pill-shaped "New" and "Beta" badges.** Try square badges, flags, or plain text labels.
|
||||||
|
- **Accordion FAQ sections.** Use a side-by-side list, searchable help, or inline progressive disclosure.
|
||||||
|
- **3-card carousel testimonials with dots.** Replace with a masonry wall, embedded social posts, or a single rotating quote.
|
||||||
|
- **Pricing table with 3 towers.** Highlight the recommended tier with color and emphasis, not just extra height.
|
||||||
|
- **Modals for everything.** Use inline editing, slide-over panels, or expandable sections instead of popups for simple actions.
|
||||||
|
- **Avatar circles exclusively.** Try squircles or rounded squares for a less generic look.
|
||||||
|
- **Light/dark toggle always a sun/moon switch.** Use a dropdown, system preference detection, or integrate it into settings.
|
||||||
|
- **Footer link farm with 4 columns.** Simplify. Focus on main navigational paths and legally required links.
|
||||||
|
|
||||||
|
### Iconography
|
||||||
|
|
||||||
|
- **Lucide or Feather icons exclusively.** These are the "default" AI icon choice. Use Phosphor, Heroicons, or a custom set for differentiation.
|
||||||
|
- **Rocketship for "Launch", shield for "Security".** Replace cliche metaphors with less obvious icons (bolt, fingerprint, spark, vault).
|
||||||
|
- **Inconsistent stroke widths across icons.** Audit all icons and standardize to one stroke weight.
|
||||||
|
- **Missing favicon.** Always include a branded favicon.
|
||||||
|
- **Stock "diverse team" photos.** Use real team photos, candid shots, or a consistent illustration style instead of uncanny stock imagery.
|
||||||
|
|
||||||
|
### Code Quality
|
||||||
|
|
||||||
|
- **Div soup.** Use semantic HTML: `<nav>`, `<main>`, `<article>`, `<aside>`, `<section>`.
|
||||||
|
- **Inline styles mixed with CSS classes.** Move all styling to the project's styling system.
|
||||||
|
- **Hardcoded pixel widths.** Use relative units (`%`, `rem`, `em`, `max-width`) for flexible layouts.
|
||||||
|
- **Missing alt text on images.** Describe image content for screen readers. Never leave `alt=""` or `alt="image"` on meaningful images.
|
||||||
|
- **Arbitrary z-index values like `9999`.** Establish a clean z-index scale in the theme/variables.
|
||||||
|
- **Commented-out dead code.** Remove all debug artifacts before shipping.
|
||||||
|
- **Import hallucinations.** Check that every import actually exists in `package.json` or the project dependencies.
|
||||||
|
- **Missing meta tags.** Add proper `<title>`, `description`, `og:image`, and social sharing meta tags.
|
||||||
|
|
||||||
|
### Strategic Omissions (What AI Typically Forgets)
|
||||||
|
|
||||||
|
- **No legal links.** Add privacy policy and terms of service links in the footer.
|
||||||
|
- **No "back" navigation.** Dead ends in user flows. Every page needs a way back.
|
||||||
|
- **No custom 404 page.** Design a helpful, branded "page not found" experience.
|
||||||
|
- **No form validation.** Add client-side validation for emails, required fields, and format checks.
|
||||||
|
- **No "skip to content" link.** Essential for keyboard users. Add a hidden skip-link.
|
||||||
|
- **No cookie consent.** If required by jurisdiction, add a compliant consent banner.
|
||||||
|
|
||||||
|
## Upgrade Techniques
|
||||||
|
|
||||||
|
When upgrading a project, pull from these high-impact techniques to replace generic patterns:
|
||||||
|
|
||||||
|
### Typography Upgrades
|
||||||
|
- **Variable font animation.** Interpolate weight or width on scroll or hover for text that feels alive.
|
||||||
|
- **Outlined-to-fill transitions.** Text starts as a stroke outline and fills with color on scroll entry or interaction.
|
||||||
|
- **Text mask reveals.** Large typography acting as a window to video or animated imagery behind it.
|
||||||
|
|
||||||
|
### Layout Upgrades
|
||||||
|
- **Broken grid / asymmetry.** Elements that deliberately ignore column structure — overlapping, bleeding off-screen, or offset with calculated randomness.
|
||||||
|
- **Whitespace maximization.** Aggressive use of negative space to force focus on a single element.
|
||||||
|
- **Parallax card stacks.** Sections that stick and physically stack over each other during scroll.
|
||||||
|
- **Split-screen scroll.** Two halves of the screen sliding in opposite directions.
|
||||||
|
|
||||||
|
### Motion Upgrades
|
||||||
|
- **Smooth scroll with inertia.** Decouple scrolling from browser defaults for a heavier, cinematic feel.
|
||||||
|
- **Staggered entry.** Elements cascade in with slight delays, combining Y-axis translation with opacity fade. Never mount everything at once.
|
||||||
|
- **Spring physics.** Replace linear easing with spring-based motion for a natural, weighty feel on all interactive elements.
|
||||||
|
- **Scroll-driven reveals.** Content entering through expanding masks, wipes, or draw-on SVG paths tied to scroll progress.
|
||||||
|
|
||||||
|
### Surface Upgrades
|
||||||
|
- **True glassmorphism.** Go beyond `backdrop-filter: blur`. Add a 1px inner border and a subtle inner shadow to simulate edge refraction.
|
||||||
|
- **Spotlight borders.** Card borders that illuminate dynamically under the cursor.
|
||||||
|
- **Grain and noise overlays.** A fixed, pointer-events-none overlay with subtle noise to break digital flatness.
|
||||||
|
- **Colored, tinted shadows.** Shadows that carry the hue of the background rather than using generic black.
|
||||||
|
|
||||||
|
## Fix Priority
|
||||||
|
|
||||||
|
Apply changes in this order for maximum visual impact with minimum risk:
|
||||||
|
|
||||||
|
1. **Font swap** — biggest instant improvement, lowest risk
|
||||||
|
2. **Color palette cleanup** — remove clashing or oversaturated colors
|
||||||
|
3. **Hover and active states** — makes the interface feel alive
|
||||||
|
4. **Layout and spacing** — proper grid, max-width, consistent padding
|
||||||
|
5. **Replace generic components** — swap cliche patterns for modern alternatives
|
||||||
|
6. **Add loading, empty, and error states** — makes it feel finished
|
||||||
|
7. **Polish typography scale and spacing** — the premium final touch
|
||||||
|
|
||||||
|
## Rules
|
||||||
|
|
||||||
|
- Work with the existing tech stack. Do not migrate frameworks or styling libraries.
|
||||||
|
- Do not break existing functionality. Test after every change.
|
||||||
|
- Before importing any new library, check the project's dependency file first.
|
||||||
|
- If the project uses Tailwind, check the version (v3 vs v4) before modifying config.
|
||||||
|
- If the project has no framework, use vanilla CSS.
|
||||||
|
- Keep changes reviewable and focused. Small, targeted improvements over big rewrites.
|
||||||
121
skills/taste-skill/skills/stitch-design-taste/DESIGN.md
Normal file
121
skills/taste-skill/skills/stitch-design-taste/DESIGN.md
Normal file
|
|
@ -0,0 +1,121 @@
|
||||||
|
# Design System: Taste Standard
|
||||||
|
**Skill:** stitch-design-taste
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Configuration — Set Your Style
|
||||||
|
Adjust these dials before using this design system. They control how creative, dense, and animated the output should be. Pick the level that fits your project.
|
||||||
|
|
||||||
|
| Dial | Level | Description |
|
||||||
|
|------|-------|-------------|
|
||||||
|
| **Creativity** | `8` | `1` = Ultra-minimal, Swiss, silent, monochrome. `5` = Balanced, clean but with personality. `10` = Expressive, editorial, bold typography experiments, inline images in headlines, strong asymmetry. Default: `8` |
|
||||||
|
| **Density** | `4` | `1` = Gallery-airy, massive whitespace. `5` = Balanced sections. `10` = Cockpit-dense, data-heavy. Default: `4` |
|
||||||
|
| **Variance** | `8` | `1` = Predictable, symmetric grids. `5` = Subtle offsets. `10` = Artsy chaotic, no two sections alike. Default: `8` |
|
||||||
|
| **Motion Intent** | `6` | `1` = Static, no animation noted. `5` = Subtle hover/entrance cues. `10` = Cinematic orchestration noted in every component. Default: `6` |
|
||||||
|
|
||||||
|
> **How to use:** Change the numbers above to match your project's vibe. At **Creativity 1–3**, the system produces clean, quiet, Notion-like interfaces. At **Creativity 7–10**, expect inline image typography, dramatic scale contrast, and strong editorial layouts. The rest of the rules below adapt to your chosen levels.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Visual Theme & Atmosphere
|
||||||
|
A restrained, gallery-airy interface with confident asymmetric layouts and fluid spring-physics motion. The atmosphere is clinical yet warm — like a well-lit architecture studio where every element earns its place through function. Density is balanced (Level 4), variance runs high (Level 8) to prevent symmetrical boredom, and motion is fluid but never theatrical (Level 6). The overall impression: expensive, intentional, alive.
|
||||||
|
|
||||||
|
## 2. Color Palette & Roles
|
||||||
|
- **Canvas White** (#F9FAFB) — Primary background surface. Warm-neutral, never clinical blue-white
|
||||||
|
- **Pure Surface** (#FFFFFF) — Card and container fill. Used with whisper shadow for elevation
|
||||||
|
- **Charcoal Ink** (#18181B) — Primary text. Zinc-950 depth — never pure black
|
||||||
|
- **Steel Secondary** (#71717A) — Body text, descriptions, metadata. Zinc-500 warmth
|
||||||
|
- **Muted Slate** (#94A3B8) — Tertiary text, timestamps, disabled states
|
||||||
|
- **Whisper Border** (rgba(226,232,240,0.5)) — Card borders, structural 1px lines. Semi-transparent for depth
|
||||||
|
- **Diffused Shadow** (rgba(0,0,0,0.05)) — Card elevation. Wide-spreading, 40px blur, -15px offset. Never harsh
|
||||||
|
|
||||||
|
### Accent Selection (Pick ONE per project)
|
||||||
|
- **Emerald Signal** (#10B981) — For growth, success, positive data dashboards
|
||||||
|
- **Electric Blue** (#3B82F6) — For productivity, SaaS, developer tools
|
||||||
|
- **Deep Rose** (#E11D48) — For creative, editorial, fashion-adjacent projects
|
||||||
|
- **Amber Warmth** (#F59E0B) — For community, social, warm-toned products
|
||||||
|
|
||||||
|
### Banned Colors
|
||||||
|
- Purple/Violet neon gradients — the "AI Purple" aesthetic
|
||||||
|
- Pure Black (#000000) — always Off-Black or Zinc-950
|
||||||
|
- Oversaturated accents above 80% saturation
|
||||||
|
- Mixed warm/cool gray systems within one project
|
||||||
|
|
||||||
|
## 3. Typography Rules
|
||||||
|
- **Display:** `Geist`, `Satoshi`, `Cabinet Grotesk`, or `Outfit` — Track-tight (`-0.025em`), controlled fluid scale, weight-driven hierarchy (700–900). Not screaming. Leading compressed (`1.1`). Alternatives forced — `Inter` is BANNED for premium contexts
|
||||||
|
- **Body:** Same family at weight 400 — Relaxed leading (`1.65`), 65ch max-width, Steel Secondary color (#71717A)
|
||||||
|
- **Mono:** `Geist Mono` or `JetBrains Mono` — For code blocks, metadata, timestamps. When density exceeds Level 7, all numbers switch to monospace
|
||||||
|
- **Scale:** Display at `clamp(2.25rem, 5vw, 3.75rem)`. Body at `1rem/1.125rem`. Mono metadata at `0.8125rem`
|
||||||
|
|
||||||
|
### Banned Fonts
|
||||||
|
- `Inter` — banned everywhere in premium/creative contexts
|
||||||
|
- Generic serif fonts (`Times New Roman`, `Georgia`, `Garamond`, `Palatino`) — BANNED. If serif is needed for editorial/creative, use only distinctive modern serifs like `Fraunces`, `Gambarino`, `Editorial New`, or `Instrument Serif`. Never use default browser serif stacks. Serif is always BANNED in dashboards or software UIs regardless
|
||||||
|
|
||||||
|
## 4. Component Stylings
|
||||||
|
* **Buttons:** Flat surface, no outer glow. Primary: accent fill with white text. Secondary: ghost/outline. Active state: `-1px translateY` or `scale(0.98)` for tactile push. Hover: subtle background shift, never glow
|
||||||
|
* **Cards/Containers:** Generously rounded corners (`2.5rem`). Pure white fill. Whisper border (`1px`, semi-transparent). Diffused shadow (`0 20px 40px -15px rgba(0,0,0,0.05)`). Internal padding `2rem–2.5rem`. Used ONLY when elevation communicates hierarchy — high-density layouts replace cards with `border-top` dividers or negative space
|
||||||
|
* **Inputs/Forms:** Label positioned above input. Helper text optional. Error text below in Deep Rose. Focus ring in accent color, `2px` offset. No floating labels. Standard `0.5rem` gap between label-input-error stack
|
||||||
|
* **Navigation:** Sleek, sticky. Icons scale on hover (Dock Magnification optional). No hamburger on desktop. Clean horizontal with generous spacing
|
||||||
|
* **Loaders:** Skeletal shimmer matching exact layout dimensions and rounded corners. Shifting light reflection across placeholder shapes. Never circular spinners
|
||||||
|
* **Empty States:** Composed illustration or icon composition with guidance text. Never just "No data found"
|
||||||
|
* **Error States:** Inline, contextual. Red accent underline or border. Clear recovery action
|
||||||
|
|
||||||
|
## 5. Hero Section
|
||||||
|
The Hero is the first impression — it must be striking, creative, and never generic.
|
||||||
|
- **Inline Image Typography:** Embed small, contextual photos or visuals directly between words or letters in the headline. Example: "We build [photo of hands typing] digital [photo of screen] products" — images sit inline at type-height, rounded, acting as visual punctuation between words. This is the signature creative technique
|
||||||
|
- **No Overlapping Elements:** Text must never overlap images or other text. Every element has its own clear spatial zone. No z-index stacking of content layers, no absolute-positioned headlines over images. Clean separation always
|
||||||
|
- **No Filler Text:** "Scroll to explore", "Swipe down", scroll arrow icons, bouncing chevrons, and any instructional UI chrome are BANNED. The user knows how to scroll. Let the content pull them in naturally
|
||||||
|
- **Asymmetric Structure:** Centered Hero layouts are BANNED at this variance level. Use Split Screen (50/50), Left-Aligned text / Right visual, or Asymmetric Whitespace with large empty zones
|
||||||
|
- **CTA Restraint:** Maximum one primary CTA button. No secondary "Learn more" links. No redundant micro-copy below the headline
|
||||||
|
|
||||||
|
## 6. Layout Principles
|
||||||
|
- **Grid-First:** CSS Grid for all structural layouts. Never flexbox percentage math (`calc(33% - 1rem)` is BANNED)
|
||||||
|
- **No Overlapping:** Elements must never overlap each other. No absolute-positioned layers stacking content on content. Every element occupies its own grid cell or flow position. Clean, separated spatial zones
|
||||||
|
- **Feature Sections:** The "3 equal cards in a row" pattern is BANNED. Use 2-column Zig-Zag, asymmetric Bento grids (2fr 1fr 1fr), or horizontal scroll galleries
|
||||||
|
- **Containment:** All content within `max-width: 1400px`, centered. Generous horizontal padding (`1rem` mobile, `2rem` tablet, `4rem` desktop)
|
||||||
|
- **Full-Height:** Use `min-height: 100dvh` — never `height: 100vh` (iOS Safari address bar jump)
|
||||||
|
- **Bento Architecture:** For feature grids, use Row 1: 3 columns | Row 2: 2 columns (70/30 split). Each tile contains a perpetual micro-animation
|
||||||
|
|
||||||
|
## 7. Responsive Rules
|
||||||
|
Every screen must work flawlessly across all viewports. **Responsive is not optional — it is a hard requirement. Every single element must be tested at 375px, 768px, and 1440px.**
|
||||||
|
- **Mobile-First Collapse (< 768px):** All multi-column layouts collapse to a strict single column. `width: 100%`, `padding: 1rem`, `gap: 1.5rem`. No exceptions
|
||||||
|
- **No Horizontal Scroll:** Horizontal overflow on mobile is a critical failure. All elements must fit within viewport width. If any element causes horizontal scroll, the design is broken
|
||||||
|
- **Typography Scaling:** Headlines scale down gracefully via `clamp()`. Body text stays `1rem` minimum. Never shrink body below `14px`. Headlines must remain readable on 375px screens
|
||||||
|
- **Touch Targets:** All interactive elements minimum `44px` tap target. Generous spacing between clickable items. Buttons must be full-width on mobile
|
||||||
|
- **Image Behavior:** Hero and inline images scale proportionally. Inline typography images (photos between words) stack below the headline on mobile instead of inline
|
||||||
|
- **Navigation:** Desktop horizontal nav collapses to a clean mobile menu (slide-in or full-screen overlay). No tiny hamburger icons without labels
|
||||||
|
- **Cards & Grids:** Bento grids and asymmetric layouts revert to stacked single-column cards with full-width. Maintain internal padding (`1rem`)
|
||||||
|
- **Spacing Consistency:** Vertical section gaps reduce proportionally on mobile (`clamp(3rem, 8vw, 6rem)`). Never cramped, never excessively airy
|
||||||
|
- **Testing Viewports:** Designs must be verified at: `375px` (iPhone SE), `390px` (iPhone 14), `768px` (iPad), `1024px` (small laptop), `1440px` (desktop)
|
||||||
|
|
||||||
|
## 8. Motion & Interaction (Code-Phase Intent)
|
||||||
|
> **Note:** Stitch generates static screens — it does not animate. This section documents the **intended motion behavior** so that the coding agent (Antigravity, Cursor, etc.) knows exactly how to implement animations when building the exported design into a live product.
|
||||||
|
|
||||||
|
- **Physics Engine:** Spring-based exclusively. `stiffness: 100, damping: 20`. No linear easing anywhere. Premium, weighty feel on all interactive elements
|
||||||
|
- **Perpetual Micro-Loops:** Every active dashboard component has an infinite-loop state — Pulse on status dots, Typewriter on search bars, Float on feature icons, Shimmer on loading states
|
||||||
|
- **Staggered Orchestration:** Lists and grids mount with cascaded delays (`animation-delay: calc(var(--index) * 100ms)`). Waterfall reveals, never instant mount
|
||||||
|
- **Layout Transitions:** Smooth re-ordering via shared element IDs. Items swap positions with physics, simulating real-time intelligence
|
||||||
|
- **Hardware Rules:** Animate ONLY `transform` and `opacity`. Never `top`, `left`, `width`, `height`. Grain/noise filters on fixed, pointer-events-none pseudo-elements only
|
||||||
|
- **Performance:** CPU-heavy perpetual animations isolated in microscopic leaf components. Never trigger parent re-renders. Target 60fps minimum
|
||||||
|
|
||||||
|
## 9. Anti-Patterns (Banned)
|
||||||
|
- No emojis — anywhere in UI, code, or alt text
|
||||||
|
- No `Inter` font — use `Geist`, `Outfit`, `Cabinet Grotesk`, `Satoshi`
|
||||||
|
- No generic serif fonts (`Times New Roman`, `Georgia`, `Garamond`) — if serif is needed, use distinctive modern serifs only (`Fraunces`, `Instrument Serif`)
|
||||||
|
- No pure black (`#000000`) — Off-Black or Zinc-950 only
|
||||||
|
- No neon outer glows or default box-shadow glows
|
||||||
|
- No oversaturated accent colors above 80%
|
||||||
|
- No excessive gradient text on large headers
|
||||||
|
- No custom mouse cursors
|
||||||
|
- No overlapping elements — text never overlaps images or other content. Clean spatial separation always
|
||||||
|
- No 3-column equal card layouts for features
|
||||||
|
- No centered Hero sections (at this variance level)
|
||||||
|
- No filler UI text: "Scroll to explore", "Swipe down", "Discover more below", scroll arrows, bouncing chevrons — all BANNED
|
||||||
|
- No generic names: "John Doe", "Sarah Chan", "Acme", "Nexus", "SmartFlow"
|
||||||
|
- No fake round numbers: `99.99%`, `50%`, `1234567` — use organic data: `47.2%`, `+1 (312) 847-1928`
|
||||||
|
- No AI copywriting clichés: "Elevate", "Seamless", "Unleash", "Next-Gen", "Revolutionize"
|
||||||
|
- No broken Unsplash links — use `picsum.photos/seed/{id}/800/600` or SVG UI Avatars
|
||||||
|
- No generic `shadcn/ui` defaults — customize radii, colors, shadows to match this system
|
||||||
|
- No `z-index` spam — use only for Navbar, Modal, Overlay layer contexts
|
||||||
|
- No `h-screen` — always `min-h-[100dvh]`
|
||||||
|
- No circular loading spinners — skeletal shimmer only
|
||||||
184
skills/taste-skill/skills/stitch-design-taste/SKILL.md
Normal file
184
skills/taste-skill/skills/stitch-design-taste/SKILL.md
Normal file
|
|
@ -0,0 +1,184 @@
|
||||||
|
---
|
||||||
|
name: stitch-design-taste
|
||||||
|
description: Semantic Design System Skill for Google Stitch. Generates agent-friendly DESIGN.md files that enforce premium, anti-generic UI standards — strict typography, calibrated color, asymmetric layouts, perpetual micro-motion, and hardware-accelerated performance.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Stitch Design Taste — Semantic Design System Skill
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
This skill generates `DESIGN.md` files optimized for Google Stitch screen generation. It translates the battle-tested anti-slop frontend engineering directives into Stitch's native semantic design language — descriptive, natural-language rules paired with precise values that Stitch's AI agent can interpret to produce premium, non-generic interfaces.
|
||||||
|
|
||||||
|
The generated `DESIGN.md` serves as the **single source of truth** for prompting Stitch to generate new screens that align with a curated, high-agency design language. Stitch interprets design through **"Visual Descriptions"** supported by specific color values, typography specs, and component behaviors.
|
||||||
|
|
||||||
|
## Prerequisites
|
||||||
|
- Access to Google Stitch via [labs.google.com/stitch](https://labs.google.com/stitch)
|
||||||
|
- Optionally: Stitch MCP Server for programmatic integration with Cursor, Antigravity, or Gemini CLI
|
||||||
|
|
||||||
|
## The Goal
|
||||||
|
Generate a `DESIGN.md` file that encodes:
|
||||||
|
1. **Visual atmosphere** — the mood, density, and design philosophy
|
||||||
|
2. **Color calibration** — neutrals, accents, and banned patterns with hex codes
|
||||||
|
3. **Typographic architecture** — font stacks, scale hierarchy, and anti-patterns
|
||||||
|
4. **Component behaviors** — buttons, cards, inputs with interaction states
|
||||||
|
5. **Layout principles** — grid systems, spacing philosophy, responsive strategy
|
||||||
|
6. **Motion philosophy** — animation engine specs, spring physics, perpetual micro-interactions
|
||||||
|
7. **Anti-patterns** — explicit list of banned AI design clichés
|
||||||
|
|
||||||
|
## Analysis & Synthesis Instructions
|
||||||
|
|
||||||
|
### 1. Define the Atmosphere
|
||||||
|
Evaluate the target project's intent. Use evocative adjectives from the taste spectrum:
|
||||||
|
- **Density:** "Art Gallery Airy" (1–3) → "Daily App Balanced" (4–7) → "Cockpit Dense" (8–10)
|
||||||
|
- **Variance:** "Predictable Symmetric" (1–3) → "Offset Asymmetric" (4–7) → "Artsy Chaotic" (8–10)
|
||||||
|
- **Motion:** "Static Restrained" (1–3) → "Fluid CSS" (4–7) → "Cinematic Choreography" (8–10)
|
||||||
|
|
||||||
|
Default baseline: Variance 8, Motion 6, Density 4. Adapt dynamically based on user's vibe description.
|
||||||
|
|
||||||
|
### 2. Map the Color Palette
|
||||||
|
For each color provide: **Descriptive Name** + **Hex Code** + **Functional Role**.
|
||||||
|
|
||||||
|
**Mandatory constraints:**
|
||||||
|
- Maximum 1 accent color. Saturation below 80%
|
||||||
|
- The "AI Purple/Blue Neon" aesthetic is strictly BANNED — no purple button glows, no neon gradients
|
||||||
|
- Use absolute neutral bases (Zinc/Slate) with high-contrast singular accents
|
||||||
|
- Stick to one palette for the entire output — no warm/cool gray fluctuation
|
||||||
|
- Never use pure black (`#000000`) — use Off-Black, Zinc-950, or Charcoal
|
||||||
|
|
||||||
|
### 3. Establish Typography Rules
|
||||||
|
- **Display/Headlines:** Track-tight, controlled scale. Not screaming. Hierarchy through weight and color, not just massive size
|
||||||
|
- **Body:** Relaxed leading, max 65 characters per line
|
||||||
|
- **Font Selection:** `Inter` is BANNED for premium/creative contexts. Force unique character: `Geist`, `Outfit`, `Cabinet Grotesk`, or `Satoshi`
|
||||||
|
- **Serif Ban:** Generic serif fonts (`Times New Roman`, `Georgia`, `Garamond`, `Palatino`) are BANNED. If serif is needed for editorial/creative contexts, use only distinctive modern serifs: `Fraunces`, `Gambarino`, `Editorial New`, or `Instrument Serif`. Serif is always BANNED in dashboards or software UIs
|
||||||
|
- **Dashboard Constraint:** Use Sans-Serif pairings exclusively (`Geist` + `Geist Mono` or `Satoshi` + `JetBrains Mono`)
|
||||||
|
- **High-Density Override:** When density exceeds 7, all numbers must use Monospace
|
||||||
|
|
||||||
|
### 4. Define the Hero Section
|
||||||
|
The Hero is the first impression and must be creative, striking, and never generic:
|
||||||
|
- **Inline Image Typography:** Embed small, contextual photos or visuals directly between words or letters in the headline. Images sit inline at type-height, rounded, acting as visual punctuation. This is the signature creative technique
|
||||||
|
- **No Overlapping:** Text must never overlap images or other text. Every element occupies its own clean spatial zone
|
||||||
|
- **No Filler Text:** "Scroll to explore", "Swipe down", scroll arrow icons, bouncing chevrons are BANNED. The content should pull users in naturally
|
||||||
|
- **Asymmetric Structure:** Centered Hero layouts BANNED when variance exceeds 4
|
||||||
|
- **CTA Restraint:** Maximum one primary CTA. No secondary "Learn more" links
|
||||||
|
|
||||||
|
### 5. Describe Component Stylings
|
||||||
|
For each component type, describe shape, color, shadow depth, and interaction behavior:
|
||||||
|
- **Buttons:** Tactile push feedback on active state. No neon outer glows. No custom mouse cursors
|
||||||
|
- **Cards:** Use ONLY when elevation communicates hierarchy. Tint shadows to background hue. For high-density layouts, replace cards with border-top dividers or negative space
|
||||||
|
- **Inputs/Forms:** Label above input, helper text optional, error text below. Standard gap spacing
|
||||||
|
- **Loading States:** Skeletal loaders matching layout dimensions — no generic circular spinners
|
||||||
|
- **Empty States:** Composed compositions indicating how to populate data
|
||||||
|
- **Error States:** Clear, inline error reporting
|
||||||
|
|
||||||
|
### 6. Define Layout Principles
|
||||||
|
- No overlapping elements — every element occupies its own clear spatial zone. No absolute-positioned content stacking
|
||||||
|
- Centered Hero sections are BANNED when variance exceeds 4 — force Split Screen, Left-Aligned, or Asymmetric Whitespace
|
||||||
|
- The generic "3 equal cards horizontally" feature row is BANNED — use 2-column Zig-Zag, asymmetric grid, or horizontal scroll
|
||||||
|
- CSS Grid over Flexbox math — never use `calc()` percentage hacks
|
||||||
|
- Contain layouts using max-width constraints (e.g., 1400px centered)
|
||||||
|
- Full-height sections must use `min-h-[100dvh]` — never `h-screen` (iOS Safari catastrophic jump)
|
||||||
|
|
||||||
|
### 7. Define Responsive Rules
|
||||||
|
Every design must work across all viewports:
|
||||||
|
- **Mobile-First Collapse (< 768px):** All multi-column layouts collapse to single column. No exceptions
|
||||||
|
- **No Horizontal Scroll:** Horizontal overflow on mobile is a critical failure
|
||||||
|
- **Typography Scaling:** Headlines scale via `clamp()`. Body text minimum `1rem`/`14px`
|
||||||
|
- **Touch Targets:** All interactive elements minimum `44px` tap target
|
||||||
|
- **Image Behavior:** Inline typography images (photos between words) stack below headline on mobile
|
||||||
|
- **Navigation:** Desktop horizontal nav collapses to clean mobile menu
|
||||||
|
- **Spacing:** Vertical section gaps reduce proportionally (`clamp(3rem, 8vw, 6rem)`)
|
||||||
|
|
||||||
|
### 8. Encode Motion Philosophy
|
||||||
|
- **Spring Physics default:** `stiffness: 100, damping: 20` — premium, weighty feel. No linear easing
|
||||||
|
- **Perpetual Micro-Interactions:** Every active component should have an infinite loop state (Pulse, Typewriter, Float, Shimmer)
|
||||||
|
- **Staggered Orchestration:** Never mount lists instantly — use cascade delays for waterfall reveals
|
||||||
|
- **Performance:** Animate exclusively via `transform` and `opacity`. Never animate `top`, `left`, `width`, `height`. Grain/noise filters on fixed pseudo-elements only
|
||||||
|
|
||||||
|
### 9. List Anti-Patterns (AI Tells)
|
||||||
|
Encode these as explicit "NEVER DO" rules in the DESIGN.md:
|
||||||
|
- No emojis anywhere
|
||||||
|
- No `Inter` font
|
||||||
|
- No generic serif fonts (`Times New Roman`, `Georgia`, `Garamond`) — distinctive modern serifs only if needed
|
||||||
|
- No pure black (`#000000`)
|
||||||
|
- No neon/outer glow shadows
|
||||||
|
- No oversaturated accents
|
||||||
|
- No excessive gradient text on large headers
|
||||||
|
- No custom mouse cursors
|
||||||
|
- No overlapping elements — clean spatial separation always
|
||||||
|
- No 3-column equal card layouts
|
||||||
|
- No generic names ("John Doe", "Acme", "Nexus")
|
||||||
|
- No fake round numbers (`99.99%`, `50%`)
|
||||||
|
- No AI copywriting clichés ("Elevate", "Seamless", "Unleash", "Next-Gen")
|
||||||
|
- No filler UI text: "Scroll to explore", "Swipe down", scroll arrows, bouncing chevrons
|
||||||
|
- No broken Unsplash links — use `picsum.photos` or SVG avatars
|
||||||
|
- No centered Hero sections (for high-variance projects)
|
||||||
|
|
||||||
|
## Output Format (DESIGN.md Structure)
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# Design System: [Project Title]
|
||||||
|
|
||||||
|
## 1. Visual Theme & Atmosphere
|
||||||
|
(Evocative description of the mood, density, variance, and motion intensity.
|
||||||
|
Example: "A restrained, gallery-airy interface with confident asymmetric layouts
|
||||||
|
and fluid spring-physics motion. The atmosphere is clinical yet warm — like a
|
||||||
|
well-lit architecture studio.")
|
||||||
|
|
||||||
|
## 2. Color Palette & Roles
|
||||||
|
- **Canvas White** (#F9FAFB) — Primary background surface
|
||||||
|
- **Pure Surface** (#FFFFFF) — Card and container fill
|
||||||
|
- **Charcoal Ink** (#18181B) — Primary text, Zinc-950 depth
|
||||||
|
- **Muted Steel** (#71717A) — Secondary text, descriptions, metadata
|
||||||
|
- **Whisper Border** (rgba(226,232,240,0.5)) — Card borders, 1px structural lines
|
||||||
|
- **[Accent Name]** (#XXXXXX) — Single accent for CTAs, active states, focus rings
|
||||||
|
(Max 1 accent. Saturation < 80%. No purple/neon.)
|
||||||
|
|
||||||
|
## 3. Typography Rules
|
||||||
|
- **Display:** [Font Name] — Track-tight, controlled scale, weight-driven hierarchy
|
||||||
|
- **Body:** [Font Name] — Relaxed leading, 65ch max-width, neutral secondary color
|
||||||
|
- **Mono:** [Font Name] — For code, metadata, timestamps, high-density numbers
|
||||||
|
- **Banned:** Inter, generic system fonts for premium contexts. Serif fonts banned in dashboards.
|
||||||
|
|
||||||
|
## 4. Component Stylings
|
||||||
|
* **Buttons:** Flat, no outer glow. Tactile -1px translate on active. Accent fill for primary, ghost/outline for secondary.
|
||||||
|
* **Cards:** Generously rounded corners (2.5rem). Diffused whisper shadow. Used only when elevation serves hierarchy. High-density: replace with border-top dividers.
|
||||||
|
* **Inputs:** Label above, error below. Focus ring in accent color. No floating labels.
|
||||||
|
* **Loaders:** Skeletal shimmer matching exact layout dimensions. No circular spinners.
|
||||||
|
* **Empty States:** Composed, illustrated compositions — not just "No data" text.
|
||||||
|
|
||||||
|
## 5. Layout Principles
|
||||||
|
(Grid-first responsive architecture. Asymmetric splits for Hero sections.
|
||||||
|
Strict single-column collapse below 768px. Max-width containment.
|
||||||
|
No flexbox percentage math. Generous internal padding.)
|
||||||
|
|
||||||
|
## 6. Motion & Interaction
|
||||||
|
(Spring physics for all interactive elements. Staggered cascade reveals.
|
||||||
|
Perpetual micro-loops on active dashboard components. Hardware-accelerated
|
||||||
|
transforms only. Isolated Client Components for CPU-heavy animations.)
|
||||||
|
|
||||||
|
## 7. Anti-Patterns (Banned)
|
||||||
|
(Explicit list of forbidden patterns: no emojis, no Inter, no pure black,
|
||||||
|
no neon glows, no 3-column equal grids, no AI copywriting clichés,
|
||||||
|
no generic placeholder names, no broken image links.)
|
||||||
|
```
|
||||||
|
|
||||||
|
## Best Practices
|
||||||
|
- **Be Descriptive:** "Deep Charcoal Ink (#18181B)" — not just "dark text"
|
||||||
|
- **Be Functional:** Explain what each element is used for
|
||||||
|
- **Be Consistent:** Same terminology throughout the document
|
||||||
|
- **Be Precise:** Include exact hex codes, rem values, pixel values in parentheses
|
||||||
|
- **Be Opinionated:** This is not a neutral template — it enforces a specific, premium aesthetic
|
||||||
|
|
||||||
|
## Tips for Success
|
||||||
|
1. Start with the atmosphere — understand the vibe before detailing tokens
|
||||||
|
2. Look for patterns — identify consistent spacing, sizing, and styling
|
||||||
|
3. Think semantically — name colors by purpose, not just appearance
|
||||||
|
4. Consider hierarchy — document how visual weight communicates importance
|
||||||
|
5. Encode the bans — anti-patterns are as important as the rules themselves
|
||||||
|
|
||||||
|
## Common Pitfalls to Avoid
|
||||||
|
- Using technical jargon without translation ("rounded-xl" instead of "generously rounded corners")
|
||||||
|
- Omitting hex codes or using only descriptive names
|
||||||
|
- Forgetting functional roles of design elements
|
||||||
|
- Being too vague in atmosphere descriptions
|
||||||
|
- Ignoring the anti-pattern list — these are what make the output premium
|
||||||
|
- Defaulting to generic "safe" designs instead of enforcing the curated aesthetic
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
Subproject commit 36bf2971c92f014b7eda67e4b2c8ccd9c9b37c05
|
|
||||||
15
skills/terrashark/.claude-plugin/marketplace.json
Normal file
15
skills/terrashark/.claude-plugin/marketplace.json
Normal file
|
|
@ -0,0 +1,15 @@
|
||||||
|
{
|
||||||
|
"name": "terrashark",
|
||||||
|
"description": "Practical Terraform and OpenTofu skill focused on structure, security, testing, and low-hallucination IaC generation.",
|
||||||
|
"owner": {
|
||||||
|
"name": "LukasNiessen"
|
||||||
|
},
|
||||||
|
"plugins": [
|
||||||
|
{
|
||||||
|
"name": "terrashark",
|
||||||
|
"source": "./",
|
||||||
|
"description": "Terraform/OpenTofu Guardrails",
|
||||||
|
"version": "2.3.0"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
1
skills/terrashark/.github/CODEOWNERS
vendored
Normal file
1
skills/terrashark/.github/CODEOWNERS
vendored
Normal file
|
|
@ -0,0 +1 @@
|
||||||
|
* @LukasNiessen
|
||||||
46
skills/terrashark/.github/PULL_REQUEST_TEMPLATE.md
vendored
Normal file
46
skills/terrashark/.github/PULL_REQUEST_TEMPLATE.md
vendored
Normal file
|
|
@ -0,0 +1,46 @@
|
||||||
|
## Summary
|
||||||
|
|
||||||
|
- What changed?
|
||||||
|
- Why is this needed?
|
||||||
|
- Which failure mode(s) does this address?
|
||||||
|
|
||||||
|
## Failure-Mode Coverage
|
||||||
|
|
||||||
|
Select all that apply:
|
||||||
|
|
||||||
|
- [ ] `identity-churn`
|
||||||
|
- [ ] `secret-exposure`
|
||||||
|
- [ ] `blast-radius`
|
||||||
|
- [ ] `ci-drift`
|
||||||
|
- [ ] `compliance-gates`
|
||||||
|
- [ ] Not applicable
|
||||||
|
|
||||||
|
## Quality Impact
|
||||||
|
|
||||||
|
- Hallucination or error pattern reduced:
|
||||||
|
- Expected quality gain:
|
||||||
|
- Token-cost impact (higher/lower/neutral):
|
||||||
|
|
||||||
|
## Validation Performed
|
||||||
|
|
||||||
|
- [ ] Ran markdown/link checks
|
||||||
|
- [ ] Checked SKILL frontmatter and file structure
|
||||||
|
- [ ] Verified all referenced files exist
|
||||||
|
- [ ] (If content change) sanity-checked examples for correctness
|
||||||
|
|
||||||
|
Commands / notes:
|
||||||
|
|
||||||
|
```text
|
||||||
|
# Paste commands or rationale used for validation
|
||||||
|
```
|
||||||
|
|
||||||
|
## Safety Checklist
|
||||||
|
|
||||||
|
- [ ] No secrets or credentials added
|
||||||
|
- [ ] No contradictory guidance across files
|
||||||
|
- [ ] Runtime/version statements are internally consistent
|
||||||
|
- [ ] Examples are newly written and not copied from external repos
|
||||||
|
|
||||||
|
## Reviewer Notes
|
||||||
|
|
||||||
|
Any context reviewers should know before approval.
|
||||||
11
skills/terrashark/.github/dependabot.yml
vendored
Normal file
11
skills/terrashark/.github/dependabot.yml
vendored
Normal file
|
|
@ -0,0 +1,11 @@
|
||||||
|
# To get started with Dependabot version updates, you'll need to specify which
|
||||||
|
# package ecosystems to update and where the package manifests are located.
|
||||||
|
# Please see the documentation for all configuration options:
|
||||||
|
# https://docs.github.com/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
|
||||||
|
|
||||||
|
version: 2
|
||||||
|
updates:
|
||||||
|
- package-ecosystem: "" # See documentation for possible values
|
||||||
|
directory: "/" # Location of package manifests
|
||||||
|
schedule:
|
||||||
|
interval: "weekly"
|
||||||
56
skills/terrashark/.github/workflows/deploy-docs.yml
vendored
Normal file
56
skills/terrashark/.github/workflows/deploy-docs.yml
vendored
Normal file
|
|
@ -0,0 +1,56 @@
|
||||||
|
name: Deploy Documentation to GitHub Pages
|
||||||
|
|
||||||
|
on:
|
||||||
|
push:
|
||||||
|
branches: [main]
|
||||||
|
workflow_dispatch:
|
||||||
|
|
||||||
|
permissions:
|
||||||
|
contents: read
|
||||||
|
pages: write
|
||||||
|
id-token: write
|
||||||
|
|
||||||
|
concurrency:
|
||||||
|
group: pages
|
||||||
|
cancel-in-progress: false
|
||||||
|
|
||||||
|
jobs:
|
||||||
|
build:
|
||||||
|
runs-on: ubuntu-latest
|
||||||
|
steps:
|
||||||
|
- name: Checkout repository
|
||||||
|
uses: actions/checkout@v4
|
||||||
|
|
||||||
|
- name: Setup Node.js
|
||||||
|
uses: actions/setup-node@v4
|
||||||
|
with:
|
||||||
|
node-version: '20'
|
||||||
|
cache: 'npm'
|
||||||
|
cache-dependency-path: docs/package-lock.json
|
||||||
|
|
||||||
|
- name: Install dependencies
|
||||||
|
working-directory: docs
|
||||||
|
run: npm ci || npm install
|
||||||
|
|
||||||
|
- name: Build documentation with HonKit
|
||||||
|
working-directory: docs
|
||||||
|
run: npx honkit build
|
||||||
|
|
||||||
|
- name: Setup Pages
|
||||||
|
uses: actions/configure-pages@v5
|
||||||
|
|
||||||
|
- name: Upload artifact
|
||||||
|
uses: actions/upload-pages-artifact@v3
|
||||||
|
with:
|
||||||
|
path: docs/_book
|
||||||
|
|
||||||
|
deploy:
|
||||||
|
environment:
|
||||||
|
name: github-pages
|
||||||
|
url: ${{ steps.deployment.outputs.page_url }}
|
||||||
|
runs-on: ubuntu-latest
|
||||||
|
needs: build
|
||||||
|
steps:
|
||||||
|
- name: Deploy to GitHub Pages
|
||||||
|
id: deployment
|
||||||
|
uses: actions/deploy-pages@v4
|
||||||
37
skills/terrashark/.github/workflows/stale.yml
vendored
Normal file
37
skills/terrashark/.github/workflows/stale.yml
vendored
Normal file
|
|
@ -0,0 +1,37 @@
|
||||||
|
name: 'Close stale issues and PRs'
|
||||||
|
|
||||||
|
on:
|
||||||
|
schedule:
|
||||||
|
- cron: '30 1 * * *'
|
||||||
|
workflow_dispatch:
|
||||||
|
|
||||||
|
permissions:
|
||||||
|
issues: write
|
||||||
|
pull-requests: write
|
||||||
|
|
||||||
|
jobs:
|
||||||
|
stale:
|
||||||
|
runs-on: ubuntu-latest
|
||||||
|
steps:
|
||||||
|
- uses: actions/stale@v9
|
||||||
|
with:
|
||||||
|
stale-issue-message: >
|
||||||
|
This issue has been automatically marked as stale because it has not had
|
||||||
|
recent activity for 2 years. It will be closed if no further activity occurs
|
||||||
|
within 30 days. Thank you for your contributions! 🦊
|
||||||
|
stale-pr-message: >
|
||||||
|
This pull request has been automatically marked as stale because it has not had
|
||||||
|
recent activity for 2 years. It will be closed if no further activity occurs
|
||||||
|
within 30 days. Thank you for your contributions! 🦊
|
||||||
|
close-issue-message: >
|
||||||
|
This issue was closed because it has been stale for 30 days with no further activity.
|
||||||
|
Feel free to reopen if this is still relevant! 🐲
|
||||||
|
close-pr-message: >
|
||||||
|
This pull request was closed because it has been stale for 30 days with no further activity.
|
||||||
|
Feel free to reopen if this is still relevant! 🐲
|
||||||
|
days-before-stale: 730
|
||||||
|
days-before-close: 30
|
||||||
|
stale-issue-label: 'stale'
|
||||||
|
stale-pr-label: 'stale'
|
||||||
|
exempt-issue-labels: 'pinned,security,good first issue'
|
||||||
|
exempt-pr-labels: 'pinned,security'
|
||||||
94
skills/terrashark/.github/workflows/validate.yml
vendored
Normal file
94
skills/terrashark/.github/workflows/validate.yml
vendored
Normal file
|
|
@ -0,0 +1,94 @@
|
||||||
|
name: Validate Terrashark
|
||||||
|
|
||||||
|
on:
|
||||||
|
pull_request:
|
||||||
|
push:
|
||||||
|
branches: [main]
|
||||||
|
|
||||||
|
jobs:
|
||||||
|
validate:
|
||||||
|
runs-on: ubuntu-latest
|
||||||
|
steps:
|
||||||
|
- name: Checkout
|
||||||
|
uses: actions/checkout@v4
|
||||||
|
|
||||||
|
- name: Setup Python
|
||||||
|
uses: actions/setup-python@v5
|
||||||
|
with:
|
||||||
|
python-version: "3.11"
|
||||||
|
|
||||||
|
- name: Validate required files
|
||||||
|
run: |
|
||||||
|
test -f SKILL.md
|
||||||
|
test -f README.md
|
||||||
|
test -d references
|
||||||
|
test -f .claude-plugin/marketplace.json
|
||||||
|
|
||||||
|
- name: Validate SKILL frontmatter fields
|
||||||
|
run: |
|
||||||
|
python - <<'PY'
|
||||||
|
from pathlib import Path
|
||||||
|
p = Path('SKILL.md')
|
||||||
|
text = p.read_text(encoding='utf-8')
|
||||||
|
assert text.startswith('---\n'), 'SKILL.md must start with YAML frontmatter'
|
||||||
|
end = text.find('\n---\n', 4)
|
||||||
|
assert end != -1, 'SKILL.md frontmatter must close with ---'
|
||||||
|
fm = text[4:end]
|
||||||
|
assert 'name:' in fm, 'frontmatter missing name'
|
||||||
|
assert 'description:' in fm, 'frontmatter missing description'
|
||||||
|
print('frontmatter OK')
|
||||||
|
PY
|
||||||
|
|
||||||
|
- name: Validate local markdown links
|
||||||
|
run: |
|
||||||
|
python - <<'PY'
|
||||||
|
import re
|
||||||
|
from pathlib import Path
|
||||||
|
|
||||||
|
md_files = list(Path('.').rglob('*.md'))
|
||||||
|
bad = []
|
||||||
|
link_re = re.compile(r'\[[^\]]+\]\(([^)]+)\)')
|
||||||
|
|
||||||
|
for f in md_files:
|
||||||
|
txt = f.read_text(encoding='utf-8', errors='ignore')
|
||||||
|
for m in link_re.finditer(txt):
|
||||||
|
link = m.group(1).strip()
|
||||||
|
if link.startswith('http://') or link.startswith('https://') or link.startswith('#'):
|
||||||
|
continue
|
||||||
|
if link.startswith('mailto:'):
|
||||||
|
continue
|
||||||
|
target = (f.parent / link.split('#',1)[0]).resolve()
|
||||||
|
if not target.exists():
|
||||||
|
bad.append((str(f), link))
|
||||||
|
|
||||||
|
if bad:
|
||||||
|
for file, link in bad:
|
||||||
|
print(f'Broken link in {file}: {link}')
|
||||||
|
raise SystemExit(1)
|
||||||
|
|
||||||
|
print('markdown links OK')
|
||||||
|
PY
|
||||||
|
|
||||||
|
- name: Check failure-mode references are present
|
||||||
|
run: |
|
||||||
|
test -f references/identity-churn.md
|
||||||
|
test -f references/secret-exposure.md
|
||||||
|
test -f references/blast-radius.md
|
||||||
|
test -f references/ci-drift.md
|
||||||
|
test -f references/compliance-gates.md
|
||||||
|
|
||||||
|
- name: Basic markdown style checks
|
||||||
|
run: |
|
||||||
|
python - <<'PY'
|
||||||
|
from pathlib import Path
|
||||||
|
issues = []
|
||||||
|
for f in Path('.').rglob('*.md'):
|
||||||
|
lines = f.read_text(encoding='utf-8', errors='ignore').splitlines()
|
||||||
|
for i, line in enumerate(lines, start=1):
|
||||||
|
if line.endswith(' '):
|
||||||
|
issues.append(f'{f}:{i}: trailing double-space')
|
||||||
|
if issues:
|
||||||
|
print('\n'.join(issues))
|
||||||
|
raise SystemExit(1)
|
||||||
|
print('basic markdown style OK')
|
||||||
|
PY
|
||||||
1
skills/terrashark/.gitignore
vendored
Normal file
1
skills/terrashark/.gitignore
vendored
Normal file
|
|
@ -0,0 +1 @@
|
||||||
|
.claude/settings.local.json
|
||||||
3
skills/terrashark/CHANGELOG.md
Normal file
3
skills/terrashark/CHANGELOG.md
Normal file
|
|
@ -0,0 +1,3 @@
|
||||||
|
# Changelog
|
||||||
|
|
||||||
|
Init
|
||||||
27
skills/terrashark/CODE_OF_CONDUCT.md
Normal file
27
skills/terrashark/CODE_OF_CONDUCT.md
Normal file
|
|
@ -0,0 +1,27 @@
|
||||||
|
# Code of Conduct
|
||||||
|
|
||||||
|
## Our Standards
|
||||||
|
|
||||||
|
We are committed to providing a welcoming and respectful environment for everyone, regardless of experience level.
|
||||||
|
|
||||||
|
**Expected behavior:**
|
||||||
|
|
||||||
|
- Be respectful and constructive in discussions and code reviews
|
||||||
|
- Accept constructive criticism gracefully
|
||||||
|
- Focus on what is best for the project and community
|
||||||
|
- Show empathy towards other contributors
|
||||||
|
|
||||||
|
**Unacceptable behavior:**
|
||||||
|
|
||||||
|
- Harassment, insults, or derogatory comments
|
||||||
|
- Trolling or deliberately inflammatory remarks
|
||||||
|
- Publishing others' private information without consent
|
||||||
|
- Any conduct that would be considered inappropriate in a professional setting
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
|
||||||
|
This code of conduct applies to all project spaces: issues, pull requests, discussions, and any other communication channels associated with this repository.
|
||||||
|
|
||||||
|
## Attribution
|
||||||
|
|
||||||
|
This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org/), version 2.1.
|
||||||
67
skills/terrashark/CONTRIBUTING.md
Normal file
67
skills/terrashark/CONTRIBUTING.md
Normal file
|
|
@ -0,0 +1,67 @@
|
||||||
|
# Contributing
|
||||||
|
|
||||||
|
Thanks for contributing to Terrashark.
|
||||||
|
|
||||||
|
## Goal of this repo
|
||||||
|
|
||||||
|
Improve Terraform/OpenTofu output quality while staying lean on token usage.
|
||||||
|
|
||||||
|
Every change should answer:
|
||||||
|
- which failure mode does this prevent?
|
||||||
|
- what measurable quality gain does it provide?
|
||||||
|
- is the token cost justified?
|
||||||
|
|
||||||
|
## Development flow
|
||||||
|
|
||||||
|
1. create a branch
|
||||||
|
2. make focused changes
|
||||||
|
3. run local checks
|
||||||
|
4. open PR using `.github/PULL_REQUEST_TEMPLATE.md`
|
||||||
|
|
||||||
|
## Local checks
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# quick sanity checks
|
||||||
|
rg -n "FIXME|placeholder-text" README.md SKILL.md references/*.md
|
||||||
|
python - <<'PY'
|
||||||
|
from pathlib import Path
|
||||||
|
assert Path('SKILL.md').exists()
|
||||||
|
assert Path('README.md').exists()
|
||||||
|
for p in [
|
||||||
|
'references/identity-churn.md',
|
||||||
|
'references/secret-exposure.md',
|
||||||
|
'references/blast-radius.md',
|
||||||
|
'references/ci-drift.md',
|
||||||
|
'references/compliance-gates.md',
|
||||||
|
]:
|
||||||
|
assert Path(p).exists(), f'missing {p}'
|
||||||
|
print('basic structure OK')
|
||||||
|
PY
|
||||||
|
```
|
||||||
|
|
||||||
|
## Content rules
|
||||||
|
|
||||||
|
- Keep examples original and clearly distinct.
|
||||||
|
- Prefer failure-mode framing over generic "best-practice dump" text.
|
||||||
|
- Avoid provider-specific deep dives unless they directly reduce a known LLM failure mode.
|
||||||
|
- Keep claims precise; avoid vague "always" language when tradeoffs exist.
|
||||||
|
|
||||||
|
## Required for PR approval
|
||||||
|
|
||||||
|
- clear mapping to one or more failure modes
|
||||||
|
- no contradictory guidance across references
|
||||||
|
- updated links/indexes if files were moved/renamed
|
||||||
|
- validation workflow passing (`.github/workflows/validate.yml`)
|
||||||
|
|
||||||
|
## Security
|
||||||
|
|
||||||
|
- never commit credentials, tokens, or secret values
|
||||||
|
- do not paste real state snippets containing sensitive data
|
||||||
|
|
||||||
|
## Community
|
||||||
|
|
||||||
|
Open an issue with:
|
||||||
|
- observed hallucination/failure pattern
|
||||||
|
- minimal reproducible prompt/context
|
||||||
|
- expected behavior
|
||||||
|
|
||||||
7
skills/terrashark/LICENSE
Normal file
7
skills/terrashark/LICENSE
Normal file
|
|
@ -0,0 +1,7 @@
|
||||||
|
Copyright 2025 Lukas Niessen <lks.niessen@gmail.com> https://lukasniessen.com
|
||||||
|
|
||||||
|
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
|
||||||
|
|
||||||
|
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
|
||||||
|
|
||||||
|
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||||
161
skills/terrashark/PHILOSOPHY.md
Normal file
161
skills/terrashark/PHILOSOPHY.md
Normal file
|
|
@ -0,0 +1,161 @@
|
||||||
|
# Philosophy
|
||||||
|
|
||||||
|
This document describes TerraShark's design strategy, architectural decisions, and the empirical process behind its content.
|
||||||
|
|
||||||
|
## Failure-Mode-First Architecture
|
||||||
|
|
||||||
|
TerraShark is built around a single insight: telling an LLM *what good Terraform looks like* is less effective than telling it *how to think about Terraform problems*.
|
||||||
|
|
||||||
|
The core SKILL.md is not a reference manual. It is a 7-step operational workflow:
|
||||||
|
|
||||||
|
1. **Capture execution context** -- runtime, version, providers, backend, execution path, criticality
|
||||||
|
2. **Diagnose likely failure modes** -- identity churn, secret exposure, blast radius, CI drift, compliance gate gaps
|
||||||
|
3. **Load only relevant references** -- pull targeted guidance, not everything
|
||||||
|
4. **Propose fix path with risk controls** -- why this works, what could go wrong, guardrails
|
||||||
|
5. **Generate implementation artifacts** -- HCL, migration blocks, CI updates, compliance controls
|
||||||
|
6. **Validate before finalize** -- command sequence tailored to runtime and risk tier
|
||||||
|
7. **Output contract** -- assumptions, tradeoffs, validation plan, rollback notes
|
||||||
|
|
||||||
|
The model diagnoses before it generates. This prevents the most common failure pattern in LLM-assisted IaC: producing syntactically valid but operationally dangerous code.
|
||||||
|
|
||||||
|
## Token Efficiency
|
||||||
|
|
||||||
|
Context window space is a finite resource. Every token spent on skill content is a token unavailable for the user's actual codebase, conversation history, and tool results.
|
||||||
|
|
||||||
|
TerraShark is designed for minimal activation cost. The core SKILL.md is 86 lines (~600 tokens). It contains no HCL examples, no inline code blocks, no tutorial material. It is purely procedural: a workflow the model follows.
|
||||||
|
|
||||||
|
Depth lives in 19 granular reference files. The model loads only the 1-2 files relevant to the diagnosed failure mode. A query about secret handling never loads the CI delivery patterns. A query about module architecture never loads the compliance gates.
|
||||||
|
|
||||||
|
This granularity matters. A single large reference file forces the model to process thousands of irrelevant tokens. 19 small files let it load precisely what it needs.
|
||||||
|
|
||||||
|
## LLM-Aware Guardrails
|
||||||
|
|
||||||
|
Every reference file that covers a risk domain includes an **LLM mistake checklist** -- a list of specific errors that language models make when generating Terraform code. Examples:
|
||||||
|
|
||||||
|
- Defaulting to `count` instead of `for_each` for collections
|
||||||
|
- Omitting `moved` blocks during refactors, causing destroy/create cycles
|
||||||
|
- Using `sensitive` and assuming the value is safe from state
|
||||||
|
- Proposing plaintext credential defaults "for demo purposes"
|
||||||
|
- Recommending CLI-only `terraform import` instead of declarative import blocks
|
||||||
|
|
||||||
|
These checklists exist because the model needs to know *what it gets wrong*, not just *what is correct*. A reference that only shows the right pattern still allows the model to hallucinate the wrong one. A reference that explicitly names the hallucination pattern reduces it.
|
||||||
|
|
||||||
|
The **Feature guard table** in `coding-standards.md` takes this further: it maps Terraform features to their minimum version and the specific LLM error pattern associated with each. This lets the model check whether a feature is available for the target runtime before emitting it.
|
||||||
|
|
||||||
|
## Output Contracts
|
||||||
|
|
||||||
|
Every TerraShark response includes a structured output contract:
|
||||||
|
|
||||||
|
- **Assumptions and version floor** -- what the model assumed about the environment
|
||||||
|
- **Selected failure modes** -- which risks were diagnosed
|
||||||
|
- **Chosen remediation and tradeoffs** -- what was recommended and what was traded off
|
||||||
|
- **Validation/test plan** -- how to verify the output
|
||||||
|
- **Rollback/recovery notes** -- how to undo if something goes wrong
|
||||||
|
|
||||||
|
This makes outputs auditable. A reader can check whether the model's assumptions were correct, whether the right failure modes were identified, and whether the rollback path is viable -- before applying anything.
|
||||||
|
|
||||||
|
## Reference Granularity
|
||||||
|
|
||||||
|
The 19 reference files are organized by concern, not by Terraform concept:
|
||||||
|
|
||||||
|
**Primary failure modes** (loaded when the failure mode is diagnosed):
|
||||||
|
- Identity churn, secret exposure, blast radius, CI drift, compliance gates
|
||||||
|
|
||||||
|
**Structural guidance** (loaded when designing, refactoring, or changing backends):
|
||||||
|
- Structure and state, backend state safety, module architecture, coding standards
|
||||||
|
|
||||||
|
**Operational references** (loaded for specific tasks):
|
||||||
|
- Migration playbooks, testing matrix, CI delivery patterns, security and governance, quick ops
|
||||||
|
|
||||||
|
**Pattern banks** (loaded for review or teaching):
|
||||||
|
- Good examples, bad examples, neutral examples, do/don't patterns
|
||||||
|
|
||||||
|
**Integration and meta**:
|
||||||
|
- MCP integration, token balance rationale
|
||||||
|
|
||||||
|
Each file is self-contained. No file depends on another file being loaded simultaneously.
|
||||||
|
|
||||||
|
## Failure Modes as First-Class Concepts
|
||||||
|
|
||||||
|
TerraShark names five failure modes explicitly:
|
||||||
|
|
||||||
|
1. **Identity churn** -- resource addressing instability, refactor breakage, index-based identity
|
||||||
|
2. **Secret exposure** -- secrets leaking through state, logs, defaults, or artifacts
|
||||||
|
3. **Blast radius** -- oversized stacks, weak boundaries, unsafe production applies
|
||||||
|
4. **CI drift** -- version mismatches, unreviewed applies, missing plan artifacts
|
||||||
|
5. **Compliance gate gaps** -- missing policies, approvals, audit controls, evidence
|
||||||
|
|
||||||
|
These are not arbitrary categories. They represent the five most common ways LLM-generated Terraform causes real damage. Every piece of content in the skill maps to at least one of these failure modes. Content that does not reduce the probability of any failure mode is excluded.
|
||||||
|
|
||||||
|
## Deep Hierarchy Model
|
||||||
|
|
||||||
|
For platform engineering at scale, TerraShark defines a 5-level module hierarchy:
|
||||||
|
|
||||||
|
- **L0 primitives** -- one resource family, strict contract
|
||||||
|
- **L1 composites** -- capability units built from primitives
|
||||||
|
- **L2 domain stacks** -- bounded business domains (payments, identity, observability)
|
||||||
|
- **L3 environment roots** -- env-specific wiring and configuration
|
||||||
|
- **L4 org orchestration** -- account/project vending and shared policy baselines
|
||||||
|
|
||||||
|
Dependencies flow downward only. No lateral imports across the same level without an explicit interface contract. Each level owns its state boundary and apply lifecycle.
|
||||||
|
|
||||||
|
## Content Inclusion Rules
|
||||||
|
|
||||||
|
Content enters TerraShark only when at least one condition is met:
|
||||||
|
|
||||||
|
1. It materially lowers the probability of destructive or non-compliant changes
|
||||||
|
2. It prevents common plan/apply surprises (identity churn, drift, unsafe upgrades)
|
||||||
|
3. It encodes organizational guardrails that general model knowledge cannot infer
|
||||||
|
|
||||||
|
Content is excluded when:
|
||||||
|
|
||||||
|
1. It is generic Terraform/OpenTofu knowledge with low failure impact
|
||||||
|
2. It is provider-specific deep design that belongs in project docs
|
||||||
|
3. It duplicates an existing rule without adding a new decision signal
|
||||||
|
|
||||||
|
If repeated failure patterns emerge, targeted lines are added for that specific failure mode instead of broad expansion.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Token Experiment
|
||||||
|
|
||||||
|
The content in TerraShark was not designed by intuition. It was empirically tested.
|
||||||
|
|
||||||
|
### Process
|
||||||
|
|
||||||
|
1. **Started large.** The initial reference content was significantly larger -- broader coverage, more examples, more inline explanations, more tutorial-style material.
|
||||||
|
|
||||||
|
2. **Built an automated test suite.** A large set of practical Terraform/OpenTofu task patterns was assembled: module creation, refactoring, CI pipeline setup, migration, security review, compliance checks, and others.
|
||||||
|
|
||||||
|
3. **Measured baseline quality.** The full-size skill was run against the test suite. Output quality was scored across correctness, safety, completeness, and hallucination rate.
|
||||||
|
|
||||||
|
4. **Stripped content iteratively.** Sections were removed one at a time. After each removal, the full test suite was re-run.
|
||||||
|
|
||||||
|
5. **Measured quality impact.** For each removal:
|
||||||
|
- If quality dropped: the content was restored. It carried signal the model needed.
|
||||||
|
- If quality stayed stable: the content was permanently removed. It was redundant with the model's existing knowledge.
|
||||||
|
|
||||||
|
6. **Converged on current size.** The process continued until every remaining section was load-bearing -- removing any further content caused measurable quality degradation.
|
||||||
|
|
||||||
|
### What Survived
|
||||||
|
|
||||||
|
The content that survived the stripping process reveals what models actually need help with versus what they already know:
|
||||||
|
|
||||||
|
- **Module role boundaries and composition rules** -- models struggle with when to split modules, how deep hierarchies should work, and where business logic belongs
|
||||||
|
- **Migration playbooks** -- models frequently omit `moved` blocks, mishandle `count`-to-`for_each` transitions, and skip import strategies
|
||||||
|
- **Native test caveats** -- models incorrectly index set-type blocks, assert computed values in plan mode, and treat mocked providers as integration coverage
|
||||||
|
- **CI delivery templates** -- models produce CI pipelines that skip policy checks, re-run plan during apply instead of using artifacts, and lack environment protection
|
||||||
|
- **Quick troubleshooting** -- models struggle with operational failures (stuck locks, backend migration, provider auth in CI) that are not well-covered in training data
|
||||||
|
|
||||||
|
### What Was Removed
|
||||||
|
|
||||||
|
Content that did not affect output quality when removed:
|
||||||
|
|
||||||
|
- Generic HCL syntax tutorials (models know this)
|
||||||
|
- Provider-specific resource deep dives (better served by MCP or docs)
|
||||||
|
- Broad "best practice" prose without failure-mode framing (low signal density)
|
||||||
|
- Duplicate explanations of concepts covered by multiple rules
|
||||||
|
|
||||||
|
### Design Principle
|
||||||
|
|
||||||
|
The token experiment established a core design principle: **high signal density**. Every line in TerraShark must earn its token cost by preventing a specific failure mode or encoding knowledge the model demonstrably lacks. Content that merely restates what the model already knows is actively harmful -- it burns context window space without improving output quality.
|
||||||
352
skills/terrashark/README.md
Normal file
352
skills/terrashark/README.md
Normal file
|
|
@ -0,0 +1,352 @@
|
||||||
|
# Terraform Skill for Claude Code and Codex: TerraShark
|
||||||
|
|
||||||
|
<div align="center" name="top">
|
||||||
|
<img align="center" src="assets/logo.png" width="180" height="180" alt="TerraShark Logo">
|
||||||
|
|
||||||
|
<!-- spacer -->
|
||||||
|
<p></p>
|
||||||
|
|
||||||
|
[](https://docs.claude.ai/docs/agent-skills)
|
||||||
|
[](https://developers.openai.com/codex/skills/)
|
||||||
|
[](https://opensource.org/licenses/MIT)
|
||||||
|
[](https://github.com/LukasNiessen/terrashark)
|
||||||
|
|
||||||
|
</div>
|
||||||
|
|
||||||
|
The #1 Terraform skill for Claude Code and Codex, measured by GitHub stars.
|
||||||
|
|
||||||
|
### Fixes Hallucinations.
|
||||||
|
|
||||||
|
LLMs hallucinate a lot when it comes to Terraform. This skill fixes it. It includes best practices for Terraform and OpenTofu - good, bad, and neutral examples so the AI avoids common mistakes. Using TerraShark, the AI keeps proven practices in mind, eliminates hallucinations, and defaults to modular, reusable, security-first design.
|
||||||
|
|
||||||
|
### Very Token-Efficient.
|
||||||
|
|
||||||
|
Most Terraform skills dump huge text-of-walls onto the agent and burn expensive tokens - with no upside. LLMs don't need the entire Terraform docs again. TerraShark was aggressively de-duplicated and optimized for maximum quality per token.
|
||||||
|
|
||||||
|
### Based on HashiCorp's Official Best Practices.
|
||||||
|
|
||||||
|
TerraShark is primarily based on [HashiCorp official recommended practices](https://developer.hashicorp.com/terraform/cloud-docs/recommended-practices). When guidance conflicts, it prioritizes HashiCorp's recommendations.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
[Quick Start](#-quick-start) • [Why TerraShark?](#-library-comparison) • [Token Strategy](#-token-strategy) • [What's Included](#-whats-included) • [How It Works](#-how-it-works) • [Philosophy](PHILOSOPHY.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ⚡ 2 min Quickstart
|
||||||
|
|
||||||
|
### Option 1: Clone
|
||||||
|
|
||||||
|
**macOS / Linux:**
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git clone https://github.com/LukasNiessen/terrashark.git ~/.claude/skills/terrashark
|
||||||
|
```
|
||||||
|
|
||||||
|
**Windows (Powershell):**
|
||||||
|
|
||||||
|
```powershell
|
||||||
|
git clone https://github.com/LukasNiessen/terrashark.git "$env:USERPROFILE\.claude\skills\terrashark"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Windows (Command Prompt):**
|
||||||
|
|
||||||
|
```powershell
|
||||||
|
git clone https://github.com/LukasNiessen/terrashark.git "%USERPROFILE%\.claude\skills\terrashark"
|
||||||
|
```
|
||||||
|
|
||||||
|
That's it. Claude Code auto-discovers skills in `~/.claude/skills/` - no restart needed.
|
||||||
|
|
||||||
|
### Option 2: Marketplace
|
||||||
|
|
||||||
|
Claude Code has a built-in plugin system with marketplace support. Instead of cloning manually, you can add TerraShark's marketplace and install directly from the CLI:
|
||||||
|
|
||||||
|
```
|
||||||
|
/plugin marketplace add LukasNiessen/terrashark
|
||||||
|
/plugin install terrashark
|
||||||
|
```
|
||||||
|
|
||||||
|
Or use the interactive plugin manager - run `/plugin`, switch to the **Discover** tab, and install from there. The marketplace reads the `.claude-plugin/marketplace.json` in this repo to register TerraShark as an installable plugin.
|
||||||
|
|
||||||
|
### Option 3: Codex
|
||||||
|
|
||||||
|
Codex has no global skill system - setup is per-project. Clone TerraShark into your repo and reference it from your `AGENTS.md`:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Clone into your project root
|
||||||
|
git clone https://github.com/LukasNiessen/terrashark.git .terrashark
|
||||||
|
```
|
||||||
|
|
||||||
|
Then add to your `AGENTS.md` (or create one in the repo root):
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Terraform
|
||||||
|
|
||||||
|
When working with Terraform or OpenTofu, follow the workflow in `.terrashark/SKILL.md`.
|
||||||
|
Load references from `.terrashark/references/` as needed.
|
||||||
|
```
|
||||||
|
|
||||||
|
### That's it!
|
||||||
|
|
||||||
|
Done. Now ask Claude Code / Codex any Terraform question. TerraShark responses follow the 7-step failure-mode workflow and include an output contract with assumptions, tradeoffs, and rollback notes.
|
||||||
|
|
||||||
|
**Invoke explicitly:**
|
||||||
|
|
||||||
|
```bash
|
||||||
|
/terrashark Create a multi-region S3 module with replication
|
||||||
|
```
|
||||||
|
|
||||||
|
```bash
|
||||||
|
/terrashark Refactor our EKS stack into separate state files per environment, add moved blocks to avoid recreation, set up a GitHub Actions pipeline with plan on PR and gated apply on merge, and wire in Checkov for compliance scanning
|
||||||
|
```
|
||||||
|
|
||||||
|
**Or just ask naturally** - TerraShark activates automatically for any Terraform/OpenTofu task:
|
||||||
|
|
||||||
|
```
|
||||||
|
Review my main.tf for security issues
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
Migrate this module from count to for_each
|
||||||
|
```
|
||||||
|
|
||||||
|
## 🎬 Demo
|
||||||
|
|
||||||
|
https://github.com/user-attachments/assets/2bc4c9ff-9f54-4a49-8bf0-5cfc0f26dec6
|
||||||
|
|
||||||
|
## 📊 Library Comparison
|
||||||
|
|
||||||
|
Here's how TerraShark compares to other Terraform and OpenTofu agent skills:
|
||||||
|
|
||||||
|
| Feature | **TerraShark** | **Anton Babenko terraform-skill** | **terraform-patterns** |
|
||||||
|
| -------------------------------- | ----------------------------------------------------- | --------------------------------- | ------------------------------------ |
|
||||||
|
| **Core Architecture** | ✅ Failure-mode workflow | ⚠️ Static reference manual | ⚠️ Pattern checklist |
|
||||||
|
| **SKILL.md Activation Cost** | ✅ ~600 tokens | ⚠️ ~4,400 tokens | ⚠️ Single broad reference |
|
||||||
|
| **Reference Granularity** | ✅ 19 focused files | ⚠️ 6 large files | ❌ No focused reference library |
|
||||||
|
| **Token Burn Per Query** | ✅ Low (load 1-2 small refs) | ⚠️ High for deep references | ⚠️ Loads broad guidance |
|
||||||
|
| **Diagnoses Before Generating** | ✅ Step 2 requires diagnosis | ❌ No | ❌ No |
|
||||||
|
| **Hallucination Prevention** | ✅ Core design goal | ⚠️ Indirect via best practices | ⚠️ Indirect via patterns |
|
||||||
|
| **Output Contract** | ✅ Assumptions, tradeoffs, rollback | ❌ No | ❌ No |
|
||||||
|
| **Failure-Mode Coverage** | ✅ Identity, secrets, blast radius, CI, compliance | ⚠️ General state/security advice | ⚠️ General anti-pattern summary |
|
||||||
|
| **Migration Playbooks** | ✅ 5 dedicated playbooks | ⚠️ Partial inline snippets | ⚠️ Import and moved-block notes |
|
||||||
|
| **Good/Bad/Neutral Examples** | ✅ 3 dedicated files | ⚠️ Inline DO/DON'T examples | ⚠️ Inline BAD/GOOD snippets |
|
||||||
|
| **Do/Don't Checklist** | ✅ Dedicated file | ⚠️ Inline only | ⚠️ Inline only |
|
||||||
|
| **Compliance Framework Mapping** | ✅ ISO 27001, SOC 2, FedRAMP, GDPR, PCI DSS, HIPAA | ⚠️ Scanner-oriented guidance | ❌ No |
|
||||||
|
| **Trusted Module Awareness** | ✅ AWS, Azure, GCP, OCI, IBM loaded conditionally | ⚠️ AWS module context | ❌ No |
|
||||||
|
| **MCP Integration Guidance** | ✅ Dedicated reference | ⚠️ Optional Terraform MCP mention | ❌ No |
|
||||||
|
| **Claude + Codex Support** | ✅ First-class Claude Code and Codex setup | ⚠️ Broad multi-agent setup | ⚠️ Claude plugin oriented |
|
||||||
|
| **Security-First Defaults** | ✅ Built into the workflow | ⚠️ Checklist-style | ⚠️ Style-guide based |
|
||||||
|
| **CI/CD Templates** | ✅ GitHub Actions, GitLab CI, Atlantis, Infracost | ✅ GitHub Actions, GitLab CI | ⚠️ Pipeline rules only |
|
||||||
|
| **License** | ✅ MIT | ⚠️ Apache 2.0 | ❌ Not highlighted in skill listing |
|
||||||
|
|
||||||
|
As you see in the table, there are some features that are only supported by us. Here is a brief highlight of those that we believe are the most critical of them:
|
||||||
|
|
||||||
|
- **Failure-mode workflow**: TerraShark does not just give the agent Terraform facts. It forces the agent to identify the likely failure mode first, then load the exact reference material needed for that risk.
|
||||||
|
|
||||||
|
- **Output contract**: TerraShark responses include assumptions, remediation choices, tradeoffs, validation steps, and rollback notes. Other skills leave that structure to the model.
|
||||||
|
|
||||||
|
- **Token efficiency**: TerraShark keeps the activation path tiny and moves depth into focused references. This gives the agent the right Terraform context without turning every request into a large reference dump.
|
||||||
|
|
||||||
|
- **Compliance mapping**: TerraShark includes explicit mappings for ISO 27001, SOC 2, FedRAMP, GDPR, PCI DSS, and HIPAA. Other skills focus more on scanners than audit-ready control mapping.
|
||||||
|
|
||||||
|
- **Trusted module awareness**: TerraShark knows when to prefer mature vendor and community modules for AWS, Azure, GCP, Oracle Cloud, and IBM Cloud, reducing the surface area for hallucinated raw resources.
|
||||||
|
|
||||||
|
- **LLM-specific hallucination prevention**: TerraShark is designed around the ways AI agents fail at infrastructure code: unstable identity, leaked secrets, wide blast radius, CI drift, and weak compliance gates.
|
||||||
|
|
||||||
|
### TerraShark vs terraform-skill
|
||||||
|
|
||||||
|
The key difference is architectural. **terraform-skill** is a static reference manual: it dumps ~4,400 tokens into context on every activation, then loads additional reference files that can be over 1,000 lines each. It gives Claude information but never tells it _how to think_ about a problem. There's no diagnosis step, no risk assessment, and no structured output - Claude reads the reference and generates whatever it thinks fits.
|
||||||
|
|
||||||
|
**TerraShark** takes the opposite approach. The core SKILL.md is an 86-line operational workflow that costs ~600 tokens on activation - **over 7x leaner**. Instead of front-loading a wall of text, it forces Claude through a diagnostic sequence: capture context → identify failure modes → load _only_ the relevant references → propose fixes with explicit risk controls → validate → deliver a structured output contract.
|
||||||
|
|
||||||
|
This matters for three reasons:
|
||||||
|
|
||||||
|
1. **Token efficiency.** terraform-skill burns ~4,400 tokens just to activate, before any reference files. A single reference file like `module-patterns.md` (1,126 lines, ~7,000 tokens) can double the cost again. TerraShark's activation is ~600 tokens, and its 19 granular reference files mean Claude loads only what's needed - typically one or two small, focused docs instead of one massive dump.
|
||||||
|
|
||||||
|
2. **Hallucination prevention.** terraform-skill provides good patterns but never asks Claude to _diagnose what could go wrong_. TerraShark's Step 2 forces failure-mode identification before any code is generated. Step 4 requires explicit risk controls for every fix. Step 7 enforces an output contract with assumptions, tradeoffs, and rollback notes. This is the difference between giving someone a cookbook and giving them a diagnostic checklist.
|
||||||
|
|
||||||
|
3. **Reference coverage.** TerraShark ships 19 focused reference files covering failure modes, backend-specific state safety, migration playbooks, good/bad/neutral examples, do/don't checklists, compliance framework mappings, and MCP integration. terraform-skill has 6 larger files that go deep on testing and module patterns but lack migration playbooks, explicit anti-pattern banks, compliance mappings beyond a few frameworks, and MCP guidance.
|
||||||
|
|
||||||
|
**In short:** TerraShark is the better skill due to 7x leaner activation, failure-mode-first diagnostic workflow, output contracts, granular references, and LLM-specific hallucination prevention. terraform-skill wins on HCL example depth and testing docs, but TerraShark's architecture is fundamentally better designed for the core use case of LLM-assisted IaC generation.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🕵️ Token Strategy
|
||||||
|
|
||||||
|
- Keep `SKILL.md` procedural and compact
|
||||||
|
- Keep references focused on failure-prone decisions
|
||||||
|
- Exclude broad tutorial material with low safety impact
|
||||||
|
- Add depth only when measured quality would otherwise drop
|
||||||
|
|
||||||
|
See `references/token-balance-rationale.md` for the full decision and tradeoffs.
|
||||||
|
|
||||||
|
## 🧱 Trusted Module Awareness
|
||||||
|
|
||||||
|
Hand-rolled `resource` blocks are one of the largest hallucination surfaces for LLMs; attribute names, defaults, and iteration shapes are where models drift. TerraShark recognizes the major vendor-maintained and community module registries and defaults to using them instead of generating raw resources, whenever a mature module covers the requested service.
|
||||||
|
|
||||||
|
### How it helps
|
||||||
|
|
||||||
|
- A pinned registry module replaces hundreds of lines of hand-rolled HCL with a version-locked interface already tested across many production stacks
|
||||||
|
- Removes attribute-name, default-value, and `for_each` drift; the exact spots where LLMs slip
|
||||||
|
- Enforces **exact** version pinning for production, so module upgrades don't silently change generated resource addresses
|
||||||
|
|
||||||
|
### When it loads (lean-token approach)
|
||||||
|
|
||||||
|
`references/conditional/trusted-modules.md` is pulled into context **only when the detected provider is one of the supported clouds**. AWS-only projects never pay the token cost for Azure or GCP guidance, and vice versa, matching TerraShark's core token-efficiency design.
|
||||||
|
|
||||||
|
### Supported providers
|
||||||
|
|
||||||
|
| Cloud | Registry namespace | Program |
|
||||||
|
| ------------ | -------------------------- | ---------------------------------- |
|
||||||
|
| AWS | `terraform-aws-modules` | Community standard |
|
||||||
|
| Azure | `Azure` | Azure Verified Modules (AVM) |
|
||||||
|
| GCP | `terraform-google-modules` | Cloud Foundation Toolkit |
|
||||||
|
| Oracle Cloud | `oracle-terraform-modules` | Vendor-maintained |
|
||||||
|
| IBM Cloud | `terraform-ibm-modules` | IBM Deployable Architectures |
|
||||||
|
|
||||||
|
Other ecosystems (Alibaba Cloud, DigitalOcean, Hetzner, etc.) are intentionally not included yet, their module programs are still small or early-stage, so recommending them as defaults would trade one failure mode (hallucinated attributes) for another (unmaintained wrappers). If a provider's ecosystem matures, it can be added later.
|
||||||
|
|
||||||
|
## 🐣 What's Included
|
||||||
|
|
||||||
|
- A focused `SKILL.md` execution flow
|
||||||
|
- Failure-mode-first guidance to prevent common IaC hallucinations
|
||||||
|
- Core failure-mode references: identity churn, secret exposure, blast radius, CI drift, compliance gates
|
||||||
|
- Backend-specific state safety loaded conditionally for state storage, locking, migration, and restore work
|
||||||
|
- Expanded architecture guidance (state, boundaries, module roles)
|
||||||
|
- Refactor/migration playbooks for safe evolution
|
||||||
|
- Stronger CI/CD and governance patterns (including Atlantis + Infracost)
|
||||||
|
- Risk-based test depth guidance with native test caveats and Terratest coverage
|
||||||
|
- Rewritten good/bad/neutral example bank
|
||||||
|
- Do/Don't pattern bank and MCP integration guidance
|
||||||
|
- Trusted community/vendor module awareness (AWS, Azure, GCP, OCI, IBM) loaded conditionally
|
||||||
|
|
||||||
|
## 🔲 Repository Layout
|
||||||
|
|
||||||
|
Here an overview of the repository layout.
|
||||||
|
|
||||||
|
| File | Description |
|
||||||
|
| --------------------------------------- | ------------------------------------------------------------- |
|
||||||
|
| `SKILL.md` | Operational workflow for TerraShark |
|
||||||
|
| `PHILOSOPHY.md` | Design strategy, architecture decisions, token experiment |
|
||||||
|
| `references/identity-churn.md` | Address stability, `count`/`for_each`, `moved` safety |
|
||||||
|
| `references/secret-exposure.md` | Preventing secret leakage through state/logs/artifacts |
|
||||||
|
| `references/blast-radius.md` | State boundaries, environment isolation, apply impact control |
|
||||||
|
| `references/ci-drift.md` | Production CI drift prevention and plan/apply integrity |
|
||||||
|
| `references/compliance-gates.md` | Policy gates, approvals, evidence, framework mappings |
|
||||||
|
| `references/structure-and-state.md` | State, boundaries, and apply safety |
|
||||||
|
| `references/conditional/backend-state-safety.md` | Backend-specific state safety and migration guardrails |
|
||||||
|
| `references/module-architecture.md` | Module role model and composition rules |
|
||||||
|
| `references/coding-standards.md` | Naming, typing, iteration, versioning |
|
||||||
|
| `references/migration-playbooks.md` | moved/import/refactor/upgrade playbooks |
|
||||||
|
| `references/testing-matrix.md` | Test tiering, native test caveats, Terratest guidance |
|
||||||
|
| `references/ci-delivery-patterns.md` | CI stages and production-oriented pipeline templates |
|
||||||
|
| `references/security-and-governance.md` | Security controls and operational governance |
|
||||||
|
| `references/quick-ops.md` | Command sequence and troubleshooting shortcuts |
|
||||||
|
| `references/examples-good.md` | Strong implementation examples |
|
||||||
|
| `references/examples-bad.md` | Anti-pattern examples |
|
||||||
|
| `references/examples-neutral.md` | Context-based tradeoff examples |
|
||||||
|
| `references/do-dont-patterns.md` | Do/Don't pattern checklist |
|
||||||
|
| `references/mcp-integration.md` | MCP integration guidance |
|
||||||
|
| `references/conditional/trusted-modules.md` | Canonical community/vendor modules per cloud (conditional) |
|
||||||
|
| `references/token-balance-rationale.md` | Why the skill stays lean and where depth is kept |
|
||||||
|
| `.github/workflows/validate.yml` | CI validation for skill structure and links |
|
||||||
|
| `.github/PULL_REQUEST_TEMPLATE.md` | PR quality and failure-mode checklist |
|
||||||
|
| `.claude-plugin/marketplace.json` | Plugin metadata |
|
||||||
|
|
||||||
|
## 🔎 How It Works
|
||||||
|
|
||||||
|
The skill runs as a failure-mode workflow whenever Claude Code handles Terraform or OpenTofu tasks:
|
||||||
|
|
||||||
|
1. **Capture execution context** - Runtime/version, providers, backend, execution path, risk level
|
||||||
|
2. **Diagnose likely failure mode(s)** - Identity churn, secret exposure, blast radius, CI drift, compliance gate gaps
|
||||||
|
3. **Load only relevant references** - Pull targeted guidance for the failure mode(s) in scope
|
||||||
|
4. **Propose fix path with controls** - Include risk notes, approvals, tests, and rollback expectations
|
||||||
|
5. **Generate implementation artifacts** - HCL changes, migration blocks, CI/policy updates
|
||||||
|
6. **Validate before finalize** - Runtime-appropriate command sequence and risk-tier checks
|
||||||
|
7. **Deliver complete output** - Assumptions, remediation choices, tradeoffs, validation plan, recovery notes
|
||||||
|
|
||||||
|
## 🐲 Scope
|
||||||
|
|
||||||
|
- Terraform and OpenTofu module design/review/refactoring
|
||||||
|
- Safe migration workflows for existing stacks
|
||||||
|
- CI/CD and policy integration for infrastructure delivery
|
||||||
|
- Blast-radius reduction and operational safety
|
||||||
|
|
||||||
|
## ℹ️ FAQ
|
||||||
|
|
||||||
|
**Q: Does this work with OpenTofu?**
|
||||||
|
|
||||||
|
Yes. TerraShark supports both Terraform and OpenTofu. The workflow captures runtime/version first and adapts guidance accordingly.
|
||||||
|
|
||||||
|
**Q: Will this slow down my AI interactions?**
|
||||||
|
|
||||||
|
No. The skill is designed for low token overhead. Only relevant references should be loaded for a given failure mode.
|
||||||
|
|
||||||
|
**Q: Can I use this outside Claude Code?**
|
||||||
|
|
||||||
|
Yes. The references are plain Markdown and can be used from any workflow or AI assistant, **including Codex**. The trigger behavior in `SKILL.md` is optimized for skill-enabled environments.
|
||||||
|
|
||||||
|
**Q: How was the content validated?**
|
||||||
|
|
||||||
|
We started with much larger references and a large automated test suite, then repeatedly removed sections and re-tested. If quality dropped, content was restored. If quality stayed stable, content remained out.
|
||||||
|
|
||||||
|
## 🦊 Contributing
|
||||||
|
|
||||||
|
We highly appreciate contributions. See [CONTRIBUTING.md](CONTRIBUTING.md) and use the PR template for failure-mode and validation details.
|
||||||
|
|
||||||
|
## 💟 Community
|
||||||
|
|
||||||
|
### Maintainers
|
||||||
|
|
||||||
|
• **[LukasNiessen](https://github.com/LukasNiessen)** - Creator and main maintainer
|
||||||
|
|
||||||
|
• **[janMagnusHeimann](https://github.com/janMagnusHeimann)** - Main maintainer
|
||||||
|
|
||||||
|
• **[TristanKruse](https://github.com/TristanKruse)** - Main maintainer
|
||||||
|
|
||||||
|
### Contributors
|
||||||
|
|
||||||
|
<a href="https://github.com/LukasNiessen/terrashark/graphs/contributors">
|
||||||
|
<img src="https://contrib.rocks/image?repo=LukasNiessen/terrashark&max=1000&contributors=10" />
|
||||||
|
</a>
|
||||||
|
|
||||||
|
### Questions
|
||||||
|
|
||||||
|
Found a bug? Want to discuss features?
|
||||||
|
|
||||||
|
- Submit an [issue on GitHub](https://github.com/LukasNiessen/terrashark/issues/new/choose)
|
||||||
|
- Join [GitHub Discussions](https://github.com/LukasNiessen/terrashark/discussions)
|
||||||
|
|
||||||
|
If TerraShark helps your project, please consider:
|
||||||
|
|
||||||
|
- Starring the repository
|
||||||
|
- Suggesting new features
|
||||||
|
- Contributing code or documentation
|
||||||
|
|
||||||
|
### Star History
|
||||||
|
|
||||||
|
[](https://www.star-history.com/#LukasNiessen/terrashark&Date)
|
||||||
|
|
||||||
|
## 📄 License
|
||||||
|
|
||||||
|
This project is under the **MIT** license.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<p align="center">
|
||||||
|
<a href="#top"><strong>Go Back to Top</strong></a>
|
||||||
|
</p>
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Other
|
||||||
|
|
||||||
|
**Version:** v2.3.0
|
||||||
|
|
||||||
|
**Website:** https://terraformskill.com/
|
||||||
|
|
||||||
|
**GitHub Pages:** [https://lukasniessen.github.io/terrashark/](https://lukasniessen.github.io/terrashark/)
|
||||||
|
|
||||||
|
## Conditional Reference Retrieval (CRR)
|
||||||
|
|
||||||
|
TerraShark adheres to Conditional Reference Retrieval (CRR): conditional references live under `references/conditional/`, are loaded only when concrete signals are detected, and neighboring conditional references are not loaded unless the task spans multiple detected routes.
|
||||||
86
skills/terrashark/SKILL.md
Normal file
86
skills/terrashark/SKILL.md
Normal file
|
|
@ -0,0 +1,86 @@
|
||||||
|
---
|
||||||
|
name: terrashark
|
||||||
|
description: "Prevent Terraform/OpenTofu hallucinations by diagnosing and fixing failure modes: identity churn, secret exposure, blast-radius mistakes, CI drift, and compliance gate gaps. Use when generating, reviewing, refactoring, or migrating IaC and when building delivery/testing pipelines."
|
||||||
|
---
|
||||||
|
|
||||||
|
# Terrashark: Failure-Mode Workflow for Terraform/OpenTofu
|
||||||
|
|
||||||
|
Run this workflow top to bottom.
|
||||||
|
|
||||||
|
## 1) Capture execution context
|
||||||
|
|
||||||
|
Record before writing code:
|
||||||
|
- runtime (`terraform` or `tofu`) and exact version
|
||||||
|
- provider(s), target platform, and state backend
|
||||||
|
- execution path (local CLI, CI, HCP Terraform/TFE, Atlantis)
|
||||||
|
- environment criticality (dev/shared/prod)
|
||||||
|
|
||||||
|
If unknown, state assumptions explicitly.
|
||||||
|
|
||||||
|
## 2) Diagnose likely failure mode(s)
|
||||||
|
|
||||||
|
Select one or more based on user intent and risk:
|
||||||
|
- identity churn: resource addressing instability, refactor breakage
|
||||||
|
- secret exposure: secrets in state, logs, defaults, artifacts
|
||||||
|
- blast radius: oversized stacks, weak boundaries, unsafe applies
|
||||||
|
- CI drift: version mismatch, unreviewed applies, missing artifacts
|
||||||
|
- compliance gate gaps: missing policies/approvals/audit controls
|
||||||
|
|
||||||
|
## 3) Load only the relevant reference file(s)
|
||||||
|
|
||||||
|
Primary references:
|
||||||
|
- `references/identity-churn.md`
|
||||||
|
- `references/secret-exposure.md`
|
||||||
|
- `references/blast-radius.md`
|
||||||
|
- `references/ci-drift.md`
|
||||||
|
- `references/compliance-gates.md`
|
||||||
|
|
||||||
|
Supplemental references (only when needed):
|
||||||
|
- `references/testing-matrix.md`
|
||||||
|
- `references/quick-ops.md`
|
||||||
|
- `references/examples-good.md`
|
||||||
|
- `references/examples-bad.md`
|
||||||
|
- `references/examples-neutral.md`
|
||||||
|
- `references/coding-standards.md`
|
||||||
|
- `references/module-architecture.md`
|
||||||
|
- `references/ci-delivery-patterns.md`
|
||||||
|
- `references/security-and-governance.md`
|
||||||
|
- `references/do-dont-patterns.md`
|
||||||
|
- `references/mcp-integration.md`
|
||||||
|
|
||||||
|
Conditional references (CRR; load only on detected signals):
|
||||||
|
- `references/conditional/backend-state-safety.md` (backend is `s3`, `azurerm`, `gcs`, `remote`, `cloud`, `pg`, `consul`, or `local`, or task mentions backend migration, locking, state backup, or restore)
|
||||||
|
- `references/conditional/trusted-modules.md` (provider is `aws`, `azurerm`, `google`, `oci`, or `ibm`)
|
||||||
|
|
||||||
|
Do not load multiple conditional references unless the task spans multiple detected backends, providers, or tools.
|
||||||
|
|
||||||
|
## 4) Propose fix path with explicit risk controls
|
||||||
|
|
||||||
|
For each fix, include:
|
||||||
|
- why this addresses the failure mode
|
||||||
|
- what could still go wrong
|
||||||
|
- guardrails (tests, approvals, rollback)
|
||||||
|
|
||||||
|
## 5) Generate implementation artifacts
|
||||||
|
|
||||||
|
When applicable, output:
|
||||||
|
- HCL changes (typed vars, stable keys, bounded versions)
|
||||||
|
- migration blocks (`moved`, import strategy)
|
||||||
|
- CI pipeline updates (plan/apply separation, artifacts, policy checks)
|
||||||
|
- compliance controls (approvals, policy rules, evidence paths)
|
||||||
|
|
||||||
|
When a trusted registry module covers the requested resource and the user has not asked for raw HCL, default to that module with an exact `version` pin (see `references/conditional/trusted-modules.md`).
|
||||||
|
|
||||||
|
## 6) Validate before finalize
|
||||||
|
|
||||||
|
Always provide command sequence tailored to runtime and risk tier.
|
||||||
|
Never recommend direct production apply without reviewed plan and approval.
|
||||||
|
|
||||||
|
## 7) Output contract
|
||||||
|
|
||||||
|
Return:
|
||||||
|
- assumptions and version floor
|
||||||
|
- selected failure mode(s)
|
||||||
|
- chosen remediation and tradeoffs
|
||||||
|
- validation/test plan
|
||||||
|
- rollback/recovery notes for destructive-impact changes
|
||||||
BIN
skills/terrashark/assets/logo.png
Normal file
BIN
skills/terrashark/assets/logo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 193 KiB |
2
skills/terrashark/docs/.gitignore
vendored
Normal file
2
skills/terrashark/docs/.gitignore
vendored
Normal file
|
|
@ -0,0 +1,2 @@
|
||||||
|
_book/
|
||||||
|
node_modules/
|
||||||
52
skills/terrashark/docs/README.md
Normal file
52
skills/terrashark/docs/README.md
Normal file
|
|
@ -0,0 +1,52 @@
|
||||||
|
# Terraform Skill for Claude Code and Codex: TerraShark
|
||||||
|
|
||||||
|
TerraShark is a lean, failure-mode-first Terraform skill for [Claude Code](https://docs.claude.ai/docs/agent-skills) and [Codex](https://developers.openai.com/codex/skills/). It prevents Terraform and OpenTofu hallucinations by forcing the AI to **diagnose risks before generating code**.
|
||||||
|
|
||||||
|
## Why Use a Terraform Skill?
|
||||||
|
|
||||||
|
LLMs hallucinate frequently when generating Terraform code. They produce configurations that are syntactically valid but operationally dangerous — unstable resource identities, leaked secrets, oversized blast radii, CI drift, and missing compliance gates. TerraShark fixes this by embedding a 7-step diagnostic workflow and 19 granular reference files directly into the AI's context.
|
||||||
|
|
||||||
|
## Key Features
|
||||||
|
|
||||||
|
- **Failure-mode-first architecture** — diagnoses risks before generating code
|
||||||
|
- **~600 token activation cost** — over 7x leaner than alternatives
|
||||||
|
- **19 granular reference files** — loads only what's relevant per query
|
||||||
|
- **LLM-specific guardrails** — explicitly names and prevents common AI hallucination patterns
|
||||||
|
- **Output contracts** — every response includes assumptions, tradeoffs, and rollback notes
|
||||||
|
- **5 migration playbooks** — safe count-to-for_each, rename, import, secrets, and upgrade flows
|
||||||
|
- **Compliance framework mappings** — ISO 27001, SOC 2, FedRAMP, GDPR, PCI DSS, HIPAA
|
||||||
|
- **Production CI/CD templates** — GitHub Actions, GitLab CI, Atlantis, Infracost
|
||||||
|
- **Based on HashiCorp's official best practices** — prioritizes [HashiCorp recommended practices](https://developer.hashicorp.com/terraform/cloud-docs/recommended-practices) when guidance conflicts
|
||||||
|
|
||||||
|
## How It Works
|
||||||
|
|
||||||
|
When Claude Code encounters a Terraform or OpenTofu task, the Terraform skill activates and runs a 7-step workflow:
|
||||||
|
|
||||||
|
1. **Capture execution context** — runtime, version, providers, backend, risk level
|
||||||
|
2. **Diagnose failure modes** — identity churn, secret exposure, blast radius, CI drift, compliance gaps
|
||||||
|
3. **Load relevant references** — pull only the targeted guidance needed
|
||||||
|
4. **Propose fix path** — include risk notes, approvals, tests, and rollback expectations
|
||||||
|
5. **Generate artifacts** — HCL changes, migration blocks, CI/policy updates
|
||||||
|
6. **Validate** — runtime-appropriate command sequence and risk-tier checks
|
||||||
|
7. **Deliver output contract** — assumptions, remediation, tradeoffs, validation plan, recovery notes
|
||||||
|
|
||||||
|
## Quick Install
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# macOS / Linux
|
||||||
|
git clone https://github.com/LukasNiessen/terrashark.git ~/.claude/skills/terrashark
|
||||||
|
|
||||||
|
# Windows (PowerShell)
|
||||||
|
git clone https://github.com/LukasNiessen/terrashark.git "$env:USERPROFILE\.claude\skills\terrashark"
|
||||||
|
```
|
||||||
|
|
||||||
|
That's it. Claude Code auto-discovers skills in `~/.claude/skills/` — no restart needed.
|
||||||
|
|
||||||
|
## Supported Runtimes
|
||||||
|
|
||||||
|
- **Terraform** (all versions, with feature guards for version-specific capabilities)
|
||||||
|
- **OpenTofu** (all versions, with equivalent command mappings)
|
||||||
|
|
||||||
|
## License
|
||||||
|
|
||||||
|
MIT License — see [GitHub repository](https://github.com/LukasNiessen/terrashark) for details.
|
||||||
58
skills/terrashark/docs/SUMMARY.md
Normal file
58
skills/terrashark/docs/SUMMARY.md
Normal file
|
|
@ -0,0 +1,58 @@
|
||||||
|
# Summary
|
||||||
|
|
||||||
|
* [Introduction](README.md)
|
||||||
|
|
||||||
|
## Getting Started
|
||||||
|
|
||||||
|
* [Installation](getting-started/installation.md)
|
||||||
|
* [Quick Start](getting-started/quick-start.md)
|
||||||
|
|
||||||
|
## Core Concepts
|
||||||
|
|
||||||
|
* [The 7-Step Terraform Skill Workflow](core-concepts/workflow.md)
|
||||||
|
* [Five Failure Modes](core-concepts/failure-modes.md)
|
||||||
|
* [Design Philosophy](core-concepts/philosophy.md)
|
||||||
|
|
||||||
|
## Terraform Failure Mode References
|
||||||
|
|
||||||
|
* [Identity Churn](failure-modes/identity-churn.md)
|
||||||
|
* [Secret Exposure](failure-modes/secret-exposure.md)
|
||||||
|
* [Blast Radius](failure-modes/blast-radius.md)
|
||||||
|
* [CI Drift](failure-modes/ci-drift.md)
|
||||||
|
* [Compliance Gate Gaps](failure-modes/compliance-gates.md)
|
||||||
|
|
||||||
|
## Terraform Architecture Guidance
|
||||||
|
|
||||||
|
* [Structure and State](architecture/structure-and-state.md)
|
||||||
|
* [Backend State Safety](architecture/backend-state-safety.md)
|
||||||
|
* [Module Architecture](architecture/module-architecture.md)
|
||||||
|
* [Coding Standards](architecture/coding-standards.md)
|
||||||
|
|
||||||
|
## Terraform Operational Guides
|
||||||
|
|
||||||
|
* [Migration Playbooks](guides/migration-playbooks.md)
|
||||||
|
* [Testing Matrix](guides/testing.md)
|
||||||
|
* [CI/CD Delivery Patterns](guides/ci-delivery.md)
|
||||||
|
* [Security and Governance](guides/security-governance.md)
|
||||||
|
* [Quick Ops and Troubleshooting](guides/quick-ops.md)
|
||||||
|
|
||||||
|
## Terraform Code Examples
|
||||||
|
|
||||||
|
* [Good Patterns](examples/good-patterns.md)
|
||||||
|
* [Bad Patterns (Anti-Patterns)](examples/bad-patterns.md)
|
||||||
|
* [Neutral Patterns (Context-Dependent)](examples/neutral-patterns.md)
|
||||||
|
* [Do and Don't Checklist](examples/do-dont-checklist.md)
|
||||||
|
|
||||||
|
## Integrations
|
||||||
|
|
||||||
|
* [MCP Integration](integrations/mcp-integration.md)
|
||||||
|
|
||||||
|
## Advanced
|
||||||
|
|
||||||
|
* [Token Efficiency Strategy](advanced/token-efficiency.md)
|
||||||
|
* [Comparison with Other Terraform Skills](advanced/comparison.md)
|
||||||
|
|
||||||
|
## Community
|
||||||
|
|
||||||
|
* [Contributing](contributing.md)
|
||||||
|
* [Changelog](changelog.md)
|
||||||
57
skills/terrashark/docs/advanced/comparison.md
Normal file
57
skills/terrashark/docs/advanced/comparison.md
Normal file
|
|
@ -0,0 +1,57 @@
|
||||||
|
# Terraform Skill Comparison: TerraShark vs Alternatives
|
||||||
|
|
||||||
|
A detailed comparison between TerraShark and other approaches to LLM-assisted Terraform code generation.
|
||||||
|
|
||||||
|
## Comparison Overview
|
||||||
|
|
||||||
|
| Dimension | TerraShark | terraform-skill | No Skill |
|
||||||
|
|---|---|---|---|
|
||||||
|
| **SKILL.md activation cost** | ~600 tokens | ~4,400 tokens | 0 |
|
||||||
|
| **Reference granularity** | 19 focused files | 6 large files | — |
|
||||||
|
| **Token burn per query** | Low (load 1-2 small refs) | High (large refs, e.g. 1,126 lines) | 0 |
|
||||||
|
| **Architecture** | Failure-mode workflow | Static reference manual | — |
|
||||||
|
| **Diagnoses before generating** | Yes (Step 2) | No | No |
|
||||||
|
| **Output contract** | Yes — assumptions, tradeoffs, rollback | No | No |
|
||||||
|
| **Migration playbooks** | Yes (5 playbooks) | Partial (inline snippets) | No |
|
||||||
|
| **Good/bad/neutral examples** | Yes (3 dedicated files) | Inline only | No |
|
||||||
|
| **Do/Don't checklist** | Yes (dedicated file) | Inline only | No |
|
||||||
|
| **Compliance framework mapping** | ISO 27001, SOC 2, FedRAMP, GDPR, PCI DSS, HIPAA | Partial | No |
|
||||||
|
| **MCP integration guidance** | Yes | No | No |
|
||||||
|
| **Hallucination prevention** | Core design goal | Not addressed | No |
|
||||||
|
| **Security-first defaults** | Built-in | Checklist-style | No |
|
||||||
|
| **CI/CD templates** | GitHub Actions, GitLab CI, Atlantis, Infracost | GitHub Actions, GitLab CI, Atlantis | No |
|
||||||
|
| **License** | MIT | Apache 2.0 | — |
|
||||||
|
|
||||||
|
## Architectural Difference
|
||||||
|
|
||||||
|
The key difference is architectural.
|
||||||
|
|
||||||
|
**Static reference approach** (terraform-skill and similar): Dumps thousands of tokens into context on every activation, then loads additional reference files that can be over 1,000 lines each. Gives the AI information but never tells it *how to think* about a problem. No diagnosis step, no risk assessment, no structured output.
|
||||||
|
|
||||||
|
**Failure-mode workflow** (TerraShark): The core SKILL.md is an 86-line operational workflow costing ~600 tokens on activation — over 7x leaner. Forces the AI through a diagnostic sequence: capture context, identify failure modes, load only relevant references, propose fixes with explicit risk controls, validate, and deliver a structured output contract.
|
||||||
|
|
||||||
|
## Why This Matters
|
||||||
|
|
||||||
|
### 1. Token Efficiency
|
||||||
|
|
||||||
|
Static skills burn ~4,400 tokens just to activate, before any reference files. A single reference file like `module-patterns.md` (1,126 lines, ~7,000 tokens) can double the cost. TerraShark's activation is ~600 tokens, and its 19 granular reference files mean the AI loads only what's needed.
|
||||||
|
|
||||||
|
### 2. Hallucination Prevention
|
||||||
|
|
||||||
|
Static skills provide good patterns but never ask the AI to diagnose what could go wrong. TerraShark's Step 2 forces failure-mode identification before any code is generated. Step 4 requires explicit risk controls. Step 7 enforces an output contract.
|
||||||
|
|
||||||
|
### 3. Reference Coverage
|
||||||
|
|
||||||
|
TerraShark ships 19 focused reference files covering failure modes, backend-specific state safety, migration playbooks, good/bad/neutral examples, do/don't checklists, compliance framework mappings, and MCP integration. Alternatives typically have fewer, larger files that go deep on some topics but lack migration playbooks, anti-pattern banks, and compliance mappings.
|
||||||
|
|
||||||
|
## When to Use No Skill
|
||||||
|
|
||||||
|
For simple, one-off Terraform questions where the AI's built-in knowledge is sufficient and you don't need:
|
||||||
|
- Failure mode diagnosis
|
||||||
|
- Output contracts
|
||||||
|
- Migration safety
|
||||||
|
- Compliance evidence
|
||||||
|
|
||||||
|
## Summary
|
||||||
|
|
||||||
|
TerraShark provides 7x leaner activation, a failure-mode-first diagnostic workflow, output contracts, granular references, and LLM-specific hallucination prevention. Its architecture is fundamentally designed for the core use case of LLM-assisted IaC generation.
|
||||||
80
skills/terrashark/docs/advanced/token-efficiency.md
Normal file
80
skills/terrashark/docs/advanced/token-efficiency.md
Normal file
|
|
@ -0,0 +1,80 @@
|
||||||
|
# Terraform Skill Token Efficiency Strategy
|
||||||
|
|
||||||
|
This page explains the token efficiency strategy that makes TerraShark the leanest Terraform skill available, and the empirical process used to validate every line of content.
|
||||||
|
|
||||||
|
## The Problem with Large Skills
|
||||||
|
|
||||||
|
Most Terraform skills dump huge walls of text into the AI's context window on every activation. This creates three problems:
|
||||||
|
|
||||||
|
1. **Wasted tokens** — context window space spent on skill content is unavailable for the user's codebase and conversation
|
||||||
|
2. **Signal dilution** — when everything is included, the model has difficulty finding what matters
|
||||||
|
3. **Redundancy** — LLMs already know basic Terraform syntax; restating it burns tokens with no quality improvement
|
||||||
|
|
||||||
|
## TerraShark's Approach
|
||||||
|
|
||||||
|
### Lean Activation (~600 tokens)
|
||||||
|
|
||||||
|
The core `SKILL.md` is 86 lines containing:
|
||||||
|
- No HCL examples
|
||||||
|
- No inline code blocks
|
||||||
|
- No tutorial material
|
||||||
|
- Pure procedure: a workflow the model follows
|
||||||
|
|
||||||
|
### Granular References (19 files)
|
||||||
|
|
||||||
|
Instead of 6 large files (as in alternatives), TerraShark uses 19 focused files. The model loads only the 1-2 files relevant to the diagnosed failure mode.
|
||||||
|
|
||||||
|
### Content Inclusion Rules
|
||||||
|
|
||||||
|
Content enters TerraShark only when at least one condition is met:
|
||||||
|
|
||||||
|
1. It materially lowers the probability of destructive or non-compliant changes
|
||||||
|
2. It prevents common plan/apply surprises
|
||||||
|
3. It encodes organizational guardrails that general model knowledge cannot infer
|
||||||
|
|
||||||
|
Content is excluded when:
|
||||||
|
|
||||||
|
1. It is generic Terraform/OpenTofu knowledge with low failure impact
|
||||||
|
2. It is provider-specific deep design that belongs in project docs
|
||||||
|
3. It duplicates an existing rule without adding a new decision signal
|
||||||
|
|
||||||
|
### Expansion Rule
|
||||||
|
|
||||||
|
If repeated failure patterns emerge, targeted lines are added for that specific failure mode instead of broad expansion.
|
||||||
|
|
||||||
|
## The Token Experiment
|
||||||
|
|
||||||
|
The content was empirically tested, not designed by intuition.
|
||||||
|
|
||||||
|
### Process
|
||||||
|
|
||||||
|
1. Started with significantly larger reference content
|
||||||
|
2. Built automated test suite of practical Terraform/OpenTofu tasks
|
||||||
|
3. Measured baseline quality (correctness, safety, completeness, hallucination rate)
|
||||||
|
4. Stripped sections one at a time, re-running the full test suite
|
||||||
|
5. If quality dropped: content was restored (load-bearing)
|
||||||
|
6. If quality stayed stable: content was permanently removed (redundant)
|
||||||
|
7. Continued until every remaining section was load-bearing
|
||||||
|
|
||||||
|
### What Survived
|
||||||
|
|
||||||
|
Content the model demonstrably needs help with:
|
||||||
|
|
||||||
|
- Module role boundaries and composition rules
|
||||||
|
- Migration playbooks (moved blocks, count-to-for_each, imports)
|
||||||
|
- Native test caveats (set indexing, computed values, mocked providers)
|
||||||
|
- CI delivery templates (policy checks, artifact integrity, env protection)
|
||||||
|
- Quick troubleshooting (stuck locks, backend migration, provider auth in CI)
|
||||||
|
|
||||||
|
### What Was Removed
|
||||||
|
|
||||||
|
Content the model already knows well:
|
||||||
|
|
||||||
|
- Generic HCL syntax tutorials
|
||||||
|
- Provider-specific resource deep dives
|
||||||
|
- Broad "best practice" prose without failure-mode framing
|
||||||
|
- Duplicate explanations
|
||||||
|
|
||||||
|
### Core Principle
|
||||||
|
|
||||||
|
**High signal density.** Every line must earn its token cost by preventing a specific failure mode or encoding knowledge the model demonstrably lacks.
|
||||||
87
skills/terrashark/docs/architecture/backend-state-safety.md
Normal file
87
skills/terrashark/docs/architecture/backend-state-safety.md
Normal file
|
|
@ -0,0 +1,87 @@
|
||||||
|
# Backend State Safety
|
||||||
|
|
||||||
|
This guide covers backend-specific state safety for Terraform and OpenTofu. Use it when configuring a backend, migrating state, handling locks, or reviewing access to state storage.
|
||||||
|
|
||||||
|
## When This Guide Applies
|
||||||
|
|
||||||
|
Load this guidance when the backend is `s3`, `azurerm`, `gcs`, `remote`, `cloud`, `pg`, `consul`, or `local`, or when work mentions backend migration, state storage, locking, force-unlock, state backup, or restore.
|
||||||
|
|
||||||
|
## Why This Matters
|
||||||
|
|
||||||
|
Terraform/OpenTofu state is the source of truth for live resource identity and often contains sensitive values. Backend mistakes can leak secrets, orphan resources, disable locking, or make a routine refactor look like a destructive replacement.
|
||||||
|
|
||||||
|
## Backend Baseline
|
||||||
|
|
||||||
|
- Use remote state for every shared, CI, or production environment
|
||||||
|
- Require locking on every apply path
|
||||||
|
- Encrypt state at rest and in transit
|
||||||
|
- Enable state versioning or point-in-time recovery where the backend supports it
|
||||||
|
- Keep backend storage and lock primitives in a bootstrap root with a separate lifecycle
|
||||||
|
- Never manage the backend bucket/container/table from the same root that uses it as its active backend
|
||||||
|
- Keep backend credentials out of checked-in backend config; prefer workload identity or CI-provided partial backend config
|
||||||
|
|
||||||
|
## Backend-Specific Checks
|
||||||
|
|
||||||
|
| Backend | Required Checks |
|
||||||
|
|---|---|
|
||||||
|
| `s3` | Bucket versioning, encryption, public access block, narrow IAM, lock mechanism configured, state key split by environment/root |
|
||||||
|
| `azurerm` | Storage account encryption, blob soft delete/versioning where available, lease-based locking, private/network restrictions, narrow data-plane RBAC |
|
||||||
|
| `gcs` | Bucket versioning, uniform bucket-level access, encryption policy, narrow IAM, prefix split by environment/root |
|
||||||
|
| `remote` / `cloud` | Workspace boundary matches blast radius, state sharing is restricted, sensitive variables are marked, applies use approved execution mode |
|
||||||
|
| `pg` | TLS, database backups, least-privilege user, lock behavior verified, connection secrets kept out of code |
|
||||||
|
| `consul` | TLS, ACLs, snapshots/backups, highly available quorum, lock/session behavior verified |
|
||||||
|
| `local` | Solo prototype only; do not use for shared, CI, or production environments |
|
||||||
|
|
||||||
|
## Migration Guardrails
|
||||||
|
|
||||||
|
- Do not combine backend migration with unrelated resource changes
|
||||||
|
- Freeze applies for the affected state before migrating
|
||||||
|
- Pull and securely store a state backup before `init -migrate-state`; do not commit it
|
||||||
|
- Record current backend type, address/key, workspace, runtime version, and actor
|
||||||
|
- Migrate the lowest-risk environment first
|
||||||
|
- After migration, compare resource addresses before/after and run a no-op plan
|
||||||
|
- Keep the old backend retained and access-controlled until restore has been tested or the rollback window has passed
|
||||||
|
|
||||||
|
Use `init -migrate-state` when moving state between backends. Use `init -reconfigure` only when intentionally accepting the configured backend without migrating existing state.
|
||||||
|
|
||||||
|
## Lock Handling
|
||||||
|
|
||||||
|
- Treat a lock as a safety signal, not an inconvenience
|
||||||
|
- Before `force-unlock`, verify the lock holder, CI run, process, and timestamp
|
||||||
|
- Never recommend `force-unlock` while an apply may still be running
|
||||||
|
- Serialize applies for shared foundation, backend, identity, and network roots
|
||||||
|
|
||||||
|
## Access and Secret Handling
|
||||||
|
|
||||||
|
- Treat state readers as secret readers
|
||||||
|
- Avoid storing plan/state artifacts in public or broad-access CI logs
|
||||||
|
- If a secret entered state, rotate the secret and use the secret remediation playbook; masking output is not enough
|
||||||
|
- Keep backend read/write permissions separate when the platform supports it
|
||||||
|
|
||||||
|
## LLM Mistake Checklist
|
||||||
|
|
||||||
|
- Suggesting `local` backend for a team, CI, or production stack
|
||||||
|
- Creating backend storage inside the same root that uses it
|
||||||
|
- Omitting a lock strategy for a shared backend
|
||||||
|
- Treating encryption as protection from anyone who can read state
|
||||||
|
- Combining backend migration with broad resource refactors
|
||||||
|
- Recommending `force-unlock` without proving no apply is active
|
||||||
|
- Deleting old backend data immediately after migration
|
||||||
|
- Hard-coding backend credentials in HCL or checked-in config
|
||||||
|
|
||||||
|
## Validation Commands
|
||||||
|
|
||||||
|
Use the active runtime (`terraform` or `tofu`) consistently:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
terraform version
|
||||||
|
terraform workspace show
|
||||||
|
terraform state pull > state-backup.json
|
||||||
|
terraform state list > state-before.txt
|
||||||
|
terraform init -migrate-state
|
||||||
|
terraform state list > state-after.txt
|
||||||
|
diff -u state-before.txt state-after.txt
|
||||||
|
terraform plan -detailed-exitcode
|
||||||
|
```
|
||||||
|
|
||||||
|
Store `state-backup.json` in a secure temporary location outside the repository and delete it only after rollback is no longer needed.
|
||||||
105
skills/terrashark/docs/architecture/coding-standards.md
Normal file
105
skills/terrashark/docs/architecture/coding-standards.md
Normal file
|
|
@ -0,0 +1,105 @@
|
||||||
|
# Terraform Coding Standards
|
||||||
|
|
||||||
|
This guide covers implementation-level consistency for Terraform and OpenTofu code generation, including naming, typing, iteration, and version discipline.
|
||||||
|
|
||||||
|
## Naming and Metadata
|
||||||
|
|
||||||
|
- Use names that reflect business purpose (`payments_api`, `audit_kms`), not temporary implementation details
|
||||||
|
- Reserve `this` for real singleton resources only
|
||||||
|
- Centralize tags/labels in `locals` and apply consistently
|
||||||
|
- Normalize provider-constrained identifiers before use
|
||||||
|
|
||||||
|
### Identifier Normalization Pattern
|
||||||
|
|
||||||
|
Some resources reject characters valid in domains or service names (e.g., `.` in RDS identifiers):
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
locals {
|
||||||
|
raw_name = "${var.domain}-prod"
|
||||||
|
normalized_name = regexreplace(lower(local.raw_name), "[^a-z0-9-]", "-")
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Then use `local.normalized_name` for fields like `identifier` and `final_snapshot_identifier`.
|
||||||
|
|
||||||
|
## Resource Block Ordering
|
||||||
|
|
||||||
|
Preferred order inside resource blocks:
|
||||||
|
|
||||||
|
1. Identity/core arguments
|
||||||
|
2. Behavior/config arguments
|
||||||
|
3. Nested blocks
|
||||||
|
4. Tags/labels
|
||||||
|
5. Lifecycle/meta-arguments
|
||||||
|
|
||||||
|
This keeps diffs predictable and reviewable.
|
||||||
|
|
||||||
|
## Variable Contract Style
|
||||||
|
|
||||||
|
Variable attribute order:
|
||||||
|
|
||||||
|
1. `description`
|
||||||
|
2. `type`
|
||||||
|
3. `default` (if used)
|
||||||
|
4. `nullable`
|
||||||
|
5. `sensitive`
|
||||||
|
6. `validation`
|
||||||
|
|
||||||
|
Prefer explicit objects with `optional()` over untyped maps for long-lived module contracts.
|
||||||
|
|
||||||
|
## Iteration and Identity
|
||||||
|
|
||||||
|
| Pattern | Use When |
|
||||||
|
|---|---|
|
||||||
|
| `count` | Optional singleton toggles (`0` or `1`) |
|
||||||
|
| `for_each` | Any collection with stable logical identities |
|
||||||
|
|
||||||
|
Never use list index as long-lived identity key.
|
||||||
|
|
||||||
|
## Set-Type Handling
|
||||||
|
|
||||||
|
Rules to avoid ordering bugs and test failures:
|
||||||
|
|
||||||
|
- Never index sets directly; convert with `sort(tolist(...))` when order matters
|
||||||
|
- Use `for_each` with `toset(...)` only when identity is the value itself
|
||||||
|
- For stable diff output, transform sets to sorted lists in outputs
|
||||||
|
- In tests, prefer `contains()` or set equality over positional assertions
|
||||||
|
|
||||||
|
## Outputs
|
||||||
|
|
||||||
|
- Expose only stable interfaces needed by consumers
|
||||||
|
- Mark secret-bearing outputs as `sensitive = true`
|
||||||
|
- Avoid dumping entire provider objects
|
||||||
|
|
||||||
|
## Version and Lock Discipline
|
||||||
|
|
||||||
|
- Set runtime floor in `required_version`
|
||||||
|
- Bound provider and module versions
|
||||||
|
- Commit lockfile changes intentionally
|
||||||
|
- Keep upgrade PRs separate from functional changes where possible
|
||||||
|
|
||||||
|
## Terraform Feature Guard Table
|
||||||
|
|
||||||
|
Use this table when deciding what to emit for a given runtime floor. Maps features to their minimum version and the specific LLM error pattern for each.
|
||||||
|
|
||||||
|
| Feature | Min Version | LLM Error Pattern |
|
||||||
|
|---|---|---|
|
||||||
|
| `moved` blocks | 1.1+ | Omitted during refactor, causing destroy/create |
|
||||||
|
| `for_each` over `count` | 0.12+ | Model defaults to `count` for every collection |
|
||||||
|
| `write_only` arguments | 1.11+ | Model uses `sensitive` and assumes state is safe |
|
||||||
|
| `optional()` defaults | 1.3+ | Model emits wrapper variables and loose maps |
|
||||||
|
| Cross-variable validation | 1.9+ | Model pushes checks into postconditions only |
|
||||||
|
| Declarative `import` blocks | 1.5+ | Model recommends ad-hoc CLI import only |
|
||||||
|
| `check` blocks | 1.5+ | Model ignores runtime assertions entirely |
|
||||||
|
| `removed` blocks | 1.7+ | Model deletes resources with no lifecycle transition |
|
||||||
|
| Provider-defined functions | 1.8+ | Model overuses data sources for transformations |
|
||||||
|
|
||||||
|
If target runtime is below a feature floor, emit fallback guidance explicitly.
|
||||||
|
|
||||||
|
## Review Checklist
|
||||||
|
|
||||||
|
- Typed inputs and validations present
|
||||||
|
- Iteration model chosen for address stability
|
||||||
|
- No plaintext secret defaults
|
||||||
|
- Version constraints and lockfile strategy are explicit
|
||||||
|
- Migration-sensitive changes include `moved`/`import` plan
|
||||||
91
skills/terrashark/docs/architecture/module-architecture.md
Normal file
91
skills/terrashark/docs/architecture/module-architecture.md
Normal file
|
|
@ -0,0 +1,91 @@
|
||||||
|
# Terraform Module Architecture
|
||||||
|
|
||||||
|
This guide covers designing reusable Terraform modules, composition layers, and the deep hierarchy model for platform engineering at scale.
|
||||||
|
|
||||||
|
## Module Roles
|
||||||
|
|
||||||
|
| Role | Responsibility |
|
||||||
|
|---|---|
|
||||||
|
| **Primitive module** | Wraps one resource family with strict interface |
|
||||||
|
| **Composite module** | Assembles multiple primitives for a deployable capability |
|
||||||
|
| **Root composition** | Injects environment values and wiring only |
|
||||||
|
|
||||||
|
Keep business policy out of primitives when it is environment-specific.
|
||||||
|
|
||||||
|
## Contract Design
|
||||||
|
|
||||||
|
A good module contract has:
|
||||||
|
|
||||||
|
- Strongly typed inputs
|
||||||
|
- Defaults only for safe/common behavior
|
||||||
|
- Explicit outputs for consumers
|
||||||
|
- Preconditions for invariants
|
||||||
|
|
||||||
|
**Bad contract smells:**
|
||||||
|
- Many loosely typed maps
|
||||||
|
- Opaque passthrough variables
|
||||||
|
- Outputs that mirror entire provider objects
|
||||||
|
|
||||||
|
## Suggested File Layout
|
||||||
|
|
||||||
|
| File | Purpose |
|
||||||
|
|---|---|
|
||||||
|
| `main.tf` | Resources and module calls |
|
||||||
|
| `variables.tf` | Typed input contract and validation |
|
||||||
|
| `outputs.tf` | Explicit consumer interface |
|
||||||
|
| `versions.tf` | Runtime and provider constraints |
|
||||||
|
| `locals.tf` | Computed values, naming, shared labels |
|
||||||
|
|
||||||
|
## Composition Rules
|
||||||
|
|
||||||
|
- Pass only required values into child modules
|
||||||
|
- Avoid circular dependencies and hidden ordering
|
||||||
|
- Prefer data flow via input/output over broad `depends_on`
|
||||||
|
- Keep module count manageable; over-fragmentation hurts maintainability
|
||||||
|
|
||||||
|
## Deep Hierarchy Model
|
||||||
|
|
||||||
|
For platform engineering at scale, use a 5-level module hierarchy:
|
||||||
|
|
||||||
|
```
|
||||||
|
L4: Org Orchestration
|
||||||
|
└── L3: Environment Roots
|
||||||
|
└── L2: Domain Stacks
|
||||||
|
└── L1: Composites
|
||||||
|
└── L0: Primitives
|
||||||
|
```
|
||||||
|
|
||||||
|
| Level | Role | Examples |
|
||||||
|
|---|---|---|
|
||||||
|
| **L0 Primitives** | One resource family, strict contract | VPC, IAM role, S3 bucket |
|
||||||
|
| **L1 Composites** | Capability units built from primitives | Networking stack, compute cluster |
|
||||||
|
| **L2 Domain stacks** | Bounded business domains | Payments, identity, observability |
|
||||||
|
| **L3 Environment roots** | Env-specific wiring and configuration | dev, staging, production |
|
||||||
|
| **L4 Org orchestration** | Account/project vending and shared policy | Organization policies, account factory |
|
||||||
|
|
||||||
|
### Composition Rules
|
||||||
|
|
||||||
|
- Dependencies flow downward only (L4 -> L3 -> L2 -> L1 -> L0)
|
||||||
|
- No lateral imports across the same level without an explicit interface contract
|
||||||
|
- Cross-state data flow is via explicit outputs or approved remote state access
|
||||||
|
- Each level owns its state boundary and apply lifecycle
|
||||||
|
- Environment roots should not embed business logic; keep it in L2/L1
|
||||||
|
|
||||||
|
### Decision Aid
|
||||||
|
|
||||||
|
Add a new level only if ownership, lifecycle, or blast radius requires it.
|
||||||
|
|
||||||
|
## Module Release Discipline
|
||||||
|
|
||||||
|
- Tag module versions
|
||||||
|
- Use bounded version constraints in consumers
|
||||||
|
- Run compatibility tests before raising lower bounds
|
||||||
|
|
||||||
|
## When to Create a New Module
|
||||||
|
|
||||||
|
Create a new module only when at least one is true:
|
||||||
|
|
||||||
|
- Reused across 2+ stacks
|
||||||
|
- Ownership differs from current module
|
||||||
|
- Lifecycle differs significantly
|
||||||
|
- Change blast radius needs isolation
|
||||||
68
skills/terrashark/docs/architecture/structure-and-state.md
Normal file
68
skills/terrashark/docs/architecture/structure-and-state.md
Normal file
|
|
@ -0,0 +1,68 @@
|
||||||
|
# Terraform Structure and State Management
|
||||||
|
|
||||||
|
This guide covers how to choose repository shape, environment segmentation, and state boundaries for Terraform projects.
|
||||||
|
|
||||||
|
## Boundary Model
|
||||||
|
|
||||||
|
Define boundaries by three factors:
|
||||||
|
|
||||||
|
1. **Change cadence** — what changes together
|
||||||
|
2. **Blast radius** — what can fail together
|
||||||
|
3. **Ownership** — who approves and supports it
|
||||||
|
|
||||||
|
If those differ between components, split stacks.
|
||||||
|
|
||||||
|
## Root Module Patterns
|
||||||
|
|
||||||
|
| Pattern | Scope |
|
||||||
|
|---|---|
|
||||||
|
| **service-root** | One business service and its direct dependencies |
|
||||||
|
| **platform-root** | Shared platform primitives (network, identity, observability) |
|
||||||
|
| **bootstrap-root** | Backend/state prerequisites and foundational security controls |
|
||||||
|
|
||||||
|
Avoid monolithic roots that mix all three.
|
||||||
|
|
||||||
|
## Environment Isolation Options
|
||||||
|
|
||||||
|
| Option | Best For |
|
||||||
|
|---|---|
|
||||||
|
| **Separate root directories** per environment | Default choice, clearest isolation |
|
||||||
|
| **Workspace-per-environment** with strict policy | When governance is strong and access controls exist |
|
||||||
|
| **Separate repositories** | Hard regulatory segregation requirements |
|
||||||
|
|
||||||
|
Pick one and document why.
|
||||||
|
|
||||||
|
## State Backend Baseline
|
||||||
|
|
||||||
|
- Remote backend only for collaborative environments
|
||||||
|
- Lock protection for every apply path
|
||||||
|
- Encryption at rest and in transit
|
||||||
|
- Narrow IAM on state and lock stores
|
||||||
|
- Versioned backup with restore tested at least once
|
||||||
|
- Load [Backend State Safety](backend-state-safety.md) for backend-specific locking, access, and migration guardrails
|
||||||
|
|
||||||
|
## Cross-Stack Dependencies
|
||||||
|
|
||||||
|
Preferred order:
|
||||||
|
|
||||||
|
1. **Explicit module outputs** passed in the same root
|
||||||
|
2. **Published interface artifacts** (preferred at scale)
|
||||||
|
3. **`terraform_remote_state`** as last-resort coupling
|
||||||
|
|
||||||
|
If `terraform_remote_state` is used, version and ownership of the producer stack must be explicit.
|
||||||
|
|
||||||
|
## Apply Safety Gates
|
||||||
|
|
||||||
|
Minimum gates for any apply:
|
||||||
|
|
||||||
|
- `fmt` and `validate`
|
||||||
|
- Lint and security scan
|
||||||
|
- Policy checks
|
||||||
|
- Reviewed plan
|
||||||
|
- Approved apply
|
||||||
|
|
||||||
|
## Change Safety for State Evolution
|
||||||
|
|
||||||
|
- Use `moved` blocks for renames and address changes
|
||||||
|
- For imports, document source of truth and verify idempotency before apply
|
||||||
|
- For manual state operations, require peer review and rollback notes
|
||||||
23
skills/terrashark/docs/book.json
Normal file
23
skills/terrashark/docs/book.json
Normal file
|
|
@ -0,0 +1,23 @@
|
||||||
|
{
|
||||||
|
"title": "Terraform Skill for Claude Code — TerraShark Documentation",
|
||||||
|
"description": "Comprehensive documentation for TerraShark, the Terraform and OpenTofu skill for Claude Code and Codex. Prevent hallucinations, enforce best practices, and generate safe infrastructure-as-code.",
|
||||||
|
"author": "Lukas Niessen",
|
||||||
|
"language": "en",
|
||||||
|
"gitbook": ">= 3.2.0",
|
||||||
|
"plugins": [
|
||||||
|
"-sharing",
|
||||||
|
"search-pro",
|
||||||
|
"-lunr",
|
||||||
|
"-search"
|
||||||
|
],
|
||||||
|
"pluginsConfig": {},
|
||||||
|
"structure": {
|
||||||
|
"readme": "README.md",
|
||||||
|
"summary": "SUMMARY.md"
|
||||||
|
},
|
||||||
|
"links": {
|
||||||
|
"sidebar": {
|
||||||
|
"GitHub Repository": "https://github.com/LukasNiessen/terrashark"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
20
skills/terrashark/docs/changelog.md
Normal file
20
skills/terrashark/docs/changelog.md
Normal file
|
|
@ -0,0 +1,20 @@
|
||||||
|
# Changelog
|
||||||
|
|
||||||
|
## Current Version: v2.3.0
|
||||||
|
|
||||||
|
TerraShark is actively maintained. For the latest changes, see the [GitHub repository](https://github.com/LukasNiessen/terrashark).
|
||||||
|
|
||||||
|
### What's Included in v2.3.0
|
||||||
|
|
||||||
|
- Focused `SKILL.md` execution flow (7-step workflow)
|
||||||
|
- Five primary failure-mode references (identity churn, secret exposure, blast radius, CI drift, compliance gates)
|
||||||
|
- Expanded architecture guidance (structure/state, module architecture, coding standards)
|
||||||
|
- Five migration playbooks for safe evolution
|
||||||
|
- CI/CD delivery patterns (GitHub Actions, GitLab CI, Atlantis, Infracost)
|
||||||
|
- Risk-based testing matrix with native test caveats and Terratest coverage
|
||||||
|
- Good/bad/neutral example banks
|
||||||
|
- Do/Don't pattern checklist
|
||||||
|
- MCP integration guidance
|
||||||
|
- Token balance rationale
|
||||||
|
- Automated validation workflow
|
||||||
|
- Plugin marketplace support
|
||||||
72
skills/terrashark/docs/contributing.md
Normal file
72
skills/terrashark/docs/contributing.md
Normal file
|
|
@ -0,0 +1,72 @@
|
||||||
|
# Contributing to the Terraform Skill
|
||||||
|
|
||||||
|
We appreciate contributions to TerraShark. Every change should improve Terraform/OpenTofu output quality while staying lean on token usage.
|
||||||
|
|
||||||
|
## Contribution Principles
|
||||||
|
|
||||||
|
Every change should answer three questions:
|
||||||
|
|
||||||
|
1. **Which failure mode does this prevent?** — must map to at least one of the five failure modes
|
||||||
|
2. **What measurable quality gain does it provide?** — demonstrate improvement
|
||||||
|
3. **Is the token cost justified?** — every line must earn its place
|
||||||
|
|
||||||
|
## Development Flow
|
||||||
|
|
||||||
|
1. Create a branch
|
||||||
|
2. Make focused changes
|
||||||
|
3. Run local checks
|
||||||
|
4. Open PR using `.github/PULL_REQUEST_TEMPLATE.md`
|
||||||
|
|
||||||
|
## Local Checks
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Quick sanity checks
|
||||||
|
rg -n "FIXME|placeholder-text" README.md SKILL.md references/*.md
|
||||||
|
python - <<'PY'
|
||||||
|
from pathlib import Path
|
||||||
|
assert Path('SKILL.md').exists()
|
||||||
|
assert Path('README.md').exists()
|
||||||
|
for p in [
|
||||||
|
'references/identity-churn.md',
|
||||||
|
'references/secret-exposure.md',
|
||||||
|
'references/blast-radius.md',
|
||||||
|
'references/ci-drift.md',
|
||||||
|
'references/compliance-gates.md',
|
||||||
|
]:
|
||||||
|
assert Path(p).exists(), f'missing {p}'
|
||||||
|
print('basic structure OK')
|
||||||
|
PY
|
||||||
|
```
|
||||||
|
|
||||||
|
## Content Rules
|
||||||
|
|
||||||
|
- Keep examples original and clearly distinct
|
||||||
|
- Prefer failure-mode framing over generic "best-practice dump" text
|
||||||
|
- Avoid provider-specific deep dives unless they directly reduce a known LLM failure mode
|
||||||
|
- Keep claims precise; avoid vague "always" language when tradeoffs exist
|
||||||
|
|
||||||
|
## Required for PR Approval
|
||||||
|
|
||||||
|
- Clear mapping to one or more failure modes
|
||||||
|
- No contradictory guidance across references
|
||||||
|
- Updated links/indexes if files were moved/renamed
|
||||||
|
- Validation workflow passing (`.github/workflows/validate.yml`)
|
||||||
|
|
||||||
|
## Security
|
||||||
|
|
||||||
|
- Never commit credentials, tokens, or secret values
|
||||||
|
- Do not paste real state snippets containing sensitive data
|
||||||
|
|
||||||
|
## Reporting Issues
|
||||||
|
|
||||||
|
Open an issue with:
|
||||||
|
|
||||||
|
- Observed hallucination/failure pattern
|
||||||
|
- Minimal reproducible prompt/context
|
||||||
|
- Expected behavior
|
||||||
|
|
||||||
|
## Community
|
||||||
|
|
||||||
|
- Submit an [issue on GitHub](https://github.com/LukasNiessen/terrashark/issues/new/choose)
|
||||||
|
- Join [GitHub Discussions](https://github.com/LukasNiessen/terrashark/discussions)
|
||||||
|
- Star the repository if TerraShark helps your project
|
||||||
108
skills/terrashark/docs/core-concepts/failure-modes.md
Normal file
108
skills/terrashark/docs/core-concepts/failure-modes.md
Normal file
|
|
@ -0,0 +1,108 @@
|
||||||
|
# Five Terraform Failure Modes
|
||||||
|
|
||||||
|
TerraShark organizes all its guidance around five explicit failure modes. These are not arbitrary categories — they represent the five most common ways LLM-generated Terraform causes real operational damage.
|
||||||
|
|
||||||
|
Every piece of content in the Terraform skill maps to at least one failure mode. Content that does not reduce the probability of any failure mode is excluded.
|
||||||
|
|
||||||
|
## 1. Identity Churn
|
||||||
|
|
||||||
|
**What it is**: Resource addressing instability that causes unexpected destroy/create cycles during refactors or collection changes.
|
||||||
|
|
||||||
|
**Common symptoms**:
|
||||||
|
- Plan shows broad replace actions after small list edits
|
||||||
|
- Renaming resources or modules triggers destroy/create
|
||||||
|
- Refactor from `count` to `for_each` causes churn
|
||||||
|
- Imported resources keep drifting because addressing is unstable
|
||||||
|
|
||||||
|
**Root causes**:
|
||||||
|
- Index-based identity (`count`) used for long-lived objects
|
||||||
|
- Keys derived from unstable data (sorted lists, transient IDs)
|
||||||
|
- Missing `moved` blocks during refactors
|
||||||
|
- `for_each` keys derived from values unknown at plan time
|
||||||
|
|
||||||
|
**LLM-specific risks**: Models default to `count` for every collection, omit `moved` blocks during refactors, and build `for_each` keys from computed IDs not known until apply.
|
||||||
|
|
||||||
|
[Full reference: Identity Churn](../failure-modes/identity-churn.md)
|
||||||
|
|
||||||
|
## 2. Secret Exposure
|
||||||
|
|
||||||
|
**What it is**: Secrets leaking into state files, CI logs, plan output, variable defaults, or artifact storage.
|
||||||
|
|
||||||
|
**Common symptoms**:
|
||||||
|
- Secret values appear in plan output or logs
|
||||||
|
- Credentials defined in variable defaults
|
||||||
|
- Sensitive outputs printed in CI
|
||||||
|
- Generated passwords stored in state unintentionally
|
||||||
|
|
||||||
|
**Root causes**:
|
||||||
|
- Hardcoded defaults in `variables.tf`
|
||||||
|
- Secret-bearing resources whose values persist in state
|
||||||
|
- Logging `terraform show` outputs without redaction
|
||||||
|
- Artifact retention policies keeping plan/state exports too long
|
||||||
|
|
||||||
|
**LLM-specific risks**: Models assume `sensitive` alone means "not in state", propose plaintext defaults for demo convenience, and use outputs that expose connection strings in PR comments.
|
||||||
|
|
||||||
|
[Full reference: Secret Exposure](../failure-modes/secret-exposure.md)
|
||||||
|
|
||||||
|
## 3. Blast Radius
|
||||||
|
|
||||||
|
**What it is**: Oversized stacks where a small change can cause widespread, unintended impact across unrelated services.
|
||||||
|
|
||||||
|
**Common symptoms**:
|
||||||
|
- Tiny change triggers a very large plan
|
||||||
|
- Unrelated services share one state and fail together
|
||||||
|
- Production and non-production are entangled
|
||||||
|
- Review/approval ownership is unclear
|
||||||
|
|
||||||
|
**Root causes**:
|
||||||
|
- No ownership boundaries between services
|
||||||
|
- Monolithic root modules mixing all concerns
|
||||||
|
- Weak state isolation between environments
|
||||||
|
- Missing apply governance for shared foundations
|
||||||
|
|
||||||
|
**LLM-specific risks**: Models propose one monolithic root for convenience, recommend workspace-only isolation without access controls, and omit rollback paths for shared foundation changes.
|
||||||
|
|
||||||
|
[Full reference: Blast Radius](../failure-modes/blast-radius.md)
|
||||||
|
|
||||||
|
## 4. CI Drift
|
||||||
|
|
||||||
|
**What it is**: Pipeline behavior diverging from local behavior or from reviewed intent, causing unreviewed or inconsistent applies.
|
||||||
|
|
||||||
|
**Common symptoms**:
|
||||||
|
- CI plan differs from local plan unexpectedly
|
||||||
|
- Apply occurs without using the reviewed plan artifact
|
||||||
|
- Provider/runtime drift between runs
|
||||||
|
- Scanner/policy stages skipped on some code paths
|
||||||
|
|
||||||
|
**Root causes**:
|
||||||
|
- Unpinned runtime/provider versions
|
||||||
|
- Missing or stale lockfile
|
||||||
|
- Apply job re-running `plan` instead of consuming the reviewed artifact
|
||||||
|
- Inconsistent credentials/auth between plan and apply
|
||||||
|
|
||||||
|
**LLM-specific risks**: Models produce CI pipelines with missing lockfile strategies, apply without saved plan artifacts, skip policy stages despite claiming compliance, and omit branch/environment protection.
|
||||||
|
|
||||||
|
[Full reference: CI Drift](../failure-modes/ci-drift.md)
|
||||||
|
|
||||||
|
## 5. Compliance Gate Gaps
|
||||||
|
|
||||||
|
**What it is**: Missing enforceable controls and evidence artifacts despite referencing compliance frameworks by name.
|
||||||
|
|
||||||
|
**Common symptoms**:
|
||||||
|
- Frameworks mentioned but no enforceable gates exist
|
||||||
|
- Security best practices confused with compliance evidence
|
||||||
|
- Missing approval workflows for different risk classes
|
||||||
|
- No evidence retention for production applies
|
||||||
|
|
||||||
|
**Root causes**:
|
||||||
|
- No preventative controls (policy/validation)
|
||||||
|
- No detective controls (logging/monitoring)
|
||||||
|
- No evidence artifacts (plans, approvals, audit records)
|
||||||
|
|
||||||
|
**LLM-specific risks**: Models mention framework names without providing enforceable gates, confuse security best practices with compliance evidence, omit risk-class approvals, and ignore data-residency obligations.
|
||||||
|
|
||||||
|
[Full reference: Compliance Gate Gaps](../failure-modes/compliance-gates.md)
|
||||||
|
|
||||||
|
## How Failure Modes Drive the Terraform Skill
|
||||||
|
|
||||||
|
The 7-step workflow uses these failure modes as the diagnostic lens in Step 2. Every reference file, every example, and every checklist in TerraShark traces back to preventing one or more of these five failure modes. This ensures the skill is focused, measurable, and directly actionable.
|
||||||
123
skills/terrashark/docs/core-concepts/philosophy.md
Normal file
123
skills/terrashark/docs/core-concepts/philosophy.md
Normal file
|
|
@ -0,0 +1,123 @@
|
||||||
|
# Terraform Skill Design Philosophy
|
||||||
|
|
||||||
|
This page describes the architectural decisions and empirical process behind TerraShark's design.
|
||||||
|
|
||||||
|
## Failure-Mode-First Architecture
|
||||||
|
|
||||||
|
TerraShark is built around a single insight: **telling an LLM what good Terraform looks like is less effective than telling it how to think about Terraform problems**.
|
||||||
|
|
||||||
|
The core `SKILL.md` is not a reference manual. It is a 7-step operational workflow that forces the model to diagnose before it generates. This prevents the most common failure pattern in LLM-assisted IaC: producing syntactically valid but operationally dangerous code.
|
||||||
|
|
||||||
|
## Token Efficiency as a Design Constraint
|
||||||
|
|
||||||
|
Context window space is a finite resource. Every token spent on skill content is a token unavailable for the user's actual codebase, conversation history, and tool results.
|
||||||
|
|
||||||
|
TerraShark is designed for minimal activation cost:
|
||||||
|
|
||||||
|
| Metric | TerraShark | Typical Alternative |
|
||||||
|
|---|---|---|
|
||||||
|
| Activation cost | ~600 tokens | ~4,400 tokens |
|
||||||
|
| Reference files | 19 focused files | 6 large files |
|
||||||
|
| Loaded per query | 1-2 small files | Large reference dumps |
|
||||||
|
|
||||||
|
The core `SKILL.md` is 86 lines containing no HCL examples, no inline code blocks, and no tutorial material. It is purely procedural. Depth lives in 19 granular reference files loaded on demand.
|
||||||
|
|
||||||
|
## LLM-Aware Guardrails
|
||||||
|
|
||||||
|
Every reference file that covers a risk domain includes an **LLM mistake checklist** — a list of specific errors that language models make when generating Terraform code:
|
||||||
|
|
||||||
|
- Defaulting to `count` instead of `for_each` for collections
|
||||||
|
- Omitting `moved` blocks during refactors, causing destroy/create cycles
|
||||||
|
- Using `sensitive` and assuming the value is safe from state
|
||||||
|
- Proposing plaintext credential defaults "for demo purposes"
|
||||||
|
- Recommending CLI-only `terraform import` instead of declarative import blocks
|
||||||
|
|
||||||
|
These checklists exist because the model needs to know **what it gets wrong**, not just what is correct. A reference that only shows the right pattern still allows the model to hallucinate the wrong one. A reference that explicitly names the hallucination pattern reduces it.
|
||||||
|
|
||||||
|
The **Feature Guard Table** in `coding-standards.md` maps Terraform features to their minimum version and the specific LLM error pattern associated with each, letting the model check feature availability before emitting code.
|
||||||
|
|
||||||
|
## Output Contracts
|
||||||
|
|
||||||
|
Every TerraShark response includes a structured output contract:
|
||||||
|
|
||||||
|
- **Assumptions and version floor** — what the model assumed
|
||||||
|
- **Selected failure modes** — which risks were diagnosed
|
||||||
|
- **Chosen remediation and tradeoffs** — what was recommended and why
|
||||||
|
- **Validation/test plan** — how to verify the output
|
||||||
|
- **Rollback/recovery notes** — how to undo if something goes wrong
|
||||||
|
|
||||||
|
This makes outputs auditable. A reader can check assumptions, verify failure mode coverage, and validate the rollback path before applying anything.
|
||||||
|
|
||||||
|
## Reference Granularity
|
||||||
|
|
||||||
|
The 19 reference files are organized by concern, not by Terraform concept:
|
||||||
|
|
||||||
|
| Category | Files | When Loaded |
|
||||||
|
|---|---|---|
|
||||||
|
| **Primary failure modes** | Identity churn, secret exposure, blast radius, CI drift, compliance gates | When that failure mode is diagnosed |
|
||||||
|
| **Structural guidance** | Structure/state, backend state safety, module architecture, coding standards | When designing, refactoring, or changing backends |
|
||||||
|
| **Operational references** | Migration playbooks, testing matrix, CI delivery, security/governance, quick ops | For specific operational tasks |
|
||||||
|
| **Pattern banks** | Good examples, bad examples, neutral examples, do/don't patterns | For review or teaching |
|
||||||
|
| **Integration and meta** | MCP integration, token balance rationale | When relevant |
|
||||||
|
|
||||||
|
Each file is self-contained. No file depends on another file being loaded simultaneously.
|
||||||
|
|
||||||
|
## Deep Hierarchy Model
|
||||||
|
|
||||||
|
For platform engineering at scale, TerraShark defines a 5-level module hierarchy:
|
||||||
|
|
||||||
|
| Level | Role | Scope |
|
||||||
|
|---|---|---|
|
||||||
|
| **L0** | Primitives | One resource family, strict contract |
|
||||||
|
| **L1** | Composites | Capability units built from primitives |
|
||||||
|
| **L2** | Domain stacks | Bounded business domains |
|
||||||
|
| **L3** | Environment roots | Env-specific wiring and configuration |
|
||||||
|
| **L4** | Org orchestration | Account/project vending and shared policy |
|
||||||
|
|
||||||
|
Dependencies flow downward only. Each level owns its state boundary and apply lifecycle.
|
||||||
|
|
||||||
|
## Content Inclusion Rules
|
||||||
|
|
||||||
|
Content enters TerraShark only when at least one condition is met:
|
||||||
|
|
||||||
|
1. It materially lowers the probability of destructive or non-compliant changes
|
||||||
|
2. It prevents common plan/apply surprises
|
||||||
|
3. It encodes organizational guardrails that general model knowledge cannot infer
|
||||||
|
|
||||||
|
Content is excluded when:
|
||||||
|
|
||||||
|
1. It is generic Terraform/OpenTofu knowledge with low failure impact
|
||||||
|
2. It is provider-specific deep design that belongs in project docs
|
||||||
|
3. It duplicates an existing rule without adding a new decision signal
|
||||||
|
|
||||||
|
## The Token Experiment
|
||||||
|
|
||||||
|
The content in TerraShark was empirically tested, not designed by intuition.
|
||||||
|
|
||||||
|
### Process
|
||||||
|
|
||||||
|
1. **Started large** — broader coverage, more examples, more tutorial material
|
||||||
|
2. **Built automated test suite** — practical Terraform/OpenTofu task patterns
|
||||||
|
3. **Measured baseline quality** — correctness, safety, completeness, hallucination rate
|
||||||
|
4. **Stripped iteratively** — removed sections one at a time, re-running the full test suite
|
||||||
|
5. **Measured quality impact** — if quality dropped, content was restored; if stable, content was permanently removed
|
||||||
|
6. **Converged** — continued until every remaining section was load-bearing
|
||||||
|
|
||||||
|
### What Survived (Models Need Help With)
|
||||||
|
|
||||||
|
- Module role boundaries and composition rules
|
||||||
|
- Migration playbooks (moved blocks, count-to-for_each, imports)
|
||||||
|
- Native test caveats (set indexing, computed values, mocked providers)
|
||||||
|
- CI delivery templates (policy checks, artifact integrity, env protection)
|
||||||
|
- Quick troubleshooting (stuck locks, backend migration, provider auth in CI)
|
||||||
|
|
||||||
|
### What Was Removed (Models Already Know)
|
||||||
|
|
||||||
|
- Generic HCL syntax tutorials
|
||||||
|
- Provider-specific resource deep dives
|
||||||
|
- Broad "best practice" prose without failure-mode framing
|
||||||
|
- Duplicate explanations of concepts covered by multiple rules
|
||||||
|
|
||||||
|
### Core Design Principle
|
||||||
|
|
||||||
|
**High signal density.** Every line must earn its token cost by preventing a specific failure mode or encoding knowledge the model demonstrably lacks. Content that merely restates what the model already knows is actively harmful — it burns context window space without improving output quality.
|
||||||
106
skills/terrashark/docs/core-concepts/workflow.md
Normal file
106
skills/terrashark/docs/core-concepts/workflow.md
Normal file
|
|
@ -0,0 +1,106 @@
|
||||||
|
# The 7-Step Terraform Skill Workflow
|
||||||
|
|
||||||
|
The core of TerraShark is a 7-step operational workflow defined in `SKILL.md`. Unlike traditional reference manuals that dump information and hope the AI uses it correctly, this workflow forces the AI to **diagnose before generating** — the single most important pattern for preventing Terraform hallucinations.
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
```
|
||||||
|
Capture Context → Diagnose Failure Modes → Load References → Propose Fix → Generate Artifacts → Validate → Output Contract
|
||||||
|
```
|
||||||
|
|
||||||
|
## Step 1: Capture Execution Context
|
||||||
|
|
||||||
|
Before writing any code, the Terraform skill records:
|
||||||
|
|
||||||
|
- **Runtime**: `terraform` or `tofu` and exact version
|
||||||
|
- **Providers**: which cloud providers and their versions
|
||||||
|
- **Target platform**: AWS, Azure, GCP, etc.
|
||||||
|
- **State backend**: S3, GCS, Azure Blob, HCP Terraform, etc.
|
||||||
|
- **Execution path**: local CLI, CI, HCP Terraform/TFE, Atlantis
|
||||||
|
- **Environment criticality**: dev, shared, or production
|
||||||
|
|
||||||
|
If any of these are unknown, the skill states assumptions explicitly in the output contract.
|
||||||
|
|
||||||
|
**Why this matters**: A module targeting Terraform 1.1 cannot use `import` blocks (requires 1.5+). A CI pipeline needs different patterns than local CLI. Production requires approval gates that dev does not.
|
||||||
|
|
||||||
|
## Step 2: Diagnose Likely Failure Modes
|
||||||
|
|
||||||
|
The skill selects one or more failure modes based on the user's intent and risk level:
|
||||||
|
|
||||||
|
| Failure Mode | When Diagnosed |
|
||||||
|
|---|---|
|
||||||
|
| **Identity churn** | Refactors, collection changes, count/for_each decisions |
|
||||||
|
| **Secret exposure** | Credential handling, state access, CI artifact management |
|
||||||
|
| **Blast radius** | Stack design, environment isolation, state boundaries |
|
||||||
|
| **CI drift** | Pipeline setup, version management, plan/apply separation |
|
||||||
|
| **Compliance gate gaps** | Policy setup, framework requirements, approval workflows |
|
||||||
|
|
||||||
|
This step is what makes TerraShark fundamentally different from static reference skills. The AI must identify **what could go wrong** before it starts generating code.
|
||||||
|
|
||||||
|
## Step 3: Load Only Relevant References
|
||||||
|
|
||||||
|
Based on the diagnosed failure modes, the skill loads targeted reference files:
|
||||||
|
|
||||||
|
**Primary references** (one per failure mode):
|
||||||
|
- `references/identity-churn.md`
|
||||||
|
- `references/secret-exposure.md`
|
||||||
|
- `references/blast-radius.md`
|
||||||
|
- `references/ci-drift.md`
|
||||||
|
- `references/compliance-gates.md`
|
||||||
|
|
||||||
|
**Supplemental references** (loaded only when needed):
|
||||||
|
- Testing, CI delivery, module architecture, coding standards, migration playbooks, security governance, quick ops, examples, and more
|
||||||
|
|
||||||
|
This granularity means a query about secret handling never loads CI delivery patterns, and a query about module architecture never loads compliance gates. Only 1-2 small, focused files are loaded per query instead of one massive dump.
|
||||||
|
|
||||||
|
## Step 4: Propose Fix Path with Explicit Risk Controls
|
||||||
|
|
||||||
|
For each proposed fix, the skill includes:
|
||||||
|
|
||||||
|
- **Why this addresses the failure mode** — direct mapping from diagnosis to solution
|
||||||
|
- **What could still go wrong** — honest risk assessment
|
||||||
|
- **Guardrails** — tests, approvals, and rollback steps to mitigate remaining risk
|
||||||
|
|
||||||
|
This forces transparency. The AI cannot silently generate code that might cause damage without disclosing the risks.
|
||||||
|
|
||||||
|
## Step 5: Generate Implementation Artifacts
|
||||||
|
|
||||||
|
When applicable, the output includes:
|
||||||
|
|
||||||
|
- **HCL changes**: typed variables, stable keys, bounded version constraints
|
||||||
|
- **Migration blocks**: `moved` blocks, `import` strategy
|
||||||
|
- **CI pipeline updates**: plan/apply separation, artifact management, policy checks
|
||||||
|
- **Compliance controls**: approval gates, policy rules, evidence paths
|
||||||
|
|
||||||
|
## Step 6: Validate Before Finalize
|
||||||
|
|
||||||
|
The skill provides a command sequence tailored to the runtime and risk tier:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
terraform fmt -check
|
||||||
|
terraform validate
|
||||||
|
terraform plan -out=plan.bin
|
||||||
|
terraform show -json plan.bin > plan.json
|
||||||
|
```
|
||||||
|
|
||||||
|
The skill **never recommends direct production apply** without a reviewed plan and approval gate.
|
||||||
|
|
||||||
|
## Step 7: Output Contract
|
||||||
|
|
||||||
|
Every response includes a structured contract:
|
||||||
|
|
||||||
|
| Section | Content |
|
||||||
|
|---|---|
|
||||||
|
| **Assumptions and version floor** | What was assumed about the environment |
|
||||||
|
| **Selected failure modes** | Which risks were diagnosed |
|
||||||
|
| **Chosen remediation and tradeoffs** | What was recommended and what was traded off |
|
||||||
|
| **Validation/test plan** | How to verify the output |
|
||||||
|
| **Rollback/recovery notes** | How to undo if something goes wrong |
|
||||||
|
|
||||||
|
This makes every output **auditable**. A reviewer can check assumptions, verify failure mode coverage, and validate the rollback path — all before applying anything.
|
||||||
|
|
||||||
|
## Why This Architecture Works
|
||||||
|
|
||||||
|
The 7-step workflow prevents the most common failure pattern in LLM-assisted infrastructure-as-code: **producing syntactically valid but operationally dangerous code**.
|
||||||
|
|
||||||
|
A static reference manual tells the AI what good Terraform looks like. The 7-step workflow tells the AI **how to think about Terraform problems**. This is the difference between giving someone a cookbook and giving them a diagnostic checklist.
|
||||||
107
skills/terrashark/docs/examples/bad-patterns.md
Normal file
107
skills/terrashark/docs/examples/bad-patterns.md
Normal file
|
|
@ -0,0 +1,107 @@
|
||||||
|
# Terraform Anti-Patterns (Bad Patterns)
|
||||||
|
|
||||||
|
Seven common anti-patterns that the Terraform skill explicitly prevents. Each pattern maps to a specific failure mode and is a known LLM hallucination risk.
|
||||||
|
|
||||||
|
## 1. List-Driven `count` for Mutable Identities
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
variable "queue_names" {
|
||||||
|
type = list(string)
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "aws_sqs_queue" "worker" {
|
||||||
|
count = length(var.queue_names)
|
||||||
|
name = var.queue_names[count.index]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this fails:** Reordering list entries forces unexpected replacements. Object identity is tied to index, not business key. **Failure mode:** Identity churn.
|
||||||
|
|
||||||
|
## 2. No Type Constraints on Critical Input
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
variable "network" {
|
||||||
|
default = {}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this fails:** Consumer mistakes surface late and noisily. Module contract is ambiguous. **Failure mode:** Blast radius from silent misconfiguration.
|
||||||
|
|
||||||
|
## 3. Sensitive Defaults Committed in Code
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
variable "api_token" {
|
||||||
|
type = string
|
||||||
|
default = "token-please-change"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this fails:** Secret can leak via VCS and logs. Violates basic secret hygiene. **Failure mode:** Secret exposure.
|
||||||
|
|
||||||
|
## 4. Floating Provider Versions
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
terraform {
|
||||||
|
required_providers {
|
||||||
|
azurerm = {
|
||||||
|
source = "hashicorp/azurerm"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this fails:** Pulls latest provider implicitly. Increases non-deterministic CI behavior. **Failure mode:** CI drift.
|
||||||
|
|
||||||
|
## 5. Blanket `ignore_changes`
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
resource "aws_db_instance" "main" {
|
||||||
|
identifier = "core-db"
|
||||||
|
engine = "postgres"
|
||||||
|
|
||||||
|
lifecycle {
|
||||||
|
ignore_changes = all
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this fails:** Masks drift and important config regressions. Erodes trust in plan output. **Failure mode:** CI drift and blast radius.
|
||||||
|
|
||||||
|
## 6. Dynamic Block with Wrong Iterator Reference
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
variable "ports" {
|
||||||
|
type = list(number)
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "aws_security_group" "app" {
|
||||||
|
name = "app-sg"
|
||||||
|
|
||||||
|
dynamic "ingress" {
|
||||||
|
for_each = var.ports
|
||||||
|
content {
|
||||||
|
from_port = ports.value # WRONG: should be ingress.value
|
||||||
|
to_port = ports.value # WRONG: should be ingress.value
|
||||||
|
protocol = "tcp"
|
||||||
|
cidr_blocks = ["0.0.0.0/0"]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this fails:** The iterator name defaults to the dynamic block label (`ingress`), not the variable name. Using `ports.value` causes an unknown reference error. **This is a common LLM hallucination pattern.**
|
||||||
|
|
||||||
|
## 7. Hidden Ordering via Unrelated `depends_on`
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
resource "aws_iam_role" "app" {
|
||||||
|
name = "app-role"
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "aws_cloudwatch_log_group" "app" {
|
||||||
|
name = "/app/runtime"
|
||||||
|
depends_on = [aws_iam_role.app]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this fails:** Artificial dependency reduces parallelism. Hides poor interface boundaries. **Failure mode:** Blast radius from hidden coupling.
|
||||||
75
skills/terrashark/docs/examples/do-dont-checklist.md
Normal file
75
skills/terrashark/docs/examples/do-dont-checklist.md
Normal file
|
|
@ -0,0 +1,75 @@
|
||||||
|
# Terraform Do and Don't Checklist
|
||||||
|
|
||||||
|
A fast reference checklist for safe Terraform and OpenTofu code generation. Use this for quick reviews.
|
||||||
|
|
||||||
|
## Identity and Iteration
|
||||||
|
|
||||||
|
| Do | Don't |
|
||||||
|
|---|---|
|
||||||
|
| Use `for_each` with stable, business-meaningful keys | Use list index as long-lived identity |
|
||||||
|
| Keep identity keys separate from mutable attributes | Derive identity from a computed attribute |
|
||||||
|
| Add `moved` blocks when renaming resources or modules | Delete/rename addresses without an explicit migration plan |
|
||||||
|
|
||||||
|
## Secrets and Sensitive Data
|
||||||
|
|
||||||
|
| Do | Don't |
|
||||||
|
|---|---|
|
||||||
|
| Mark secret outputs as `sensitive = true` | Put secrets in `default` values or `.tfvars` committed to VCS |
|
||||||
|
| Use secret managers and data sources for runtime injection | Echo secrets in provisioner commands |
|
||||||
|
| Avoid logging sensitive values in `locals` or `output` | Rely on `sensitive` alone to protect state contents |
|
||||||
|
|
||||||
|
## State Boundaries and Blast Radius
|
||||||
|
|
||||||
|
| Do | Don't |
|
||||||
|
|---|---|
|
||||||
|
| Keep production in isolated state backends or workspaces | Mix unrelated systems in a single root state |
|
||||||
|
| Split large stacks by lifecycle and ownership | Apply directly to production from unreviewed branches |
|
||||||
|
| Use environment protection and approvals for apply | Use one monolithic stack for all environments |
|
||||||
|
|
||||||
|
## Module Contracts
|
||||||
|
|
||||||
|
| Do | Don't |
|
||||||
|
|---|---|
|
||||||
|
| Expose typed inputs and explicit outputs | Accept untyped `map(any)` for core interfaces |
|
||||||
|
| Use `optional()` for evolution-friendly contracts | Expose entire provider objects as outputs |
|
||||||
|
| Validate invariants with `validation` and `precondition` | Push environment-specific policy into primitive modules |
|
||||||
|
|
||||||
|
## Providers and Versions
|
||||||
|
|
||||||
|
| Do | Don't |
|
||||||
|
|---|---|
|
||||||
|
| Pin runtime and providers with bounded constraints | Float provider versions |
|
||||||
|
| Commit `.terraform.lock.hcl` intentionally | Rely on implicit provider inheritance in multi-region setups |
|
||||||
|
| Pass provider aliases explicitly to child modules | Mix upgrades with functional changes in the same PR |
|
||||||
|
|
||||||
|
## Data Sources and Dependencies
|
||||||
|
|
||||||
|
| Do | Don't |
|
||||||
|
|---|---|
|
||||||
|
| Use data sources for read-only integration | Use `depends_on` to paper over missing interfaces |
|
||||||
|
| Model dependencies via input/output wiring | Use data sources for identity fields that can change |
|
||||||
|
| Keep `depends_on` for real ordering requirements only | Create hidden ordering between unrelated resources |
|
||||||
|
|
||||||
|
## CI/CD and Policy
|
||||||
|
|
||||||
|
| Do | Don't |
|
||||||
|
|---|---|
|
||||||
|
| Separate plan and apply | Allow direct apply from arbitrary branches |
|
||||||
|
| Keep an auditable reviewed plan artifact | Skip policy checks for production changes |
|
||||||
|
| Run policy and cost checks on every plan | Delete plan artifacts before approval |
|
||||||
|
|
||||||
|
## Testing
|
||||||
|
|
||||||
|
| Do | Don't |
|
||||||
|
|---|---|
|
||||||
|
| Run `terraform test` / `tofu test` for module-level checks | Rely on plan-only validation for runtime-only attributes |
|
||||||
|
| Use Terratest for workflow or integration validation | Run destructive tests without isolation and cleanup |
|
||||||
|
| Tier tests by risk and cost | Treat mocked provider tests as full integration coverage |
|
||||||
|
|
||||||
|
## Migration and Refactors
|
||||||
|
|
||||||
|
| Do | Don't |
|
||||||
|
|---|---|
|
||||||
|
| Include `moved` or `import` strategy in the same change | Rename resources without preserving state identity |
|
||||||
|
| Run a reviewed plan before any apply | Apply refactors without plan review |
|
||||||
|
| Document rollback steps for destructive changes | Remove resources without lifecycle transition |
|
||||||
153
skills/terrashark/docs/examples/good-patterns.md
Normal file
153
skills/terrashark/docs/examples/good-patterns.md
Normal file
|
|
@ -0,0 +1,153 @@
|
||||||
|
# Terraform Good Patterns
|
||||||
|
|
||||||
|
Eight strong implementation patterns that the Terraform skill uses as positive examples. Each pattern directly prevents one or more failure modes.
|
||||||
|
|
||||||
|
## 1. Stable Identity Map for Service Accounts
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
variable "service_accounts" {
|
||||||
|
type = map(object({
|
||||||
|
display_name = string
|
||||||
|
roles = set(string)
|
||||||
|
}))
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "google_service_account" "app" {
|
||||||
|
for_each = var.service_accounts
|
||||||
|
account_id = each.key
|
||||||
|
display_name = each.value.display_name
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this works:** Key-based identity survives insertion/removal changes. Contract is strict and predictable. Prevents identity churn.
|
||||||
|
|
||||||
|
## 2. Cross-Variable Validation for Safe Combinations
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
variable "public_endpoint" {
|
||||||
|
type = bool
|
||||||
|
default = false
|
||||||
|
}
|
||||||
|
|
||||||
|
variable "allowed_cidrs" {
|
||||||
|
type = list(string)
|
||||||
|
default = []
|
||||||
|
|
||||||
|
validation {
|
||||||
|
condition = var.public_endpoint || length(var.allowed_cidrs) == 0
|
||||||
|
error_message = "allowed_cidrs must be empty unless public_endpoint is true."
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this works:** Invalid combinations fail early. Intent is encoded directly in the module interface. Prevents blast radius from misconfigured access.
|
||||||
|
|
||||||
|
## 3. Strong Object Typing with Optional Fields
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
variable "node_pool" {
|
||||||
|
type = object({
|
||||||
|
size = string
|
||||||
|
min_replicas = number
|
||||||
|
max_replicas = number
|
||||||
|
spot_instances = optional(bool, false)
|
||||||
|
})
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this works:** Flexible without sacrificing schema clarity. Avoids ad-hoc maps and runtime surprises.
|
||||||
|
|
||||||
|
## 4. Narrow, Useful Outputs
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
output "app_subnet_ids" {
|
||||||
|
description = "Subnet ids for application workloads"
|
||||||
|
value = values(aws_subnet.app)[*].id
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this works:** Downstream modules get exactly what they need. Avoids leaking full provider objects that could expose sensitive data.
|
||||||
|
|
||||||
|
## 5. Controlled Provider Pinning
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
terraform {
|
||||||
|
required_version = ">= 1.6.0"
|
||||||
|
|
||||||
|
required_providers {
|
||||||
|
aws = {
|
||||||
|
source = "hashicorp/aws"
|
||||||
|
version = ">= 5.40.0, < 6.0.0"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this works:** Controlled upgrade window prevents accidental major-version breakage. Prevents CI drift from floating versions.
|
||||||
|
|
||||||
|
## 6. Dynamic Block with Typed Variable
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
variable "ingress_rules" {
|
||||||
|
type = list(object({
|
||||||
|
port = number
|
||||||
|
protocol = string
|
||||||
|
cidr_blocks = list(string)
|
||||||
|
}))
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "aws_security_group" "app" {
|
||||||
|
name = "app-sg"
|
||||||
|
vpc_id = var.vpc_id
|
||||||
|
|
||||||
|
dynamic "ingress" {
|
||||||
|
for_each = var.ingress_rules
|
||||||
|
content {
|
||||||
|
from_port = ingress.value.port
|
||||||
|
to_port = ingress.value.port
|
||||||
|
protocol = ingress.value.protocol
|
||||||
|
cidr_blocks = ingress.value.cidr_blocks
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this works:** Iterator uses `ingress.value` (named after the block label, not the variable). Typed input prevents runtime shape errors.
|
||||||
|
|
||||||
|
## 7. Provider Alias for Multi-Region
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
provider "aws" {
|
||||||
|
region = "us-east-1"
|
||||||
|
}
|
||||||
|
|
||||||
|
provider "aws" {
|
||||||
|
alias = "eu"
|
||||||
|
region = "eu-west-1"
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "aws_s3_bucket" "replica" {
|
||||||
|
provider = aws.eu
|
||||||
|
bucket = "my-replica-bucket"
|
||||||
|
}
|
||||||
|
|
||||||
|
module "eu_network" {
|
||||||
|
source = "./modules/network"
|
||||||
|
providers = {
|
||||||
|
aws = aws.eu
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this works:** Explicit alias keeps region intent clear. Modules receive providers via `providers` map, not implicit inheritance.
|
||||||
|
|
||||||
|
## 8. `moved` Block for Safe Rename
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
moved {
|
||||||
|
from = aws_kms_key.logs
|
||||||
|
to = aws_kms_key.audit
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Why this works:** Keeps state continuity during naming refactors. Prevents unnecessary replacement that could destroy encryption keys.
|
||||||
83
skills/terrashark/docs/examples/neutral-patterns.md
Normal file
83
skills/terrashark/docs/examples/neutral-patterns.md
Normal file
|
|
@ -0,0 +1,83 @@
|
||||||
|
# Terraform Neutral Patterns (Context-Dependent)
|
||||||
|
|
||||||
|
Six patterns that are neither universally good nor bad — they depend on organizational context, team size, and governance maturity. The Terraform skill presents these as explicit tradeoffs rather than recommendations.
|
||||||
|
|
||||||
|
## 1. Workspace-Centric Environment Split
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
locals {
|
||||||
|
env = terraform.workspace
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "aws_cloudwatch_log_group" "audit" {
|
||||||
|
name = "/org/${local.env}/audit"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Tradeoff:** Clean for workspace-managed workflows. Harder to reason about in ad-hoc CLI usage across many environments.
|
||||||
|
|
||||||
|
## 2. Single Repo with Many Modules
|
||||||
|
|
||||||
|
```
|
||||||
|
iac-repo/
|
||||||
|
modules/
|
||||||
|
network/
|
||||||
|
identity/
|
||||||
|
observability/
|
||||||
|
environments/
|
||||||
|
dev/
|
||||||
|
prod/
|
||||||
|
```
|
||||||
|
|
||||||
|
**Tradeoff:** Easy discovery and shared standards. Larger blast radius for repo-level process changes.
|
||||||
|
|
||||||
|
## 3. Remote-State Bridge Across Stacks
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
data "terraform_remote_state" "platform" {
|
||||||
|
backend = "gcs"
|
||||||
|
config = {
|
||||||
|
bucket = "infra-state-org"
|
||||||
|
prefix = "platform/prod"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Tradeoff:** Quick integration path. Introduces coupling to producer stack internals.
|
||||||
|
|
||||||
|
## 4. Composite Module Owning Many Primitives
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
module "payments_platform" {
|
||||||
|
source = "./modules/payments-platform"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Tradeoff:** Simplifies root composition. Can become hard to evolve if internal boundaries are unclear.
|
||||||
|
|
||||||
|
## 5. Apply-Mode Native Tests in CI
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
run "database_contract" {
|
||||||
|
command = apply
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Tradeoff:** Catches real runtime behavior. Increases cost and pipeline duration significantly.
|
||||||
|
|
||||||
|
## 6. Aggressive Precondition Usage
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
resource "aws_s3_bucket" "artifact" {
|
||||||
|
bucket = var.bucket_name
|
||||||
|
|
||||||
|
lifecycle {
|
||||||
|
precondition {
|
||||||
|
condition = startswith(var.bucket_name, "org-")
|
||||||
|
error_message = "Bucket names must start with org-."
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Tradeoff:** Protects conventions early and enforces naming standards. Too many strict checks can reduce module reuse across different org units.
|
||||||
85
skills/terrashark/docs/failure-modes/blast-radius.md
Normal file
85
skills/terrashark/docs/failure-modes/blast-radius.md
Normal file
|
|
@ -0,0 +1,85 @@
|
||||||
|
# Terraform Blast Radius: Limiting Change Impact Scope
|
||||||
|
|
||||||
|
Blast radius problems occur when infrastructure stacks are too large or poorly isolated, causing small changes to have widespread, unintended impact across unrelated services.
|
||||||
|
|
||||||
|
## Symptoms of Blast Radius Problems
|
||||||
|
|
||||||
|
- Tiny change triggers a very large plan
|
||||||
|
- Unrelated services share one state and fail together
|
||||||
|
- Production and non-production are entangled
|
||||||
|
- Review/approval ownership is unclear
|
||||||
|
|
||||||
|
## Boundary Model
|
||||||
|
|
||||||
|
Split stacks along three axes:
|
||||||
|
|
||||||
|
| Axis | Question |
|
||||||
|
|---|---|
|
||||||
|
| **Ownership** | Who approves and supports this? |
|
||||||
|
| **Change cadence** | What changes together? |
|
||||||
|
| **Recovery** | What can fail together? |
|
||||||
|
|
||||||
|
If these differ between components, split the stack/state.
|
||||||
|
|
||||||
|
## Architecture Patterns
|
||||||
|
|
||||||
|
| Pattern | Scope |
|
||||||
|
|---|---|
|
||||||
|
| **Platform foundation stack** | Network, identity, shared controls |
|
||||||
|
| **Service stack(s)** | One per business workload |
|
||||||
|
| **Bootstrap stack** | Backend/state prerequisites |
|
||||||
|
|
||||||
|
Do not combine all of them in one root.
|
||||||
|
|
||||||
|
## State Isolation Rules
|
||||||
|
|
||||||
|
- One backend key per isolated stack/environment
|
||||||
|
- Dedicated lock scope per stack
|
||||||
|
- Backup/versioning required for production states
|
||||||
|
- No shared prod/non-prod state files
|
||||||
|
|
||||||
|
## Environment Separation Options
|
||||||
|
|
||||||
|
1. **Separate directories** + separate backend keys (recommended default)
|
||||||
|
2. **Workspace per environment** (only with strict governance and access controls)
|
||||||
|
3. **Separate repositories** for hard regulatory segregation
|
||||||
|
|
||||||
|
## Apply Governance
|
||||||
|
|
||||||
|
- Serialize applies to shared foundations
|
||||||
|
- Require explicit approval for production and destructive plans
|
||||||
|
- Block auto-apply for high-impact stacks
|
||||||
|
|
||||||
|
## Example Directory Structure
|
||||||
|
|
||||||
|
```
|
||||||
|
infra/
|
||||||
|
bootstrap/
|
||||||
|
platform/
|
||||||
|
dev/
|
||||||
|
prod/
|
||||||
|
services/
|
||||||
|
billing/
|
||||||
|
dev/
|
||||||
|
prod/
|
||||||
|
catalog/
|
||||||
|
dev/
|
||||||
|
prod/
|
||||||
|
```
|
||||||
|
|
||||||
|
## LLM Mistake Checklist
|
||||||
|
|
||||||
|
Common model mistakes the Terraform skill corrects:
|
||||||
|
|
||||||
|
- Proposes one monolithic root for convenience
|
||||||
|
- Recommends workspace-only isolation without access controls
|
||||||
|
- Mixes blast radius discussion with purely stylistic concerns
|
||||||
|
- Omits rollback path for shared foundation changes
|
||||||
|
|
||||||
|
## Verification Checks
|
||||||
|
|
||||||
|
Before applying, verify:
|
||||||
|
|
||||||
|
- Does the plan only touch the intended stack?
|
||||||
|
- Does the state key scope match the ownership boundary?
|
||||||
|
- Is the rollback path documented for this apply?
|
||||||
157
skills/terrashark/docs/failure-modes/ci-drift.md
Normal file
157
skills/terrashark/docs/failure-modes/ci-drift.md
Normal file
|
|
@ -0,0 +1,157 @@
|
||||||
|
# Terraform CI Drift: Preventing Pipeline Divergence
|
||||||
|
|
||||||
|
CI drift occurs when pipeline behavior diverges from local behavior or from reviewed intent. This leads to unreviewed applies, inconsistent infrastructure state, and broken trust in the delivery process.
|
||||||
|
|
||||||
|
## Symptoms of CI Drift
|
||||||
|
|
||||||
|
- CI plan differs from local plan unexpectedly
|
||||||
|
- Apply occurs without using the reviewed plan artifact
|
||||||
|
- Provider/runtime drift appears between runs
|
||||||
|
- Scanner/policy stages are skipped on some paths
|
||||||
|
|
||||||
|
## Root Causes
|
||||||
|
|
||||||
|
- **Unpinned runtime/provider versions** — different versions produce different plans
|
||||||
|
- **Missing or stale lockfile** — providers resolve differently across environments
|
||||||
|
- **Apply re-runs plan** — apply job runs `plan` again instead of consuming the reviewed artifact
|
||||||
|
- **Inconsistent auth** — different credentials between plan and apply stages
|
||||||
|
|
||||||
|
## Drift Prevention Baseline
|
||||||
|
|
||||||
|
- Pin runtime and provider version ranges
|
||||||
|
- Commit lockfile and review lockfile changes
|
||||||
|
- Generate one reviewed plan artifact and apply exactly that artifact
|
||||||
|
- Run policy/security checks on every path to apply
|
||||||
|
- Enforce branch protections and environment approvals
|
||||||
|
|
||||||
|
## Production-Ready GitHub Actions Template
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
name: terraform-delivery
|
||||||
|
|
||||||
|
on:
|
||||||
|
pull_request:
|
||||||
|
paths:
|
||||||
|
- '**/*.tf'
|
||||||
|
- '**/*.tfvars'
|
||||||
|
push:
|
||||||
|
branches: [main]
|
||||||
|
paths:
|
||||||
|
- '**/*.tf'
|
||||||
|
- '**/*.tfvars'
|
||||||
|
|
||||||
|
concurrency:
|
||||||
|
group: terraform-${{ github.ref }}
|
||||||
|
cancel-in-progress: false
|
||||||
|
|
||||||
|
permissions:
|
||||||
|
contents: read
|
||||||
|
id-token: write
|
||||||
|
pull-requests: write
|
||||||
|
|
||||||
|
jobs:
|
||||||
|
plan:
|
||||||
|
if: github.event_name == 'pull_request'
|
||||||
|
runs-on: ubuntu-latest
|
||||||
|
steps:
|
||||||
|
- uses: actions/checkout@v4
|
||||||
|
- uses: hashicorp/setup-terraform@v3
|
||||||
|
- run: terraform fmt -check
|
||||||
|
- run: terraform init -backend=false
|
||||||
|
- run: terraform validate
|
||||||
|
- run: terraform init
|
||||||
|
- run: terraform plan -out=plan.bin
|
||||||
|
- run: terraform show -json plan.bin > plan.json
|
||||||
|
- run: conftest test plan.json --policy policy/
|
||||||
|
- uses: actions/upload-artifact@v4
|
||||||
|
with:
|
||||||
|
name: reviewed-plan
|
||||||
|
path: plan.bin
|
||||||
|
|
||||||
|
apply:
|
||||||
|
if: github.event_name == 'push' && github.ref == 'refs/heads/main'
|
||||||
|
needs: [validate]
|
||||||
|
runs-on: ubuntu-latest
|
||||||
|
environment: production
|
||||||
|
steps:
|
||||||
|
- uses: actions/checkout@v4
|
||||||
|
- uses: hashicorp/setup-terraform@v3
|
||||||
|
- uses: actions/download-artifact@v4
|
||||||
|
with:
|
||||||
|
name: reviewed-plan
|
||||||
|
- run: terraform init
|
||||||
|
- run: terraform apply -auto-approve plan.bin
|
||||||
|
```
|
||||||
|
|
||||||
|
**Notes:**
|
||||||
|
- Replace auth steps with OIDC/provider-specific login actions
|
||||||
|
- In real repos, split plan/apply workflows if artifact lifetime across events is an issue
|
||||||
|
|
||||||
|
## Production-Ready GitLab CI Template
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
stages:
|
||||||
|
- validate
|
||||||
|
- plan
|
||||||
|
- policy
|
||||||
|
- apply
|
||||||
|
|
||||||
|
variables:
|
||||||
|
TF_IN_AUTOMATION: "true"
|
||||||
|
|
||||||
|
validate:
|
||||||
|
stage: validate
|
||||||
|
image: hashicorp/terraform:1.7
|
||||||
|
script:
|
||||||
|
- terraform fmt -check
|
||||||
|
- terraform init -backend=false
|
||||||
|
- terraform validate
|
||||||
|
|
||||||
|
plan:
|
||||||
|
stage: plan
|
||||||
|
image: hashicorp/terraform:1.7
|
||||||
|
script:
|
||||||
|
- terraform init
|
||||||
|
- terraform plan -out=plan.bin
|
||||||
|
- terraform show -json plan.bin > plan.json
|
||||||
|
artifacts:
|
||||||
|
paths:
|
||||||
|
- plan.bin
|
||||||
|
- plan.json
|
||||||
|
expire_in: 24h
|
||||||
|
|
||||||
|
policy:
|
||||||
|
stage: policy
|
||||||
|
image: openpolicyagent/conftest:latest
|
||||||
|
script:
|
||||||
|
- conftest test plan.json --policy policy/
|
||||||
|
dependencies:
|
||||||
|
- plan
|
||||||
|
|
||||||
|
apply:
|
||||||
|
stage: apply
|
||||||
|
image: hashicorp/terraform:1.7
|
||||||
|
when: manual
|
||||||
|
allow_failure: false
|
||||||
|
script:
|
||||||
|
- terraform init
|
||||||
|
- terraform apply -auto-approve plan.bin
|
||||||
|
dependencies:
|
||||||
|
- plan
|
||||||
|
```
|
||||||
|
|
||||||
|
## LLM Mistake Checklist
|
||||||
|
|
||||||
|
Common model mistakes the Terraform skill corrects:
|
||||||
|
|
||||||
|
- Missing lockfile strategy
|
||||||
|
- Apply without saved plan artifact
|
||||||
|
- No policy stage despite claiming compliance
|
||||||
|
- No branch/environment protection discussion
|
||||||
|
|
||||||
|
## Quick Diagnostics
|
||||||
|
|
||||||
|
- Compare runtime versions local vs CI
|
||||||
|
- Diff lockfile in PR
|
||||||
|
- Ensure apply consumes `plan.bin` from the reviewed plan stage
|
||||||
|
- Verify policy scanner runs on every apply path
|
||||||
103
skills/terrashark/docs/failure-modes/compliance-gates.md
Normal file
103
skills/terrashark/docs/failure-modes/compliance-gates.md
Normal file
|
|
@ -0,0 +1,103 @@
|
||||||
|
# Terraform Compliance Gates: Enforceable Controls and Evidence
|
||||||
|
|
||||||
|
Compliance gate gaps occur when frameworks are referenced by name but no enforceable controls or evidence artifacts actually exist. The Terraform skill treats compliance as delivery gates, not static documentation.
|
||||||
|
|
||||||
|
## Core Principle
|
||||||
|
|
||||||
|
Every compliance framework mapping should translate into:
|
||||||
|
|
||||||
|
- **Preventative controls** — policy/validation that blocks non-compliant changes
|
||||||
|
- **Detective controls** — logging/monitoring that catches issues post-deploy
|
||||||
|
- **Evidence artifacts** — plans, approvals, audit records that prove compliance
|
||||||
|
|
||||||
|
## Framework Starter Mappings
|
||||||
|
|
||||||
|
### ISO 27001
|
||||||
|
|
||||||
|
**Focus:** Formal ISMS governance, access control and change management, incident response and evidence retention.
|
||||||
|
|
||||||
|
**IaC gate examples:**
|
||||||
|
- Mandatory change approval records
|
||||||
|
- Encryption and logging policy checks
|
||||||
|
- Periodic access review evidence from CI/CD systems
|
||||||
|
|
||||||
|
### SOC 2
|
||||||
|
|
||||||
|
**Focus:** Security, availability, confidentiality controls.
|
||||||
|
|
||||||
|
**IaC gate examples:**
|
||||||
|
- Least-privilege IAM enforcement
|
||||||
|
- Transport/at-rest encryption checks
|
||||||
|
- Audit logging enabled on critical services
|
||||||
|
|
||||||
|
### FedRAMP
|
||||||
|
|
||||||
|
**Focus:** Strict baseline controls, boundary protection, continuous monitoring (when US federal workloads apply).
|
||||||
|
|
||||||
|
**IaC gate examples:**
|
||||||
|
- Region/service allowlists for authorized environments
|
||||||
|
- Hardened network segmentation policies
|
||||||
|
- Continuous scan artifacts attached to each release
|
||||||
|
|
||||||
|
### GDPR
|
||||||
|
|
||||||
|
**Focus:** Data protection by design, minimization, lawful processing support (when processing EU personal data).
|
||||||
|
|
||||||
|
**IaC gate examples:**
|
||||||
|
- Data residency constraints via policy
|
||||||
|
- Retention/lifecycle enforcement for personal data stores
|
||||||
|
- Access logging for data systems with evidence retention
|
||||||
|
|
||||||
|
### PCI DSS
|
||||||
|
|
||||||
|
**Focus:** Segmentation, key management, hardening, monitoring (when cardholder data environment exists).
|
||||||
|
|
||||||
|
**IaC gate examples:**
|
||||||
|
- Deny public exposure of CDE components
|
||||||
|
- No default credentials
|
||||||
|
- Strong encryption and key rotation controls
|
||||||
|
|
||||||
|
### HIPAA
|
||||||
|
|
||||||
|
**Focus:** Confidentiality/integrity of ePHI, auditability, access controls (when handling protected health information).
|
||||||
|
|
||||||
|
**IaC gate examples:**
|
||||||
|
- Private network boundaries for ePHI systems
|
||||||
|
- Immutable audit trails for infra changes
|
||||||
|
- Backup/retention and recovery controls
|
||||||
|
|
||||||
|
## Policy-as-Code Gate Pattern
|
||||||
|
|
||||||
|
| Stage | Tool/Action | Purpose |
|
||||||
|
|---|---|---|
|
||||||
|
| **Stage 1** | Static scanning (`tfsec`, `checkov`) | Catch common misconfigurations |
|
||||||
|
| **Stage 2** | Plan policy checks (Sentinel/OPA/Conftest) | Enforce organizational policies |
|
||||||
|
| **Stage 3** | Approval workflow by risk class | Human oversight for high-impact changes |
|
||||||
|
| **Stage 4** | Evidence archival | Retain plan, policy result, approver identity |
|
||||||
|
|
||||||
|
## Risk-Classed Approval Model
|
||||||
|
|
||||||
|
| Risk Level | Required Approval |
|
||||||
|
|---|---|
|
||||||
|
| **Low** | One maintainer approval |
|
||||||
|
| **Medium** | Platform owner + service owner approval |
|
||||||
|
| **High** (identity/network/encryption/state) | Security or compliance sign-off required |
|
||||||
|
|
||||||
|
## Minimal Evidence Checklist
|
||||||
|
|
||||||
|
For each production apply, retain:
|
||||||
|
|
||||||
|
- Reviewed plan artifact and hash
|
||||||
|
- Policy scan output
|
||||||
|
- Approver identity and timestamp
|
||||||
|
- Runtime/provider versions
|
||||||
|
- Post-apply verification logs
|
||||||
|
|
||||||
|
## LLM Mistake Checklist
|
||||||
|
|
||||||
|
Common model mistakes the Terraform skill corrects:
|
||||||
|
|
||||||
|
- Mentions framework names but gives no enforceable gates
|
||||||
|
- Confuses security best practices with compliance evidence
|
||||||
|
- Omits who approves what risk class
|
||||||
|
- Ignores data-residency obligations for GDPR/FedRAMP-like contexts
|
||||||
149
skills/terrashark/docs/failure-modes/identity-churn.md
Normal file
149
skills/terrashark/docs/failure-modes/identity-churn.md
Normal file
|
|
@ -0,0 +1,149 @@
|
||||||
|
# Terraform Identity Churn: Preventing Resource Address Instability
|
||||||
|
|
||||||
|
Identity churn is one of the most common and dangerous Terraform failure modes. It occurs when resource addresses or object identity shift unexpectedly, causing destroy/create cycles that can take down production infrastructure.
|
||||||
|
|
||||||
|
## Symptoms of Identity Churn
|
||||||
|
|
||||||
|
- Plan shows broad replace actions after small list edits
|
||||||
|
- Renaming resources/modules triggers destroy/create instead of in-place updates
|
||||||
|
- Refactor from `count` to `for_each` causes churn
|
||||||
|
- Imported resources keep drifting because addressing is unstable
|
||||||
|
|
||||||
|
## Primary Causes
|
||||||
|
|
||||||
|
- **Index-based identity** (`count`) used for long-lived logical objects
|
||||||
|
- **Unstable keys** derived from sorted lists or transient IDs
|
||||||
|
- **Missing `moved` blocks** during refactors
|
||||||
|
- **Hidden dependencies** forcing replacement chains
|
||||||
|
- **`for_each` keys** derived from values unknown at plan time
|
||||||
|
|
||||||
|
## Prevention Rules
|
||||||
|
|
||||||
|
- Use `for_each` for long-lived identities
|
||||||
|
- Choose stable keys from business identity (e.g., `zone-a`, `payments-api`)
|
||||||
|
- Keep identity attributes separate from mutable attributes
|
||||||
|
- Add `moved` blocks before first apply after rename/restructure
|
||||||
|
|
||||||
|
## Decision Matrix: `count` vs `for_each`
|
||||||
|
|
||||||
|
### Use `count` only when:
|
||||||
|
- Resource is truly optional singleton (`0` or `1`)
|
||||||
|
- No downstream references depend on stable per-item addresses
|
||||||
|
|
||||||
|
### Use `for_each` when:
|
||||||
|
- Multiple logical instances are expected
|
||||||
|
- Insertion/removal/reordering happens over time
|
||||||
|
- Downstream references need stable keys
|
||||||
|
- Keys are fully known during planning
|
||||||
|
|
||||||
|
### When keys are unknown at plan time:
|
||||||
|
- Drive `for_each` from known input keys
|
||||||
|
- Use `count` for conditional/singleton creation when key-stable `for_each` is not possible
|
||||||
|
|
||||||
|
## Safe Migration: `count` to `for_each`
|
||||||
|
|
||||||
|
1. Define stable key map
|
||||||
|
2. Refactor resource to `for_each`
|
||||||
|
3. Add one `moved` block per old index
|
||||||
|
4. Verify plan reports move operations, not replace
|
||||||
|
5. Apply in lower environment first
|
||||||
|
|
||||||
|
### Example
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
locals {
|
||||||
|
app_subnets = {
|
||||||
|
a = { cidr = "10.40.1.0/24", az = "us-east-1a" }
|
||||||
|
b = { cidr = "10.40.2.0/24", az = "us-east-1b" }
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "aws_subnet" "app" {
|
||||||
|
for_each = local.app_subnets
|
||||||
|
vpc_id = aws_vpc.main.id
|
||||||
|
cidr_block = each.value.cidr
|
||||||
|
availability_zone = each.value.az
|
||||||
|
tags = {
|
||||||
|
Name = "app-${each.key}"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
moved {
|
||||||
|
from = aws_subnet.app[0]
|
||||||
|
to = aws_subnet.app["a"]
|
||||||
|
}
|
||||||
|
|
||||||
|
moved {
|
||||||
|
from = aws_subnet.app[1]
|
||||||
|
to = aws_subnet.app["b"]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Rename Playbook
|
||||||
|
|
||||||
|
When renaming resource/module labels, always add `moved` first:
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
moved {
|
||||||
|
from = module.network_core
|
||||||
|
to = module.network_foundation
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Known-at-Plan Failure Pattern
|
||||||
|
|
||||||
|
**Bad** — key depends on apply-time value:
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
resource "aws_security_group_rule" "egress" {
|
||||||
|
for_each = toset([aws_security_group.ecs.id])
|
||||||
|
type = "egress"
|
||||||
|
from_port = 443
|
||||||
|
to_port = 443
|
||||||
|
protocol = "tcp"
|
||||||
|
security_group_id = each.value
|
||||||
|
cidr_blocks = ["0.0.0.0/0"]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Safer fallback** for optional singleton behavior:
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
resource "aws_security_group_rule" "egress" {
|
||||||
|
count = var.enable_egress_rule ? 1 : 0
|
||||||
|
type = "egress"
|
||||||
|
from_port = 443
|
||||||
|
to_port = 443
|
||||||
|
protocol = "tcp"
|
||||||
|
security_group_id = aws_security_group.ecs.id
|
||||||
|
cidr_blocks = ["0.0.0.0/0"]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## LLM Mistake Checklist
|
||||||
|
|
||||||
|
Common model mistakes the Terraform skill corrects:
|
||||||
|
|
||||||
|
- Defaults to `count` for every collection
|
||||||
|
- Omits `moved` blocks in refactors
|
||||||
|
- Uses list index as identity key
|
||||||
|
- Suggests `terraform state mv` in automation where `moved` is safer and reviewable
|
||||||
|
- Builds `for_each` keys from computed IDs not known until apply
|
||||||
|
|
||||||
|
## Verification Commands
|
||||||
|
|
||||||
|
```bash
|
||||||
|
terraform fmt -check
|
||||||
|
terraform validate
|
||||||
|
terraform plan -out=plan.bin
|
||||||
|
terraform show plan.bin | grep -i moved
|
||||||
|
```
|
||||||
|
|
||||||
|
OpenTofu equivalent:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
tofu fmt -check
|
||||||
|
tofu validate
|
||||||
|
tofu plan -out=plan.bin
|
||||||
|
tofu show plan.bin | grep -i moved
|
||||||
|
```
|
||||||
94
skills/terrashark/docs/failure-modes/secret-exposure.md
Normal file
94
skills/terrashark/docs/failure-modes/secret-exposure.md
Normal file
|
|
@ -0,0 +1,94 @@
|
||||||
|
# Terraform Secret Exposure: Preventing Credential Leaks
|
||||||
|
|
||||||
|
Secret exposure occurs when credentials, tokens, or sensitive data leak into Terraform state files, CI logs, plan output, variable defaults, or artifact storage. This is a critical security failure mode.
|
||||||
|
|
||||||
|
## Symptoms of Secret Exposure
|
||||||
|
|
||||||
|
- Secret values appear in plan output or logs
|
||||||
|
- Credentials are defined in variable defaults
|
||||||
|
- Sensitive outputs are printed in CI
|
||||||
|
- Generated passwords are stored in state unintentionally
|
||||||
|
|
||||||
|
## Exposure Paths
|
||||||
|
|
||||||
|
- **Hardcoded defaults** in `variables.tf`
|
||||||
|
- **State persistence** — secret-bearing resources whose values are persisted in state
|
||||||
|
- **Logging** — `terraform show` outputs without redaction
|
||||||
|
- **Artifact retention** — policies that keep plan/state exports too long
|
||||||
|
|
||||||
|
## Prevention Baseline
|
||||||
|
|
||||||
|
- Never set secret defaults in code
|
||||||
|
- Source secrets from managed secret stores at runtime
|
||||||
|
- Mark secret variables and outputs as `sensitive = true`
|
||||||
|
- Restrict state backend access aggressively
|
||||||
|
- Avoid publishing raw plan JSON as broadly accessible artifact
|
||||||
|
|
||||||
|
## Runtime Patterns (Preferred Order)
|
||||||
|
|
||||||
|
1. **External secret manager lookup** (AWS Secrets Manager, HashiCorp Vault, etc.)
|
||||||
|
2. **Workload identity federation** for providers
|
||||||
|
3. **Short-lived credentials** from trusted broker
|
||||||
|
|
||||||
|
Avoid long-lived static credentials in repository or runner config.
|
||||||
|
|
||||||
|
## Understanding `sensitive` and `write_only`
|
||||||
|
|
||||||
|
- `sensitive = true` masks display but the value can still exist in state depending on provider behavior
|
||||||
|
- `write_only` arguments (where supported) reduce state persistence risk
|
||||||
|
- Always verify provider docs before assuming secret material is excluded from state
|
||||||
|
|
||||||
|
## Good Example: Secret Manager Integration
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
variable "db_admin_username" {
|
||||||
|
description = "Database admin user"
|
||||||
|
type = string
|
||||||
|
}
|
||||||
|
|
||||||
|
data "aws_secretsmanager_secret_version" "db_password" {
|
||||||
|
secret_id = "prod/db/admin"
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "aws_db_instance" "core" {
|
||||||
|
identifier = "core-db-prod"
|
||||||
|
username = var.db_admin_username
|
||||||
|
password = jsondecode(
|
||||||
|
data.aws_secretsmanager_secret_version.db_password.secret_string
|
||||||
|
)["password"]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Bad Example: Plaintext Default
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
variable "db_password" {
|
||||||
|
type = string
|
||||||
|
default = "ChangeMe123!" # NEVER do this
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Rotation Playbook
|
||||||
|
|
||||||
|
1. Create new secret version in manager
|
||||||
|
2. Update application to consume new version
|
||||||
|
3. Roll infrastructure safely
|
||||||
|
4. Revoke old credential
|
||||||
|
5. Verify no leaked copies remain in logs/artifacts
|
||||||
|
|
||||||
|
## LLM Mistake Checklist
|
||||||
|
|
||||||
|
Common model mistakes the Terraform skill corrects:
|
||||||
|
|
||||||
|
- Assumes `sensitive` alone means "not in state"
|
||||||
|
- Proposes plaintext defaults for demo convenience
|
||||||
|
- Uses outputs that expose full connection strings in PR comments
|
||||||
|
- Forgets artifact retention and access controls in CI
|
||||||
|
|
||||||
|
## Verification Commands
|
||||||
|
|
||||||
|
```bash
|
||||||
|
terraform plan -out=plan.bin
|
||||||
|
terraform show -json plan.bin > plan.json
|
||||||
|
# Ensure secret fields are not emitted to shared artifacts/logs
|
||||||
|
```
|
||||||
92
skills/terrashark/docs/getting-started/installation.md
Normal file
92
skills/terrashark/docs/getting-started/installation.md
Normal file
|
|
@ -0,0 +1,92 @@
|
||||||
|
# Installing the Terraform Skill
|
||||||
|
|
||||||
|
TerraShark can be installed in three ways depending on your environment: direct clone, marketplace, or per-project for Codex.
|
||||||
|
|
||||||
|
## Option 1: Clone to Skills Directory (Recommended)
|
||||||
|
|
||||||
|
The simplest method. Clone the repository into Claude Code's skills directory.
|
||||||
|
|
||||||
|
### macOS / Linux
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git clone https://github.com/LukasNiessen/terrashark.git ~/.claude/skills/terrashark
|
||||||
|
```
|
||||||
|
|
||||||
|
### Windows (PowerShell)
|
||||||
|
|
||||||
|
```powershell
|
||||||
|
git clone https://github.com/LukasNiessen/terrashark.git "$env:USERPROFILE\.claude\skills\terrashark"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Windows (Command Prompt)
|
||||||
|
|
||||||
|
```cmd
|
||||||
|
git clone https://github.com/LukasNiessen/terrashark.git "%USERPROFILE%\.claude\skills\terrashark"
|
||||||
|
```
|
||||||
|
|
||||||
|
Claude Code auto-discovers skills in `~/.claude/skills/` — **no restart needed**.
|
||||||
|
|
||||||
|
## Option 2: Marketplace Install
|
||||||
|
|
||||||
|
Claude Code has a built-in plugin system with marketplace support. Add TerraShark directly from the CLI:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
/plugin marketplace add LukasNiessen/terrashark
|
||||||
|
/plugin install terrashark
|
||||||
|
```
|
||||||
|
|
||||||
|
Or use the interactive plugin manager:
|
||||||
|
1. Run `/plugin`
|
||||||
|
2. Switch to the **Discover** tab
|
||||||
|
3. Install TerraShark from there
|
||||||
|
|
||||||
|
The marketplace reads the `.claude-plugin/marketplace.json` in the repository to register TerraShark as an installable plugin.
|
||||||
|
|
||||||
|
## Option 3: Codex (Per-Project Setup)
|
||||||
|
|
||||||
|
Codex has no global skill system — setup is per-project. Clone TerraShark into your repository and reference it from your `AGENTS.md`:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Clone into your project root
|
||||||
|
git clone https://github.com/LukasNiessen/terrashark.git .terrashark
|
||||||
|
```
|
||||||
|
|
||||||
|
Then add to your `AGENTS.md` (or create one in the repo root):
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Terraform
|
||||||
|
|
||||||
|
When working with Terraform or OpenTofu, follow the workflow in `.terrashark/SKILL.md`.
|
||||||
|
Load references from `.terrashark/references/` as needed.
|
||||||
|
```
|
||||||
|
|
||||||
|
## Updating the Terraform Skill
|
||||||
|
|
||||||
|
To update to the latest version, pull the latest changes:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cd ~/.claude/skills/terrashark
|
||||||
|
git pull origin main
|
||||||
|
```
|
||||||
|
|
||||||
|
## Verifying the Installation
|
||||||
|
|
||||||
|
After installing, test it by asking Claude Code any Terraform question:
|
||||||
|
|
||||||
|
```
|
||||||
|
/terrashark Create a multi-region S3 module with replication
|
||||||
|
```
|
||||||
|
|
||||||
|
Or ask naturally — the Terraform skill activates automatically for any Terraform/OpenTofu task:
|
||||||
|
|
||||||
|
```
|
||||||
|
Review my main.tf for security issues
|
||||||
|
```
|
||||||
|
|
||||||
|
The response should follow the 7-step failure-mode workflow and include an output contract with assumptions, tradeoffs, and rollback notes.
|
||||||
|
|
||||||
|
## System Requirements
|
||||||
|
|
||||||
|
- **Claude Code** or **Codex** with skill support
|
||||||
|
- **Git** for cloning the repository
|
||||||
|
- No additional dependencies required — the skill is pure Markdown
|
||||||
69
skills/terrashark/docs/getting-started/quick-start.md
Normal file
69
skills/terrashark/docs/getting-started/quick-start.md
Normal file
|
|
@ -0,0 +1,69 @@
|
||||||
|
# Terraform Skill Quick Start Guide
|
||||||
|
|
||||||
|
Get productive with the Terraform skill in under 2 minutes.
|
||||||
|
|
||||||
|
## Step 1: Install
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git clone https://github.com/LukasNiessen/terrashark.git ~/.claude/skills/terrashark
|
||||||
|
```
|
||||||
|
|
||||||
|
## Step 2: Use It
|
||||||
|
|
||||||
|
### Explicit Invocation
|
||||||
|
|
||||||
|
Use the `/terrashark` command to explicitly invoke the Terraform skill:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
/terrashark Create a multi-region S3 module with replication
|
||||||
|
```
|
||||||
|
|
||||||
|
```bash
|
||||||
|
/terrashark Refactor our EKS stack into separate state files per environment, add moved blocks to avoid recreation, set up a GitHub Actions pipeline with plan on PR and gated apply on merge, and wire in Checkov for compliance scanning
|
||||||
|
```
|
||||||
|
|
||||||
|
### Automatic Activation
|
||||||
|
|
||||||
|
The Terraform skill activates automatically for any Terraform/OpenTofu task. Just ask naturally:
|
||||||
|
|
||||||
|
```
|
||||||
|
Review my main.tf for security issues
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
Migrate this module from count to for_each
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
Set up a CI pipeline for our Terraform modules
|
||||||
|
```
|
||||||
|
|
||||||
|
## What to Expect
|
||||||
|
|
||||||
|
Every TerraShark response follows the 7-step workflow and includes a structured output:
|
||||||
|
|
||||||
|
1. **Assumptions** — what the skill assumed about your environment and versions
|
||||||
|
2. **Failure modes** — which risks were identified (identity churn, secret exposure, etc.)
|
||||||
|
3. **Remediation** — what was recommended and what tradeoffs were made
|
||||||
|
4. **Validation plan** — how to verify the output before applying
|
||||||
|
5. **Rollback notes** — how to undo changes if something goes wrong
|
||||||
|
|
||||||
|
## Example Tasks
|
||||||
|
|
||||||
|
Here are some common tasks the Terraform skill excels at:
|
||||||
|
|
||||||
|
| Task | Example Prompt |
|
||||||
|
|------|---------------|
|
||||||
|
| Module creation | "Create an AWS VPC module with public and private subnets" |
|
||||||
|
| Security review | "Review my Terraform for secret exposure risks" |
|
||||||
|
| Migration | "Migrate from count to for_each for my subnet resources" |
|
||||||
|
| CI/CD setup | "Set up GitHub Actions for Terraform with plan on PR and apply on merge" |
|
||||||
|
| Compliance | "Add SOC 2 compliance gates to our Terraform pipeline" |
|
||||||
|
| Refactoring | "Split this monolithic root into service stacks with blast radius isolation" |
|
||||||
|
| Troubleshooting | "Why does my plan show replacements after renaming a module?" |
|
||||||
|
|
||||||
|
## Next Steps
|
||||||
|
|
||||||
|
- Read about the [7-Step Workflow](../core-concepts/workflow.md) to understand how the skill processes tasks
|
||||||
|
- Explore the [Five Failure Modes](../core-concepts/failure-modes.md) that drive every diagnostic
|
||||||
|
- Check the [Good Patterns](../examples/good-patterns.md) and [Bad Patterns](../examples/bad-patterns.md) for reference
|
||||||
211
skills/terrashark/docs/guides/ci-delivery.md
Normal file
211
skills/terrashark/docs/guides/ci-delivery.md
Normal file
|
|
@ -0,0 +1,211 @@
|
||||||
|
# Terraform CI/CD Delivery Patterns
|
||||||
|
|
||||||
|
This guide covers implementing auditable Terraform and OpenTofu delivery pipelines with GitHub Actions, GitLab CI, Atlantis, and Infracost.
|
||||||
|
|
||||||
|
## Delivery Principles
|
||||||
|
|
||||||
|
- Plan and apply are separate concerns
|
||||||
|
- Apply must consume the reviewed plan artifact when architecture permits
|
||||||
|
- Policy and security checks run on every apply path
|
||||||
|
- Production applies require environment protection and approvals
|
||||||
|
|
||||||
|
## Baseline Stages
|
||||||
|
|
||||||
|
Every production Terraform pipeline should include:
|
||||||
|
|
||||||
|
1. `fmt` + `validate`
|
||||||
|
2. Lint + security scan
|
||||||
|
3. Plan creation
|
||||||
|
4. Policy checks against plan JSON
|
||||||
|
5. Approval gate
|
||||||
|
6. Apply from trusted branch/runner
|
||||||
|
7. Post-apply drift and evidence capture
|
||||||
|
|
||||||
|
## GitHub Actions Template
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
name: terraform-delivery
|
||||||
|
|
||||||
|
on:
|
||||||
|
pull_request:
|
||||||
|
paths:
|
||||||
|
- '**/*.tf'
|
||||||
|
- '**/*.tfvars'
|
||||||
|
workflow_dispatch:
|
||||||
|
push:
|
||||||
|
branches: [main]
|
||||||
|
paths:
|
||||||
|
- '**/*.tf'
|
||||||
|
- '**/*.tfvars'
|
||||||
|
|
||||||
|
permissions:
|
||||||
|
contents: read
|
||||||
|
id-token: write
|
||||||
|
pull-requests: write
|
||||||
|
|
||||||
|
concurrency:
|
||||||
|
group: terraform-${{ github.ref }}
|
||||||
|
cancel-in-progress: false
|
||||||
|
|
||||||
|
env:
|
||||||
|
TF_IN_AUTOMATION: "true"
|
||||||
|
|
||||||
|
jobs:
|
||||||
|
validate:
|
||||||
|
runs-on: ubuntu-latest
|
||||||
|
steps:
|
||||||
|
- uses: actions/checkout@v4
|
||||||
|
- uses: hashicorp/setup-terraform@v3
|
||||||
|
- run: terraform fmt -check
|
||||||
|
- run: terraform init -backend=false
|
||||||
|
- run: terraform validate
|
||||||
|
|
||||||
|
plan:
|
||||||
|
if: github.event_name == 'pull_request'
|
||||||
|
needs: [validate]
|
||||||
|
runs-on: ubuntu-latest
|
||||||
|
steps:
|
||||||
|
- uses: actions/checkout@v4
|
||||||
|
- uses: hashicorp/setup-terraform@v3
|
||||||
|
- run: terraform init
|
||||||
|
- run: terraform plan -out=plan.bin
|
||||||
|
- run: terraform show -json plan.bin > plan.json
|
||||||
|
- run: conftest test plan.json --policy policy/
|
||||||
|
- uses: actions/upload-artifact@v4
|
||||||
|
with:
|
||||||
|
name: reviewed-plan
|
||||||
|
path: |
|
||||||
|
plan.bin
|
||||||
|
plan.json
|
||||||
|
|
||||||
|
apply:
|
||||||
|
if: github.event_name == 'push' && github.ref == 'refs/heads/main'
|
||||||
|
runs-on: ubuntu-latest
|
||||||
|
environment: production
|
||||||
|
needs: [validate]
|
||||||
|
steps:
|
||||||
|
- uses: actions/checkout@v4
|
||||||
|
- uses: hashicorp/setup-terraform@v3
|
||||||
|
- run: terraform init
|
||||||
|
- run: terraform plan -out=plan.bin
|
||||||
|
- run: terraform apply -auto-approve plan.bin
|
||||||
|
```
|
||||||
|
|
||||||
|
**Notes:**
|
||||||
|
- Configure provider auth with OIDC (avoid static cloud keys)
|
||||||
|
- For strict "apply reviewed PR plan" semantics, keep plan/apply in same workflow run or externalize signed plan storage
|
||||||
|
|
||||||
|
## GitLab CI Template
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
stages:
|
||||||
|
- validate
|
||||||
|
- plan
|
||||||
|
- policy
|
||||||
|
- apply
|
||||||
|
- verify
|
||||||
|
|
||||||
|
variables:
|
||||||
|
TF_IN_AUTOMATION: "true"
|
||||||
|
|
||||||
|
validate:
|
||||||
|
stage: validate
|
||||||
|
image: hashicorp/terraform:1.7
|
||||||
|
script:
|
||||||
|
- terraform fmt -check
|
||||||
|
- terraform init -backend=false
|
||||||
|
- terraform validate
|
||||||
|
|
||||||
|
plan:
|
||||||
|
stage: plan
|
||||||
|
image: hashicorp/terraform:1.7
|
||||||
|
script:
|
||||||
|
- terraform init
|
||||||
|
- terraform plan -out=plan.bin
|
||||||
|
- terraform show -json plan.bin > plan.json
|
||||||
|
artifacts:
|
||||||
|
paths: [plan.bin, plan.json]
|
||||||
|
expire_in: 24h
|
||||||
|
|
||||||
|
policy:
|
||||||
|
stage: policy
|
||||||
|
image: openpolicyagent/conftest:latest
|
||||||
|
dependencies: [plan]
|
||||||
|
script:
|
||||||
|
- conftest test plan.json --policy policy/
|
||||||
|
|
||||||
|
apply:
|
||||||
|
stage: apply
|
||||||
|
image: hashicorp/terraform:1.7
|
||||||
|
dependencies: [plan]
|
||||||
|
when: manual
|
||||||
|
allow_failure: false
|
||||||
|
script:
|
||||||
|
- terraform init
|
||||||
|
- terraform apply -auto-approve plan.bin
|
||||||
|
|
||||||
|
verify:
|
||||||
|
stage: verify
|
||||||
|
image: hashicorp/terraform:1.7
|
||||||
|
script:
|
||||||
|
- terraform plan -detailed-exitcode
|
||||||
|
```
|
||||||
|
|
||||||
|
## Atlantis (PR-Driven Delivery)
|
||||||
|
|
||||||
|
Use Atlantis for chat-driven, PR-scoped plan/apply with locking.
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
version: 3
|
||||||
|
projects:
|
||||||
|
- name: platform
|
||||||
|
dir: .
|
||||||
|
workspace: default
|
||||||
|
autoplan:
|
||||||
|
enabled: true
|
||||||
|
when_modified: ["**/*.tf", "**/*.tfvars"]
|
||||||
|
workflow: default
|
||||||
|
|
||||||
|
workflows:
|
||||||
|
default:
|
||||||
|
plan:
|
||||||
|
steps:
|
||||||
|
- init
|
||||||
|
- plan
|
||||||
|
apply:
|
||||||
|
steps:
|
||||||
|
- apply
|
||||||
|
```
|
||||||
|
|
||||||
|
**Hardening notes:**
|
||||||
|
- Restrict apply to approved PRs and protected branches
|
||||||
|
- Enable Atlantis server-side locking
|
||||||
|
- Use custom workflows to add policy checks and cost steps
|
||||||
|
- Keep CI auth in OIDC where supported; avoid static secrets
|
||||||
|
|
||||||
|
## Infracost (Cost Visibility)
|
||||||
|
|
||||||
|
Surface cost deltas from plan JSON in PRs:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
terraform plan -out=plan.bin
|
||||||
|
terraform show -json plan.bin > plan.json
|
||||||
|
infracost breakdown --path plan.json --format json --out-file infracost.json
|
||||||
|
```
|
||||||
|
|
||||||
|
Store `plan.json` and `infracost.json` as artifacts for auditability. Treat cost checks like policy checks for high-risk environments.
|
||||||
|
|
||||||
|
## Pipeline Hardening Checklist
|
||||||
|
|
||||||
|
- Enforce branch protection on default branch
|
||||||
|
- Require CODEOWNERS review for prod-impacting paths
|
||||||
|
- Restrict apply jobs to protected runners
|
||||||
|
- Set artifact retention + access policies
|
||||||
|
- Preserve audit trail (approver, actor, commit, runtime version)
|
||||||
|
|
||||||
|
## Cost and Speed Controls
|
||||||
|
|
||||||
|
- Run expensive integration suites only for IaC path changes
|
||||||
|
- Serialize shared-foundation applies
|
||||||
|
- Use provider plugin cache where supported
|
||||||
|
- Schedule cleanup for ephemeral test environments
|
||||||
117
skills/terrashark/docs/guides/migration-playbooks.md
Normal file
117
skills/terrashark/docs/guides/migration-playbooks.md
Normal file
|
|
@ -0,0 +1,117 @@
|
||||||
|
# Terraform Migration Playbooks
|
||||||
|
|
||||||
|
Five dedicated playbooks for safely migrating Terraform resources without causing identity churn, data loss, or downtime.
|
||||||
|
|
||||||
|
## Playbook 1: `count` to `for_each` Migration
|
||||||
|
|
||||||
|
**Goal:** Keep object identity stable during refactor.
|
||||||
|
|
||||||
|
### Steps
|
||||||
|
|
||||||
|
1. Define stable keys (not list indexes)
|
||||||
|
2. Add `for_each` implementation
|
||||||
|
3. Add `moved` mappings from old index addresses to new keyed addresses
|
||||||
|
4. Run plan and confirm move operations (not destroy/create)
|
||||||
|
5. Apply in low-risk environment first
|
||||||
|
|
||||||
|
### Example Mapping
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
moved {
|
||||||
|
from = aws_subnet.app[0]
|
||||||
|
to = aws_subnet.app["a"]
|
||||||
|
}
|
||||||
|
|
||||||
|
moved {
|
||||||
|
from = aws_subnet.app[1]
|
||||||
|
to = aws_subnet.app["b"]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Playbook 2: Resource/Module Rename
|
||||||
|
|
||||||
|
Use `moved` for address renames before any apply.
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
moved {
|
||||||
|
from = module.edge_cache
|
||||||
|
to = module.cdn_edge
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Playbook 3: Import-First Adoption
|
||||||
|
|
||||||
|
When taking over manually created resources:
|
||||||
|
|
||||||
|
1. Confirm remote object exactly matches intended config shape
|
||||||
|
2. Import into correct address
|
||||||
|
3. Run plan and ensure no surprise replacements
|
||||||
|
|
||||||
|
### Declarative `import` Block (TF 1.5+ / OpenTofu 1.5+)
|
||||||
|
|
||||||
|
Prefer declarative `import` blocks over CLI `terraform import`:
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
import {
|
||||||
|
to = aws_s3_bucket.logs
|
||||||
|
id = "my-existing-bucket-name"
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "aws_s3_bucket" "logs" {
|
||||||
|
bucket = "my-existing-bucket-name"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Bulk Import with `for_each`
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
locals {
|
||||||
|
existing_buckets = {
|
||||||
|
logs = "prod-logs-bucket"
|
||||||
|
archive = "prod-archive-bucket"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
import {
|
||||||
|
for_each = local.existing_buckets
|
||||||
|
to = aws_s3_bucket.managed[each.key]
|
||||||
|
id = each.value
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "aws_s3_bucket" "managed" {
|
||||||
|
for_each = local.existing_buckets
|
||||||
|
bucket = each.value
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Post-Import Checklist
|
||||||
|
|
||||||
|
- Run `terraform plan` and verify zero changes (no-diff)
|
||||||
|
- If plan shows changes, align config with actual state before applying
|
||||||
|
- Remove `import` blocks after successful apply (they are one-time directives)
|
||||||
|
|
||||||
|
## Playbook 4: Secrets Remediation
|
||||||
|
|
||||||
|
If secrets are currently in state:
|
||||||
|
|
||||||
|
1. Create new secret path in managed secret store
|
||||||
|
2. Switch resources to reference external secret material
|
||||||
|
3. Rotate credentials after cutover
|
||||||
|
4. Remove old secret-generating Terraform resources where possible
|
||||||
|
|
||||||
|
## Playbook 5: Runtime/Provider Upgrade Flow
|
||||||
|
|
||||||
|
1. Bump constraints intentionally
|
||||||
|
2. Regenerate lockfile
|
||||||
|
3. Run full test tier for target risk
|
||||||
|
4. Inspect deprecations and behavior shifts
|
||||||
|
5. Ship upgrade independently from functional changes when possible
|
||||||
|
|
||||||
|
## Migration Red Flags
|
||||||
|
|
||||||
|
Watch for these warning signs during any migration:
|
||||||
|
|
||||||
|
- Plan shows broad replace for unrelated resources
|
||||||
|
- Key changes derived from unstable list order
|
||||||
|
- Unknown ownership of imported resources
|
||||||
|
- No rollback narrative for production apply
|
||||||
150
skills/terrashark/docs/guides/quick-ops.md
Normal file
150
skills/terrashark/docs/guides/quick-ops.md
Normal file
|
|
@ -0,0 +1,150 @@
|
||||||
|
# Terraform Quick Ops and Troubleshooting
|
||||||
|
|
||||||
|
Fast command recall and common failure handling for Terraform and OpenTofu operations.
|
||||||
|
|
||||||
|
## Core Command Sequence
|
||||||
|
|
||||||
|
### Terraform
|
||||||
|
|
||||||
|
```bash
|
||||||
|
terraform fmt -check
|
||||||
|
terraform init
|
||||||
|
terraform validate
|
||||||
|
terraform plan -out=plan.bin
|
||||||
|
terraform show -json plan.bin > plan.json
|
||||||
|
```
|
||||||
|
|
||||||
|
### OpenTofu
|
||||||
|
|
||||||
|
```bash
|
||||||
|
tofu fmt -check
|
||||||
|
tofu init
|
||||||
|
tofu validate
|
||||||
|
tofu plan -out=plan.bin
|
||||||
|
tofu show -json plan.bin > plan.json
|
||||||
|
```
|
||||||
|
|
||||||
|
## Common Failures and Fixes
|
||||||
|
|
||||||
|
### CI Passes Locally but Fails in Runner
|
||||||
|
|
||||||
|
**Causes:**
|
||||||
|
- Mismatch in runtime/provider versions
|
||||||
|
- Missing lockfile updates
|
||||||
|
- Environment variables present locally but missing in CI
|
||||||
|
|
||||||
|
**Fix:**
|
||||||
|
- Pin runtime and providers
|
||||||
|
- Commit lockfile
|
||||||
|
- Make required env vars explicit in pipeline
|
||||||
|
|
||||||
|
### Large Unexpected Replacements in Plan
|
||||||
|
|
||||||
|
**Causes:**
|
||||||
|
- Unstable iteration keys
|
||||||
|
- Hidden rename without `moved` mapping
|
||||||
|
- Data source drift feeding identity fields
|
||||||
|
|
||||||
|
**Fix:**
|
||||||
|
- Stabilize keys
|
||||||
|
- Add `moved` blocks
|
||||||
|
- Separate identity from mutable attributes
|
||||||
|
|
||||||
|
### AWS RDS Identifier Validation Errors
|
||||||
|
|
||||||
|
**Symptoms:** `InvalidParameterValue` for `identifier` or `final_snapshot_identifier`, names include dots.
|
||||||
|
|
||||||
|
**Fix:** Normalize to lowercase letters, numbers, and hyphens:
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
locals {
|
||||||
|
rds_base = regexreplace(lower("${var.project}-prod"), "[^a-z0-9-]", "-")
|
||||||
|
}
|
||||||
|
|
||||||
|
resource "aws_db_instance" "main" {
|
||||||
|
identifier = local.rds_base
|
||||||
|
final_snapshot_identifier = "${local.rds_base}-final"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Apply Contention on Shared State
|
||||||
|
|
||||||
|
**Cause:** Concurrent pipelines targeting same backend key.
|
||||||
|
|
||||||
|
**Fix:**
|
||||||
|
- Serialize applies for that stack
|
||||||
|
- Use lock timeout and per-stack concurrency guard
|
||||||
|
|
||||||
|
### Tests Are Too Costly
|
||||||
|
|
||||||
|
**Fix:**
|
||||||
|
- Tag tests by risk (`fast`, `integration`, `destructive`)
|
||||||
|
- Run full suite nightly, risk-tier suite on PRs
|
||||||
|
- Auto-clean ephemeral infra with TTL tags
|
||||||
|
|
||||||
|
### State Lock Stuck
|
||||||
|
|
||||||
|
**Symptom:** `Error: Error acquiring the state lock`
|
||||||
|
|
||||||
|
**Fix:**
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Identify the lock holder from the error message (lock ID shown)
|
||||||
|
terraform force-unlock LOCK_ID
|
||||||
|
# OpenTofu equivalent:
|
||||||
|
tofu force-unlock LOCK_ID
|
||||||
|
```
|
||||||
|
|
||||||
|
Only force-unlock when you are certain no other apply is running. Check CI pipelines and team activity first.
|
||||||
|
|
||||||
|
### State Corruption or Lost State
|
||||||
|
|
||||||
|
**Fix:**
|
||||||
|
- Restore from versioned state backend (S3 versioning, GCS versioning)
|
||||||
|
- If no backup: re-import resources using `import` blocks
|
||||||
|
- Never manually edit state JSON unless absolutely no alternative and with peer review
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Pull current state for inspection
|
||||||
|
terraform state pull > state-backup.json
|
||||||
|
# List all tracked resources
|
||||||
|
terraform state list
|
||||||
|
```
|
||||||
|
|
||||||
|
### Backend Migration
|
||||||
|
|
||||||
|
When changing state backends (e.g., local to S3, or S3 to different bucket):
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Update backend config in code, then:
|
||||||
|
terraform init -migrate-state
|
||||||
|
```
|
||||||
|
|
||||||
|
- Always backup state before migration
|
||||||
|
- Verify resource count matches after migration
|
||||||
|
- Test plan shows no changes after migration
|
||||||
|
|
||||||
|
### Provider Authentication Failures in CI
|
||||||
|
|
||||||
|
**Symptom:** `Error: No valid credential sources found`
|
||||||
|
|
||||||
|
**Fix:**
|
||||||
|
- Verify environment variables are set in CI runner
|
||||||
|
- Prefer workload identity federation over static keys
|
||||||
|
- Check credential expiry for short-lived tokens
|
||||||
|
- Ensure CI runner IAM role/service account has required permissions
|
||||||
|
|
||||||
|
### `null_resource` vs `terraform_data`
|
||||||
|
|
||||||
|
Use `terraform_data` (TF 1.4+) instead of `null_resource` + `null` provider:
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
# Prefer this (no extra provider needed):
|
||||||
|
resource "terraform_data" "bootstrap" {
|
||||||
|
triggers_replace = [var.config_hash]
|
||||||
|
|
||||||
|
provisioner "local-exec" {
|
||||||
|
command = "bootstrap.sh"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
64
skills/terrashark/docs/guides/security-governance.md
Normal file
64
skills/terrashark/docs/guides/security-governance.md
Normal file
|
|
@ -0,0 +1,64 @@
|
||||||
|
# Terraform Security and Governance
|
||||||
|
|
||||||
|
This guide covers security controls for Terraform and OpenTofu delivery pipelines. For framework-specific compliance mappings and evidence gates, see [Compliance Gates](../failure-modes/compliance-gates.md).
|
||||||
|
|
||||||
|
## Identity Controls
|
||||||
|
|
||||||
|
- Least privilege for CI identities
|
||||||
|
- Separate `plan` and `apply` roles where possible
|
||||||
|
- Short-lived credentials via workload identity federation
|
||||||
|
- Deny direct human write access to production backends
|
||||||
|
|
||||||
|
## Secret Controls
|
||||||
|
|
||||||
|
- Prohibit plaintext secret defaults in code
|
||||||
|
- Source sensitive values from managed secret stores
|
||||||
|
- Mark secret variables and outputs as sensitive
|
||||||
|
- Sanitize logs/artifacts and restrict access
|
||||||
|
|
||||||
|
## Supply-Chain Controls
|
||||||
|
|
||||||
|
- Pin provider/module versions with bounded constraints
|
||||||
|
- Commit lockfile and review lockfile diffs
|
||||||
|
- Verify action/container versions in CI workflows
|
||||||
|
|
||||||
|
## Policy Layers
|
||||||
|
|
||||||
|
Use layered controls, not single-tool reliance:
|
||||||
|
|
||||||
|
| Layer | Tool/Approach | Purpose |
|
||||||
|
|---|---|---|
|
||||||
|
| **Static scanning** | `tfsec`, `checkov`, equivalent | Catch common misconfigurations early |
|
||||||
|
| **Plan-policy checks** | Sentinel, OPA, Conftest | Enforce organizational policies on plan output |
|
||||||
|
| **Approval gates** | By risk class | Human oversight for high-impact changes |
|
||||||
|
|
||||||
|
## High-Impact Change Controls
|
||||||
|
|
||||||
|
Require elevated approval for:
|
||||||
|
|
||||||
|
- IAM privilege expansion
|
||||||
|
- Network exposure/public ingress changes
|
||||||
|
- Encryption disablement/key-policy weakening
|
||||||
|
- Backend/state changes
|
||||||
|
- Production replacement/destruction actions
|
||||||
|
|
||||||
|
## Minimal OPA Example
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
package main
|
||||||
|
|
||||||
|
deny[msg] {
|
||||||
|
r := input.resource_changes[_]
|
||||||
|
r.type == "aws_security_group_rule"
|
||||||
|
r.change.after.cidr_blocks[_] == "0.0.0.0/0"
|
||||||
|
r.change.after.from_port == 22
|
||||||
|
msg := sprintf("Public SSH is not allowed: %s", [r.address])
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Operational Governance
|
||||||
|
|
||||||
|
- Serialize applies for shared foundations
|
||||||
|
- Require explicit opt-in for destroy
|
||||||
|
- Keep break-glass runbook and test it periodically
|
||||||
|
- Retain run metadata and policy outputs for auditability
|
||||||
152
skills/terrashark/docs/guides/testing.md
Normal file
152
skills/terrashark/docs/guides/testing.md
Normal file
|
|
@ -0,0 +1,152 @@
|
||||||
|
# Terraform Testing Matrix
|
||||||
|
|
||||||
|
This guide covers choosing testing depth proportional to risk and cost for Terraform and OpenTofu modules.
|
||||||
|
|
||||||
|
## Testing Layers
|
||||||
|
|
||||||
|
1. **Static checks**: format, validate, lint, security scan
|
||||||
|
2. **Plan checks**: reviewed execution intent
|
||||||
|
3. **Native tests**: module-level assertions (`terraform test` / `tofu test`)
|
||||||
|
4. **Integration tests**: ephemeral apply + live assertions
|
||||||
|
5. **Terratest**: workflow/system validation in Go for complex scenarios
|
||||||
|
|
||||||
|
## Tier A: All Changes (Minimum)
|
||||||
|
|
||||||
|
Required for every change:
|
||||||
|
|
||||||
|
- `fmt -check`
|
||||||
|
- `init -backend=false` + `validate`
|
||||||
|
- Lint + security scan
|
||||||
|
- Reviewed plan artifact
|
||||||
|
|
||||||
|
Use for low-risk isolated updates.
|
||||||
|
|
||||||
|
## Tier B: Shared Modules and Medium-Risk Changes
|
||||||
|
|
||||||
|
Add on top of Tier A:
|
||||||
|
|
||||||
|
- Native test runs for module behavior
|
||||||
|
- Targeted integration apply tests in ephemeral environment
|
||||||
|
- Policy checks on plan JSON
|
||||||
|
|
||||||
|
**Typical triggers:**
|
||||||
|
- Shared module changes
|
||||||
|
- IAM/network updates
|
||||||
|
- Encryption/data-boundary updates
|
||||||
|
|
||||||
|
## Tier C: High-Risk Production Changes
|
||||||
|
|
||||||
|
Add on top of Tier A + B:
|
||||||
|
|
||||||
|
- Staged rollout (dev -> stage -> prod)
|
||||||
|
- Rollback rehearsal or documented rollback proof
|
||||||
|
- Manual owner approvals + security/compliance sign-off
|
||||||
|
- Post-apply drift detection
|
||||||
|
|
||||||
|
**Typical triggers:**
|
||||||
|
- State backend migration
|
||||||
|
- Major refactor with address changes
|
||||||
|
- Foundational platform stack changes
|
||||||
|
|
||||||
|
## Native Test Guidance
|
||||||
|
|
||||||
|
### When to Use `command = plan`
|
||||||
|
|
||||||
|
- Input validation
|
||||||
|
- Static contract checks
|
||||||
|
- Argument shape assertions not relying on computed runtime values
|
||||||
|
|
||||||
|
### When to Use `command = apply`
|
||||||
|
|
||||||
|
- Computed attributes known only after creation
|
||||||
|
- Assertions over provider-populated fields
|
||||||
|
- Set/list semantics unresolved in plan stage
|
||||||
|
|
||||||
|
### Frequent Pitfalls
|
||||||
|
|
||||||
|
- Asserting unknown values in plan mode
|
||||||
|
- Indexing set-type blocks directly
|
||||||
|
- Assuming mocked providers equal integration confidence
|
||||||
|
|
||||||
|
## Terratest Guidance
|
||||||
|
|
||||||
|
Use Terratest when native tests are insufficient:
|
||||||
|
|
||||||
|
- Cross-module workflows
|
||||||
|
- External API verification (health checks, connectivity)
|
||||||
|
- Failover/disaster-recovery scenarios
|
||||||
|
- Multi-step lifecycle tests (apply-change-destroy)
|
||||||
|
|
||||||
|
### Terratest Test Pyramid
|
||||||
|
|
||||||
|
- **Fast**: contract tests (mocked or plan-level)
|
||||||
|
- **Medium**: environment integration tests (ephemeral)
|
||||||
|
- **Slow**: limited end-to-end smoke tests for critical paths
|
||||||
|
|
||||||
|
### Cost Controls
|
||||||
|
|
||||||
|
- Tag tests by class (`unit`, `integration`, `destructive`)
|
||||||
|
- Parallelize only isolated stacks
|
||||||
|
- Auto-clean resources with TTL tags
|
||||||
|
- Run expensive tests nightly and on protected branches
|
||||||
|
|
||||||
|
## Test Framework Scaffolding
|
||||||
|
|
||||||
|
```
|
||||||
|
.
|
||||||
|
test/
|
||||||
|
terratest/
|
||||||
|
go.mod
|
||||||
|
helpers/
|
||||||
|
examples/
|
||||||
|
network_test.go
|
||||||
|
native/
|
||||||
|
main.tftest.hcl
|
||||||
|
Makefile
|
||||||
|
```
|
||||||
|
|
||||||
|
Minimal Makefile targets:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
test-native:
|
||||||
|
terraform test
|
||||||
|
|
||||||
|
test-terratest:
|
||||||
|
go test ./test/terratest -timeout 45m
|
||||||
|
```
|
||||||
|
|
||||||
|
## Example Command Flow
|
||||||
|
|
||||||
|
```bash
|
||||||
|
terraform fmt -check
|
||||||
|
terraform init -backend=false
|
||||||
|
terraform validate
|
||||||
|
terraform plan -out=plan.bin
|
||||||
|
terraform show -json plan.bin > plan.json
|
||||||
|
conftest test plan.json --policy policy/
|
||||||
|
terraform test
|
||||||
|
```
|
||||||
|
|
||||||
|
Terratest stage:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
go test ./test -run TestCriticalPath -timeout 45m
|
||||||
|
```
|
||||||
|
|
||||||
|
## Quick Selection Rules
|
||||||
|
|
||||||
|
| Change Type | Testing Tier |
|
||||||
|
|---|---|
|
||||||
|
| Tiny tag change in isolated stack | Tier A |
|
||||||
|
| Module contract change | Tier A + Tier B |
|
||||||
|
| Refactor with `moved` and shared impact | Tier A + B + targeted Terratest |
|
||||||
|
| Production identity/network/encryption/state changes | Tier A + B + C + Terratest smoke |
|
||||||
|
|
||||||
|
## Done Criteria
|
||||||
|
|
||||||
|
Not done until:
|
||||||
|
|
||||||
|
- Required tier passes
|
||||||
|
- Reviewed plan is approved
|
||||||
|
- Apply path is trusted and auditable
|
||||||
|
- Evidence artifacts are retained
|
||||||
40
skills/terrashark/docs/integrations/mcp-integration.md
Normal file
40
skills/terrashark/docs/integrations/mcp-integration.md
Normal file
|
|
@ -0,0 +1,40 @@
|
||||||
|
# MCP Integration with the Terraform Skill
|
||||||
|
|
||||||
|
This guide covers how to safely use MCP (Model Context Protocol) servers to supply trusted context during Terraform and OpenTofu work.
|
||||||
|
|
||||||
|
## When to Use MCP
|
||||||
|
|
||||||
|
- Fetch authoritative provider or platform facts for the current environment
|
||||||
|
- Read organization-specific standards, naming rules, or guardrails
|
||||||
|
- Pull inventory or baseline state summaries when local context is missing
|
||||||
|
|
||||||
|
## What MCP Should Not Do
|
||||||
|
|
||||||
|
- Do not retrieve or transmit plaintext secrets
|
||||||
|
- Do not treat MCP responses as change authorization
|
||||||
|
- Do not use MCP to bypass review or approval controls
|
||||||
|
|
||||||
|
## Safe Integration Pattern
|
||||||
|
|
||||||
|
1. **Query** MCP for environment facts and constraints
|
||||||
|
2. **Compare** with local inputs and repo defaults
|
||||||
|
3. **Emit assumptions** explicitly if MCP data is partial
|
||||||
|
4. **Preserve** least-privilege access and log sources used
|
||||||
|
|
||||||
|
## Output Hygiene
|
||||||
|
|
||||||
|
- Quote MCP-derived values as inputs, not hard-coded defaults
|
||||||
|
- Keep environment-specific data out of reusable primitives
|
||||||
|
- Record MCP-provided versions or IDs in notes for traceability
|
||||||
|
|
||||||
|
## Example Uses
|
||||||
|
|
||||||
|
- Resolve account or project IDs for the target environment
|
||||||
|
- Confirm region allow-lists and data residency boundaries
|
||||||
|
- Retrieve approved module registry versions or constraints
|
||||||
|
|
||||||
|
## Failure Handling
|
||||||
|
|
||||||
|
- If MCP is unavailable, proceed with explicit assumptions
|
||||||
|
- Avoid speculative values for IDs, names, or policy constraints
|
||||||
|
- Request confirmation before emitting high-impact changes
|
||||||
2744
skills/terrashark/docs/package-lock.json
generated
Normal file
2744
skills/terrashark/docs/package-lock.json
generated
Normal file
File diff suppressed because it is too large
Load diff
14
skills/terrashark/docs/package.json
Normal file
14
skills/terrashark/docs/package.json
Normal file
|
|
@ -0,0 +1,14 @@
|
||||||
|
{
|
||||||
|
"name": "terrashark-docs",
|
||||||
|
"version": "2.3.0",
|
||||||
|
"description": "TerraShark documentation - Terraform Skill for Claude Code",
|
||||||
|
"private": true,
|
||||||
|
"scripts": {
|
||||||
|
"build": "honkit build",
|
||||||
|
"serve": "honkit serve"
|
||||||
|
},
|
||||||
|
"devDependencies": {
|
||||||
|
"honkit": "^6.1.7",
|
||||||
|
"gitbook-plugin-search-pro": "^2.0.2"
|
||||||
|
}
|
||||||
|
}
|
||||||
77
skills/terrashark/references/blast-radius.md
Normal file
77
skills/terrashark/references/blast-radius.md
Normal file
|
|
@ -0,0 +1,77 @@
|
||||||
|
# Blast Radius
|
||||||
|
|
||||||
|
Use this guide to limit impact scope for changes, failures, and rollbacks.
|
||||||
|
|
||||||
|
## Symptoms
|
||||||
|
|
||||||
|
- tiny change triggers very large plan
|
||||||
|
- unrelated services share one state and fail together
|
||||||
|
- production and non-production are entangled
|
||||||
|
- review/approval ownership is unclear
|
||||||
|
|
||||||
|
## Boundary model
|
||||||
|
|
||||||
|
Split along:
|
||||||
|
- ownership boundaries
|
||||||
|
- change cadence boundaries
|
||||||
|
- recovery boundaries
|
||||||
|
|
||||||
|
If these differ, split stack/state.
|
||||||
|
|
||||||
|
## Architecture patterns
|
||||||
|
|
||||||
|
- platform foundation stack (network, identity, shared controls)
|
||||||
|
- service stack(s) per business workload
|
||||||
|
- bootstrap stack for backend/state prerequisites
|
||||||
|
|
||||||
|
Do not combine all of them in one root.
|
||||||
|
|
||||||
|
## State isolation rules
|
||||||
|
|
||||||
|
- one backend key per isolated stack/environment
|
||||||
|
- dedicated lock scope per stack
|
||||||
|
- backup/versioning required for production states
|
||||||
|
- no shared prod/non-prod state files
|
||||||
|
|
||||||
|
## Environment separation options
|
||||||
|
|
||||||
|
1. separate directories + separate backend keys
|
||||||
|
2. workspace per environment (only with strict governance)
|
||||||
|
3. separate repositories for hard regulatory segregation
|
||||||
|
|
||||||
|
## Apply governance
|
||||||
|
|
||||||
|
- serialize applies to shared foundations
|
||||||
|
- require explicit approval for production and destructive plans
|
||||||
|
- block auto-apply for high-impact stacks
|
||||||
|
|
||||||
|
## Example structure
|
||||||
|
|
||||||
|
```text
|
||||||
|
infra/
|
||||||
|
bootstrap/
|
||||||
|
platform/
|
||||||
|
dev/
|
||||||
|
prod/
|
||||||
|
services/
|
||||||
|
billing/
|
||||||
|
dev/
|
||||||
|
prod/
|
||||||
|
catalog/
|
||||||
|
dev/
|
||||||
|
prod/
|
||||||
|
```
|
||||||
|
|
||||||
|
## LLM mistake checklist
|
||||||
|
|
||||||
|
Common model mistakes to correct:
|
||||||
|
- proposes one monolithic root for convenience
|
||||||
|
- recommends workspace-only isolation without access controls
|
||||||
|
- mixes blast radius discussion with purely stylistic concerns
|
||||||
|
- omits rollback path for shared foundation changes
|
||||||
|
|
||||||
|
## Verification checks
|
||||||
|
|
||||||
|
- does plan only touch intended stack?
|
||||||
|
- does state key scope match ownership boundary?
|
||||||
|
- is rollback path documented for this apply?
|
||||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue