poistettu turha instructions kansio
This commit is contained in:
parent
668d1e007f
commit
73f4901d07
@ -108,6 +108,9 @@ This main file references specialized instruction files. **Load relevant files b
|
||||
- [Documentation](instructions/skills/documentation.instructions.md) - Writing principles, workflow, scope rules
|
||||
- [Mermaid](instructions/skills/mermaid.instructions.md) - Diagram types, color contrast rules, sizing
|
||||
- [Analysis](instructions/skills/analysis.instructions.md) - Where to write analysis, tmp/ convention, full-pass writing allowed
|
||||
- [Grill Me](instructions/skills/grill-me.instructions.md) - Active workflow: relentlessly interview user about a design/plan. ONE question at a time. No code.
|
||||
- [Use Cases](instructions/skills/use-cases.instructions.md) - Active workflow: strictly formatted, concise business use cases to prevent bloat.
|
||||
- [Write Skill](instructions/skills/write-skill.instructions.md) - Meta-skill: interview user to create a new, high-quality AI instruction/skill file.
|
||||
|
||||
- [Helm](instructions/skills/helm.instructions.md) - Resource ownership, values hygiene, required vs defaults, dependency caching
|
||||
- [Clean Code](instructions/skills/clean-code.instructions.md) - Naming, functions, classes, error handling, formatting, DRY/KISS/SOLID, Helm YAML
|
||||
@ -130,6 +133,9 @@ User asks to edit files → instructions/skills/file-editing.instru
|
||||
User asks to write docs → instructions/skills/documentation.instructions.md
|
||||
User creates a Mermaid diagram → instructions/skills/mermaid.instructions.md
|
||||
User asks for analysis/comparison → instructions/skills/analysis.instructions.md
|
||||
User asks to "grill me" / test plan → instructions/skills/grill-me.instructions.md
|
||||
User asks for use cases or reqs → instructions/skills/use-cases.instructions.md
|
||||
User wants to create a new AI skill → instructions/skills/write-skill.instructions.md
|
||||
User asks about project → instructions/behavior/project-context.instructions.md → <docs>/ai-context.md
|
||||
User needs to debug cluster → instructions/constraints/agent-capabilities.instructions.md + instructions/constraints/kubernetes-access.instructions.md
|
||||
User reports pod issues → instructions/constraints/container-limitations.instructions.md
|
||||
|
||||
32
.ai/skills/grill-me.instructions.md
Normal file
32
.ai/skills/grill-me.instructions.md
Normal file
@ -0,0 +1,32 @@
|
||||
# Grill Me Instructions
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Purpose
|
||||
Use this skill when the user wants to **stress-test a design or plan** before implementation, or when they explicitly say something like "grill me".
|
||||
|
||||
This puts you into an **interrogation mode**, acting as an extremely strict and detail-oriented Staff Engineer/Architect.
|
||||
|
||||
## 🚦 Interview Rules — DO NOT BREAK
|
||||
|
||||
1. **ONE QUESTION AT A TIME:** You are strictly forbidden from asking more than ONE question per message. A wall of questions is overwhelming and useless. If there are 5 critical things to ask, pick the most important one first. Wait for the user's answer before asking the next.
|
||||
2. **NO CODE:** Do not write code or documentation. Your only job is to challenge the user's thinking.
|
||||
3. **EXPLORE FIRST:** If a question could be answered by exploring the existing codebase with `file_search`, `read_file`, or `grep_search`, do that *before* bothering the user.
|
||||
4. **NO SOFTENING:** Do not soften the blow. Be direct. E.g., instead of *"Have you considered how this scales?"*, ask *"This design fails if traffic spikes 10x. How exactly does component X handle backpressure?"*
|
||||
|
||||
## 🔍 Areas to Grill On
|
||||
|
||||
Challenge the plan on these specific axes:
|
||||
- **Resilience:** What happens if the database reconnect fails? What if the 3rd party API times out?
|
||||
- **State & Idempotency:** If this operation runs twice, does it corrupt data?
|
||||
- **Scalability:** Will this logic still work perfectly with 10 million rows in the database?
|
||||
- **Security:** Are secrets exposed? Can a user bypass validation?
|
||||
- **Complexity:** Is this over-engineered? Can it be done with half the code?
|
||||
|
||||
## 🛑 How to Exit Grill Mode
|
||||
|
||||
Continue asking one question at a time until **either of these happens**:
|
||||
1. You run out of critical flaws to point out (all decision branches are resolved).
|
||||
2. The user explicitly says "that's enough", "let's implement", or similar.
|
||||
|
||||
When exiting, summarize the final agreed-upon architecture/plan in bullet points and ask if you should proceed to implement it.
|
||||
35
.ai/skills/use-cases.instructions.md
Normal file
35
.ai/skills/use-cases.instructions.md
Normal file
@ -0,0 +1,35 @@
|
||||
# Use Cases Instructions
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Purpose
|
||||
Use this skill when you are asked to generate or analyze **business use cases** or functional requirements.
|
||||
|
||||
This skill is designed to prevent **Use Case Bloat** — the tendency for LLMs to generate 1500-line monolithic documents filled with marginal, unlikely edge cases.
|
||||
|
||||
## 🛑 Strict Format Rules
|
||||
|
||||
A single use case must NEVER exceed **one screen's worth of text**. The goal is immediate business understanding, not a novel.
|
||||
|
||||
**REQUIRED STRUCTURE:**
|
||||
1. **Name**: Clear action (e.g., "Customer resets password")
|
||||
2. **Actor**: Who triggers this? (e.g., "Registered User")
|
||||
3. **Precondition**: What must be true first? (e.g., "User is logged out but knows their email")
|
||||
4. **Main Success Scenario**:
|
||||
- The "Happy Path".
|
||||
- **MAXIMUM 3-5 short bullet points**. Keep it extremely abstract and business-focused (e.g., "System sends email link", "User clicks link", "System updates password").
|
||||
5. **Exceptions (Edge Cases)**:
|
||||
- **MAXIMUM 2-3 most critical exceptions**.
|
||||
- Example: "Email not found -> System shows success message but sends no email to prevent enumeration."
|
||||
- Do NOT invent dozens of technical edge cases here (database down, internet disconnects). Focus only on *business* exceptions.
|
||||
|
||||
## 🚫 Avoid Hallucinations and Edge Case Bloat
|
||||
- **FORBIDDEN:** Do NOT list more than 3 exceptions unless the user *explicitly requests a deep-dive exception analysis*.
|
||||
- **FORBIDDEN:** Do NOT bloat the document with technical steps (e.g., "System opens TCP connection to DB", "System parses JSON payload"). Use cases describe *what* happens in the business, not *how* it happens technically.
|
||||
- If a system has multiple actors and flows, keep each use case distinct and short.
|
||||
|
||||
## 🤝 Workflow
|
||||
|
||||
1. Present an outline/list of the identified use cases (e.g., 5 bullet points with names only).
|
||||
2. Ask the user: "Would you like me to write out the full details for these 5 use cases using the strict 5-part format?"
|
||||
3. Only upon approval, generate the document holding to the strict format constraints above.
|
||||
116
.ai/skills/write-skill.instructions.md
Normal file
116
.ai/skills/write-skill.instructions.md
Normal file
@ -0,0 +1,116 @@
|
||||
---
|
||||
name: write-skill
|
||||
description: Create new agent skills with proper structure and AI superpower constraints. Use when user wants to create, write, or build a new skill, rule, or instruction.
|
||||
---
|
||||
|
||||
# Write Skill Instructions (Meta-Skill)
|
||||
|
||||
## Process
|
||||
|
||||
1. **Gather requirements** - ask user about:
|
||||
- What task/domain does the skill cover?
|
||||
- What is the fundamental problem or hallucination the AI currently makes?
|
||||
- What are the strict absolute rules ("Thou Shalt Not"s)?
|
||||
- Do you have concrete ✅ (good) and ❌ (bad) examples?
|
||||
|
||||
2. **Draft the skill** - create:
|
||||
- `SKILL.md` with concise instructions
|
||||
- Additional reference files (`REFERENCE.md`) if content exceeds 100 lines
|
||||
- Usage examples (`EXAMPLES.md`) if needed
|
||||
|
||||
3. **Review with user** - present draft and ask:
|
||||
- Does this cover your use cases?
|
||||
- Anything missing or unclear?
|
||||
- Should any section be more/less detailed?
|
||||
|
||||
## Skill Structure
|
||||
|
||||
```
|
||||
.ai/skills/skill-name/
|
||||
├── SKILL.md # Main instructions (required)
|
||||
├── REFERENCE.md # Detailed docs (if needed)
|
||||
└── EXAMPLES.md # Usage examples (if needed)
|
||||
```
|
||||
|
||||
## SKILL.md Template
|
||||
|
||||
```md
|
||||
---
|
||||
name: skill-name
|
||||
description: Brief description of capability. Use when [specific triggers].
|
||||
---
|
||||
|
||||
# Skill Name
|
||||
|
||||
## 🎯 Purpose (Quick start)
|
||||
|
||||
[Minimal working example or brief introduction]
|
||||
|
||||
## 🚨 Prohibitions
|
||||
|
||||
[What is strictly forbidden?]
|
||||
|
||||
## Workflows
|
||||
|
||||
[Step-by-step processes with checklists for complex tasks]
|
||||
|
||||
## ✅ / ❌ Examples
|
||||
|
||||
[Concrete examples of right and wrong behavior]
|
||||
```
|
||||
|
||||
## Description Requirements
|
||||
|
||||
The description is **the only thing your agent sees** when deciding which skill to load. It's surfaced in the system prompt alongside all other installed skills. Your agent reads these descriptions and picks the relevant skill based on the user's request.
|
||||
|
||||
**Goal**: Give your agent just enough info to know:
|
||||
|
||||
1. What capability this skill provides
|
||||
2. When/why to trigger it (specific keywords, contexts, file types)
|
||||
|
||||
**Format**:
|
||||
|
||||
- Max 1024 chars
|
||||
- Write in third person
|
||||
- First sentence: what it does
|
||||
- Second sentence: "Use when [specific triggers]"
|
||||
|
||||
**Good example**:
|
||||
|
||||
```
|
||||
Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when user mentions PDFs, forms, or document extraction.
|
||||
```
|
||||
|
||||
**Bad example**:
|
||||
|
||||
```
|
||||
Helps with documents.
|
||||
```
|
||||
|
||||
The bad example gives your agent no way to distinguish this from other document skills.
|
||||
|
||||
## When to Split Files
|
||||
|
||||
Split into separate files when:
|
||||
|
||||
- SKILL.md exceeds 100 lines
|
||||
- Content has distinct domains (finance vs sales schemas)
|
||||
- Advanced features are rarely needed
|
||||
|
||||
## Integration (Mandatory Final Step)
|
||||
|
||||
Once the user approves the draft, you MUST perform BOTH of these actions:
|
||||
1. Use `create_directory` and `create_file` to save the new instruction into the agreed `.ai/skills/[skill-name]/SKILL.md` location.
|
||||
2. Use `replace_string_in_file` to update `.ai/ai-root-instructions.md`. Add a new trigger line to the routing section so the new skill is discoverable.
|
||||
|
||||
## Review Checklist
|
||||
|
||||
After drafting, verify:
|
||||
|
||||
- [ ] Description includes triggers ("Use when...")
|
||||
- [ ] Contains YAML frontmatter exactly as specified
|
||||
- [ ] SKILL.md under 100 lines
|
||||
- [ ] References one level deep
|
||||
- [ ] No time-sensitive info
|
||||
- [ ] Consistent terminology
|
||||
- [ ] Concrete ✅ / ❌ examples included
|
||||
Loading…
Reference in New Issue
Block a user