deuk-agent-rule 2.2.0 → 2.2.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +90 -71
- package/LICENSE +0 -0
- package/README.ko.md +125 -125
- package/README.md +125 -123
- package/bundle/.cursorrules +7 -7
- package/bundle/AGENTS.md +36 -87
- package/bundle/rules/delivery-and-parallel-work.mdc +7 -7
- package/bundle/rules/git-commit.mdc +17 -11
- package/bundle/rules/multi-ai-workflow.mdc +105 -105
- package/bundle/templates/MODULE_RULE_TEMPLATE.md +24 -0
- package/bundle/templates/TICKET_TEMPLATE.md +40 -0
- package/package.json +13 -6
- package/scripts/changelog-polish.mjs +22 -0
- package/scripts/cli-args.mjs +45 -43
- package/scripts/cli-init-commands.mjs +65 -65
- package/scripts/cli-init-logic.mjs +21 -21
- package/scripts/cli-prompts.mjs +123 -123
- package/scripts/cli-ticket-commands.mjs +269 -159
- package/scripts/cli-ticket-logic.mjs +229 -229
- package/scripts/cli-utils.mjs +82 -82
- package/scripts/cli.mjs +112 -110
- package/scripts/merge-logic.mjs +365 -365
- package/scripts/sync-bundle.mjs +50 -50
- package/scripts/sync-oss.mjs +122 -0
package/README.md
CHANGED
|
@@ -1,123 +1,125 @@
|
|
|
1
|
-
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
###
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
[
|
|
65
|
-
[
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
```
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
###
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
|
112
|
-
|
|
113
|
-
|
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
|
|
1
|
+
# DeukAgentRules
|
|
2
|
+
|
|
3
|
+
> A core module of the **Deuk Family**. Maximizes collaboration efficiency of AI agents through structured rules.
|
|
4
|
+
|
|
5
|
+
**npm package:** `deuk-agent-rule` · **CLI:** `deuk-agent-rule`
|
|
6
|
+
|
|
7
|
+
**Korean:** [README.ko.md](https://github.com/joygram/DeukAgentRules/blob/master/README.ko.md)
|
|
8
|
+
|
|
9
|
+
A **submodule-isolated collaborative framework** designed to be used alongside various coding agents such as Cursor, GitHub Copilot, Gemini / Antigravity, Claude, Windsurf, and JetBrains AI Assistant.
|
|
10
|
+
It standardizes project rules (`AGENTS.md`, `.cursor/rules`) and strongly prevents wasteful prompt token consumption and AI context hallucination through a **ticket-based workflow**.
|
|
11
|
+
|
|
12
|
+
> **🚀 Core Value:**
|
|
13
|
+
> Compresses the mandatory loaded context of approx. 1,500~2,000 tokens per session down to a mere 200~300 tokens. By isolating the AI to a specific **"Target Submodule"** using exact tickets (work orders), it prevents the AI from wandering through an entire monolithic repository.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## 🛠️ Getting Started (Workspace Initialization)
|
|
18
|
+
|
|
19
|
+
Install and initialize the package once at the project root.
|
|
20
|
+
|
|
21
|
+
```bash
|
|
22
|
+
npm install deuk-agent-rule
|
|
23
|
+
npx deuk-agent-rule init
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
Upon initialization, interactive questions will ask for the project's **tech stack** and **agent tools in use**. Based on your selections, optimized markdown templates and rule files (`.cursor/rules/*`) will be automatically generated and synchronized.
|
|
27
|
+
- If you don't need to change the tech stack later, simply run `npx deuk-agent-rule init` to refresh the rules.
|
|
28
|
+
- Suppress interactive prompts in CI or script environments by appending the `--non-interactive` flag.
|
|
29
|
+
|
|
30
|
+
### 🔄 Updating the Rules Package
|
|
31
|
+
When a new version of the agent rules or templates is released, you can sync the latest instructions to your project by updating the package and re-running `init`.
|
|
32
|
+
Since your previous configurations are saved (`.deuk-agent-rule.config.json`), using the `--non-interactive` flag will quietly and cleanly overwrite the obsolete rules with the latest ones without asking any questions.
|
|
33
|
+
```bash
|
|
34
|
+
npm install deuk-agent-rule@latest
|
|
35
|
+
npx deuk-agent-rule init --non-interactive
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
## 🎯 The Ticket Workflow
|
|
41
|
+
|
|
42
|
+
Running `npx deuk-agent-rule init` deploys a **zero-touch scaffolding sandbox** at your workspace root, spawning two essential directories:
|
|
43
|
+
|
|
44
|
+
1. **`.deuk-agent-templates/` (Agent Templates)**: Houses the official blueprint (`TICKET_TEMPLATE.md`) dictating how AIs must process and report tasks. Committed alongside your source code to serve as the team's rulebook.
|
|
45
|
+
2. **`.deuk-agent-ticket/` (Ticket Execution Space)**: The covert space where volatile instructions (`TICKET-XXX.md`) are exchanged between agents and workers. (Automatically hidden by `.gitignore` to prevent security leaks and repository bloat).
|
|
46
|
+
|
|
47
|
+
The optimal **3-Step AI Coding Sequence** utilizing these sandbox folders is as follows.
|
|
48
|
+
|
|
49
|
+
### [Step 1] Ticket Creation & Submodule Isolation
|
|
50
|
+
Do not issue scattered, unbounded commands to your AI. Narrowing the **context** via a clear ticket is strictly required to prevent astronomical costs and accidental code corruption.
|
|
51
|
+
|
|
52
|
+
```bash
|
|
53
|
+
npx deuk-agent-rule ticket create --topic ui-refactoring --group frontend --project DeukUI --content "## Task: Plugin UI Refactoring"
|
|
54
|
+
```
|
|
55
|
+
This command instantly creates a templated `TICKET-ui-refactoring.md` file within the `.deuk-agent-ticket/` directory.
|
|
56
|
+
The developer must simply specify the exact isolated directory path (e.g., `src/client`) inside the `[Target Submodule]` attribute at the top of the generated file.
|
|
57
|
+
|
|
58
|
+
### [Step 2] Agent Execution & Handoff (Ticket Session)
|
|
59
|
+
Provide a single line of instruction to your AI chatbot (Cursor, Gemini, etc.):
|
|
60
|
+
> *"Open the recently issued `.deuk-agent-ticket/TICKET-ui-refactoring.md` ticket and strictly follow the checklist within the specified target submodule."*
|
|
61
|
+
|
|
62
|
+
The AI will faithfully read the defined Phases in the ticket and write optimized code while **completely blocking out unnecessary computations for unrelated server logic or sibling modules**. (This mechanism drastically reduces token costs).
|
|
63
|
+
|
|
64
|
+
### [Step 3] Status Review & Closure
|
|
65
|
+
As the AI writes the code, it will simultaneously update the markup checkboxes (`[x]`) inside the ticket. If the agent's session memory limit is approaching, simply leave the ticket file saved, turn off the chat window, open a fresh session, and issue [Step 2] again. The handoff (session transfer) is seamlessly completed.
|
|
66
|
+
Once all steps are accomplished, promote the Phase status to `[Phase Complete]`. Instead of manually typing terminal commands, **you can simply tell your AI chatbot via natural language prompt: "Show me the list of active tickets" or "Archive the completed tickets with reports"**, and the AI will autonomously invoke the CLI to manage them for you.
|
|
67
|
+
To track tickets manually from the terminal, run:
|
|
68
|
+
|
|
69
|
+
```bash
|
|
70
|
+
npx deuk-agent-rule ticket list
|
|
71
|
+
```
|
|
72
|
+
```text
|
|
73
|
+
📦 Agent Tickets (Direct System Scan):
|
|
74
|
+
✅ [TICKET-DEUKUI-Button.md]
|
|
75
|
+
Title: Add Button Component
|
|
76
|
+
Target: DeukUI
|
|
77
|
+
Status: [Complete]
|
|
78
|
+
🔨 [TICKET-ui-refactoring.md]
|
|
79
|
+
Title: Plugin UI Refactoring
|
|
80
|
+
Target: DeukUI
|
|
81
|
+
Status: [In Progress]
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## 🤖 AI Agent Prompting Guide
|
|
87
|
+
|
|
88
|
+
Even after installing and initializing the package, some AI agents (Cursor, Gemini, etc.) might not actively read the rule file (`AGENTS.md`) in a fresh session. **Whenever you start a new chat session, copy and paste the following prompts to force the AI to align with the rules. This effectively eliminates hallucination and accidental scope-creep.**
|
|
89
|
+
|
|
90
|
+
### 1. Force Rule Familiarization (Mandatory)
|
|
91
|
+
> *"Before starting any work, please read the `AGENTS.md` (DeukAgentRules) file at the workspace root from top to bottom. Make sure you fully understand your Identity, the core project rules, and the ticket workflow. Once you have read and understood them, do NOT summarize them; simply reply 'Rules Acknowledged' and await my first instruction."*
|
|
92
|
+
|
|
93
|
+
### 2. Ticket Execution (Recommended)
|
|
94
|
+
> *"Open the recently issued `.deuk-agent-ticket/TICKET-XXX.md` ticket. Restrict all your file exploration, analysis, and modifications STRICTLY to the target submodule path explicitly specified in the ticket. Do not wander into other submodules or accidentally modify unrelated files."*
|
|
95
|
+
|
|
96
|
+
---
|
|
97
|
+
|
|
98
|
+
## ⚙️ CLI Reference & Advanced Options
|
|
99
|
+
|
|
100
|
+
Advanced commands for workflow automation and target control.
|
|
101
|
+
|
|
102
|
+
### Ticket-based Commands
|
|
103
|
+
Instead of manually typing the CLI commands below into the terminal, you can **delegate their execution to your AI chatbot by giving natural language prompt instructions**.
|
|
104
|
+
|
|
105
|
+
| Command | Description / Natural Language Prompt Example |
|
|
106
|
+
|--------|------|
|
|
107
|
+
| `npx deuk-agent-rule ticket create ...` | Generates a new ticket document (accepts `--group`, `--project`) <br>💬 *"Create new ticket (topic: refactor)"* |
|
|
108
|
+
| `npx deuk-agent-rule ticket list` | Lists and displays active tickets (`--archived`, `--all` supported) <br>💬 *"Ticket list"* |
|
|
109
|
+
| `npx deuk-agent-rule ticket use --latest ...` | Returns only the file path of the most recent ticket <br>💬 *"Recent ticket path"* |
|
|
110
|
+
| `npx deuk-agent-rule ticket close ...` | Soft-closes a target ticket by locking its status to completed without moving the file <br>💬 *"Close this ticket"* |
|
|
111
|
+
| `npx deuk-agent-rule ticket archive ...` | Securely moves completed tickets to `archive/` and updates INDEX <br>💬 *"Archive this ticket (attach report)"* |
|
|
112
|
+
| `npx deuk-agent-rule ticket reports` | Lists structurally preserved agent work reports (`reports/`) <br>💬 *"List archived reports"* |
|
|
113
|
+
| `npx deuk-agent-rule ticket migrate` | Migrates legacy LATEST.md structures into indexed module architecture <br>💬 *"Migrate legacy tickets"* |
|
|
114
|
+
|
|
115
|
+
### Advanced Init Options
|
|
116
|
+
| Flag | Default | Description |
|
|
117
|
+
|--------|--------|------|
|
|
118
|
+
| `--non-interactive` | Off | For CI/Scripts. Disables interactive UI and adopts existing `.config.json` |
|
|
119
|
+
| `--interactive` | Off | Forces the interactive setup to reappear even if config already exists |
|
|
120
|
+
| `--cwd <path>` | Current dir | Adjust target workspace root (absolute/relative path) |
|
|
121
|
+
| `--dry-run` | Off | Simulates the execution text in the console without generating/altering files |
|
|
122
|
+
| `--backup` | Off | Safely creates `*.bak` copies of `AGENTS.md` and rule files before overwriting |
|
|
123
|
+
|
|
124
|
+
## Versioning Policy
|
|
125
|
+
Before pushing any core updates/feature changes to this package (`DeukAgentRules`), strictly bump the `version` inside `package.json` and publish it (`npm run sync:oss`).
|
package/bundle/.cursorrules
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
|
-
# Cursor — AGENTS.md is authoritative
|
|
2
|
-
|
|
3
|
-
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.
|
|
4
|
-
|
|
5
|
-
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.
|
|
6
|
-
|
|
7
|
-
Do not assume stacks or repo layouts (microservices, api-gateway, OpenAPI-only workflows) unless they appear in this repository and AGENTS.md.
|
|
1
|
+
# Cursor — AGENTS.md is authoritative
|
|
2
|
+
|
|
3
|
+
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.
|
|
4
|
+
|
|
5
|
+
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.
|
|
6
|
+
|
|
7
|
+
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
CHANGED
|
@@ -1,87 +1,36 @@
|
|
|
1
|
-
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
-
|
|
37
|
-
|
|
38
|
-
## Cost-effective sessions
|
|
39
|
-
|
|
40
|
-
- Prefer short, high-signal answers and patches; avoid filler, long tutorials, and repeating context the user already has unless they ask for depth.
|
|
41
|
-
- One clear objective per session or turn when practical; do not expand scope into unrelated refactors.
|
|
42
|
-
- For read-only or exploratory tasks, summarize and point to paths instead of pasting large blobs.
|
|
43
|
-
|
|
44
|
-
## Delivery, portfolio, and parallel work
|
|
45
|
-
|
|
46
|
-
- 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.
|
|
47
|
-
- 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.
|
|
48
|
-
- 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.
|
|
49
|
-
- 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.
|
|
50
|
-
|
|
51
|
-
## IDE Branding
|
|
52
|
-
|
|
53
|
-
No editor or vendor tool branding in code, docs, README, commits, or published artifacts.
|
|
54
|
-
|
|
55
|
-
## Ticket format
|
|
56
|
-
|
|
57
|
-
When handing work between tools or people, use:
|
|
58
|
-
|
|
59
|
-
```markdown
|
|
60
|
-
## Task: [title]
|
|
61
|
-
### Files to modify
|
|
62
|
-
- path/to/file: [what to change]
|
|
63
|
-
### Design decisions
|
|
64
|
-
- [decision]
|
|
65
|
-
### Constraints
|
|
66
|
-
- [constraint]
|
|
67
|
-
```
|
|
68
|
-
|
|
69
|
-
## Ticket persistence (internal implementation docs)
|
|
70
|
-
|
|
71
|
-
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.
|
|
72
|
-
|
|
73
|
-
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.
|
|
74
|
-
|
|
75
|
-
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.
|
|
76
|
-
|
|
77
|
-
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.
|
|
78
|
-
|
|
79
|
-
Optional last line in the file: e.g. <!-- Ticket (repo-relative): path/from/root.md --> as an HTML comment on the very last line.
|
|
80
|
-
|
|
81
|
-
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).
|
|
82
|
-
|
|
83
|
-
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.
|
|
84
|
-
|
|
85
|
-
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).
|
|
86
|
-
|
|
87
|
-
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).
|
|
1
|
+
<!-- deuk-agent-rule:begin -->
|
|
2
|
+
|
|
3
|
+
# Project Agent Rules
|
|
4
|
+
|
|
5
|
+
## Identity
|
|
6
|
+
|
|
7
|
+
- **핸드오프 저장 후 채팅**: 파일로 남긴 뒤 채팅에 **`Path: \`루트기준/전체/경로.md\``** 형태로 **한 줄**을 반드시 넣어 다음 세션이 동일 파일을 연다.
|
|
8
|
+
- **핸드오프 파일 머리줄(선택)**: 파일 첫 줄에 `**Ticket (repo-relative):** \`경로\`` 또는 동일 경로의 HTML 주석을 두어 검색·스캔에 쓸 수 있다.
|
|
9
|
+
- **플랜 UI(선택)**: 플랜 전용 패널에 같은 문서를 띄우려면, 관리 중인 **multi-ai-workflow** 규칙에 적힌 **선택적 미러 경로**(예: `.cursor/plans/*.plan.md`)에 동일 본문을 둘 수 있다. 정본은 `.deuk-agent-ticket/` 또는 `DeukAgentRules/ticket/`를 유지하고 두 곳 내용을 맞출 것.
|
|
10
|
+
|
|
11
|
+
English sections above are canonical for tooling; this block is a short Korean mirror for the same rules.
|
|
12
|
+
|
|
13
|
+
## Ticket format & Submodule Isolation
|
|
14
|
+
|
|
15
|
+
When handing work between tools or people—especially in an environment with multiple submodules like DeukUI, DeukPack, etc.—you **MUST NOT** use free-form markdown.
|
|
16
|
+
|
|
17
|
+
You **MUST** use the official Ticket Skeleton Template located at:
|
|
18
|
+
`.deuk-agent-templates/TICKET_TEMPLATE.md`
|
|
19
|
+
|
|
20
|
+
By copying this template to `.deuk-agent-ticket/TICKET-XXX.md` (or `LATEST.md`), you ensure that:
|
|
21
|
+
1. The **Target Submodule** is explicitly locked.
|
|
22
|
+
2. The agent is forced to read specific **Module Rules** (e.g., `.deuk-agent-templates/MODULE_RULE_TEMPLATE.md`).
|
|
23
|
+
3. Execution happens in explicit **Phases** to prevent context bleed.
|
|
24
|
+
|
|
25
|
+
## 🔗 Ticket Framework & Execution Strategy
|
|
26
|
+
|
|
27
|
+
When given a ticket, you MUST run commands and write code **strictly within the boundaries** of the `[Target Submodule]` defined in the `TICKET-XXX.md`.
|
|
28
|
+
|
|
29
|
+
1. **Read the Ticket**: Identify the active `.deuk-agent-ticket/TICKET-XXX.md` file.
|
|
30
|
+
2. **Execute Phase**: Process only the checklist for the **Current Phase**. Do not hallucinate or wander into other architectural areas.
|
|
31
|
+
3. **Update Status**: Mark checkboxes (`[x]`) as tasks are completed.
|
|
32
|
+
4. **Archive on Completion**: When all phases are completed, append the execution report or walkthrough markdown natively at the bottom of the ticket under a `## 📜 Execution Report` header, then move the single file to `.deuk-agent-ticket/archive/TICKET-XXX.md`.
|
|
33
|
+
|
|
34
|
+
All Tickets are volatile and strictly local. Do not attempt to version them or mirror them to obsolete plan directories.
|
|
35
|
+
|
|
36
|
+
<!-- deuk-agent-rule:end -->
|
|
@@ -7,20 +7,20 @@ alwaysApply: true
|
|
|
7
7
|
|
|
8
8
|
## Default shape of work
|
|
9
9
|
|
|
10
|
-
- Prefer one PR (or one agent session outcome) = one vertically integrated slice
|
|
11
|
-
- When the user states portfolio, demo, or ship-this-week priority
|
|
10
|
+
- 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.
|
|
11
|
+
- 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.
|
|
12
12
|
|
|
13
13
|
## Parallel branches and file ownership
|
|
14
14
|
|
|
15
|
-
- Assume other branches or developers may be editing the same repo
|
|
16
|
-
- If the user names an owner branch, feature lane, or file ownership (e.g. “UI lane owns components
|
|
17
|
-
- 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.
|
|
15
|
+
- 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.
|
|
16
|
+
- 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.
|
|
17
|
+
- 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.
|
|
18
18
|
|
|
19
19
|
## Refactor discipline
|
|
20
20
|
|
|
21
|
-
- Shrink refactor scope by default
|
|
21
|
+
- **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.
|
|
22
22
|
- Do not use “while we’re here” to rename, reformat, or reorganize unrelated modules.
|
|
23
23
|
|
|
24
24
|
## Interaction with tickets
|
|
25
25
|
|
|
26
|
-
- If a ticket or user message defines Files to modify and Constraints
|
|
26
|
+
- 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.
|
|
@@ -1,18 +1,24 @@
|
|
|
1
1
|
---
|
|
2
|
-
description:
|
|
3
|
-
alwaysApply:
|
|
2
|
+
description: Git 커밋 메시지 — 짧고 의미 있게(저비용 출력)
|
|
3
|
+
alwaysApply: false
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
# Git
|
|
6
|
+
# Git commit messages (agent)
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
커밋 메시지·스테이징 요약을 쓸 때만 적용. **출력은 최소 토큰**, 내용은 **검색·리뷰에 쓸 만한 정보**만.
|
|
9
9
|
|
|
10
|
-
|
|
11
|
-
- Optional type(scope): summary — feat, fix, refactor, docs, chore, etc. Use a single word for scope (directory or module).
|
|
12
|
-
- Body: Only when requested by the user or when changes span multiple topics. Use a maximum of 3 bullet points, each under 80 characters.
|
|
10
|
+
## 형식 (기본)
|
|
13
11
|
|
|
14
|
-
-
|
|
15
|
-
-
|
|
12
|
+
- **첫 줄만**: 명령형, **72자 이내**, 마침표 없음.
|
|
13
|
+
- **선택** `type(scope): summary` — `feat` `fix` `refactor` `docs` `chore` 등; `scope`는 디렉터리·모듈 한 단어.
|
|
14
|
+
- **본문**: 사용자가 요청하거나 변경이 여러 주제일 때만. 그때도 **불릿 최대 3줄**, 각 80자 이내.
|
|
16
15
|
|
|
17
|
-
|
|
18
|
-
|
|
16
|
+
## 쓸 것 / 쓰지 말 것
|
|
17
|
+
|
|
18
|
+
- **쓸 것**: 무엇이 바뀌었는지 한 문장(동작·계약·호환). 위험한 변경이면 한 단어로 표시(`BREAKING` 또는 마이그레이션 한 줄).
|
|
19
|
+
- **쓰지 말 것**: diff 재서술, 파일 목록 나열, “업데이트함/개선함” 같은 빈 말, 이모지, 장문 튜토리얼, 영어·한국어 이중 번역(팀 언어 하나만). 커밋 메시지 제목(Title)에 "sync" 단어 사용 금지 (대신 "release", "update", "apply" 등으로 구체적으로 표현).
|
|
20
|
+
|
|
21
|
+
## 비용
|
|
22
|
+
|
|
23
|
+
- 한 커밋 주제면 **제목 한 줄로 끝낸다.**
|
|
24
|
+
- 스테이징이 크면 제목은 요약하고, 본문은 **사용자가 본문 달라고 할 때만** 추가한다.
|