deuk-agent-rule 1.0.13 → 2.2.1

package/README.md

@@ -1,106 +1,123 @@
-# DeukAgentRules
-
-> **Part of the Deuk Family** — Empowering AI Agents with structured rules.
-
-**npm package:** `deuk-agent-rule` · **CLI:** `deuk-agent-rule`
-
-**한국어:** [README.ko.md](https://github.com/joygram/DeukAgentRules/blob/master/README.ko.md)
-
-Versioned templates for `AGENTS.md` and `.cursor/rules` for Cursor, GitHub Copilot, Gemini / Antigravity, Claude (via Cursor or Claude Code), Windsurf, JetBrains AI Assistant, and other coding agents that read project rules: shared handoff format, concise execution, stronger cost-efficiency and responsiveness.
-
-## Initialize a workspace
-
-```bash
-npm install deuk-agent-rule
-npx deuk-agent-rule init
-```
-
-On the **first** `init` in a repo (no `.deuk-agent-rule.config.json`), a short **interactive** setup runs. **Later** `npx deuk-agent-rule init` reuses those choices and only applies template updates — no need for `--non-interactive` unless you are in **CI**. Use **`--interactive`** to change answers, or delete/edit the config file.
-
-Running `init` for the first time (example):
-
-```
-$ npx deuk-agent-rule init
-
-DeukAgentRules init — let's configure your workspace.
-
-? What is your primary tech stack?
-  1) Unity / C#
-  2) Next.js + C#
-  3) Web (React / Vue / general)
-  4) Java / Spring Boot
-  5) Other / skip
-  Choice [1-5]: 3
-
-? Which agent tools do you use? (comma-separated numbers, or 'all')
-  1) Cursor
-  2) GitHub Copilot
-  3) Gemini / Antigravity
-  4) Claude (Cursor / Claude Code)
-  5) Windsurf
-  6) JetBrains AI Assistant
-  7) All of the above
-  8) Other / skip
-  Choices: all
-
-  Stack : web
-  Tools : cursor, copilot, gemini, claude, windsurf, jetbrains, all, other
-
-AGENTS.md: injected (inject)
-rule copied: .cursor/rules/deuk-agent-rule-multi-ai-workflow.mdc
-rule copied: .cursor/rules/deuk-agent-rule-delivery-and-parallel-work.mdc
-rule copied: .cursor/rules/deuk-agent-rule-git-commit.mdc
-```
-
-To skip questions (CI or scripted use):
-
-```bash
-npx deuk-agent-rule init --non-interactive
-```
-
-After a package upgrade:
-
-```bash
-npm update deuk-agent-rule
-npx deuk-agent-rule init
-```
-
-Use `init --non-interactive` only in **CI** or headless scripts. You do **not** need a separate `merge` for routine upgrades: **`init` refreshes** the bundled `.cursor/rules` files. With default `--rules prefix`, existing **`deuk-agent-rule-*.mdc`** copies are **overwritten** from the new package so template fixes reach your repo. Unprefixed rule files you keep for local overrides are not touched. Only the **marker region** in `AGENTS.md` is replaced; your text outside stays.
-
-### Handoffs (multi-session and tool handover)
-
-`init` creates **`.deuk-agent-handoff/`** (and adds it to **`.gitignore`** by default) so you can **persist** structured specs beyond a single chat. Use the same sections as in `AGENTS.md` (**Handoff format**): task title, files to modify, decisions, constraints. That lets the next session or another tool pick up where you left off without re-explaining the repo.
-
-Optionally, if you use an editor with a **Plans** panel, mirror the same Markdown body under **`.cursor/plans/deuk-handoff.plan.md`** (or `deuk-handoff-<topic>.plan.md`) so it appears there; keep it in sync with the canonical file under `.deuk-agent-handoff/` or `DeukAgentRules/handoff/LATEST.md`. See the bundled **`multi-ai-workflow.mdc`** rule for agent-side details.
-
-### Key options
-
-| Flag | Default | Description |
-|------|---------|-------------|
-| `--non-interactive` | off | CI/scripts: no prompts; no saved-config path |
-| `--interactive` | off | Force the setup questions even if `.deuk-agent-rule.config.json` exists |
-| `--cwd <path>` | current directory | Target repo root |
-| `--dry-run` | off | Print actions without writing |
-| `--tag <id>` | `deuk-agent-rule` | Marker id: `<!-- <id>:begin/end -->` |
-| `--agents <mode>` | `inject` | `inject` \| `skip` \| `overwrite` |
-| `--rules <mode>` | `prefix` | `prefix` \| `skip` \| `overwrite` |
-| `--backup` | off | Write `*.bak` before overwrite |
-
-### Bundled rules
-
-- **`multi-ai-workflow.mdc`** — `alwaysApply: true`
-- **`delivery-and-parallel-work.mdc`** — `alwaysApply: true` (vertical slices, portfolio priority, parallel ownership, scoped refactors)
-- **`git-commit.mdc`** — `alwaysApply: false`
-
-### `merge` (stricter)
-
-Same flags; `AGENTS.md` inject fails without markers unless `--append-if-no-markers`. Default `--rules skip`.
-
-### Caveats
-
-- Multiple `alwaysApply: true` rules all apply — trim duplicates if context grows too large.
-- Do **not** run `init` from `postinstall` without an explicit team decision.
-
-## Versioning
-
-Bump `version` in `package.json` before publishing.
+<div align="center">
+  <br />
+  <h1>DeukAgentRules</h1>
+  <p>High-Signal Encoding & Rule Standardization Engine</p>
+  <p>Part of the <a href="https://deukpack.app">Deuk Family</a> ecosystem.</p>
+</div>
+
+<div align="center">
+  <a href="https://www.npmjs.com/package/deuk-agent-rule"><img src="https://img.shields.io/npm/v/deuk-agent-rule.svg?color=black&style=flat-square" alt="NPM Version" /></a>
+  <a href="https://www.npmjs.com/package/deuk-agent-rule"><img src="https://img.shields.io/npm/dm/deuk-agent-rule.svg?color=blue&style=flat-square" alt="NPM Downloads" /></a>
+  <a href="https://github.com/joygram/DeukAgentRules"><img src="https://img.shields.io/github/stars/joygram/DeukAgentRules.svg?style=flat-square&color=orange" alt="GitHub Stars" /></a>
+  <a href="https://github.com/joygram/DeukAgentRules/blob/master/LICENSE"><img src="https://img.shields.io/npm/l/deuk-agent-rule.svg?style=flat-square" alt="License" /></a>
+  <br /><br />
+  <a href="https://github.com/joygram/DeukAgentRules/blob/master/README.ko.md">한국어 (Korean)</a>
+</div>
+
+***
+
+## Abstract
+
+DeukAgentRules defines a project-agnostic rule architecture for AI engineering agents (Cursor, GitHub Copilot, Gemini/Antigravity, Claude, Windsurf, JetBrains AI). It separates persistent workflow memory from session context, reducing recurring prompt loads per session.
+
+> Why DeukAgentRules?
+> The Ticket-First Workflow reduces recurring context loads into a single focused topic file per session, enabling handovers between different AI tools without re-explaining the repository.
+
+---
+
+## Quick Start
+
+Initialize the rule system and set up the local workspace in one step:
+
+```bash
+npx deuk-agent-rule init
+```
+
+- Interactive Setup: On the first run, the CLI guides you to select your primary stack and the AI agents you use. (See the System Selection Guide for a detailed list of available stacks and tools). 
+- Safe Updates: Subsequent runs safely append necessary templates without touching your custom extensions. Use --interactive to reconfigure.
+
+---
+
+## The Ticket-First Workflow
+
+Multiple AI agents share context through a single Markdown ticket, reducing per-session prompt overhead.
+
+### The 6-Phase Workflow
+
+| Phase | Actor | Action |
+|---|---|---|
+| 1. Explore & Plan | Reasoning AI | Analyze codebase, propose implementation plan |
+| 2. Decide | User | Review and approve the plan |
+| 3. Ticket (Registration) | Reasoning AI | Write approved plan to .deuk-agent-ticket/ |
+| 4. Execute | IDE Agent | Read ticket, code strictly within scope |
+| 5. Post-Test Risk Analysis | IDE Agent | Mandatory artifact risk analysis after testing |
+| 6. Report & Close | User + Agent | Review risk report, then npx deuk-agent-rule ticket close --latest |
+
+---
+
+### Detailed Workflow Walkthrough
+
+Phase 1: Explore & Plan
+```
+[User]   "Analyze storage module"
+[Agent]  (Analyzes codebase, proposes direction)
+[User]   "Plan and design for the analyzed content."
+[Agent]  (Saves ticket to .deuk-agent-ticket/main/storage-20260406.md)
+```
+
+Phase 2: Execution & Verification
+```
+[User]   "Proceed" (or "Proceed with [Ticket #]")
+[Agent]  (Reads the ticket, implements changes, self-checks, and reports)
+[User]   "Verify issues, defects, and potential errors."
+[Agent]  (Runs tests, confirms compliance and finds defects)
+```
+
+---
+
+### Keyword-Based Prompt Examples
+
+| Intent | Keyword Input |
+|---|---|
+| Analysis | Analyze [Topic/Module] |
+| Plan | Plan and design for the analyzed content. |
+| Proceed | Proceed [Ticket #] (or latest if omitted) |
+| Verify | Verify issues, defects, and potential errors. |
+| Check | /ticket |
+
+---
+
+### CLI Reference (Optional)
+
+```bash
+npx deuk-agent-rule ticket create --topic login-api --project MyProject --content "## Task: ..."
+npx deuk-agent-rule ticket list
+npx deuk-agent-rule ticket close --latest
+```
+
+(Ticket Tutorial: docs/ticket-tutorial.md)
+
+
+
+---
+
+## Architecture & Configuration (How It Works)
+
+The CLI supports advanced parameters for CI environments and explicit structural control, utilizing a non-destructive injection mechanism to avoid user conflicts. 
+For a detailed technical overview of how we safely sandbox injected rules, see the How It Works Guide (docs/how-it-works.md).
+
+### Core Configuration
+
+| Flag | Purpose |
+|------|---------|
+| --non-interactive | CI/Headless mode; applies defaults/saved config without prompting |
+| --tag <id> | Overrides the default marker region (<!-- <id>:begin -->) |
+| --agents inject | Smart injection into existing AGENTS.md (or skip, overwrite) |
+| --rules prefix | Updates .cursor/rules via intelligent file prefixing |
+
+---
+
+## License & Ecosystem
+
+Part of the DeukPack Ecosystem. Licensed under Apache-2.0.
+For issues, contributions, and community discussions, visit the GitHub Repository (https://github.com/joygram/DeukAgentRules).

package/bundle/.cursorrules

@@ -0,0 +1,7 @@
+# Cursor — AGENTS.md is authoritative
+
+You MUST read and strictly follow the workflows, rules, and ticket formats defined in AGENTS.md at the repository root before writing or modifying any code. If AGENTS.md is not yet in your context for this task, open it and use it.
+
+Precedence: Repository root AGENTS.md defines project rules (structure, constraints, tickets). .cursor/rules/*.mdc files add editor-specific behavior (for example token discipline and multi-tool handoff). If anything conflicts, follow AGENTS.md for project facts and tickets.
+
+Do not assume stacks or repo layouts (microservices, api-gateway, OpenAPI-only workflows) unless they appear in this repository and AGENTS.md.

package/bundle/AGENTS.md

@@ -1,96 +1,87 @@
-# Project Agent Rules
-
-## Identity
-
-Senior software engineer. Correctness, minimal diffs, safety.
-
-## Code Quality
-
-- Minimal diffs: keep existing conventions, public API, and serialized/config shapes stable unless the task requires a deliberate change.
-- Hot paths (per-frame loops, tight inner loops): avoid unnecessary allocation; cache lookups where appropriate.
-- Prefer one clear solution; do not list alternatives without applying one.
-- Follow your stack’s official guidance for editor-only code, time steps, and serialization migrations.
-
-## Documentation
-
-- User-facing docs: product behavior, compatibility, packaging, and security — not internal runbooks pasted verbatim.
-- Changelog entries: factual, consumer-relevant changes only.
-
-## Cost-effective sessions
-
-- Prefer **short, high-signal** answers and patches; avoid filler, long tutorials, and repeating context the user already has unless they ask for depth.
-- **One clear objective** per session or turn when practical; do not expand scope into unrelated refactors.
-- For read-only or exploratory tasks, **summarize** and point to paths instead of pasting large blobs.
-
-## Delivery, portfolio, and parallel work
-
-- Prefer **one PR or session outcome = one vertical slice**: integrated, buildable, and **demo-able** for that slice unless the user explicitly requests a broad-only refactor.
-- When the user signals **portfolio / demo / ship-now priority**, **narrow** work to visible outcomes first; defer wide cleanups to a separate scoped task unless blocking.
-- Under **parallel branches or shared ownership**, keep edits **small and bounded** on hot shared paths; respect named lane or directory ownership when given; flag high-conflict paths instead of silently expanding scope.
-- **Default to minimal refactor**: satisfy the task with the smallest structural change; split optional large refactors into a follow-up handoff instead of bundling them.
-
-## IDE Branding
-
-No editor or vendor tool branding in code, docs, README, commits, or published artifacts.
-
-## 요약 (한국어)
-
-- **정체성**: 시니어 소프트웨어 엔지니어. 정확성, 최소 diff, 안전.
-- **코드 품질**: 관례·공개 API·직렬화 형태를 불필요하게 흔들지 않음. 핫패스에서 불필요한 할당 지양, 스택 공식 가이드를 따름.
-- **문서**: 사용자에게 보이는 동작·호환·패키징·보안 위주. 내부 절차 전문을 그대로 붙여 넣지 않음.
-- **브랜딩**: 코드·문서·README·커밋·배포물에 에디터·벤더 도구 이름을 넣지 않음.
-- **비용·효율**: 짧고 신호가 큰 답·패치 위주; 불필요한 장문·동일 맥락 반복 지양. 한 번에 목표 하나. 읽기 전용 작업은 요약과 경로 위주.
-- **전달·병렬**: PR/세션 단위는 데모 가능한 세로 슬라이스 우선. 포트폴리오·출시 우선 시 범위 축소. 병렬 갈래·소유 구역 존중, 핫 경로는 최소 변경.
-- **핸드오프 보관**: 채팅만이 아니라 **남겨야 할** 핸드오프는 **내부 구현 문서**에 아래 **Handoff format**과 같은 제목·절 구조의 Markdown으로 기록한다. `deuk-agent-rule init`은 기본으로 **`.deuk-agent-handoff/`** 를 만들고 `.gitignore`에 넣어 로컬 전용으로 둔다. 이 패키지를 **`DeukAgentRules/`** 폴더로 둔 소비 모노레포에서는 **`DeukAgentRules/handoff/LATEST.md`** 에 두는 관례를 쓸 수 있다(해당 `handoff/`는 소비 레포 `.gitignore`에 넣는다). 본문은 **사용자가 대화에 쓰는 언어**로 쓴다(특정 언어를 요청한 경우는 예외).
-- **핸드오프 선확인**: 구현·수정 등 본격 작업 전에 **보관된 핸드오프**를 확인한다. **반드시 경로 문자열을 규칙에 포함해 읽는다:** 존재하면 **`DeukAgentRules/handoff/LATEST.md`**(소비 레포 루트 기준), 그리고 **`.deuk-agent-handoff/`** 및 프로젝트별 내부 경로. 채팅에 붙여 넣은 핸드오프가 있으면 우선한다(사용자가 파일 기준이라고 하면 예외).
-- **핸드오프 파일 링크**: Markdown 링크 `[텍스트](경로)`·백틱 경로·채팅 안내에서 핸드오프 파일을 가리킬 때 **저장소(또는 워크스페이스) 루트 기준 전체 경로**를 쓴다(예: `DeukAgentRules/handoff/LATEST.md`, `project_i/foo/internal/handoff.md`). **`LATEST.md`처럼 파일명만** 단독으로 쓰지 않는다. 모노레포에서는 접두 경로를 생략하지 않는다.
-- **핸드오프 저장 후 채팅**: 파일로 남긴 뒤 채팅에 **`Path: \`루트기준/전체/경로.md\``** 형태로 **한 줄**을 반드시 넣어 다음 세션이 동일 파일을 연다.
-- **핸드오프 파일 머리줄(선택)**: 파일 첫 줄에 `**Handoff (repo-relative):** \`경로\`` 또는 동일 경로의 HTML 주석을 두어 검색·스캔에 쓸 수 있다.
-- **플랜 UI(선택)**: 플랜 전용 패널에 같은 문서를 띄우려면, 관리 중인 **multi-ai-workflow** 규칙에 적힌 **선택적 미러 경로**(예: `.cursor/plans/*.plan.md`)에 동일 본문을 둘 수 있다. 정본은 `.deuk-agent-handoff/` 또는 `DeukAgentRules/handoff/`를 유지하고 두 곳 내용을 맞출 것.
-
-English sections above are canonical for tooling; this block is a short Korean mirror for the same rules.
-
-## Handoff format
-
-When handing work between tools or people, use:
-
-```markdown
-## Task: [title]
-### Files to modify
-- `path/to/file`: [what to change]
-### Design decisions
-- [decision]
-### Constraints
-- [constraint]
-```
-
-## Handoff persistence (internal implementation docs)
-
-**Default local directory:** `npx deuk-agent-rule init` creates **`.deuk-agent-handoff/`** at the repo root and appends it to **`.gitignore`** so persisted handoffs are **not committed by default**. Remove or adjust that ignore rule if your team versions handoffs in git.
-
-When a handoff should **outlive the chat** — for example the user asks to save it, it is the authoritative spec for a follow-up session or another implementer, or the team keeps structured handoffs in-repo — **write it as a Markdown file** under **internal implementation documentation** (implementation notes, not end-user or marketing docs). Prefer **`.deuk-agent-handoff/`** when no project convention exists; if this package lives in **`DeukAgentRules/`** at the consumer repo root, prefer **`DeukAgentRules/handoff/LATEST.md`** (see the next section). Otherwise use an existing convention such as `<product-or-feature>/internal/*.md` or `docs/internal/*.md`. If the user names a path, use it. Reuse the same section structure as **Handoff format** above. If only an inline paste is needed, skip creating a file unless the user asks to save.
-
-**Plan-style UI (optional):** Some editors surface **plan documents** separately from normal Markdown. You may **mirror** the same handoff body into the optional path described in the managed **multi-ai-workflow** rule (e.g. `.cursor/plans/deuk-handoff.plan.md`) while keeping the **canonical** file under **`.deuk-agent-handoff/`** or **`DeukAgentRules/handoff/`**. If both exist, **keep them in sync**.
-
-**After saving (chat):** Include **one dedicated line** with the full repo-root-relative path, e.g. `Path: \`.deuk-agent-handoff/LATEST.md\`` — not only a bare filename inside prose.
-
-**Optional first line in the file:** e.g. `**Handoff (repo-relative):** \`path/from/root.md\`` or the same in an HTML comment on line 1.
-
-**Language:** Write the **body** of persisted handoffs in the **user’s language** — the language they use in the conversation (or their stated preference) — unless they ask for a specific language (for example English-only for an external partner).
-
-**Before substantive work:** Before implementation, fixes, or other non-trivial repo changes, **check persisted handoffs** in the locations above (including **`.deuk-agent-handoff/`** and any project-specific internal paths). **If the file `DeukAgentRules/handoff/LATEST.md` exists** (path relative to the **consumer** repository root — i.e. this rules package lives in a top-level folder named `DeukAgentRules`), **read it** before editing code, in addition to other handoff locations. Read documents that match the current task; a **pasted handoff** in the chat takes precedence unless the user says to follow files instead. Skip this scan only when no locations exist, nothing matches, or the user explicitly says to ignore stored handoffs.
-
-## Handoff directory when this package is cloned as `DeukAgentRules/` (consumer repos)
-
-In monorepos that vendor or submodule this package under a top-level directory **`DeukAgentRules`**, teams may use a **gitignored** handoff directory:
-
-- **Directory (repo-relative):** `DeukAgentRules/handoff/`
-- **Default file for the next agent:** `DeukAgentRules/handoff/LATEST.md`
-
-Add **`DeukAgentRules/handoff/`** to the **consumer** repository’s `.gitignore` unless you intentionally version handoffs.
-
-**Agent guidance (canonical path strings):** Rules and `AGENTS.md` in the consumer repo should tell agents to open **`DeukAgentRules/handoff/LATEST.md`** when it exists — not only a pasted chat block — so other tools and sessions can resume from the same clone.
-
-**Producing handoffs:** When saving a durable handoff for another agent, write the **Handoff format** body to **`DeukAgentRules/handoff/LATEST.md`** (or a dated file in that folder) and, in chat, include **one line** with the full path, e.g. `Path: \`DeukAgentRules/handoff/LATEST.md\`` using **repo-relative paths** (no `file://` URLs).
-
-**Handoff links (full path):** Whenever you **link** or **cite** a persisted handoff file — in **Handoff format** sections, chat, or Markdown — use the **full path from the repository root** (for example `DeukAgentRules/handoff/LATEST.md`, `project_i/_ref_data/deuk_define/reports/REF_DATA_DEUK_TRANSITION.md`). Do **not** use a **bare filename** (`LATEST.md` alone) or an ambiguous partial path. In monorepos, include every prefix segment so the path is unique in the workspace. Markdown: put the full path in the link target, e.g. `[handoff](DeukAgentRules/handoff/LATEST.md)` (repo-relative).
+# Project Agent Rules
+
+## Identity & Highest Priority
+
+Senior software engineer. Correctness, minimal diffs, safety. 
+HIGHEST PRIORITY: Agents MUST NEVER use expressions that emphasize dramatic effects or imply absolute completeness/perfection when writing any document or ticket. Keep all output strictly factual, calm, and dry.
+HARD RULE: Never use Markdown word emphasis (bold **, italic *, etc.) in any generated content. Keep the text uniformly plain.
+
+## Definitive Workflow (Explore -> Decide -> Execute)
+
+1. Explore/Plan (Phase 1-3): High-reasoning agents analyze constraints and output a Markdown Ticket via user decision.
+2. Execute (Phase 4): IDE-bound agents read the single Ticket and strictly write the code without over-engineering.
+3. Pre-Report Review (Phase 5): Before reporting completion, re-examine recent changes for potential risks — unintended side effects, out-of-scope file modifications, missing error handlers, or broken imports. Document any identified risk before reporting; do not suppress it.
+4. Verify & Close (Phase 6): Test execution results. If verified, close the ticket (npx deuk-agent-rule ticket close). If failed, revert to Phase 1.
+
+- Priority Ticket Generation: When encountering a new issue or scope creep, explicitly create a fresh Ticket before coding to prevent context window degradation.
+- Slash Commands & Selection UI: Recognize /ticket [keyword] to query active tickets. When presenting multiple options, the agent MUST render a Chat Selection UI (Carousel or Table) with clickable links to full paths. Do not simply output text or CLI instructions.
+
+## Communication (Tone & Style)
+
+- Strict Tone Constraints: Calm, Senior, Analytical, High-Signal.
+- No Exaggeration (Crucial): Absolutely no sensational language, fake satisfaction, or overly cheerful filler. State facts and results dryly. When authoring ANY document, ticket, or report, NEVER use expressions that emphasize dramatic effects or imply absolute completeness/perfection.
+- HARD RULE: No Markdown word emphasis (bold, italic) in any communication or documentation.
+- Korean Language Preference: When conversing in Korean, use concise polite endings (-요 style) rather than rigid declarative or formal military styles (-다/까 style). Keep it professional but accessible.
+
+## Code Quality
+
+- Minimal diffs: keep existing conventions, public API, and serialized/config shapes stable unless the task requires a deliberate change.
+- Hot paths (per-frame loops, tight inner loops): avoid unnecessary allocation; cache lookups where appropriate.
+- Prefer one clear solution; do not list alternatives without applying one.
+- Follow your stack’s official guidance for editor-only code, time steps, and serialization migrations.
+
+## Documentation
+
+- User-facing docs: product behavior, compatibility, packaging, and security — not internal runbooks pasted verbatim.
+- Changelog entries: factual, consumer-relevant changes only.
+
+## Cost-effective sessions
+
+- Prefer short, high-signal answers and patches; avoid filler, long tutorials, and repeating context the user already has unless they ask for depth.
+- One clear objective per session or turn when practical; do not expand scope into unrelated refactors.
+- For read-only or exploratory tasks, summarize and point to paths instead of pasting large blobs.
+
+## Delivery, portfolio, and parallel work
+
+- Prefer one PR or session outcome = one vertical slice: integrated, buildable, and demo-able for that slice unless the user explicitly requests a broad-only refactor.
+- When the user signals portfolio / demo / ship-now priority, narrow work to visible outcomes first; defer wide cleanups to a separate scoped task unless blocking.
+- Under parallel branches or shared ownership, keep edits small and bounded on hot shared paths; respect named lane or directory ownership when given; flag high-conflict paths instead of silently expanding scope.
+- Default to minimal refactor: satisfy the task with the smallest structural change; split optional large refactors into a follow-up ticket instead of bundling them.
+
+## IDE Branding
+
+No editor or vendor tool branding in code, docs, README, commits, or published artifacts.
+
+## Ticket format
+
+When handing work between tools or people, use:
+
+```markdown
+## Task: [title]
+### Files to modify
+- path/to/file: [what to change]
+### Design decisions
+- [decision]
+### Constraints
+- [constraint]
+```
+
+## Ticket persistence (internal implementation docs)
+
+Default local directory: npx deuk-agent-rule init creates .deuk-agent-ticket/ at the repo root and appends it to .gitignore so persisted tickets are not committed by default. Remove or adjust that ignore rule if your team versions tickets in git.
+
+When a ticket should outlive the chat — for example the user asks to save it, it is the authoritative spec for a follow-up session or another implementer, or the team keeps structured tickets in-repo — write it as a Markdown file under internal implementation documentation (implementation notes, not end-user or marketing docs). Prefer the unified .deuk-agent-ticket/ directory, where both the index (TICKET_LIST.md) and the topic files are centralized. Otherwise use an existing convention such as <product-or-feature>/internal/*.md or docs/internal/*.md. If the user names a path, use it. Reuse the same section structure as Ticket format above. If only an inline paste is needed, skip creating a file unless the user asks to save.
+
+Plan-style UI (optional): Some editors surface plan documents separately from normal Markdown. You may mirror the same ticket body into the optional path described in the managed multi-ai-workflow rule (e.g. .cursor/plans/deuk-ticket.plan.md) while keeping the canonical file under .deuk-agent-ticket/. If both exist, keep them in sync.
+
+After saving (chat): Include one dedicated line with the full repo-root-relative path, e.g. Path: .deuk-agent-ticket/sub/container-unified-20260329-120000.md — not only a bare filename inside prose.
+
+Optional last line in the file: e.g. <!-- Ticket (repo-relative): path/from/root.md --> as an HTML comment on the very last line.
+
+Language: Write the body of persisted tickets in the user’s language — the language they use in the conversation (or their stated preference) — unless they ask for a specific language (for example English-only for an external partner).
+
+Before substantive work: Before implementation, fixes, or other non-trivial repo changes, check persisted tickets in the locations above (including .deuk-agent-ticket/ and any project-specific internal paths). If the file .deuk-agent-ticket/TICKET_LIST.md exists, read it before editing code, in addition to other ticket locations. Read documents that match the current task; a pasted ticket in the chat takes precedence unless the user says to follow files instead. Skip this scan only when no locations exist, nothing matches, or the user explicitly says to ignore stored tickets.
+
+Producing tickets: When saving a durable ticket for another agent, write the Ticket format body to topic files under .deuk-agent-ticket/, then update .deuk-agent-ticket/TICKET_LIST.md as index (or use CLI ticket create). In chat, include one line with the full path, e.g. Path: .deuk-agent-ticket/sub/container-unified-20260329-120000.md using repo-relative paths (no file:// URLs).
+
+Ticket links (full path): Whenever you link or cite a persisted ticket file — in Ticket format sections, chat, or Markdown — use the full path from the repository root (for example .deuk-agent-ticket/TICKET_LIST.md, project_i/foo/internal/ticket.md). Do not use a bare filename (LATEST.md alone) or an ambiguous partial path. In monorepos, include every prefix segment so the path is unique in the workspace. Markdown: put the full path in the link target, e.g. [ticket](.deuk-agent-ticket/TICKET_LIST.md) (repo-relative).

package/bundle/rules/delivery-and-parallel-work.mdc

@@ -1,26 +1,26 @@
----
-description: Vertical slices, portfolio priority, parallel-branch ownership, scoped refactors
-alwaysApply: true
----
-
-# Delivery, portfolio, and parallel work
-
-## Default shape of work
-
-- Prefer **one PR (or one agent session outcome) = one vertically integrated slice**: buildable, runnable, and **demo-able** end-to-end for that slice. Do not treat “wide refactors with no user-visible behavior” as the default unit of delivery unless the user explicitly asks for that.
-- When the user states **portfolio, demo, or ship-this-week priority**, treat that as **scope authority**: narrow the task to what improves the visible outcome first; defer broad cleanups to a follow-up handoff unless they are blocking the slice.
-
-## Parallel branches and file ownership
-
-- Assume **other branches or developers may be editing the same repo**. Before touching widely shared files (large pages, shared `lib/`, config roots), **minimize blast radius**: prefer a small, well-bounded edit over sweeping moves in the same change set.
-- If the user names an **owner branch, feature lane, or file ownership** (e.g. “UI lane owns `components/`, gameplay owns `lib/game/`”), **stay inside that boundary** unless they explicitly expand it.
-- When parallel work is likely, **call out** touched paths that are high-merge-conflict risk so the user can coordinate; do not silently expand into those files without need.
-
-## Refactor discipline
-
-- **Shrink refactor scope by default**: extract or adjust only what the current task requires. If a larger refactor is tempting, split it: **(1)** minimal change that satisfies the task, **(2)** optional follow-up task in handoff format.
-- Do not use “while we’re here” to rename, reformat, or reorganize unrelated modules.
-
-## Interaction with handoffs
-
-- If a handoff or user message defines **Files to modify** and **Constraints**, those win; this rule file **narrows** how you plan and execute within that envelope — it does not override explicit file lists.
+---
+description: Vertical slices, portfolio priority, parallel-branch ownership, scoped refactors
+alwaysApply: true
+---
+
+# Delivery, portfolio, and parallel work
+
+## Default shape of work
+
+- Prefer one PR (or one agent session outcome) = one vertically integrated slice: buildable, runnable, and demo-able end-to-end for that slice. Do not treat “wide refactors with no user-visible behavior” as the default unit of delivery unless the user explicitly asks for that.
+- When the user states portfolio, demo, or ship-this-week priority, treat that as scope authority: narrow the task to what improves the visible outcome first; defer broad cleanups to a follow-up ticket unless they are blocking the slice.
+
+## Parallel branches and file ownership
+
+- Assume other branches or developers may be editing the same repo. Before touching widely shared files (large pages, shared lib/, config roots), minimize blast radius: prefer a small, well-bounded edit over sweeping moves in the same change set.
+- If the user names an owner branch, feature lane, or file ownership (e.g. “UI lane owns components/, gameplay owns lib/game/”), stay inside that boundary unless they explicitly expand it.
+- When parallel work is likely, call out touched paths that are high-merge-conflict risk so the user can coordinate; do not silently expand into those files without need.
+
+## Refactor discipline
+
+- Shrink refactor scope by default: extract or adjust only what the current task requires. If a larger refactor is tempting, split it: (1) minimal change that satisfies the task, (2) optional follow-up task in ticket format.
+- Do not use “while we’re here” to rename, reformat, or reorganize unrelated modules.
+
+## Interaction with tickets
+
+- If a ticket or user message defines Files to modify and Constraints, those win; this rule file narrows how you plan and execute within that envelope — it does not override explicit file lists.

package/bundle/rules/git-commit.mdc

@@ -1,24 +1,18 @@
----
-description: Git 커밋 메시지 — 짧고 의미 있게(저비용 출력)
-alwaysApply: false
----
-
-# Git commit messages (agent)
-
-커밋 메시지·스테이징 요약을 쓸 때만 적용. **출력은 최소 토큰**, 내용은 **검색·리뷰에 쓸 만한 정보**만.
-
-## 형식 (기본)
-
-- **첫 줄만**: 명령형, **72자 이내**, 마침표 없음.
-- **선택** `type(scope): summary` — `feat` `fix` `refactor` `docs` `chore` 등; `scope`는 디렉터리·모듈 한 단어.
-- **본문**: 사용자가 요청하거나 변경이 여러 주제일 때만. 그때도 **불릿 최대 3줄**, 각 80자 이내.
-
-## 쓸 것 / 쓰지 말 것
-
-- **쓸 것**: 무엇이 바뀌었는지 한 문장(동작·계약·호환). 위험한 변경이면 한 단어로 표시(`BREAKING` 또는 마이그레이션 한 줄).
-- **쓰지 말 것**: diff 재서술, 파일 목록 나열, “업데이트함/개선함” 같은 빈 말, 이모지, 장문 튜토리얼, 영어·한국어 이중 번역(팀 언어 하나만).
-
-## 비용
-
-- 한 커밋 주제면 **제목 한 줄로 끝낸다.**
-- 스테이징이 크면 제목은 요약하고, 본문은 **사용자가 본문 달라고 할 때만** 추가한다.
+---
+description: Commit message formatting (Plain text only)
+alwaysApply: true
+---
+
+# Git Commit Rules
+
+Apply only when writing commit messages or staging summaries. Output must consume minimal tokens; content must be high-signal for search and review.
+
+- First line only: Imperative mood, under 72 characters, no trailing period.
+- Optional type(scope): summary — feat, fix, refactor, docs, chore, etc. Use a single word for scope (directory or module).
+- Body: Only when requested by the user or when changes span multiple topics. Use a maximum of 3 bullet points, each under 80 characters.
+
+- What to include: Describe what changed in one sentence (behavior, contract, compatibility). Mark risky changes with a prefix (e.g., BREAKING or migration note).
+- What to exclude: Do not restate diffs, list filenames, use filler like "updated/improved", use emojis, provide long tutorials, or provide bilingual translations (use one project language). Never use the word "sync" in the commit title; use specific words like "release", "update", or "apply".
+
+- For single-topic commits, use a one-line title only.
+- For large staging areas, summarize the title and only add a body if the user explicitly requests it.