@jhm1909/ag-kit 0.1.0

package/.agent/rules/git-workflow.md

@@ -0,0 +1,68 @@
+---
+trigger: model_decision
+description: Always apply when using git for commits, branches, or version control
+---
+
+# Git Workflow Rule
+
+## Critical Rules (MUST Follow)
+
+1. **MUST** use **Conventional Commits** format for all commit messages: `type(scope): description`
+2. **MUST** review `git diff --stat` before staging — never commit blindly
+3. **MUST** ask user before staging protected files (`.env`, lock files, CI configs)
+4. **MUST** suggest creating a feature branch when on `main` with > 5 file changes
+5. **MUST NOT** use `--no-verify` unless there is a tooling failure (OOM, SIGKILL) — never to bypass real lint/test errors
+6. **MUST NOT** commit `.env` files, secrets, or API keys — check `.gitignore` first
+
+## Commit Type Reference
+
+| Type | Use For | Example |
+|------|---------|---------|
+| `feat` | New feature | `feat(auth): add OAuth2 login flow` |
+| `fix` | Bug fix | `fix(api): handle null response in user endpoint` |
+| `refactor` | Code restructuring (no behavior change) | `refactor(utils): extract validation helpers` |
+| `docs` | Documentation only | `docs: add API reference to README` |
+| `chore` | Maintenance, deps, config | `chore: upgrade React to v19` |
+| `test` | Adding/fixing tests | `test(auth): add token expiry edge cases` |
+| `style` | Formatting, whitespace (no logic) | `style: fix indentation in config files` |
+| `ci` | CI/CD pipeline changes | `ci: add deploy workflow for staging` |
+| `perf` | Performance improvement | `perf(db): add index on user_email column` |
+
+## Decision Flow
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│ BEFORE any git commit:                                       │
+├─────────────────────────────────────────────────────────────┤
+│ 1. Check current branch                                      │
+│    On main + many changes? → Suggest feature branch          │
+├─────────────────────────────────────────────────────────────┤
+│ 2. Review changes (git status + git diff --stat)             │
+│    Protected files changed? → List and ask confirmation      │
+├─────────────────────────────────────────────────────────────┤
+│ 3. Stage files                                               │
+│    > 15 files? → Offer split by scope / selective staging    │
+├─────────────────────────────────────────────────────────────┤
+│ 4. Generate commit message                                   │
+│    → Conventional Commits format                             │
+│    → Present to user for approval                            │
+├─────────────────────────────────────────────────────────────┤
+│ 5. Commit and push                                           │
+│    Push rejected? → git pull --rebase, then retry            │
+└─────────────────────────────────────────────────────────────┘
+```
+
+## Scope Detection
+
+Auto-detect scope from file paths — use the **first meaningful directory**:
+
+| Path Pattern | Scope |
+|-------------|-------|
+| `apps/<name>/...` | `<name>` |
+| `packages/<name>/...` | `<name>` |
+| `src/components/...` | `components` |
+| `.agent/skills/...` | `skills` |
+| `cli/...` | `cli` |
+| Root files | omit scope |
+
+When files span multiple scopes, omit scope or use the dominant one.

package/.agent/rules/nano-banana.md

@@ -0,0 +1,46 @@
+---
+trigger: model_decision
+description: Apply this rule when generating images, icons, or visual assets using generate_image tool.
+---
+
+# Generate Image Usage Guide
+
+## 1. The Prompting Formula
+
+To maximize image quality, ALWAYS structure your prompt using this progression. Do not just send a raw description.
+
+**`[Core Subject]` + `[Visual Style]` + `[Lighting/Color]` + `[Technical/Quality specs]`**
+
+### Examples:
+
+- **Bad**: "A robot"
+- **Good**: "Cute round robot avatar, flat vector art style, soft indigo and white lighting, minimal UI icon, high resolution"
+
+- **Bad**: "Dashboard background"
+- **Good**: "Abstract geometric patterns, soft cyberpunk aesthetic, dark slate and neon blue dark mode, subtle texture, 4k wallpaper"
+
+## 2. Capability & Constraints
+
+- **Naming**: You **MUST** use `snake_case` with a maximum of **3 words**.
+  - ✅ `hero_robot_icon`
+  - ❌ `HeroRobotIcon` (CamelCase not allowed)
+  - ❌ `blue_hero_robot_floating_in_space` (Too long)
+- **Text Handling**: The tool cannot render legible text. **NEVER** ask for text inside the image (e.g., "A button that says Start"). Request the _button shape_ only.
+- **Composition**: It excels at single objects (Icons, Avatars) and abstract backgrounds. It struggles with complex multi-character scenes or precise UI layouts.
+
+## 3. High-Leverage Keywords
+
+Use these specific keywords to steer the model towards specific outcomes:
+
+| Goal            | Keywords to Inject                                                                                 |
+| :-------------- | :------------------------------------------------------------------------------------------------- |
+| **UI Icons**    | `vector icon`, `flat design`, `minimalist`, `app icon`, `white background`, `svg style`            |
+| **Game Assets** | `game sprite`, `isometric view`, `digital painting`, `character concept`, `unreal engine 5 render` |
+| **Backgrounds** | `abstract`, `bokeh`, `gradient`, `blur`, `texture`, `wallpaper`, `geometric`                       |
+| **Styling**     | `soft lighting`, `cinematic`, `volumetric light`, `rule of thirds`, `ultra detailed`               |
+
+## 4. Operational Best Practices
+
+1.  **One Concept per Request**: Don't try to generate a "Dashboard with a sidebar and a chart". Generate the "Sidebar background" and the "Chart graphic" separately.
+2.  **Color Accuracy**: Use descriptive color names ("Emerald Green", "Midnight Blue") rather than just Hex codes, as models understand names better visually.
+3.  **Iteration**: If the first specific result isn't perfect, generalize the prompt slightly (remove strict constraints) and try again.

package/.agent/rules/research.md

@@ -0,0 +1,35 @@
+---
+trigger: model_decision
+description: Always apply when doing research
+---
+
+# Deep Research & Insight Gathering Rule
+
+## Core Rules (MUST Follow)
+
+1. **PROACTIVE SEARCHING**: Before planning or implementation, MUST use `search_web` with at least 5-10 varied keyword groups to gather the latest trends, best practices, and innovative ideas.
+2. **MULTI-DIMENSIONAL KEYWORDS**: Keywords must cover multiple angles:
+   - **Current Trends**: e.g., "modern UI design trends 2026", "latest React performance patterns".
+   - **Competitive/Comparative Analysis**: e.g., "top-tier SaaS landing pages", "comparison of agentic AI frameworks".
+   - **Deep Technical Details**: e.g., "advanced CSS glassmorphism implementation", "Vercel edge function benchmarks".
+   - **Common Pitfalls**: e.g., "anti-patterns in multi-agent systems", "UI accessibility common mistakes".
+3. **INSIGHT SYNTHESIS**: Research findings MUST be documented in `docs/050-Research/Analysis-{Topic}.md` BEFORE moving to the execution phase.
+4. **NO GENERIC PLACEHOLDERS**: Use research results to identify actual color palettes, modern typography, and real-world examples instead of using safe/default values.
+5. **CONTINUOUS DISCOVERY**: If a technical hurdle is met during implementation, trigger a new research cycle instead of guessing.
+
+## Decision Flow
+
+1. Identify the core domains of the task (e.g., Fintech UX, Scalable Go Backend, WebGL Performance).
+2. Generate 10+ specific search queries.
+3. Execute `search_web` and consume in-depth content using `read_url_content` or `read_browser_page`.
+4. Extract "Wow Factors" and modern standards.
+5. Document insights in the Research folder.
+6. Apply these specific insights to the Roadmap, PRD, and Implementation.
+
+## Examples of Inactive vs. Proactive Behavior
+
+- **Inactive**: Using standard blue/white for a dashboard because it's "professional".
+- **Proactive**: Searching for "premium dark mode dashboard aesthetics 2026", finding "Deep Emerald & Gold" lacquer-inspired themes, and implementing a high-contrast premium UI.
+
+- **Inactive**: Writing shared utility functions for API calls.
+- **Proactive**: Searching for "TanStack Query v5 optimistic update patterns", finding a more robust signal-based approach, and implementing that instead.

package/.agent/rules/skill-loading.md

@@ -0,0 +1,100 @@
+---
+trigger: model_decision
+description: Always apply when loading, routing, or recommending skills from the agent kit
+---
+
+# Skill Loading Rule
+
+## Critical Rules (MUST Follow)
+
+1. **MUST** check `skills-manifest.json` before loading any skill — verify skill exists and read its triggers
+2. **MUST** follow the Knowledge Graph relationships in `SKILL.md` — load `extends` parents first, then the skill itself
+3. **MUST** respect `conflicts` — never load two conflicting skills simultaneously
+4. **MUST** load `requires` dependencies automatically (hard requirements)
+5. **MUST** suggest `suggests` skills to user (soft recommendations, don't auto-load)
+6. **MUST** consider `estimated_tokens` — avoid loading more skills than the context window allows
+7. **MUST NOT** load a skill's full content unless it's needed — use trigger matching first
+
+## Decision Flow
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│ WHEN user request comes in:                                  │
+├─────────────────────────────────────────────────────────────┤
+│ 1. Match request against skill triggers                      │
+│    → Check skills-manifest.json "triggers" arrays            │
+│    → Also check file patterns (e.g., app/_layout.tsx → mobile)│
+│    Found match? → Load that skill's SKILL.md                 │
+│    No match?   → Use project-manager as default router       │
+├─────────────────────────────────────────────────────────────┤
+│ 2. Check Knowledge Graph section of loaded skill             │
+│    Has "extends"?  → Load parent skill FIRST                 │
+│    Has "requires"? → Load required skills automatically      │
+│    Has "suggests"? → Mention to user: "Consider also..."     │
+│    Has "conflicts"?→ Check if conflicting skill is active    │
+├─────────────────────────────────────────────────────────────┤
+│ 3. Estimate token budget                                     │
+│    Sum estimated_tokens of all loaded skills                  │
+│    > 50% of context? → Warn user, suggest unloading          │
+│    > 80% of context? → STOP, ask user which to prioritize    │
+├─────────────────────────────────────────────────────────────┤
+│ 4. Load sub-skills on demand                                 │
+│    Don't preload all sub-skills                               │
+│    Load only when task requires specific sub-capability       │
+└─────────────────────────────────────────────────────────────┘
+```
+
+## Trigger Matching Priority
+
+| Priority | Match Type | Example |
+|----------|-----------|---------|
+| 1 (highest) | File pattern detected | `app/_layout.tsx` → `mobile-developer` |
+| 2 | Explicit keyword in request | "deploy to AWS" → `devops-engineer` |
+| 3 | Domain context | Working in `.sol` files → `blockchain-engineer` |
+| 4 | Suggested by active skill | `frontend-developer` suggests `designer` |
+
+## Token Budget Guidelines
+
+| Skill Load | Tokens | Context Usage |
+|-----------|--------|---------------|
+| 1 base skill | 3-10K | ✅ Light |
+| 1 base + 1 sub-skill | 10-20K | ✅ Normal |
+| 2 base + extends chain | 20-40K | ⚠️ Monitor |
+| 3+ skills loaded | 40K+ | 🚨 Review & trim |
+
+## Skill Chain Examples
+
+**React Next.js project:**
+```
+frontend-developer (3.5K)
+  └─ extends: none (base)
+  └─ load sub: react-nextjs/ (additional)
+  └─ suggests: designer, tailwind-setup
+Total: ~8K tokens
+```
+
+**Mobile Expo project:**
+```
+mobile-developer (8K)
+  └─ extends: frontend-developer (3.5K)
+  └─ load sub: building-ui/ (on demand)
+  └─ suggests: backend-developer, designer
+Total: ~12K tokens
+```
+
+## Progressive Disclosure (from Anthropic's skill-creator)
+
+Skills should follow a **3-level loading** strategy to minimize token usage:
+
+| Level | What | When |
+|-------|------|------|
+| **L1: Metadata** | `skills-manifest.json` entry (name, triggers, size) | Always loaded — routing decisions |
+| **L2: SKILL.md** | Main instruction file — **≤ 150 lines** | Loaded when skill is activated |
+| **L3: references/** | Deep docs, examples, sub-skills | Loaded on-demand when specific topic needed |
+
+**Key rules:**
+- SKILL.md **MUST** stay under 150 lines — force progressive disclosure
+- Description in manifest **MUST** be < 200 chars — for efficient discovery
+- Put detailed content in `references/` folder, link from SKILL.md
+- Never front-load everything — load deep context only when task requires it
+

package/.agent/rules/skill-suggestion.md

@@ -0,0 +1,47 @@
+# Skill Suggestion Rule
+
+## When to Apply
+Always active. AI should continuously monitor for skill gaps during conversations.
+
+## Rule: Auto-Suggest External Skills
+
+When the AI detects it's working in a **domain not covered by installed skills**, it should:
+
+### 1. Detect Skill Gap
+Trigger when:
+- User mentions a technology/service not in `skills-manifest.json`
+- AI is about to write code for an unfamiliar framework
+- User asks about best practices for a specific tool/platform
+- Task requires domain expertise beyond general coding
+
+### 2. Check Known Registries
+```
+Read .agent/known-registries.json
+→ Search for matching skill by name or description
+```
+
+### 3. Suggest (non-blocking)
+
+Format suggestion as a brief inline note — do NOT interrupt the workflow:
+
+```
+💡 Skill suggestion: `stripe-best-practices` is available from the official 
+   Stripe registry. Run `/install-skill stripe` to install it.
+   (Continuing without it for now...)
+```
+
+### 4. Important Constraints
+
+- **Never block** the user's current task to suggest a skill
+- **Suggest once** per domain per conversation — don't repeat
+- **Prefer context7** for simple docs lookups — only suggest skill install for comprehensive best-practices or methodology content
+- **Don't suggest** for domains the user is clearly experienced in
+- **Registry-only suggestions** — never suggest unverified community skills without user explicitly searching
+
+### 5. Suggestion Priority
+
+| Situation | Action |
+|-----------|--------|
+| Registry has matching skill | Suggest `/install-skill <name>` |
+| No registry match, but context7 has docs | Say "I can query context7 for `<lib>` docs" |
+| No match anywhere | Work with general knowledge, no suggestion |

package/.agent/rules/testing.md

@@ -0,0 +1,52 @@
+---
+trigger: model_decision
+description: Always apply when doing or writing testing
+---
+
+# Testing and Regression Rule
+
+## Critical Rules (MUST Follow)
+
+1. **MUST** run existing tests before starting any work to establish a baseline.
+2. **MUST** run tests after completing changes to ensure no regressions were introduced.
+3. **MUST** add new tests for any new features implemented.
+4. **MUST** add reproduction tests for any bug fixes to ensure the bug does not return.
+5. **MUST** report test results (pass/fail) in the task summary and walkthrough.
+6. **MUST NOT** proceed to finalize a task if tests are failing, unless explicitly instructed by the user after explaining the failure and its impact.
+
+## Decision Flow
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│ WHEN implementing a feature or fixing a bug:                │
+├─────────────────────────────────────────────────────────────┤
+│ 1. Run baseline tests.                                      │
+│    Are they passing?                                        │
+│    NO  → Notify user of existing failures before proceeding. │
+│    YES → Continue.                                          │
+├─────────────────────────────────────────────────────────────┤
+│ 2. Implement changes (Feature/Fix/Refactor).                │
+├─────────────────────────────────────────────────────────────┤
+│ 3. Add/Update tests for the new code.                       │
+├─────────────────────────────────────────────────────────────┤
+│ 4. Run ALL relevant tests.                                  │
+│    Are they passing?                                        │
+│    NO  → Analyze failures, fix code/tests, repeat step 4.   │
+│    YES → Continue.                                          │
+├─────────────────────────────────────────────────────────────┤
+│ 5. Document test results in Walkthrough/Task Summary.       │
+└─────────────────────────────────────────────────────────────┘
+```
+
+## Running Tests
+
+- Use `npm test` to run the test suite.
+- For specific tests, use `npm test -- <path_to_test_file>`.
+- If the project uses a different test runner (e.g., `pytest`, `jest`, `vitest`), adapt the command accordingly based on `package.json` or project documentation.
+
+## What to do on Failure
+
+1. **Analyze logs**: Look for the specific assertion failure or error message.
+2. **Determine Root Cause**: Is it a bug in the code, a bug in the test, or a change in requirements?
+3. **Fix and Re-run**: Apply the necessary fix and run the tests again.
+4. **Communicate**: If a failure is expected or cannot be fixed easily, notify the user with a detailed explanation.

package/.agent/rules/workflow-advisor.md

@@ -0,0 +1,108 @@
+---
+trigger: model_decision
+description: Always suggest relevant workflows when user starts a new task or seems unsure what to do next
+---
+
+# Workflow Advisor Rule
+
+## Critical Rules (MUST Follow)
+
+1. **MUST** suggest relevant workflows when user describes a new project or task
+2. **MUST** suggest the *next* workflow when a current workflow completes
+3. **MUST** present workflow chains for multi-phase projects, not individual commands
+4. **MUST NOT** overwhelm — suggest max 3 options at a time
+5. **MUST NOT** force workflows — suggestions are optional, user can always say "no"
+
+## When to Activate
+
+| User Signal | Action |
+|-------------|--------|
+| "I want to build..." / "tạo project mới" | Suggest full project chain |
+| "What should I do next?" / "làm gì tiếp" | Analyze context → suggest next step |
+| User finishes a workflow | Auto-suggest the logical next workflow |
+| User seems lost or asks vague question | Offer `/guide` |
+| User mentions specific phase (design, code, test) | Suggest matching workflow |
+
+## Workflow Chains (Pre-built Recipes)
+
+### 🆕 New Project (from scratch)
+```
+/brainstorm → /documentation → /break-tasks → /implement-feature → /commit
+```
+
+### 🔄 New Feature (existing project)
+```
+/break-tasks → /implement-feature → /gen-tests → /commit
+```
+
+### 🐛 Bug Fix
+```
+/development → /gen-tests → /commit
+```
+
+### 🎨 UI/UX Feature
+```
+/ui-ux-design → /break-tasks → /implement-feature → /commit
+```
+
+### 📚 Documentation Only
+```
+/documentation → /commit
+```
+
+### 🔍 Study External Kit
+```
+/absorb → /break-tasks → /implement-feature → /commit
+```
+
+### 🚀 MVP Sprint
+```
+Phase 0: /brainstorm → /documentation
+Phase 1: /break-tasks → /implement-feature → /commit
+Phase 2: /break-tasks → /implement-feature → /commit
+Phase N: (repeat until done)
+Final:   /qa → /commit
+```
+
+## Suggestion Format
+
+When suggesting, use this compact format:
+
+```
+💡 Suggested workflow:
+   /brainstorm → /documentation → /break-tasks → /implement-feature
+
+   Or pick a specific one:
+   1. /brainstorm — define requirements & roadmap
+   2. /break-tasks — break features into atomic tasks
+   3. /guide — help me choose
+```
+
+## Chain Transition Detection
+
+After each workflow completes, check what logically comes next:
+
+| Just Finished | Suggest Next |
+|--------------|-------------|
+| `/brainstorm` | `/documentation` (create specs from PRD) |
+| `/documentation` | `/break-tasks` (break specs into tasks) |
+| `/break-tasks` | `/implement-feature` (start coding) |
+| `/implement-feature` | `/gen-tests` or `/commit` |
+| `/gen-tests` | `/commit` |
+| `/ui-ux-design` | `/break-tasks` → `/implement-feature` |
+| `/qa` | `/commit` |
+| `/absorb` | `/break-tasks` (implement absorbed items) |
+| `/development` | `/commit` |
+
+## Context Detection
+
+Detect project stage from existing files:
+
+| Files Found | Stage | Suggestion |
+|------------|-------|-----------|
+| No `docs/` folder | 🆕 Brand new | Start with `/brainstorm` |
+| `docs/010-Planning/Roadmap.md` exists | Planning done | `/documentation` or `/break-tasks` |
+| `docs/020-Requirements/PRD-*.md` exists | Requirements ready | `/break-tasks` |
+| `docs/050-Tasks/Task-*.md` exists | Tasks defined | `/implement-feature` |
+| Source code exists but no docs | Legacy project | `/documentation` (Mode A: from codebase) |
+| Tests exist but failing | Bug phase | `/development` (debug mode) |

package/.agent/rules/workflow-skill-convention.md

@@ -0,0 +1,127 @@
+---
+trigger: model_decision
+description: Convention for how workflows must invoke skills — the multi-layer architecture
+---
+
+# Workflow ↔ Skill Convention
+
+## Multi-Layer Architecture
+
+```
+┌───────────────────────────────────────────────┐
+│                   USER                         │
+│         "I want to build a SaaS app"          │
+├───────────────────────────────────────────────┤
+│              LAYER 1: Guide                    │
+│   /guide detects intent → recommends chain    │
+├───────────────────────────────────────────────┤
+│           LAYER 2: Workflow Chain              │
+│   /brainstorm → /documentation → /break-tasks │
+├───────────────────────────────────────────────┤
+│            LAYER 3: Skills                     │
+│   Each step invokes expert skills:            │
+│   [project-manager] → [lead-architect] →      │
+│   [business-analysis] → [frontend-developer]  │
+├───────────────────────────────────────────────┤
+│          LAYER 4: Manifest                    │
+│   skills-manifest.json routes dependencies:   │
+│   extends, requires, suggests, conflicts      │
+├───────────────────────────────────────────────┤
+│            LAYER 5: Rules                      │
+│   Always-on guardrails: clean-code, testing,  │
+│   git-workflow, skill-loading, research       │
+└───────────────────────────────────────────────┘
+```
+
+## Critical Rules (MUST Follow)
+
+1. **MUST** invoke at least one skill per major workflow step
+2. **MUST** use the format: `**Invoke \`[skill-name]\` skill** to <action>`
+3. **MUST** invoke the most relevant skill — not just any skill
+4. **MUST NOT** create workflows that are just shell commands without skill context
+5. **MUST NOT** invoke skills for trivial operations (file copy, git status)
+
+## Skill Selection Guide
+
+| Workflow Step Doing... | Invoke This Skill |
+|----------------------|-------------------|
+| Analyzing requirements | `[business-analysis]` |
+| Planning roadmap / PRD | `[project-manager]` |
+| Architecture decisions | `[lead-architect]` |
+| Breaking into tasks | `[lead-architect]` + `[business-analysis]` |
+| UI/UX design | `[designer]` |
+| Frontend code | `[frontend-developer]` |
+| Backend/API code | `[backend-developer]` |
+| Mobile code | `[mobile-developer]` |
+| Testing | `[qa-tester]` |
+| Research | `[research rule]` (not a skill, but activates deep research) |
+| DevOps / deploy | `[devops-engineer]` |
+| Security review | `[blockchain-engineer]` or domain-specific |
+| AI/LLM integration | `[ai-engineer]` |
+
+## Why This Matters
+
+### For Beginners (non-technical users)
+- They type `/guide` → AI suggests the chain
+- Each workflow step tells AI which **expert mindset** to adopt
+- Result: expert-level output without knowing anything about skills
+
+### For Experienced Developers
+- They can call any workflow directly or skip steps
+- Skills provide **domain-specific best practices** they might miss
+- Knowledge graph prevents loading conflicting or redundant skills
+- They can override: "skip the research step" → workflow adapts
+
+### For the AI
+- Skills are **not decorative** — they change the AI's behavior
+- `Invoke [lead-architect]` = think about system design, scalability, trade-offs
+- `Invoke [qa-tester]` = think about edge cases, test coverage, regression
+- Without skill invocation, AI defaults to generic responses
+- With skill invocation, AI activates domain expertise
+
+## Example: Good vs Bad Workflow Step
+
+### ❌ Bad (no skill, vague instruction)
+```markdown
+## Step 2: Create Plan
+1. Create a plan document
+2. Save to docs/
+```
+
+### ✅ Good (skill invoked, specific actions)
+```markdown
+## Step 2: Create Plan
+
+**Invoke `[lead-architect]` skill** to analyze technical requirements.
+**Invoke `[project-manager]` skill** to create phased roadmap.
+
+1. Break project into phases (MVP → v1.0 → v2.0)
+2. Identify dependencies between features
+3. Estimate complexity per phase
+4. Create `docs/010-Planning/Roadmap-{Name}.md`
+```
+
+## Workflow Template
+
+When creating new workflows, follow this template:
+
+```markdown
+---
+description: <what this workflow does>
+---
+
+# Workflow Name
+
+## Step N: <Step Name>
+
+// turbo (if safe to auto-run)
+
+**Invoke `[relevant-skill]` skill** to <specific action>.
+
+> **For beginners**: <explain what happens in simple terms>
+> **For experts**: <mention what can be skipped or customized>
+
+1. <Specific action>
+2. <Specific action>
+3. **WAIT** for user input (if needed)
+```