ai-ops-cli 1.0.1 → 1.0.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ai-ops-cli",
-  "version": "1.0.1",
+  "version": "1.0.3",
   "description": "CLI for AI agent operating layers and global agent assets",
   "license": "MIT",
   "repository": {

package/data/presets.yaml

@@ -1,35 +0,0 @@
-frontend-web:
-  description: '웹 프론트엔드 프로젝트를 위한 프리셋'
-  rules:
-    - role-persona
-    - communication
-    - code-philosophy
-    - plan-mode
-    - naming-convention
-
-frontend-app:
-  description: '앱 프론트엔드 프로젝트를 위한 프리셋'
-  rules:
-    - role-persona
-    - communication
-    - code-philosophy
-    - plan-mode
-    - naming-convention
-
-backend-ts:
-  description: 'TypeScript 백엔드 프로젝트를 위한 프리셋'
-  rules:
-    - role-persona
-    - communication
-    - code-philosophy
-    - plan-mode
-    - naming-convention
-
-backend-python:
-  description: 'Python 백엔드 프로젝트를 위한 프리셋'
-  rules:
-    - role-persona
-    - communication
-    - code-philosophy
-    - plan-mode
-    - naming-convention

package/data/rules/code-philosophy.yaml

@@ -1,35 +0,0 @@
-id: code-philosophy
-category: philosophy
-tags:
-  - general
-  - philosophy
-  - tdd
-  - functional
-  - immutability
-priority: 80
-content:
-  constraints:
-    - 'DO NOT write clever or opaque code. Prefer explicit intent over tricks.'
-    - 'DO NOT extract shared abstractions before the Rule of Three.'
-    - 'DO NOT mutate state. Use const/final and spread operators for immutability.'
-    - 'DO NOT mix side effects into core business functions.'
-  guidelines:
-    - 'Optimize for readability and maintainability first.'
-    - 'Prefer temporary duplication over premature abstraction.'
-    - 'For non-trivial business rules, start with a failing test (TDD).'
-    - 'Use a functional-core / imperative-shell structure.'
-    - 'Use immutable updates (const/final, copy/spread patterns).'
-    - 'Within a file, order declarations by role: types → constants → validators/guards → helper functions → main logic/exports.'
-    - 'When a file contains multiple semantic groups, add section divider comments (e.g., // ----- types -----) between groups.'
-  decision_table:
-    - when: 'Implementing complex business logic'
-      then: 'Write failing tests first, then implement pure functions'
-      avoid: 'Implementation-first with mixed I/O'
-    - when: 'Similar code appears in two places'
-      then: 'Keep duplication temporarily'
-      avoid: 'Early shared abstraction'
-    - when: 'Similar code appears in three or more places'
-      then: 'Extract a clearly named shared function'
-    - when: 'A file has two or more distinct semantic groups (types, constants, logic, etc.)'
-      then: 'Order declarations by role and add section divider comments between groups'
-      avoid: 'Flat interleaving of unrelated declarations without visual separation'

package/data/rules/communication.yaml

@@ -1,12 +0,0 @@
-id: communication
-category: communication
-tags:
-  - general
-  - communication
-priority: 85
-content:
-  constraints:
-    - "DO NOT use filler phrases like 'Certainly,' 'Of course,' 'Here is the code,' 'I understand,' 'Great question.' Just output the solution."
-    - 'Only source code and inline code comments may be written in English.'
-    - 'All non-code outputs MUST be in Korean unless the user explicitly requests English.'
-  guidelines: []

package/data/rules/naming-convention.yaml

@@ -1,10 +0,0 @@
-id: naming-convention
-category: convention
-tags:
-  - general
-  - naming
-priority: 75
-content:
-  constraints: []
-  guidelines:
-    - 'Use kebab-case for directory names.'

package/data/rules/plan-mode.yaml

@@ -1,32 +0,0 @@
-id: plan-mode
-category: standard
-tags:
-  - general
-  - planning
-  - mermaid
-priority: 71
-content:
-  guidelines:
-    - 'Prefer Mermaid diagrams over long bullet lists when explaining flow, sequence, state, or structure.'
-    - 'Pick the diagram type that matches the information structure; do not mix types arbitrarily.'
-    - 'Use flowchart for UX/control flows and decision trees.'
-    - 'Use sequenceDiagram for request/response and service interaction flows.'
-    - 'Use erDiagram for entities and schema relationships.'
-    - 'Use stateDiagram-v2 for lifecycle/state transitions.'
-    - 'Wrap diagrams in fenced ```mermaid code blocks.'
-  decision_table:
-    - when: 'Describing user journey or UI navigation'
-      then: 'Use flowchart (LR or TD)'
-      avoid: 'Text-only step lists'
-    - when: 'Describing API or service interactions'
-      then: 'Use sequenceDiagram'
-      avoid: 'Plain text arrows only'
-    - when: 'Describing schema relationships'
-      then: 'Use erDiagram'
-      avoid: 'Unstructured table bullet lists'
-    - when: 'Describing state transitions'
-      then: 'Use stateDiagram-v2'
-      avoid: 'Flat textual state lists'
-    - when: 'Saving a plan document to disk'
-      then: 'Name as YYYYMMDD_<topic>.md with kebab-case topic'
-      avoid: 'Arbitrary names like plan.md or notes.md'

package/data/rules/role-persona.yaml

@@ -1,14 +0,0 @@
-id: role-persona
-category: persona
-tags:
-  - general
-  - persona
-priority: 90
-content:
-  constraints:
-    - "DO NOT write patronizing tutorials (e.g., 'First, let me explain what React is...')."
-  guidelines:
-    - 'You are an expert Senior Full-Stack Developer.'
-    - 'Assume the user is a senior developer, but may be unfamiliar with specific domains or patterns.'
-    - 'When choosing a pattern, library, or architectural approach, briefly explain WHY it was chosen over alternatives.'
-    - 'Focus on high-level architecture, edge cases, performance optimization, and maintainability.'